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.