Ich baue selbst an Tooling für E-Rechnungen und schaue mir beruflich sehr viele XRechnung- und ZUGFeRD-Dateien an, quer über JTL, Lexware, sevDesk und ein paar Eigenbauten. Dabei wiederholen sich dieselben Fehler, und fast alle fallen erst beim Empfänger oder im Prüflauf auf, nicht in der Vorschau. Der häufigste ist die leere Leistungsbeschreibung pro Position (BT-153). Die Rechnung sieht im Viewer perfekt aus, im XML steht aber kein Positionstext, und dann fällt sie durch die Schematron-Prüfung. Direkt danach kommt die Steuernummer bzw. USt-IdNr des Verkäufers. Oft ist nur eins von beiden im XML, oder eins davon ist leer. Beides gehört rein, BT-31 und BT-32. Der dritte Klassiker sind Rundungsdifferenzen. Wenn die USt pro Position gerundet wird und die Summe anders gerundet wird, geht der Gesamtbetrag um ein paar Cent nicht auf (BR-CO-15). Bei vielen Positionen summiert sich das. Dann die Steuerkategorie. Bei 0 Prozent oder Kleinunternehmer muss die Kategorie stimmen, sonst passt der Satz nicht zur Kategorie. Und beim Import achten viele nicht auf das Datumsformat und den Dezimaltrenner. Ein Punkt statt Komma oder ein falsch erkanntes Datum reicht, und die Datei ist formal falsch. Wichtig fürs Testen: eine Rechnung kann in der PDF-Ansicht perfekt aussehen und trotzdem durchfallen, weil ein Pflichtfeld im eingebetteten factur-x.xml leer ist. Bei reinem ZUGFeRD steckt die XML in der PDF, bei XRechnung ist sie die Datei selbst. Ihr müsst also die XML prüfen lassen, ein Viewer zeigt nur die Optik. Für den Check gibt es den EN-16931-Test, der die KoSIT-Regeln anwendet. Ich habe dafür einen kostenlosen Validator ohne Anmeldung gebaut, Server in Deutschland, Datei nur im Arbeitsspeicher und direkt nach der Prüfung gelöscht: https://e-rechnung-validator.onrender.com Wenn jemand eine kryptische Meldung hat und nicht weiß was sie bedeutet, postet sie hier oder schickt sie mir, ich übersetze sie in Klartext. Am besten ohne echte Kundendaten.
Neu XRechnung/ZUGFeRD: die fünf Fehler, die fast immer durchfallen, und was die Meldung bedeutet
- Ersteller des Themas Saa1001zp
- Erstellungsdatum
Kein Bot, versprochen. Ich schreibe solche Beiträge ohne Stichpunkte, weil eine Liste nach der anderen in einem Forum schnell nach reinkopiert aussieht, und dann liest es eh keiner. Wenn es dich beruhigt, liefere ich die fünf Punkte auch als Aufzählung nach. Wichtiger: hast du gerade eine Datei, die durchfällt, oder eine KoSIT-Meldung, die keiner versteht? Dann geht es hier weiter.
Laut Changelog soll einiges in der 2.2.0 behoben sein:
https://issues.jtl-software.de/issues/WAWI-86642
https://issues.jtl-software.de/issues/WAWI-80914
https://issues.jtl-software.de/issues/WAWI-90657
Zu Rundungfehler, oder 2 statt 4 Nachkommastellen und Beträge international zu formatieren hilft oft das gute alte:
{{ totals.GrossPriceTotalBzwWasAuchImmer | Nummer : '0.00', 'en-US' }}
Fall die MwSt. anders gerundet wird als es in der Wawi Rechnung/PDF steht hilft das gute alte selber Brutto minus Netto rechnen, Hauptsache es ist überall einheitlich:
<ram:CalculatedAmount>{{ totals.GrossPriceTotal | Minus: totals.NetPriceTotal | Nummer: '0.00','en-US' }}</ram:CalculatedAmount>
Und ich weiß nicht ob es nur in unserer Vorlage war oder mal so von JTL kam, aber falls man Zolltarifnummern angeben muss, das:
<ram:ClassCode listID="TS">{{ taric }}</ram:ClassCode>
Da wäre "TS" falsch, es muss "HS" sein.
Zu BT-153 haben wir einfach den Namen genommen:
{%- comment -%} BT-153 [1]{%- endcomment -%}
{%- comment -%} Artikelbezeichnung {%- endcomment -%}
<ram:Name><![CDATA[{{ position.Name }}]]></ram:Name>
https://issues.jtl-software.de/issues/WAWI-86642
https://issues.jtl-software.de/issues/WAWI-80914
https://issues.jtl-software.de/issues/WAWI-90657
Zu Rundungfehler, oder 2 statt 4 Nachkommastellen und Beträge international zu formatieren hilft oft das gute alte:
{{ totals.GrossPriceTotalBzwWasAuchImmer | Nummer : '0.00', 'en-US' }}
Fall die MwSt. anders gerundet wird als es in der Wawi Rechnung/PDF steht hilft das gute alte selber Brutto minus Netto rechnen, Hauptsache es ist überall einheitlich:
<ram:CalculatedAmount>{{ totals.GrossPriceTotal | Minus: totals.NetPriceTotal | Nummer: '0.00','en-US' }}</ram:CalculatedAmount>
Und ich weiß nicht ob es nur in unserer Vorlage war oder mal so von JTL kam, aber falls man Zolltarifnummern angeben muss, das:
<ram:ClassCode listID="TS">{{ taric }}</ram:ClassCode>
Da wäre "TS" falsch, es muss "HS" sein.
Zu BT-153 haben wir einfach den Namen genommen:
{%- comment -%} BT-153 [1]{%- endcomment -%}
{%- comment -%} Artikelbezeichnung {%- endcomment -%}
<ram:Name><![CDATA[{{ position.Name }}]]></ram:Name>
gibt es denn mittlerweile schon eine wawi version, die eine ordentliche e-rechnung generiert. bei 1.11.7 erhalte ich noch immer fehler, wenn ich die rechnung prüfen lasse. oder läuft da bei mir was falsch?
Moin,
wie ich lese hat hier beinahe jeder seine eigenen Probleme mit dem Format 😵
Viele unserer (Industrie-)Kunden lehnen unsere Rechnungen auch noch immer ab - solange diese nicht hier https://www.portinvoice.com valide durchgehen.
Korrekte XML Struktur: Nein
Und ich scheitere gerade an Daten, die ich scheinbar nicht beeinflussen kann:
Warnung: [VD-Valitool-H-024]-Der Wert der im PDF angegebenen Version des hybriden Dokuments passt nicht zur Version des XML-Formates XRechnung 3.0.2 CII.
Warnung: [VD-Valitool-H-025]-Der Wert der im PDF angegebenen Version des hybriden Dokuments soll >>3.0<< sein. Angegeben ist .
Error: [VD-Valitool-H-023]-Der Wert der im PDF angegebenen Version des hybriden Dokuments ist ungültig.
Hat hier jemand vielleicht einen Tipp? Man setzt uns zum 1.1.27 von einigen Partnern die Pistole in den Nacken.
Viele Grüße,
Jürgen
wie ich lese hat hier beinahe jeder seine eigenen Probleme mit dem Format 😵
Viele unserer (Industrie-)Kunden lehnen unsere Rechnungen auch noch immer ab - solange diese nicht hier https://www.portinvoice.com valide durchgehen.
Korrekte XML Struktur: Nein
Und ich scheitere gerade an Daten, die ich scheinbar nicht beeinflussen kann:
Warnung: [VD-Valitool-H-024]-Der Wert der im PDF angegebenen Version des hybriden Dokuments passt nicht zur Version des XML-Formates XRechnung 3.0.2 CII.
Warnung: [VD-Valitool-H-025]-Der Wert der im PDF angegebenen Version des hybriden Dokuments soll >>3.0<< sein. Angegeben ist .
Error: [VD-Valitool-H-023]-Der Wert der im PDF angegebenen Version des hybriden Dokuments ist ungültig.
Hat hier jemand vielleicht einen Tipp? Man setzt uns zum 1.1.27 von einigen Partnern die Pistole in den Nacken.
Viele Grüße,
Jürgen
Das dürfte dieses Ticket sein:
https://issues.jtl-software.de/issues/WAWI-86919
https://issues.jtl-software.de/issues/WAWI-86919
Danke Dir, ich habs dort auch kommentiert - krass, dass das wieder so ein "Auf den letzten Drücker"-Fix werden wird 🙁 hoffe ich zumindest!
Wenn es dir vorerst nur darum geht, die Rechnungen einzureichen, kannst du die Versionsangabe in den XMP-Metadaten des PDFs auch nachträglich korrigieren.
Ich habe das gerade mit einer Rechnung aus unserer Wawi getestet.
Das leere Versionsfeld auf 3.0 gesetzt und anschließend erneut durch Valitool gejagt.
Die PDF-Prüfung war danach vollständig grün, einschließlich PDF/A-3 und XMP-Metadaten.
Ist natürlich nur ein Workaround, bis JTL den Fehler behebt.
Ich habe das gerade mit einer Rechnung aus unserer Wawi getestet.
Das leere Versionsfeld auf 3.0 gesetzt und anschließend erneut durch Valitool gejagt.
Die PDF-Prüfung war danach vollständig grün, einschließlich PDF/A-3 und XMP-Metadaten.
Ist natürlich nur ein Workaround, bis JTL den Fehler behebt.
Ich danke Dir, das ist zwar ganz nett - aber das kann ich mir in der Menge nicht antun, das ist ja Wahnsinn, wenn ich in die automatischen Versandprozesse eingreifen soll.
Es wäre gut wenn es bei dem Ticket (oben) noch ein paar mehr Kommentare gäbe, dass das als Priorität wahrgenommen wird.
Viele GRüße,
Jürgen
Ähnliche Themen
- Wichtig
- Wichtig
- Wichtig