Rundungsfehler

[PepeG]

Irgendwie habe ich ein Rundungsproblem - Version 9.9.894.

Es fehlt 1 Cent:
500 x "Artikel A" je 0,89 Netto / 1,0591 Brutto
Summe "Artikel A": 445 Netto / 529,55 Brutto
1 x Versand 12,50 Netto / 14,875 Brutto
MwSt. Gesamt: 86,92
insgesamt: 457,50 Netto / Brutto 544,42

Es müssten aber 544,43 Brutto sein.
Ich vermute, dass bei 14,875 nicht gerundet wird.


In der Rechnungsübersicht steht eine Gesamtsumme von 544,42€ was auch gedruckt wird.
Wenn ich die Rechnung markiere, wird weiter unten bei Positionen 529,55 & 14,88 in Summe also 544,43 angezeigt.

Öffne ich die Rechnung wird ein VK Brutto für "Artikel A" von 1,06€ angezeigt. Die zweite Position mit 14,88.


Die Verwirrung ist groß...

 

[reneromann]

AW: Rundungsfehler

Tja - und da hat das Problem mit der binären Darstellung zugeschlagen...

0,89 = 0b0,111000111101011100001010 (bei einfacher Genauigkeit, sprich Speicherung als 32-bit-Float)
Zurückgerechnet ergibt das dann aber "nur" 0,8899999 - ergo "weniger" als 0,89.
Multipliziert mit 500 wird's dann nicht besser - denn etwas weniger als 0,89 multipliziert mit 500 ist halt auch etwas weniger als 445,00... [ca. 444,99999285 €]
Wenn man dort nun 12,5 draufaddiert, erhält man 457,49999285 €, ergo etwas weniger als 457,50 €, was dann mit 1,19 multipliziert auch etwas weniger als deine 544,425 € ergibt...

Beim Runden kommt dann die Prüfung, ob x >= 0,005 ist - und die schlägt fehl, weil 0,00499 eben halt kleiner und NICHT glech 0,005 ist.
Ergo: Die CPU macht, was sie machen soll - nur ist hier mal die binäre Darstellung dran Schuld.

Einzige Lösung:
Umstellung ALLER Finanzgrößen von Fließkommazahlen (egal ob 32-bit-Floatingpoint-/Single Precision- oder 64-bit-Floatingpoint-/Double Precision-Darstellung) auf BCD (Binary Coded Decimals). Leider ist jedoch die BCD-Darstellung deutlich speicherintensiver und vor allem deutlich langsamer von CPUs bei der Berechnung; jedoch ist dies z.B. bei Banken Standard!

 

[PepeG]

AW: Rundungsfehler

Vielen Dank für Deine Erklärung!

Das tritt dann ja bei (allen) Fällen mit 0,89;0,99;0,79;0,59 usw. auf.
Man sollte hier grunsätzlich mit 64bit Genauigkeit und nicht mit 32bit rechnen.
Langsamer - bei wie vielen Berechnungen wird das denn spürbar?

...Ist das in jedem anderen Wawi, Buchhaltungsprogramm, Kassenssystem genauso wie hier?
Oder wird da mit 64bit gerechnet?

 

[++chris++]

AW: Rundungsfehler

Auch mit 64bit oder meinetwegen mit nem Gigabit kommen immer mal 1Cent-Rundungsdifferenzen.
Es tritt auch nicht bei allen o.og. Fällen auf, sondern nur vereinzelt. Andernfalls gäbe es hier täglich Meldungen im Forum.

Das Phänomen ist ein generell mathematisch unlösbares Problem und übrigens auch den Finanzämtern bekannt.

 

[reneromann]

AW: Rundungsfehler

@PepeG:
Wie ++chris++ schon schrieb:
Das Problem liegt an der endlichen Genauigkeit der Fließkommadarstellung im Binärsystem und der Umwandlung zwischen den Zahlensystemen. Ob das Problem auch bei anderen Preisen (z.B. 0,69) auftritt, hängt sehr von der binären Darstellung der Zahl ab. Selbst 1/3 ist dezimal nicht vernünftig darstellbar (da periodisch) - bei deutlich mehr Brüchen tritt diese Periodizität im Binärsystem auf.
Der Fehler, den man bei Umwandlung ins Binärsystem machen kann, hängt von der Darstellung ab - bei 64-bit-Fließkommazahlen (Double Precision) werden 53 bit für die Mantisse verwendet, bei 32bit (Single Precision) "nur" 23 bit.
Aufgrund der Darstellung bedeutet dies dann, dass der Fehler bei Single Precision maximal 1/2 * 1/2^24 =~ 3 * 10^-8.
Bei 64-bit-Darstellung dementsprechend 1/2 * 1/2^54 =~ 2,8 * 10^-17...
Wohlgemerkt immer auf den Wert bezogen und nicht absolut.

