Neu Rundungsfehler in der Rechnung

[deliman]

Genau so hatte ich das auch in Erinnerung, was die Umsetzung bei JTL angeht.

 

[Spielzeugmacher]

Hallo,
selten aber doch macht das System bei mir auch spannende Berechnungen.

Hier ist intressant das sowohl 0% MWSt. als auch 0% Rabatt auf der Rechnung sind und trozdem 2 Cent falsch gerundet wird!
(Pos. 2 331,6667)
Hoffe das JTL dies mit den nächsten Versionen lösen wird.

Werde jezt versuchen dies zu lösen. Vielen Dank für die vielen Ansätze.

 

[frankell]

Den Anhang 124936 betrachten

Ach, Du dickes Ei! Wenn ich das richtig sehe, sind das Positionen mit einer Mange von jeweils 1. Wenn es jetzt Rundungsfehler auf Grund von höheren Mengen wären, ok. Aber das ist ja echt arg.

Hattest Du meine Formeln verwendet? Du könntest sonst auch den E.-Preis so ausgeben:

JTL_DirectQuery("
SELECT CAST(NetPricePerUnit AS MONEY) FROM Report.InvoicePosition WHERE InternalID = "+Str$(InvoicePosition.InternalId)+"
") + " €"

 

[Spielzeugmacher]

Guten Morgen vielen Dank für deinen Code dieser hat sehr geholfen. 🙏

ich habe es jezt mit folgendem gelöst:

LocCurrL$(
  Round(
    ToNumber(
      JTL_DirectQuery(
        "SELECT CONVERT(decimal(18,2), ISNULL(SUM(ROUND(InvoicePosition.TotalGrossPrice,2)),0)) " +
        "FROM Report.InvoicePosition " +
        "WHERE InvoiceInternalID = " + Str$(Report.InternalId)
      )
    ),
    2
  ),
  @InvoiceCulture
)

Ich hoffe das jezt die Richtigen Zahlen rauskommen. (Auf den ersten Blick passt es.)

 

[mh1]

Das Problem mit den Rundungsdifferenzen in den Rechnungsbelegen soll so einfach lösbar sein?

Nein leider lässt sich das nicht so einfach lösen. Aber man kann versuchen durch entsprechende Rundungsregeln den Fehler zu minimieren und ihn im besten Fall unsichtbar zu machen.

Das Problem hat die Ursache in der Verwendung von Gleitkommazahlen, die bestimmte Zahlen nur approximieren können.
Da wurde in der Datenbank schon vieles umgebaut, aber wer weiß an welchen Stellen die Wawi überall Gleitkommaberechnungen durchführt (Steuerberechnungen? Statistiken? Rabatte? Zahlungsdifferenzen...?) 🤔

Das trägt jetzt zwar nichts zur Lösung des Problems in diesem Thread bei, aber vielleicht noch als Info, dass das folgendes absolut richtig ist:

Das ist doch schon seit Jahren ein Mangel, dessen Erledigung von JTL immer auf die Neugestaltung der kompletten Fakturierung verschoben wurde (Rechnung 2.0), soweit ich mich erinnere.

=> kann nur durch einen kompletten "Umbau des Fundaments" gelöst werden.
...und niemand von uns Anwendern der proprietären Wawi kann das Problem lösen (...wohl aber zufriedenstellende Darstellungen erzielen, so wie @Spielzeugmacher )

 

[tobiasgraeber]

@Jürgen Jester @mvh

Möchte mich hier mal dranhängen da wir das gleiche Problem haben. Ihr scheint ja tief im Thema zu sein, insb. mvh, den View-Ansatz finde ich interessant. Mich würde interessieren: Kommt das von dir oder weiß JTL davon? Vielleicht wäre es sinnvoll JTL nochmal genau darauf aufmerksam zu machen?

@Jürgen Jester du schreibst in https://forum.jtl-software.de/threads/rundungsfehler-in-der-rechnung.237959/post-1294547 davon, das lt. JTL das Thema via Ticket 80642, in Bearbeitung sei. Leider gibt es dieses Ticket aber nicht (mehr?), siehe https://issues.jtl-software.de/issues/WAWI-80642

Mit wem von JTL genau hattest du da damals E-Mail Verkehr? Ggf. könnte man denjenigen nochmal auf diesen Thread hier aufmerksam machen oder den Ticket verbleib erfragen?

Außerdem sehe ich noch das Problem, dass wenn man die Vorlagen Anpasst, man das ganze zwar in der Ausgabe irgendwie "zurechtgebogen" bekommt aber innerhalb der WaWi ist ja bspw. dann auch z.B. die Rechnungssumme (z.B. in den WaWi Listen) weiterhin ggf. falsch gerundet. Und, woran man auch denken und wo man auch aufpassen muss: ZugFerd und X-Rechnung müssten dann auch entsprechend "zurechtgebogen" werden...

Wie habt ihr das gelöst? Oder wisst ihr oder sonstjemand generell zum Thema inzwischen schon mehr?

Danke!