Brutto-Gesamtbetrag wird (wieder) falsch berechnet - 2.0.1

[pannscheck]

Auf Papierrechnungen sind Fehler oftmals nicht aufgefallen.
Zugferd-Rechnungen werden aber geprüft und bei Fehlern abgelehnt.

JTL muss schleunigst reagieren!

 

[mvh]

Die Option wird es vor 2.2 nicht geben, weil diese durch alle Bereiche und Module durchzuschleifen war gar nicht geplant. Und ob in 2.2 die überhaupt kommt - sehr fraglich.

 

[kaefer]

...also ab welcher Version ist dieses Rundungsproblem nun behoben?

Haben schon einige Rückfragen der B2B Kunden zu der Differenz...

möchte nicht auf die aktuellste Version, wenn dort wieder andere große Probleme vorhanden sind 😕

 

[ergowebshop]

...also ab welcher Version ist dieses Rundungsproblem nun behoben?
...
möchte nicht auf die aktuellste Version, wenn dort wieder andere große Probleme vorhanden sind 😕

Willst du eine ehrliche Antwort oder eine geschönte Antwort?
Letztere wäre das "ist in Prüfung und ist in Planung mit der nächsten größeren xyz Version".
Für eine ehrlich Antwort, hui bzgl. Rundung und anderen großen Problemen in der aktuellen Version..., Ehm, wieviel Zeit hast du?

 

[kaefer]

bekommen halt immer wieder von B2B Kunden diese Info über Differenzen

ist nicht schön.

n.b. sind gerade dabei für ebay auf die aktuelle (2.0.6) Designvorlage "EVO" aufzubauen, um die GARAN Siegel mit zu integrieren.
Wollen aber nicht, dass bei einem nächsten Update dies wieder nicht funktionieren sollte?!

 

[neuling-help]

bekommen halt immer wieder von B2B Kunden diese Info über Differenzen

ist nicht schön.

n.b. sind gerade dabei für ebay auf die aktuelle (2.0.6) Designvorlage "EVO" aufzubauen, um die GARAN Siegel mit zu integrieren.
Wollen aber nicht, dass bei einem nächsten Update dies wieder nicht funktionieren sollte?!

Ob du jetzt 2.0.6 oder 2.1.2 hast, ist für das Rundungsproblem schnuppe egal 🙂. Wenn ihr aktuell aktiv an eBay arbeitet, lasst die Finger von 2.1.1 aufwärts und bleibt erstmal auf der 2.0.6.

Wir können eigentlich nur hoffen, dass JTL irgendwann erkennt, welche Priorität solche grundlegenden Themen haben sollten. Korrekte Rechnungsbeträge und ein funktionierendes eBay-Listing gehören für mich schlicht zu den absoluten Basisfunktionen einer ERP.

Umso unverständlicher ist es, wenn parallel immer neue Funktionen und Optionen entwickelt werden, die zusätzliche Abo-Gebühren verursachen, während solche elementaren Fehler teilweise über Monate bestehen bleiben.

 

[neuling-help]

Laut IssueTracker soll das Problem nun behoben sein mit den Versionen: 2.0.7, 2.1.2 und 2.2.2.

https://issues.jtl-software.de/issues/WAWI-90931

Im Changelog von 2.2.2 steht zumindest, dass es behoben wurde. Bei 2.0.7 konnte ich diesbezüglich keine Info entdecken.

Hat jemand von euch schon die Möglichkeit gehabt, dies zu prüfen?

 

[kaefer]

wir haben gestern auf 2.2.2 umgestellt,
aber noch nicht überprüft

 

[neuling-help]

Bei uns sind die Aufträge/Rechnungen wo auf einmal die Rechnungssummen sich erhöht hatten, gleich geblieben 🙁. Das zum Thema, hier wird es einen Fix dazu geben. Konnte jetzt noch nicht prüfen, ob bei neuen Aufträgen weiterhin dieses Problem auftritt. Bin gespannt.

 

[Massgestickt]

Ich habe Version 2.2.2 und es ist immer noch falsch. MwSt. müsste lauten 231,76, also fehlt 1 cent.
Ich habe es auf den Belegen angepasst, dass netto x MwSt. gerechnet wird und dann netto + MwSt.-zahl für den Bruttobetrag. Aber in der Zugpferd-Rechnung ist es dann trotzdem falsch. Und erst die vielen "nicht bezahlten"-1cent Aufträge in meinem System.

 

[wawi-dl]

Rundungsfehler werden sicherlich nicht gefixt, ich denke da muss man die XML anpassen und selbst ausrechnen lassen, dass die Beträge zueinander passen.

 

[Massgestickt]

Ich habe es gestern sogar mithilfe KI geschafft, die XML entsprechend anzupassen. Blöderweise wird dann nicht mehr die E-Rechnung anerkannt! Ist hier ein Fehler drin? Ich wäre wirklich sehr dankbar für eine Hilfe, auch gegen Gebühr, wenn mir jemand wirklich hiermit helfen kann.

1. Umsatzsteuer (TaxTotalAmount)
liquid
<ram:TaxTotalAmount currencyID="{{ Report.CurrencyISO | Trim }}">{{ VATSum | FormatNumber: 'F2', 'en-US' | Trim }}</ram:TaxTotalAmount>
Verwende Code mit Vorsicht.

Falls das immer noch abstürzt, nutzen wir die pure SQL-Variante, bügeln aber über StripNewlines und Trim die unsichtbaren Zeichen aus, die DATEV blockiert haben:

liquid
{% capture queryVat %}SELECT FORMAT(ROUND(COALESCE(TRY_CAST('{{ VATSum }}' AS DECIMAL(18,4)), 0.0), 2), 'F2', 'en-US'){% endcapture -%}
<ram:TaxTotalAmount currencyID="{{ Report.CurrencyISO | Trim }}">{{ queryVat | DirectQueryScalar | StripNewlines | Trim }}</ram:TaxTotalAmount>
Verwende Code mit Vorsicht.


2. Gesamt-Bruttowert (GrandTotalAmount)

liquid
{% capture queryGross %}SELECT FORMAT(ROUND(COALESCE(TRY_CAST('{{ Report.TotalGrossPrice }}' AS DECIMAL(18,4)), 0.0), 2), 'F2', 'en-US'){% endcapture -%}
<ram:GrandTotalAmount>{{ queryGross | DirectQueryScalar | StripNewlines | Trim }}</ram:GrandTotalAmount>
Verwende Code mit Vorsicht.

3. Zahlbetrag (DuePayableAmount)

liquid
{% capture queryDue %}SELECT FORMAT(ROUND(COALESCE(TRY_CAST('{{ Report.TotalGrossPrice }}' AS DECIMAL(18,4)), 0.0) - COALESCE(TRY_CAST('{{ totalPayment }}' AS DECIMAL(18,4)), 0.0), 2), 'F2', 'en-US'){% endcapture -%}
<ram😀uePayableAmount>{{ queryDue | DirectQueryScalar | StripNewlines | Trim }}</ram😀uePayableAmount>