Berechnung Einzelposten (Unit-Price, Net-Price)

[Harry Stahl]

Auch

ShowMessage('Currency: ' + CurrToStr (RoundCurrency(NettoC, 2))); // Ausgabe: 8.40

wirft 8.40 aus.

[Sinspin]

8.40 ist ja aber auch richtig. Nimm mal einen Taschenrechner und guck dir mal die Nachkommastellen an.

[Harry Stahl]

Formatfloat rundet auf 2 Stellen.

Die Double-Variable hat den Wert "8,39495798319328" und wird dann auf 8,39 gerundet
Die Currency-Variable (die ja immer nur mit 4 stellen rechnet - d.h. bei jeder Rechenaktion wird das Ergebnis auf 4 Stellen gerundet) hat den Wert ("8,395") und wird dann eben auf 8,4 gerundet.

Mir geht es ja ein wenig um die Frage, ob es Sinn macht mit den genaueren Float-Werten zu rechnen und erst am Ende die Currency-Rundung zu verwenden, oder ob ich alles mit Currency rechne (aber dann eher mit Rundungsfehlern zu tun habe).

Wäre mal schön zu wissen, wie die Validatoren das rechnen.

[Sinspin]

Wichtiger ist eher das man sich überlegt was man speichert. Also was hat mehr Bedeutung.
Im Handel sollte das Netto sein. Also alle internen Berechnungen für Menge, Rabat, etc. laufen mit dem Nettowert. Am Ende die Bruttobeträge ausrechnen und alles zusammen addieren und danach Runden.
Listet man dann die Nettobeträge und die Steuern einzeln auf kann es durch die einzelnen Rundungen der Sätze zu Fehlern kommen.
Das ist aber faktisch nur ein Darstellungsfehler. Entweder einen Rundungsposten mit anegeben oder den Rundungsfehler auf den größten Betrag addieren.

Wir haben es mit großen Beträgen zu tuen, also theoretisch auch großen Fehlbeträgen.
Ich wüsste nicht das wir in den vielen Jahren irgend einen Kunden gehabt hätten der sich über einen Fehlbetrag beklagt hätte.
Ich kann mich auch nur an ein oder zwei Fälle pro Jahr (im Fibu Export) erinnern in denen es mal 1 "Cent" Abweichung gegeben hat.
Es funktioniert also mit Money/Currency und konsequentem Netto.