Offen Rechnungen im ZUGFeRD Format

Status
Es sind keine weiteren Antworten möglich.

Aspidoras

Gut bekanntes Mitglied
28. April 2015
239
7
Hallo zusammen,

in unserem Fall muss für den Kunden das XML an eine vorgegebene E-Mail-Adresse gemailt werden.
Wie kann automatisiert entschieden werden, ob er die normale Rechnungsmail bekommt oder eine Mail mit XML-Anhang?
(Ich gehe davon aus - in Rechnung Mail bearbeiten die XML als Ausgabeprozess anhängen?)

Bzw. ... Wie würdet Ihr das machen?


VG Frank
 

Gual61

Sehr aktives Mitglied
13. Juli 2009
449
33
@Manuel Pietzsch

Hallo Manuel, ich muss leider meine Aussage zurücknehmen. Das was vor ein Paar Wochen als gültig erkannt wurde (nur die fehlende Leitweg-ID wurde moniert) wird jetzt als ungültig erkannt

Unbenannt.PNG

Hier was in der Hilfe vom ZRE steht

Für die Ausstellung von elektronischen Rechnungen an die Bundesverwaltung ist grundsätzlich der Standard XRechnung in der jeweils aktuellen Fassung zu verwenden. Zusätzlich kann jeder andere Standard verwendet werden, wenn dieser den Anforderungen der europäischen Norm für die elektronische Rechnungsstellung (EN-16931), der E-RechV und den Nutzungsbedingungen der Rechnungseingangsplattformen des Bundes entspricht.
Das ZUGFeRD 2.1.1 Profil „XRechnung“ erfüllt grundsätzlich die Anforderungen und ermöglicht das Einreichen von Rechnungen über die Plattformen des Bundes.

Kannst du da weiter helfen?
Vielen Dank und Grüße
Gual
 

Manuel Pietzsch

JTL-Wawi
Mitarbeiter
2. Januar 2012
2.851
1.015
Hückelhoven
Hi Zusammen,

wir sind da direkt mit einem Kunden in Kontakt. Ich denke hier wird das UBL Format erwartet, wir gehen aber auf CII mit der Vorlage hier im Forum.
Demnach muss ich wahrscheinlich zurücknehmen was ich oben geschrieben hab und mich um eine UBL Vorlage kümmern. Sobald ich da mehr weiß melde ich mich hier und wenn es eine Vorlage für UBL gibt erfahrt ihr das als erstes hier :)

Gruß und gerne mehr Feedback

Manuel
 

JTL_fwenzl

WMS Entwickler
Mitarbeiter
15. Dezember 2017
561
181
Hürth
Hallo zusammen,

s. auch meine vorherigen Posts.

Unsere Vorlage ist eine XRechnung in der aktuellen Version!!
Würden wir dieses XML in ein PDF einbetten dann wäre es Zugferd.

Das Format entspricht den Vorgaben der deutschen Behörden.
Aber hier gibt es viel Spielraum für individuelle Anforderungen, je nach Bundesland, Branche usw.

UBL darf nicht zwingend gefordert werden! Wir haben uns die entsprechenden Richtlinien natürlich angesehen.

Welchen Fehler hat der Kosit Validator denn ausgegeben?

Gruß,
Frank
 
Zuletzt bearbeitet:

Gual61

Sehr aktives Mitglied
13. Juli 2009
449
33
@JTL_fwenzl

Moin Frank,
Das ZRE des Bundes hat mir kein Fehler ausgegeben, ausser "kein gültiger Format erkannt"
Ich hatte jedoch ein Test mit einer Fake Rechnung vor ein Paar Wochen gemacht (das war die Vorlage mit dem "en-en" Fehler) und da hatte er mir nur das fehlende Leitweg-Id gemeckert.
Entweder wurde seitens des ZRE was geändert oder es hat sich einen Fehler in die Exportvorlage eingeschlichen.
Ich schaue ob die "alte" exportvorlage gespeichert habe und probiere es nochmal.

Grüße
Gual
 

JTL_fwenzl

WMS Entwickler
Mitarbeiter
15. Dezember 2017
561
181
Hürth
Hallo Gual,

ich probiere das Montag auch mal selbst aus. Das das Format komplett ungültig ist, kann eigentlich nicht sein.

Dieser Validator von kosit ist sehr kompliziert.

Die XRechung-Spezifikation wird jedes halbe Jahr aktualisiert und es muss immer die aktuelle Version verwendet werden.

Daher möchten wir es vermeiden mehrere Vorlagen dafür zu haben, da diese alle regelmäßig aktualisiert werden müssten.

Gruß,
Frank
 

JTL_fwenzl

WMS Entwickler
Mitarbeiter
15. Dezember 2017
561
181
Hürth
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: mitlaser

Manuel Pietzsch