Bei BCD-Darstellung wird intern nicht mit Fließkommazahlen gerechnet, sondern mit Ganzzahlen - die CPU muss dabei mehrere Schritte nacheinander machen:
1) Komma (Anzahl der Nachkommastellen) "merken"
2) neue Nachkommastellenanzahl berechnen (je nach Operation), ggf. Operanden entsprechend anpassen, in dem Nullen vorne davor oder hinten hinter gesetzt werden
3) BCD-Zahlen stellenweise verarbeiten (je nach Operation und CPU kann auch eine Umwandlung nach Integer erfolgen)
4) Operationsergebnis ggf. in BCD zurückwandeln
5) Komma setzen

Wieviel langsamer BCD-Operationen gegenüber Integer oder Floating-Point-Operationen sind, hängt ganz von der CPU ab - aber es ist meist langsamer als Integer- oder Floating-Point-Operationen, da für Integer-Operationen die ALU spezialisiert ist und für Fließkommaoperationen der sog. mathematische Koprozessor (seit dem Intel Pentium IMMER Teil der CPU) zur Verfügung steht. BCD-Operationen müssen über die ALU abgewickelt werden - jedoch ist dies dabei deutlich langsamer.

 

[marcos software]

AW: Rundungsfehler

summa summarum:

umgehen kannst du es nur schwerlich (bzw. der programmierer zu lasten der ressourcen), die FA kennen die problematik, schreib einen entsprechenden hinweis drunter und gut ist =)
siehe auch: http://forum.jtl-software.de/geloes...wawi/47250-mehrwertsteuer-rundungsfehler.html

gruß,
marc

 

[reneromann]

AW: Rundungsfehler

Na ja - das Problem sollte aber nicht durch solche "halbseidenen" Begründungen "umgangen" werden.

Es gibt nur eine Lösung für das Problem: Die Umstellung sämtlicher Finanzberechnungen auf BCD-Zahlen!

Der Nachteil bei der Berechnungsgeschwindigkeit dürfte gerade bei kleinen und mittelständischen Firmen kaum bemerkbar sein - wahrscheinlich ist ein schlecht eingestelltes Antivirenprogramm oder ein nutzloses Hintergrundprogramm eher der Performance-Killer als die Berechnung mit BCD-Zahlen.
Übrigens: Selbst Banken verwenden BCD-Zahlen - dort wären Rundungsfehler fatal, da dort selbst Fehler im Zehntel-/Hundertstel-/Tausendstelcentbeträge durch die Anzahl der Buchungen sich schnell zu Größenordnungen von einigen 1000 € aufsummieren können.

 

[PepeG]

AW: Rundungsfehler

Danke für die Rückmeldungen, das macht das Thema transparenter.

@JTL: Ist es angedacht, auf double umzustellen oder bleibt das bei single?

@reneromann: genau, das Problem nicht umgehen, sondern langfristig lösen bzw. eindämmen.
Dies wegen der Performance nicht umzustellen, wäre meiner Meinung nach mehr eine Ausrede als ein sinnvoller Ansatz, vor 10 Jahren war es evtl. ein Argument.

...Wenn ich nach "rundungsfehler wawi" google, bekommt man den Eindruck, dass Rundungsfehler nur bei JTL auftreten - was aber natürlich nicht stimmt!!!

 

[reneromann]

AW: Rundungsfehler

Diese Rundungsfehler treten bei vielen Programmen auf - nur das nicht jeder sofort weiß, dass es aufgrund der Fließkommaberechnung auftritt.

Übrigens: Intern wird der Prozessor mit Double arbeiten (Intel arbeitet m.W. in der FPU/Floating-Point-Unit sogar mit 80bit Genauigkeit und "kürzen" erst danach auf 64/32bit ein) jedoch bringt dir dies nichts, wenn in der Datenbank Float verwendet wird. Selbst mit Double wird das Problem nur "verschoben", nicht aber beseitigt.

 

[Manuel Pietzsch]

AW: Rundungsfehler

@JTL: Ist es angedacht, auf double umzustellen oder bleibt das bei single?

Hallo,

wir stellen nach und nach die ganze Wawi um. Ist viel Aufwand, wird sich mit der Zeit aber erledigen. Also etwas Geduld, wir sind dran.

Gruß Manuel

 

[PepeG]

AW: Rundungsfehler

Danke für die Rückmeldungen, hat mir sehr geholfen.