Neu Wawi 1.6.31.2 - Rundungsfehler bei manchen Aufträgen

[qconq]

Hallo,

bei manchen Aufträgen kommt es unabhängig von genutzter Zahlungsart und gewährtem Rabatt zu Rundungsfehler. Der Gesamtbetrag auf dem geöffneten Auftrag stimmt nicht mit dem in der Übersicht angezeigten überein. Ein ähnliches Problem existiert ja seit einiger Zeit wenn Staffelpreise oder Rabatte gewährt werden nun aber ohne diesen Einfluss.


Geöffneter Auftrag (36,33€ Brutto):


In der Auftragsübersicht (36,32€ Brutto):


Zahlungsfenster:

 

[Roßteutscher]

Ebenso bei der 1.7.8.1. Hier werden in der Übersicht der Aufrtäge der "Auftragswert netto" sowie der "Auftragswert brutto" aufgerundet.

 

[Pinkman]

bei manchen Aufträgen kommt es unabhängig von genutzter Zahlungsart und gewährtem Rabatt zu Rundungsfehler.

das ist schon seit langem so und nicht erst seit der 1.6.
Das liegt leider an der Berechnung wie die Wawi im Hintergrund arbeitet und bei JTL schon Jahre bekannt

 

[mh1]

das ist schon seit langem so und nicht erst seit der 1.6.
Das liegt leider an der Berechnung wie die Wawi im Hintergrund arbeitet und bei JTL schon Jahre bekannt

Trägt nichts zur Lösung des eigentlichen Problems bei, aber vielleicht zum näheren Verständnis:

Es ist leider eine Eigenart der Fließkommaarithmetik, mit der bei weitem ncht nur JTL zu kämpfen hat.
Manche Zahlen, die auf dem Papier der Rechnung ganz harmlos aussehen, weil sie nur endlich viele Nachkommastellen haben, sind vom Computer intern nicht exakt darstellbar, weil sie periodisch werden. Wir benutzen das Dezimalsystem - der Computer rechnet aber im Binärsystem.
Die Dezimalzahl 5,5 sieht der Computer in seinem Binärsystem als 101,1 => alles gut
Aber z.b. die Dezimalzahl 0,1 würde zu 0,00011001100.......... -> hier fangen die Probleme an

Wer Programme schreibt, die mit Geldbeträgen rechnen, sollte daher unbedingt die Finger von Fließkommavariablen lassen, weil Rechnen mit Fließkommazahlen immer nur näherungsweise ist. Das ist meistens zwar kein Problem, weil die Näherung gut genug ist, man muss sich aber des Fehlers bewusst sein, um abwägen zu können.

 

[fibergirl]

Nun ja.
Es gibt in C# den Datentyp "decimal". Dieser hat in der Größe reichlich Luft, arbeitet auf der Basis 10, und verhält sich in den für die Wawi typischen kaufmännischen Zahlenbereichen wie eine Dezimalzahl, nicht wie eine Fließkommazahl.

Die JTL-Wawi wird ja gerade auf C# komplett neu implementiert. Sicherlich wird da für die relevanten Größen Geldbeträge+Berechnungen, Mengen, Gewichte der decimal-Typ verwendet.
Es besteht also die Hoffnung, dass die Rundungsprobleme zumindest innerhalb der Wawi irgendwann der Vergangenheit angehören werden.

Gruß, fibergirl
(die mittlerweile auch unter die C#-Programmierer gegangen ist)

 

[mh1]

Die JTL-Wawi wird ja gerade auf C# komplett neu implementiert. Sicherlich wird da für die relevanten Größen Geldbeträge+Berechnungen, Mengen, Gewichte der decimal-Typ verwendet.
Es besteht also die Hoffnung, dass die Rundungsprobleme zumindest innerhalb der Wawi irgendwann der Vergangenheit angehören werden.

Wird denn im Zuge der JTL Wawi-Sharp dann auch die ganze Struktur der Datenbank überarbeitet und NUMERIC oder MONEY verwendet?
Das so ein großes Umstellungsprojekt angegangen wird hätte ich mir jetzt eher nicht vorstellen können...