Neu xRechnung validieren
- Ersteller des Themas PatrickSt
- Erstellungsdatum
„Neueste Version“ ist bei der Wawi leider keine belastbare Angabe, weil zwischen Download, installierter Build und ggf. Server/Client-Version schnell Unterschiede entstehen. Am besten einmal die genaue Versionsnummer aus Hilfe -> Über JTL-Wawi posten.
Wichtiger wäre aber die eigentliche Validator-Meldung bzw. der Ausschnitt daraus. Bei XRechnung ist die Fehlermeldung meistens ziemlich konkret, z.B. fehlende BuyerReference/Leitweg-ID, ungültige USt-ID/Steuernummer, fehlende Zahlungsdaten, falscher Ländercode oder ein Problem bei Steuerkategorie/Steuersatz.
Zum Eingrenzen würde ich die exportierte XML einmal durch den offiziellen Validator jagen und hier die konkrete Regelnummer/Meldung posten. Ohne diese Meldung kann man nur raten, weil „XRechnung validiert nicht“ von Stammdaten bis Vorlage/Export alles Mögliche sein kann.
Und bitte auch dazu schreiben, ob es B2G mit Leitweg-ID ist oder normale B2B-E-Rechnung, das macht bei den Pflichtfeldern einen Unterschied.
VG Lukas
Wichtiger wäre aber die eigentliche Validator-Meldung bzw. der Ausschnitt daraus. Bei XRechnung ist die Fehlermeldung meistens ziemlich konkret, z.B. fehlende BuyerReference/Leitweg-ID, ungültige USt-ID/Steuernummer, fehlende Zahlungsdaten, falscher Ländercode oder ein Problem bei Steuerkategorie/Steuersatz.
Zum Eingrenzen würde ich die exportierte XML einmal durch den offiziellen Validator jagen und hier die konkrete Regelnummer/Meldung posten. Ohne diese Meldung kann man nur raten, weil „XRechnung validiert nicht“ von Stammdaten bis Vorlage/Export alles Mögliche sein kann.
Und bitte auch dazu schreiben, ob es B2G mit Leitweg-ID ist oder normale B2B-E-Rechnung, das macht bei den Pflichtfeldern einen Unterschied.
VG Lukas
2.2.1+Sha.907a9c3 wäre die Revision.
Die Exportierte XML haben wir unter "Verkauf" XRechnung..validieren" versucht einzulesen und erhalten entsprechend die Fehlermeldung wie im Bild.
Die entsprechende Nummer ist unter GLN hinterlegt.
Moin Patrick,
2.2.1 ist gut – entscheidend ist die exakte Meldung aus dem Validator (Regel + Zeile), nicht nur „validiert nicht“. Die interne Prüfung unter Verkauf kann strenger oder anders filtern als der KoSIT-/EN16931-Validator.
Exportierte XML einmal extern prüfen (z. B. KoSIT-Validator oder Viewer). Typische Ursachen bei uns: BuyerReference/Leitweg-ID bei B2G leer, USt-IdNr. Format, fehlende Zahlungsmittel-Angaben, GLN/Endpoint-ID passt nicht zum Kundenprofil.
Bitte kurz: B2G mit Leitweg oder B2B, und den Wortlaut der Validator-Meldung (Screenshot reicht). Dann lässt sich gezielt sagen, ob Stammdaten Kunde, Rechnungsvorlage oder Exportprofil.
FAQ E-Rechnung: https://guide.jtl-software.com/jtl-wawi/verkauf/faq-zu-e-rechnungen-in-jtl-wawi/
Die storeSchmi.de · storeSchmi.de – JTL-Servicepartner Platinum
2.2.1 ist gut – entscheidend ist die exakte Meldung aus dem Validator (Regel + Zeile), nicht nur „validiert nicht“. Die interne Prüfung unter Verkauf kann strenger oder anders filtern als der KoSIT-/EN16931-Validator.
Exportierte XML einmal extern prüfen (z. B. KoSIT-Validator oder Viewer). Typische Ursachen bei uns: BuyerReference/Leitweg-ID bei B2G leer, USt-IdNr. Format, fehlende Zahlungsmittel-Angaben, GLN/Endpoint-ID passt nicht zum Kundenprofil.
Bitte kurz: B2G mit Leitweg oder B2B, und den Wortlaut der Validator-Meldung (Screenshot reicht). Dann lässt sich gezielt sagen, ob Stammdaten Kunde, Rechnungsvorlage oder Exportprofil.
FAQ E-Rechnung: https://guide.jtl-software.com/jtl-wawi/verkauf/faq-zu-e-rechnungen-in-jtl-wawi/
Die storeSchmi.de · storeSchmi.de – JTL-Servicepartner Platinum
Also mit dem Quba Viewer kann ich die Datei Problemlos aufrufen und mir wird alles entsprechend angezeigt.
Moin Patrick,
dass Quba die Datei öffnet und anzeigt, heißt nur, dass die XML lesbar ist. Die Anzeige prüft die XRechnung-Regeln nicht. In Quba einmal die Prüfung laufen lassen und hier die Regel-ID posten, am besten denselben Text, den die Wawi unter Verkauf bei XRechnung validieren ausgibt.
Zur GLN: die Leitweg-ID für Behördenrechnungen kommt nicht aus dem GLN-Feld. Am Auftrag braucht es ein eigenes Feld, das exakt Leitweg-ID heißt. Steht die Nummer nur in der GLN, fehlt die Buyer Reference in der XML, und der Validator meckert trotzdem.
Weil es bei beiden Rechnungen derselbe Fehler ist, lohnt parallel ein Blick in die Firmendaten: PLZ, Straße, Ort, Steuernummer und USt-IdNr. Die FAQ listet genau diese Meldungen: https://guide.jtl-software.com/jtl-wawi/verkauf/faq-zu-e-rechnungen-in-jtl-wawi/
Die storeSchmi.de · storeSchmi.de – JTL-Servicepartner Platinum
dass Quba die Datei öffnet und anzeigt, heißt nur, dass die XML lesbar ist. Die Anzeige prüft die XRechnung-Regeln nicht. In Quba einmal die Prüfung laufen lassen und hier die Regel-ID posten, am besten denselben Text, den die Wawi unter Verkauf bei XRechnung validieren ausgibt.
Zur GLN: die Leitweg-ID für Behördenrechnungen kommt nicht aus dem GLN-Feld. Am Auftrag braucht es ein eigenes Feld, das exakt Leitweg-ID heißt. Steht die Nummer nur in der GLN, fehlt die Buyer Reference in der XML, und der Validator meckert trotzdem.
Weil es bei beiden Rechnungen derselbe Fehler ist, lohnt parallel ein Blick in die Firmendaten: PLZ, Straße, Ort, Steuernummer und USt-IdNr. Die FAQ listet genau diese Meldungen: https://guide.jtl-software.com/jtl-wawi/verkauf/faq-zu-e-rechnungen-in-jtl-wawi/
Die storeSchmi.de · storeSchmi.de – JTL-Servicepartner Platinum
Das wäre nun die Meldung die wir bei der Rechnung entsprechend erhalten
Anhänge
Hallo Patrick,
danke für den Screenshot, damit ist es eindeutig: BR-DEC-23 heißt, dass der Nettobetrag jeder Rechnungsposition (BT-131) mit vier statt zwei Nachkommastellen in der XML steht. Das ist ein bekannter Fehler in der JTL-Standardvorlage (WAWI-80914). Die Beträge selbst stimmen, es geht nur um die Formatierung. Eine Meldung pro Position, daher zwei Fehler.
Dass du auf 2.2.1 bist, hilft hier leider nicht: Beim Update tauscht die Wawi bestehende Vorlagen nicht aus. Deine XRechnung-Vorlage (Vorlagenset Rechnung, Reiter "Exportieren") ist vermutlich noch der alte Stand von vor dem Fix.
Weg 1 (empfohlen): Die XRechnung-Vorlage im Vorlagenset neu anlegen, also eine frische "XRechnung 3.0 CII (UNCEFACT)" hinzufügen und die alte entfernen. Seit 2.0.2 bringt die neu angelegte Vorlage die Korrektur mit. Wenn du eigene Anpassungen in der alten Vorlage hast, die vorher sichern.
Weg 2 (alte Vorlage behalten): Vorher bitte den kompletten Inhalt der Vorlage in eine Textdatei kopieren, dann kommst du jederzeit zurück. Und falls der Block bei dir nicht genau so aussieht wie unten (andere Variablennamen, schon '0.00' drin o. ä.), nichts ändern, sondern kurz hier posten, was bei dir an der Stelle steht. Je nach Vorlagenstand sieht das leicht unterschiedlich aus.
Vorlage im Editor öffnen und nach "Gesamtbetrag netto (auf Positionsebene)" suchen. Direkt darunter steht dieser Block:
Den komplett ersetzen durch:
Wichtig: Nicht einfach alle '0.0000' in der Vorlage auf '0.00' ändern, wie man es manchmal liest. Die übrigen Stellen sind Einzelpreise und Mengen, die dürfen mehr Nachkommastellen haben. Wenn du nur die Anzeige kürzt und nicht rundest, bevor summiert wird, kann es außerdem passieren, dass die Positionen in der Summe nicht mehr genau auf den Gesamtbetrag kommen (BR-CO-10). Deshalb erst Round: 2, dann ausgeben und summieren.
Wenn du ZUGFeRD-PDFs verschickst, steckt im Reiter "ZUGFeRD" desselben Sets meist eine zweite Vorlage mit genau demselben Block. Die musst du dann genauso anpassen.
Danach die Rechnung neu exportieren und nochmal validieren, dann sollten beide Fehler weg sein.
Viele Grüße
danke für den Screenshot, damit ist es eindeutig: BR-DEC-23 heißt, dass der Nettobetrag jeder Rechnungsposition (BT-131) mit vier statt zwei Nachkommastellen in der XML steht. Das ist ein bekannter Fehler in der JTL-Standardvorlage (WAWI-80914). Die Beträge selbst stimmen, es geht nur um die Formatierung. Eine Meldung pro Position, daher zwei Fehler.
Dass du auf 2.2.1 bist, hilft hier leider nicht: Beim Update tauscht die Wawi bestehende Vorlagen nicht aus. Deine XRechnung-Vorlage (Vorlagenset Rechnung, Reiter "Exportieren") ist vermutlich noch der alte Stand von vor dem Fix.
Weg 1 (empfohlen): Die XRechnung-Vorlage im Vorlagenset neu anlegen, also eine frische "XRechnung 3.0 CII (UNCEFACT)" hinzufügen und die alte entfernen. Seit 2.0.2 bringt die neu angelegte Vorlage die Korrektur mit. Wenn du eigene Anpassungen in der alten Vorlage hast, die vorher sichern.
Weg 2 (alte Vorlage behalten): Vorher bitte den kompletten Inhalt der Vorlage in eine Textdatei kopieren, dann kommst du jederzeit zurück. Und falls der Block bei dir nicht genau so aussieht wie unten (andere Variablennamen, schon '0.00' drin o. ä.), nichts ändern, sondern kurz hier posten, was bei dir an der Stelle steht. Je nach Vorlagenstand sieht das leicht unterschiedlich aus.
Vorlage im Editor öffnen und nach "Gesamtbetrag netto (auf Positionsebene)" suchen. Direkt darunter steht dieser Block:
Code:
{%- if Report.ExemptFromVAT == 'ExemptFromVATnotEU' or Report.ExemptFromVAT == 'IGL' or Report.ExemptFromVAT == 'ReverseCharge' -%}
ram:LineTotalAmount{{ position.TotalGrossPrice | Nummer : '0.0000', 'en-US' }}</ram:LineTotalAmount>
{%- assign sumOfInvoiceineNetAmountBT131 = position.TotalGrossPrice | Plus : sumOfInvoiceineNetAmountBT131 -%}
{%- endif -%}
{%- if Report.ExemptFromVAT == '' -%}
ram:LineTotalAmount{{ position.TotalNetPrice | Nummer : '0.0000', 'en-US' }}</ram:LineTotalAmount>
{%- assign sumOfInvoiceineNetAmountBT131 = position.TotalNetPrice | Plus : sumOfInvoiceineNetAmountBT131-%}
{%- endif -%}Den komplett ersetzen durch:
Code:
{%- if Report.ExemptFromVAT == 'ExemptFromVATnotEU' or Report.ExemptFromVAT == 'IGL' or Report.ExemptFromVAT == 'ReverseCharge' -%}
{%- assign lineTotalBT131 = position.TotalGrossPrice | Round: 2 -%}
ram:LineTotalAmount{{ lineTotalBT131 | Nummer : '0.00', 'en-US' }}</ram:LineTotalAmount>
{%- assign sumOfInvoiceineNetAmountBT131 = lineTotalBT131 | Plus : sumOfInvoiceineNetAmountBT131 -%}
{%- endif -%}
{%- if Report.ExemptFromVAT == '' -%}
{%- assign lineTotalBT131 = position.TotalNetPrice | Round: 2 -%}
ram:LineTotalAmount{{ lineTotalBT131 | Nummer : '0.00', 'en-US' }}</ram:LineTotalAmount>
{%- assign sumOfInvoiceineNetAmountBT131 = lineTotalBT131 | Plus : sumOfInvoiceineNetAmountBT131 -%}
{%- endif -%}Wichtig: Nicht einfach alle '0.0000' in der Vorlage auf '0.00' ändern, wie man es manchmal liest. Die übrigen Stellen sind Einzelpreise und Mengen, die dürfen mehr Nachkommastellen haben. Wenn du nur die Anzeige kürzt und nicht rundest, bevor summiert wird, kann es außerdem passieren, dass die Positionen in der Summe nicht mehr genau auf den Gesamtbetrag kommen (BR-CO-10). Deshalb erst Round: 2, dann ausgeben und summieren.
Wenn du ZUGFeRD-PDFs verschickst, steckt im Reiter "ZUGFeRD" desselben Sets meist eine zweite Vorlage mit genau demselben Block. Die musst du dann genauso anpassen.
Danach die Rechnung neu exportieren und nochmal validieren, dann sollten beide Fehler weg sein.
Viele Grüße
Da wir aktuell dies erst einpflegen und noch nicht viel angepasst haben an den vorlagen selbst habe ich diese nun einfach neu angelegt. Laut Quba kann diese gelesen werden und es besteht kein Fehler. In JTL kann ich dies weiterhin nicht validieren
