Zugferd Rechnung Validierungsprobleme (Rundungsdifferenzen Netto/Brutto)

[Antonin123]

Hallo,
ich weiß, dass es bereits Beiträge zur E-Rechnung gibt, allerdings sind diese voll von allgemeinen Fragestellungen und ich möchte hier ein konkretes Problem mit der aktuellen Beta der Zugferd Rechnung ansprechen:

Wir haben eine Rechnung mit einem Artikel, Menge 4, Einzelpreis Brutto 2,20 EUR (wurde so hinterlegt, also kein Nettopreis eingegeben sondern direkt der Bruttopreis) = Gesamtpreis 8.80
In der Zugferd Rechnung wird nun vermutlich wegen dem Nettobetrag und Rundung als GrandTotalAmount 8,81 EUR angegeben, TotalPrepaidAmount 8,80 EUR, DuePayableAmount 0,01 EUR, also wie wenn 0,01 noch als offene Forderung besteht obwohl der Brutto-Gesamtpreis 8,80 EUR ist. Das Problem also: Der Nettopreis 1,8487 EUR wird gerundet zu 1,85 EUR Netto x 4 = 7,40 EUR netto zzgl. 19% = 8,81 EUR. Es müssten entsprechend die Nachkommastellen erhöht werden auf mindestens 4, dass der Gesamtpreis stimmt.
Dies führt bei Valdierung zu:
[BR-CO-10]-Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131).

Aktuell lässt sich das Beta Zugferd ja nicht ändern, deshalb die Frage ob die Fehler bekannt sind und behoben werden? (Falls ja, gibt es eventuell schon ein voraussichtliches Releasedate?)
Vielen Dank

 

[Antonin123]

Nach einigem rumprobieren hier nun das, was zum Fehler führt (aber ohne Lösung):
<ram:SpecifiedTradeSettlementLineMonetarySummation>
<ram:LineTotalAmount>7.3950</ram:LineTotalAmount>

sollte sein: <ram:LineTotalAmount>7.40</ram:LineTotalAmount>
oder folgendes funktioniert auch: <ram:LineTotalAmount>7.3955</ram:LineTotalAmount>
oder auch <ram:LineTotalAmount>7.3951</ram:LineTotalAmount>
Nur nicht mit der 0 am Ende

Änder ich dies manuell, dann wird die Rechnung ohne Fehler valdiert
---

Komischerweise, wenn ich nur 1x den Artikel mit 2,20 anlege und die xrechnung erstelle, weichen beide beträge auch ab, es gibt aber keinen Valdierungsfehler:
<ram:SpecifiedTradeSettlementLineMonetarySummation>
<ram:LineTotalAmount>1.8487</ram:LineTotalAmount>

<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
<ram:LineTotalAmount>1.85</ram:LineTotalAmount>

 

[Steffen80]

Ich häng mich hier mal ran da die Differenz ebenfalls in der X-Rechnung vorhanden ist.

 

[Markus Hütz]

Guten Morgen,

wäre es möglich, dass ihr das im Kundensupport meldet? Dann könnten wir uns das genauer anschauen. Rundungsdifferenzen lassen sich, je nach Aufbau der Daten, leider nicht vermeiden (was summiere ich wann).

Gruß,
Markus

 

[jherchen]

Ja, den Fehler habe ich auch bei einem Kunden....

 

[Steffen80]

Guten Morgen,

wäre es möglich, dass ihr das im Kundensupport meldet? Dann könnten wir uns das genauer anschauen. Rundungsdifferenzen lassen sich, je nach Aufbau der Daten, leider nicht vermeiden (was summiere ich wann).

Gruß,
Markus

Kann ich bei Gelegenheit gerne mal machen.

Problem bei uns mit einen Auftrag wo 10% Rabatt gesetzt wurden.

In der Auftragsansicht werden die Positionen mit 4 Nachkommastellen angezeigt
Summe aller Positionen : 292,7526

In der Zusammenfassung (Auftragswert) mit nur 2 Nachkommastellen:
Gesamtbetrag netto: 292,75
MwSt. 19% 55,63€
Gesamtbetrag brutto 348,38€

in der exportierten X-Rechnung
Summe aller Positionen: 292,75€
Summe Umsatzsteuer: 55,62€
Gesamtsumme: 348,37€


Info zu Artikelpreisen:
Die krumme BruttoSumme der ersten beiden Positionen kommt zustande da der Artikel im Shop bereits 10% Rabatt hat.

 

[Antonin123]

Guten Morgen,

wäre es möglich, dass ihr das im Kundensupport meldet? Dann könnten wir uns das genauer anschauen. Rundungsdifferenzen lassen sich, je nach Aufbau der Daten, leider nicht vermeiden (was summiere ich wann).

Gruß,
Markus

Ich weiss leider nicht genau, ob es tatsächlich an der Rundung liegt oder was genau das Problem ist. Ihr könnt einfach eine Rechnung mit 4x 2,20 EUR brutto anlegen, dann könnt Ihr den Fehler replizieren.

 