JTL-Wawi
Mitarbeiter
2. Januar 2012
2.851
1.015
Hückelhoven
Hi Freunde,

ich habe die Vorlage jetzt mit dem Kosit Validator geprüft und nochmal angepasst. Das ist der Validator den auch die deutsche Bahn benutzt.

Im Anhang findet ihr die aktuelle Vorlage.

1606831943738.png

Gruß und Danke fürs Feedback

Manuel
 

Anhänge

  • Rechnung_XRechnung 1.2 CII (UNCEFACT) Stand 01.12.2020_Exportieren.vlg
    6,2 KB · Aufrufe: 208

gutberle

Sehr aktives Mitglied
29. März 2011
1.292
395
Hallo Manuel, hallo JTL,

erst einmal vielen Dank an Dich und Euch, dass ihr Euch diesem super-wichtigen Themas angenommen habt. Gelinde gesagt hat mir die Vorlage Ende des Jahres den Kopf gerettet, da gleich ein paar meiner ÖR Kunden meine PDF Rechnungen zurückgewiesen haben und ich schon das Schlimmste befürchtete, es mit der Vorlage dann aber echt "smooth" ging.

Ich habe jetzt erste Erfahrungen mit der Vorlage gemacht und bekomme von meinen Kunden fast durchgängig zurückgemeldet, meine XRechnungen würden meine Bankverbindung gleich zwei Mal ausweisen und deren automatischer Leseprozess würde eine Fehlermeldung ausspucken, das Ganze aber dennoch korrekt einlesen und verarbeiten.

In der XML Datei finde ich bei den Zahlungsangaben meine IBAN Nummer tatsächlich 2x angegeben, kann aber in Unkenntnis des XRechnungsformats nicht sagen, ob das OK ist oder es daran liegt. Ich habe mir meine XRechnungen aber auch mit dem Viewer https://xrechnung.psp.eu/ der auf den von der KoSIT veröffentlichten Informationen basiert angeschaut und auch dort wird die IBAN im gleichen Feld "Zahlungsangaben > Überweisung > IBAN" doppelt aneinandergehängt angezeigt.

Hier einmal ein Snippet aus einer meiner mit der 1.5.38.0 erzeugten XRechnungen, mit den IBANs unkenntlich gemacht.

XML:
<!-- *********************************************************************************************** -->
    <!--                             ZAHLUNGSANGABEN                                                     -->
    <!-- *********************************************************************************************** -->
    <ram:ApplicableHeaderTradeSettlement>
    
      <ram:PaymentReference><![CDATA[]]></ram:PaymentReference>     <!-- Zahlungsreferenz -->
      <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>      <!-- Währung -->
    
      <ram:SpecifiedTradeSettlementPaymentMeans>
        <ram:TypeCode>57</ram:TypeCode>
        <!-- Zahlungsart -->
        <ram:Information><![CDATA[]]></ram:Information>
        <ram:PayeePartyCreditorFinancialAccount>
            <ram:IBANID>DE00 0000 0000 0000 0000 00</ram:IBANID>
            <ram:AccountName>Sparkasse Mittelerde</ram:AccountName>
            <ram:ProprietaryID>DE00 0000 0000 0000 0000 00</ram:ProprietaryID>
        </ram:PayeePartyCreditorFinancialAccount>
      </ram:SpecifiedTradeSettlementPaymentMeans>

Ich würde mich freuen, wenn Ihr einmal danach schauen könntet, ob hier was im Argen liegt.

Danke und viele Grüße,
Marie
 

deliman

Sehr aktives Mitglied
13. Februar 2016
961
116
Hallo,

muss es da nicht auch zwingend ein Gutschriftformat für geben oder werden Gutschriften/Rechnungskorrekturen dann wieder als normale PDF Dokumente akzeptiert? Nur falls das mal nötig sein sollte...
 

madsnake

Aktives Mitglied
15. Januar 2017
65
23
Ich habe noch eine Modifikation gemacht. Die Kundenbestellnummer wird bei uns als Auftragsattribut geführt oder als externe Auftragsnummer. Ohne die ist eine Zuordnung beim Kunden nicht möglich. Da wir uns die Arbeit sparen wollen die Auftragsnummer immer in die Bemerkungen oder andere freie Felder zu schreiben habe ich da Script etwas modifiziert.

So sieht es derzeit aus, es wird per SQL unsere Wawi Auftragsnummer über die vorhandene RechnungsID ausgelesen:

XML:
<ram:BuyerOrderReferencedDocument>

        <ram:IssuerAssignedID>

          {% capture query -%}

          SELECT tBestellung.cBestellNr AS Auftragsnummer

          FROM dbo.trechnung

          JOIN dbo.tBestellung ON trechnung.tBestellung_kBestellung = tBestellung.kBestellung

          WHERE trechnung.kRechnung = {{ Report.InternalId | SqlEscape }}

          {% endcapture -%}\

          {% assign result = query | DirectQueryScalar -%}\

          <![CDATA[{{ result }}]]>

        </ram:IssuerAssignedID>

      </ram:BuyerOrderReferencedDocument>

