Brutto-Gesamtbetrag wird (wieder) falsch berechnet - 2.0.1

[intrinsicforce]

Wawi 2.0.1
Schon fast vermisst, die Rundungsfehler der Wawi, mal zu viel, mal zu wenig. Diesmal sogar etwas großzügiger. Aus 65,212 wird z.B. 65,23, siehe Screenshot (Bestellung stammt aus JTL Shop 5.7.0, Bestellbestätigungsemail vom Shop summiert auf 65,21). Nettobetrag wird aber noch korrekt ausgegeben.

Der gleiche Auftrag wurde in einer 1.9.x Version betrachtet noch mit dem richtigen Bruttowert 65,21 beziffert, sowohl in Auftragsansicht, Auftragsbestätigung und Rechnung. Wird dann später aus der 2.0.1 Wawi heraus erneut eine Rechnung an den Kunden versendet oder exportiert, hat diese einen anderen Gesamtbetrag (Chaos bei der FiBu, GoBD...)

Nachtrag: Es sind auch Aufträge betroffen, die manuell in der Wawi erstellt werden.

Nachtrag 2: Fehlverhalten ist wie folgt reproduzierbar:
Konstellation 1: 1 Position mit 27,00 EUR netto = 32,13 EUR Brutto (korrekt)
Konstellation 2: 2 Positionen, 22,50 EUR + 4,50 EUR (Summe 27,00 EUR netto) = 32,14 Brutto (falsch)

 

[Javi]

Hi schau das an, könnte evtl dein problem beheben.

https://forum.jtl-software.de/threa...t-z-b-0-01-zahlung-offen.139545/#post-1344854

 

[intrinsicforce]

Hi schau das an, könnte evtl dein problem beheben.

https://forum.jtl-software.de/threa...t-z-b-0-01-zahlung-offen.139545/#post-1344854

Leider nicht, das Problem liegt 100 % an der Wawi. Es sind nicht alle Aufträge betroffen, aber ein großer Teil, der viel Chaos in der Buchhaltung stiften wird.

Wie gesagt, wenn Rechnung mit 1.9.x für Auftrag A erstellt wird, ist der Betrag zB 10.00, wenn die gleiche Rechnung später mit 2.0.1 erneut gedruckt wird, ist der Betrag 10,01. Das hat nichts mit dem Shop zu tun.

 

[Harry_]

Evtl. liegt es daran wie die Steuer berechnet wird.
Jede Position einzeln oder nur die Gesamtsumme, da wird es zu Abweichungen kommen (rechne es mal durch).

 

[Javi]

Leider nicht, das Problem liegt 100 % an der Wawi. Es sind nicht alle Aufträge betroffen, aber ein großer Teil, der viel Chaos in der Buchhaltung stiften wird.

Wie gesagt, wenn Rechnung mit 1.9.x für Auftrag A erstellt wird, ist der Betrag zB 10.00, wenn die gleiche Rechnung später mit 2.0.1 erneut gedruckt wird, ist der Betrag 10,01. Das hat nichts mit dem Shop zu tun.

Hi, wenn nur Bestellungen aus dem Shop betroffen sind, dann liegt der Fehler sehr wahrscheinlich im Shop selbst.

bei uns hat das hier geholfen.
Shop 5.6? Da gibts das hier: https://issues.jtl-software.de/issues/SHOP-9358
In dem Fall kann es helfen in der /includes/src/Cart/Cart.php die Zeilen 1094, 1144 und 1171 von

$total = \round(\round($total, 3), 2);

in

$total = \round(\round($total, 4), 2);

zu ändern.

 

[intrinsicforce]

Hi, wenn nur Bestellungen aus dem Shop betroffen sind, dann liegt der Fehler sehr wahrscheinlich im Shop selbst.

bei uns hat das hier geholfen.
Shop 5.6? Da gibts das hier: https://issues.jtl-software.de/issues/SHOP-9358
In dem Fall kann es helfen in der /includes/src/Cart/Cart.php die Zeilen 1094, 1144 und 1171 von

$total = \round(\round($total, 3), 2);

in

$total = \round(\round($total, 4), 2);

zu ändern.

Sieh dir doch mal das Beispiel vom ersten Post an, habe neue Screenshots hochgeladen. Es sind auch Aufträge betroffen, die nicht vom Shop kommen.

ES IST NICHT DER SHOP

 

[MirkoWK]

Hi,