[Steffen80]

Ich habe es mal dem Support gemeldet und folgende Antwort erhalten:

vielen Dank für Ihre Anfrage.

Ich habe Ihren Auftrag anhand der vorliegenden Daten auf unserem Testsystem nachgebaut und konnte das Verhalten reproduzieren. Hierbei handelt es sich leider um bekannte Rundungsdifferenzen im Cent-Bereich, die nicht durch die Ausgabe/Vorlage erzeugt werden, sondern durch die Summierung der Positions-Beträge mit dreizehn Nachkommastellen in der jeweiligen Tabelle.

Rundungsfehler im Cent-Bereich lassen sich leider auf Grund von technischen Gegebenheiten bei der Plattform-übergreifenden Verarbeitung von Aufträgen derzeit nicht vollständig vermeiden. Das Thema ist bekannt und wir befinden uns dazu intern in Klärung. Leider handelt es sich dabei um ein technisch sehr umfangreiches Thema, weshalb die Lösung nicht einfach umsetzbar ist.

Trotz der Rundungsdifferenzen, da es hier sicherlich auch Toleranzen gibt, kann die XRechnung dennoch erfolgreich validiert werden. Dafür wurde der folgende Validator verwendet: https://erechnungsvalidator.service-bw.de/

Mit freundlichen Grüßen

Es ist Montag...

 

[Antonin123]

Ich habe es mal dem Support gemeldet und folgende Antwort erhalten:



Es ist Montag...

Hallo,
ich gehe davon aus, dass du das Problem mit den Rabatten gemeldet hast? Diese sollen ja trotzdem validiert werden können. Könntest du bitte antworten, dass das gleiche Problem besteht, wenn man eine 4x 2,20 EUR Brutto Rechnung erstellt und diese mit dem genannten Validator nicht validiert werden kann?
Vielen Dank

 

[Steffen80]

Hallo,
ich gehe davon aus, dass du das Problem mit den Rabatten gemeldet hast? Diese sollen ja trotzdem validiert werden können. Könntest du bitte antworten, dass das gleiche Problem besteht, wenn man eine 4x 2,20 EUR Brutto Rechnung erstellt und diese mit dem genannten Validator nicht validiert werden kann?
Vielen Dank

Ja habe das Problem mit den Rabatten gemeldet und zur Antwort vom Support auch nochmal geschrieben das ich mir sowas ähnliches schon gedacht habe.

Antwort war:

danke für das Verständnis. Wichtig ist es auf jeden Fall, das einmal gegen zu prüfen, da die XRechnung Vorlage neu ist. Das Verhalten tritt aber tatsächlich auch bei anderen Ausgabewegen auf.

insofern gehe ich davon aus, das das Problem auch bei anderen Wegen bekannt ist.

Problem ist halt die Brutto netto Umrechnung und wann man rundet

4,20 Brutto wird zu 3,5294117647 netto (*100/119)

3,5294117647 netto x4 = 14.1176470588 (*119/100)= 16,7999999999

Das gleiche Spiel kannst mit deinen 2,20 machen...
Wenn Deine Rechnung aber nicht validiert werden kann würde ich Dir empfehlen das selber evtl. nochmal zu melden

 

[aend]

Für die XRechnung habe ich das einfach so gelöst, dass keine "krummen" Beträge (4 Dezimalstellen) in den Rechnungspositionen mehr ausgegeben werden, also an der Stelle schon gerundet wird. Damit stimmen die Summen dann auch wieder mit denen im Fuß der Rechnung überein.

Beispiel:

<ram:LineTotalAmount>{{ position.TotalGrossPrice | Nummer : '0.00', 'en-US' }}</ram:LineTotalAmount>

Ggf. müsste man das auch noch bei Postionsrabatten machen. Mal schauen. In allen Rechnungen für diesen Monat passt es erst mal.

 

[Antonin123]

Für die XRechnung habe ich das einfach so gelöst, dass keine "krummen" Beträge (4 Dezimalstellen) in den Rechnungspositionen mehr ausgegeben werden, also an der Stelle schon gerundet wird. Damit stimmen die Summen dann auch wieder mit denen im Fuß der Rechnung überein.

Beispiel:

<ram:LineTotalAmount>{{ position.TotalGrossPrice | Nummer : '0.00', 'en-US' }}</ram:LineTotalAmount>

Ggf. müsste man das auch noch bei Postionsrabatten machen. Mal schauen. In allen Rechnungen für diesen Monat passt es erst mal.

Hallo,
vielen Dank für die Antwort! Leider kann man die Zugferd aktuell nicht abändern, aber wenn man dies mal kann, geht es ggf. ähnlich, deshalb danke fürs teilen!

 

[SHAAN]

Das Rundungsproblem, oder Phänomen, oder vertikalen und horizontalen Rechnungsmethoden im vierstelligen Bereich nach dem Komma, ist seit vielen Jahren bei JTL bekannt. Ich selbst beschäftige mich immer wieder seit 2020 damit.

