Kunde haut mir die E-Rechnung um die Ohren. Länge des BT-131 sollte 2 Nachkommastellen haben

[Richard von Eggstätt]

Nach nun sieben Monaten E-Rechnung bei uns, hat uns heute ein Kunde diese zum ersten mal um die Ohren gehaut. Ich glaube zurecht.

Seine Validierung lautet:

Fehler:
[BR-DEC-23]-The allowed maximum number of decimals for the Invoice
line net amount (BT-131) is 2.
Feldinhalte:
BT-131: "14.0500"
BT-131: "3.5042"

Fehler:
[BR-DEC-23]-The allowed maximum number of decimals for the Invoice
line net amount (BT-131) is 2.
Feldinhalte:
BT-131: "14.0500"
BT-131: "3.5042"

Wir haben schon Rechnungen bei den Ländern eingereicht z.B. BW. War problemlos. Die betroffene Rechnung des Kunden habe ich bei der Validierung des Landes BW mal probehalber durchlaufen lassen. Ergebnis: grün.
Auch die Validierung bei https://erechnungs-validator.de/ sagt: alles korrekt.



Und trotzdem könnte der Kunde recht haben, zumal in der Erklärung zu BT-131 es wörtlich heißt:

Der Gesamtpreis wird auf zwei Nachkommastellen gerundet. Sollten Rundungsfehler entstehen, kann im Feld "Rundungsbetrag" (BT-114) in den Rechnungsbeträgen die entsprechende Differenz eingegeben werden.

.xml Anhänge, die wir von Lieferanten bekommen, haben bei BT-131 tatsächlich nur zwei Nachommastellen.
Was nun?

Unsere WaWi ist 1.9.7.1
Da die Suche im Forum dazu nichts ergeben hat, habe ich hier ein neues Thema aufgemacht. Falls eine Lösung existiert, bitte um Hinweis
LG Richard

 

[Richard von Eggstätt]

Habe mich eben mit dem Kunden ausgetauscht. Der Fehler wurde durch Lexware Professional erkannt.

LG Richard

 

[Richard von Eggstätt]

Weitere Information:
Habe die .xml-Datei manuell abgeändert und an sechs stellen die Preise von vier Nachkommastellen auf zwei Nachkommastellen gekürzt und die Datei dem Kunden übergeben.
Abgeändert habe ich bei:
<ram:GrossPriceProductTradePrice>
<ram:NetPriceProductTradePrice>
<ram:SpecifiedTradeSettlementLineMonetarySummation>
So abgeändert hat Lexware Professional des Kunden die .xml-Datei problemlos verarbeitet.
Das zeigt mir, dass hier JTL bei der E-Rechnung nacharbeiten muss, da es bei Lexware Professional zu Konflikten kommt. Dieses Lexware ist weit verbreitet.

LG Richard

 

[Peeters]

Wer sagt, dass Lexware fehlerfrei ist? Schon mal die Datei bei https://erechnungsvalidator.service-bw.de/ validiert?

 

[Richard von Eggstätt]

Ja, hab ich. Das hab ich auch anfangs geschrieben. Die Validatoren nehmen die Datei problemlos an. Ich gehe davon aus, dass das Lexware zu überkandidelt ist aber...

(Beispiel) die Übersicht über die BT-Felder – OZG-RE auf e-rechnung-bund.de kommentiert, BT-131 sollte zwei Nachkommastellen haben, siehe:


Auch die google KI ist der Meinung, es sollen zwei Nachkommestellen sein.
In den .xml-Dateien von JTL sind es aber vier, zumindest in der 1.9.7...
Mir ist nichts bekannt, dass sich das geändert hat.

Ich zeige hier also einen möglichen Konflikt auf, der gebügelt werden muss. Lieber bei zeiten, als später irgend etwas mit der heißen Nadel zu stricken.
Ich verweise hier z.B. auf die Sache aus dem Januar, wo auf mein Hintun hin sich herausgestellt hat, dass die Entwickler hier BT-13 und BT-14 vertauscht haben.
Die Folge war damals eine neue Version der WaWi.

Lexware ist weit verbreitet, zählt irgendwo 500.000 Kunden.
Je mehr Buchhaltungen nun zunehmend die Dateien einlesen werden, was offensichtlich noch wenig verbreitet ist, um so brisanter könnte dieser Konflikt werden.

LG Richard

 

[Peeters]

Ich würde das jetzt auch so verstehen. Muss nur noch JTL entgegenkommen.