der zweite Fall oben sind ja 2 Werte, welche wohl erst jeweils gerundet und dann summiert werden. (22,5 * 19% = 4,275 = 4,28 / 4,5 * 19% = 0,855 = 0,86 > ergibt dann 5,14. Dagegen 27 * 19% = 5,13.

Das wird dann wohl einfach anders wie im Shop behandelt.

Viele Grüße
Mirko

 

[intrinsicforce]

Hi,

der zweite Fall oben sind ja 2 Werte, welche wohl erst jeweils gerundet und dann summiert werden. (22,5 * 19% = 4,275 = 4,28 / 4,5 * 19% = 0,855 = 0,86 > ergibt dann 5,14. Dagegen 27 * 19% = 5,13.

Das wird dann wohl einfach anders wie im Shop behandelt.

Viele Grüße
Mirko

Vielleicht rechnet die Wawi neuerdings tatsächlich so, aber die Brutto-Positionswerte sind nicht gerundet in der Datenbank gespeichert - wie man auch auf dem Screenshot sieht.

 

[Harry_]

Erst nachdenken, dann schreiben, danke

Sorry, aber was soll diese Bemerkung? So falsch ist der Ansatz m.E. nicht

 

[intrinsicforce]

Sorry, aber was soll diese Bemerkung? So falsch ist der Ansatz m.E. nicht

Sorry, hatte gehofft es noch rechtzeitig gelöscht zu haben. Bisschen überreagiert. Aber um ehrlich zu sein ist es mir egal, wie genau der Fehler zustandekommt, und es ist nicht meine Aufgabe, das zu prüfen.

JTL haut halt Betas als stable raus wie gewohnt und baut Fehler ein die einfach immer und immer wieder kommen. Oder lässt einbauen, mittlerweile doch auch nur noch am vibecoden. Diese Rundungsdifferenzgeschichten kommen ja regelmäßig wieder in der Wawi (Aufträge, Rechnungen, XRechnung) und im Shop (siehe Suchwort "Rundungsdifferenz", "Rundungsfehler" im Issuetracker).

Ist vielleicht jemand im Forum der diesen Fehler netterweise bestätigen würde damit das Problem auch ernstgenommen wird, bevor es erst im nächsten Quartal oder gar im nächsten Jahr beim Steuerberater auffällt?

edit: Stichwort XRechnung, glaube hier wird ja neuerdings auch auf Positionsebene gerundet... Damit es validierbar ist, da nicht mehr als 2 Nachkommastellen akzeptiert werden. Mal so, mal so! Chaos!

 

[ergowebshop]

Bestätige, hier ist es auch so in 2.0.1, kann man sogar in einen Auftrag packen 5,13+5,14




Erinnert thematisch an diesen Klassiker seit 2013, der alte Freund Rundungsfehler:
https://forum.jtl-software.de/threads/rundungsdifferenzen.100765/page-5

Bzgl. XRechnung kannst du auch Beträge runden, z.B.

{%- for position in Report.InvoicePosition -%}
{{ position.TotalNetPrice | Nummer : '0.00', 'de-DE' }}
{%- endfor -%}

Oder wenn gar nichts hilft direkt was aus der Datenbank abfragen. Nicht schön, aber möglich.

{% capture query -%}
                SELECT TOP (1) irgendwas
                FROM Rechnung.tRechnung
                ...
{% endcapture -%}
{%- assign ergebnis = query | DirectQueryScalar -%}
Ergebnis: {{ ergebnis }}

 

[intrinsicforce]

@ergowebshop danke für die Bestätigung.

Wurde das XRechnungs-Format nicht ohnehin überarbeitet? Wundere mich grade dass wieder Beträge als "Nummer : '0.0000', 'en-US'" ausgegeben werden bei neu hinzugefügter Vorlage.

Der Workaround wird wohl helfen was Rechnungs- und Auftragsdokumente betrifft, aber in der Wawi stehen dann rund 30 % der Aufträge mit Unter- bzw Überzahlung da. Hier muss jedes mal geprüft werden, ob das durch die falsche Berechnung durch die Wawi kommt, oder ob der Kunde tatsächlich zu viel/zu wenig überwiesen hat, und dementsprechend eine Korrektur vorgenommen werden. Sonst gibt's später überall Differenzen bei den Debitorensalden in der FiBu. Stundenlanges ausziffern aufgrund von banalen Softwarefehlern hat mir schon genug Zeit und Geld gekostet...

 

[ergowebshop]

Wurde das XRechnungs-Format nicht ohnehin überarbeitet?

Mehrmals, in der 1.0 von 2017, in der 1.1 von 2018, in der 1.2 und 1.2.1 von 2019, angewendet 2020, in der 2.3.1, lange bevor JTL das auf dem Schirm hatte bzw. angeblich umsetzen wollte, in der 3.0.0 von 2023, in der 3.0.1, in der 3.0.2 die eigentlich nur bis Juli 2025 geplant war.
Und mit EU-Norm EN 16931-1:2026 wird voraussichtlich Mitte 2026 die Version 4.0 veröffentlicht.
Aber weil man damit Marcell D'Avis mäßig noch nicht ausgelastet war gab und gibt es ja auch noch mehrere Zugferd Versionen.

Frag mich nicht was eigentlich gilt mit den Nachkommastellen da, wir machen einfach auf zwei Nachkommastellen und bei internationalen auf en-US.
Aber wie gesagt, ändert ja nichts am ursprünglichen Thema der Wawi Rundung.
Und da haben wir noch garnicht darüber gesprochen ob Rechnung und Rechnungskorrektur genauso runden.

 

[Buk]

Hallo,
also wir haben keinen Shop und haben das gleiche Problem. Zieht sich von Aufträgen in Rechnungen, was jetzt mit unseren B2B Kunden Probleme macht in der Buchhaltung.

 

[intrinsicforce]

Hallo,
also wir haben keinen Shop und haben das gleiche Problem. Zieht sich von Aufträgen in Rechnungen, was jetzt mit unseren B2B Kunden Probleme macht in der Buchhaltung.

Dein erster Beitrag nach 10 Jahren, und das in meinem Thread. Vielen Dank für die Ehre!

 

[weitergehts]

Hallo, gibt es schon was neues zu den falschen Preisen?
Ich habe das gleiche Problem seit dem Update auf 2.0.3. Wie es scheint rundet die WAWI netto auf 2 Nachkommastellen.

 

[Peeters]

Wir verwenden 2.0.3, und JTL verwendet hier die Horizontale Umsatzsteuerberechnung. Diese ist per se also nicht falsch, es gibt halt Vor- und Nachteile.

Horizontale Steuerberechnung
Funktionsweise: Die Steuer wird für jede einzelne Artikelzeile (Position) separat berechnet und kaufmännisch gerundet. Der Gesamtsteuerbetrag ist die Summe all dieser gerundeten Einzelbeträge.
Vorteil: Transparente Darstellung, da der genaue Steueranteil direkt an der Position nachvollziehbar ist.
Nachteil: Die Summe der gerundeten Einzelsteuerbeträge weicht bei vielen Positionen fast immer leicht vom Gesamtbetrag ab, der bei einer Gesamtsummenberechnung herauskäme.

Vertikale Steuerberechnung
Funktionsweise: Zuerst werden alle Nettobeträge (Summe der Netto-Werte) desselben Steuersatzes über die gesamte Rechnung addiert. Die Umsatzsteuer wird erst am Ende auf diese Gesamtsumme aufgeschlagen und gerundet.
Vorteil: Keine Rundungsdifferenzen, da nur einmal am Ende der gesamten Rechnung gerundet wird.
Nachteil: Der ausgewiesene Steuerwert auf Einzelpositionen lässt sich oft nicht exakt auf den Cent genau zurückrechnen (z. B. wenn 19 % aus einer Position aufgeteilt werden sollen).

Rundungsdifferenzen (Beispiel)
Wenn 3 Artikel für jeweils Netto 3,33 verkauft werden, addieren sich diese zu 9,99 netto. Die Mehrwertsteuer beträgt 19%.

Vertikal:
9,99 x 0,19 = 1,8981. Gerundet sind das 1,90.

Horizontal:
3,33 x 0,19 = 0,6327. Gerundet sind das pro Artikel 0,63. Bei 3 Artikeln sind das 3x 0,63 = 1,89.
Ergebnis: Es entsteht eine Differenz von 0,01.

 

[intrinsicforce]

@Peeters Ob Berechnung horizontal oder vertikal erfolgt - es sollte über alle JTL Produkte hinweg und in allen Ansichten einheitlich sein.

 

[GOEKE]

Wir haben das gleiche Chaos.. unfassbar für so eine Software...
müssen das auch in der Datev alles manuel berichtigen, damit dort es stimmt.

 

[neuling-help]

Wir haben das Problem nun seit Wawi 2.0.4 auch. Wie handhabt ihr dieses Problem? Wir hatten Rechungen (nicht bezahlt) noch in der Wawi. Jetzt nach dem Update mussten wir feststellen, als ein Kunde bezahlt hat, dass die Rechnung weiterhin unter Nicht bezahlt aufgeführt wurde. Grund: Jetzt ist der Rechnungsbetrag auf einmal 2 Cent höher. Die PDF Rechnung ist weiterhin mit dem alten Betrag versehen. Einfach 2 cent per Zahlungseingang setzen wird am ende das Problem ja auch nicht beheben, wenn wir alle Infos falsch an Datev übermitteln oder?