Jetzt ist es so, dass unsere Rechnungen von einem Geschäftskunden nicht akzeptiert werden, da diese nicht korrekt validiert werden. Der Kunde vereist darauf, dass die PDF Rechnung in deren System eingespielt und automatisch ermittelt wird, ob es sich um eine E-Rechnung handelt oder eine normale PDF Rechnung. Es wird also beim Kunden erkannt, dass in die PDF-Rechnung ein XML eingebunden ist. Da dieses XML nicht korrekt validiert werden kann, wird die Rechnung vollständig abgelehnt, mit der Bitte eine Rechnung zu senden, welche ohne Fehler validiert werden kann, oder eine PDF zu senden, welche nicht im Zugferd Format ist, also keine E-Rechnung. Der Kunde sagt, er habe als Großkonzern keinen Spielraum die Rechnung anders einzupflegen.

Da wir mit der Version JTL 1.9.7 keine Möglichkeit haben Zugferd einfach zu deaktivieren, wissen wir nicht, was wir nun genau tun können und wie wir dem Kunden eine korrekte Rechnung senden?

Hat vielleicht einer dazu eine Idee?

 

[frankell]

Hat vielleicht einer dazu eine Idee?

Ich habe es jetzt nicht getestet, aber es sollte doch immer noch möglich sein, anstelle einer ZUGFeRD-Rechnung eine reine X-Rechnung zu versenden.

Wenn ich die Ausführungen auf https://guide.jtl-software.com/jtl-wawi/verkauf/x-und-zugferd-rechnungen-ausgeben/ richtig verstehe, wird nur dann eine ZUGFeRD-Rechnung ausgegeben, wenn "Vorlage als PDF-Anhang" angehakt ist. Ist das nicht der Fall, sollte man nach wie vor stattdessen über "Hinzufügen - Anhang hinzufügen" reine PDF-Rechnungen (Speichern) als auch reine X-Rechnungen (Export) senden können. In diesen beiden Fällen sind die Vorlagen bearbeitbar und man kann (SQL-Kenntnisse vorausgesetzt) auf andere Datenbank-Tabellen zugreifen und so die Rundung nach den eigenen Bedürfnissen einstellen, wenn das dann überhaupt noch notwendig ist.

 

[Markus Hütz]

Guten Morgen,

zur Not ist die Generierung von ZUGFeRD deaktivierbar: Beta-Feature über die neue Oberfläche aktivieren: Ausgabe.DisableZugferd

Mit Ticket https://issues.jtl-software.de/issues/WAWI-78844 wird die Vorlage für ZUGFeRD dann ebenfalls selber verwaltbar.

Gruß,
Markus

 

[SHAAN]

Vielen Dank @frankell vielen Dank @Markus Hütz

ich habe über die Beta-Feature die Ausgabe deaktiviert. Habe es auch direkt getestet und es scheint zu funktionieren. In der PDF ist keine XML mehr enthalten.
So haben wir Zeit bis alle Kinderkrankheiten ausgerottet sind.

 

[GBK]

Hallo,

das ist ein interessantes Thema. Und was macht man nun, wenn der Kunde seine XML Rechnung haben möchte, aber nicht mit den Werten der PDF Rechnung übereinstimmen aufgrund dieser Rundungsdifferenzen?

Habe mir die Vorlagen mal angesehen und das Problem beginnt ja schon mit Anlegen des Auftrages. Habe hier sowas:
Gesamt Netto (19,00 %) 21,79 €
zzgl. MwSt (19,00 %) 4,14 €
Rechnungsbetrag 25,92

Bei den meisten Kunden ist das kein Problem, solange der Zahlbetrag mit dem Rechnungsbetrag übereinstimmt. Ein Cent Differenz im Nettobetrag wird da schnell übersehen. Aber größere Firmenkunden meckern da gerne mal. So wie ich nun einen Kunden hier habe, der möchte, dass die XML Rechnung entsprechend angepasst wird. Denn dort ist der Gesamtbetrag 25,93. Was ja mit Netto + MwSt passt. Was kann ich da nun machen?

Beste Grüße, Marco

 

[SHAAN]

Guten Morgen,

zur Not ist die Generierung von ZUGFeRD deaktivierbar: Beta-Feature über die neue Oberfläche aktivieren: Ausgabe.DisableZugferd

Mit Ticket https://issues.jtl-software.de/issues/WAWI-78844 wird die Vorlage für ZUGFeRD dann ebenfalls selber verwaltbar.

Gruß,
Markus

Moin Markus,

wir haben nun die Version JTL 1.10.10.3 und ich wollte ZUGPeRD mit "Ausgabe.EnableZugferd" über BETA-Features wieder aktivieren, aber es klappt nicht. Dort steht zwar, dass die Ausgabe aktiviert ist, aber es erfolgt keine ZUGFeRD Ausgabe´. Habe ich etwas vergessen.