Das ist natürlich völlig unsinnig da die Kunden eigene Bestellnummern vorgeben und sind diese nicht vorhanden wird die Rechnung im besten Fall abgelehnt oder es kommt einfach kein Geld bis die Mahnung folgt.

Deshalb erstmal die Abfrage ob unsere Kundenauftragsnummer als Auftragsattribut vorliegt, andernfalls die Externe Bestellnummer

XML:
<ram:BuyerOrderReferencedDocument>
        <ram:IssuerAssignedID>
          {% capture query -%}
            SELECT  TOP(1) BuyerOrderReferencedDocument.cValue
            FROM dbo.trechnung
            JOIN
            (   
                SELECT  tBestellungAttribute.kBestellung,
                        CASE WHEN tBestellungAttribute.cName = 'Kundenauftragsnummer' THEN 2 ELSE 1 END AS nPriority,
                        tBestellungAttribute.cValue
                FROM dbo.tBestellungAttribute
                WHERE   tBestellungAttribute.cName IN ('Kundenauftragsnummer', 'BuyerOrderReferencedDocument')
                        AND LEN(ISNULL(tBestellungAttribute.cValue, '')) > 0
                        
                UNION ALL
                
          SELECT tBestellung.kBestellung, 3 AS nPriority, tBestellung.cInetBestellNr AS cValue
          FROM dbo.trechnung
          JOIN dbo.tBestellung ON trechnung.tBestellung_kBestellung = tBestellung.kBestellung
          WHERE trechnung.kRechnung = {{ Report.InternalId | SqlEscape }}
                
                UNION ALL
                
          SELECT tBestellung.kBestellung, 4 AS nPriority, tBestellung.cBestellNr AS cValue
          FROM dbo.trechnung
          JOIN dbo.tBestellung ON trechnung.tBestellung_kBestellung = tBestellung.kBestellung
          WHERE trechnung.kRechnung = {{ Report.InternalId | SqlEscape }}

            ) AS BuyerOrderReferencedDocument ON trechnung.tBestellung_kBestellung = BuyerOrderReferencedDocument.kBestellung
            WHERE trechnung.kRechnung = {{ Report.InternalId | SqlEscape }}
            ORDER BY BuyerOrderReferencedDocument.nPriority ASC
          {% endcapture -%}\
          {% assign result = query | DirectQueryScalar -%}\
          <![CDATA[{{ result }}]]>
        </ram:IssuerAssignedID>
      </ram:BuyerOrderReferencedDocument>


Vielleicht kann ja jemand was damit anfangen...
 
  • Gefällt mir
Reaktionen: Peter B.

madsnake

Aktives Mitglied
15. Januar 2017
65
23
Ich habe jetzt erste Erfahrungen mit der Vorlage gemacht und bekomme von meinen Kunden fast durchgängig zurückgemeldet, meine XRechnungen würden meine Bankverbindung gleich zwei Mal ausweisen und deren automatischer Leseprozess würde eine Fehlermeldung ausspucken, das Ganze aber dennoch korrekt einlesen und verarbeiten.

In der XML Datei finde ich bei den Zahlungsangaben meine IBAN Nummer tatsächlich 2x angegeben, kann aber in Unkenntnis des XRechnungsformats nicht sagen, ob das OK ist oder es daran liegt. Ich habe mir meine XRechnungen aber auch mit dem Viewer https://xrechnung.psp.eu/ der auf den von der KoSIT veröffentlichten Informationen basiert angeschaut und auch dort wird die IBAN im gleichen Feld "Zahlungsangaben > Überweisung > IBAN" doppelt aneinandergehängt angezeigt.

Hier einmal ein Snippet aus einer meiner mit der 1.5.38.0 erzeugten XRechnungen, mit den IBANs unkenntlich gemacht.

XML:
            <ram:IBANID>DE00 0000 0000 0000 0000 00</ram:IBANID>
            <ram:AccountName>Sparkasse Mittelerde</ram:AccountName>
            <ram:ProprietaryID>DE00 0000 0000 0000 0000 00</ram:ProprietaryID>

Meiner Ansicht nach ist der Tag ram:proprietaryID nicht nötig. Laut aktuellem Standard reicht für die Zahlungen im SEPA Raum die IBAN aus. Kannst du einfach aus kommentieren oder löschen.
 
  • Gefällt mir
Reaktionen: gutberle

madsnake

Aktives Mitglied
15. Januar 2017
65
23
Die Rechnung wurde anstandslos geprüft, angenommen und bereitgestellt. Sollte sich daran noch etwas ändern werde ich mich melden.
 
Status
Es sind keine weiteren Antworten möglich.

Ähnliche Themen