Berechnung Einzelposten (Unit-Price, Net-Price)

[Harry Stahl]

Was ist eigentlich bei der Berechnung des Einzelposten für Unit-Price und Net-Price (E-Rechnung) der richtige Variablentyp?

Sollte man hier Float oder Currency verwenden?

Je nach dem, gibt es unterschiedliche Ergebnisse für die Berechnung bei Eingabe eines Bruttopreises und der Berechnung des Nettos daraus:

Delphi-Quellcode:

procedure Tfrm_Main.Button2Click(Sender: TObject);
var
  BruttoD: Double;
  NettoD: Double;
  BruttoC: Currency;
  NettoC: Currency;
begin
  // Mit Double
  BruttoD := 9.99;
  NettoD := BruttoD / 1.19;
  ShowMessage('Double: ' + FormatFloat('0.00', NettoD));  // Ausgabe: 8.39

  // Mit Currency
  BruttoC := 9.99;
  NettoC := BruttoC / (1 + (19 / 100));
  ShowMessage('Currency: ' + FormatFloat('0.00', NettoC));  // Ausgabe: 8.40
end;

Also einmal 8.39 für Net-Price, das andere mal 8.40.

Wenn man Currency verwendet und somit 8.40 ergibt sich hier z.B. bei der Seite PDF-Tools24 das Ergebnis wie anliegend angezeigt.

Also aus dem 9,99 Brutto wird 10,00 Brutto.

Anmerkung: Wenn ich in der Eingabemaske zunächst die 8,39 für den Unit-Price eingebe, dann erhalte ich wie bei mir 9,98 Brutto und das gesammte Rechenergebnis (also mit der Netto-Methode) ist identisch, wie bei mir.

[Sinspin]

Ich arbeite grundsätzlich mit Currency wenn es um Geldbeträge geht. Das was da intern bei einem Double/Float passiert ist schön wenn man Musik abspielen will, hat aber nichts Finanzen zu tuen.
Preise werden immer so lange wie möglich Netto gehalten um Unrechnungsfehler zu vermeiden (die treten natürlich bei allen Datentypen auf, bei Gleitkomma trastischer)

Das FormatFloat scheint bei Float einfach abzuschneiden und nicht zu Runden.
Besser gleich Currency nehmen oder den Floatwert vorher Runden.

[Harry Stahl]

Auch

Delphi-Quellcode:

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.