kaufmännisch runden

[Furtbichler]

Allgemein wird in der praktischen Anwendung technisch-wissenschaftlicher Auswertung mit Augenmaß hantiert. Das bedeutet, das 3-4 (seltener 5) signifikante Stellen als vollkommen ausreichend erachtet werden, um Kenngrößen darzustellen. 3-4 Stellen bedeutet eine Genauigkeit von 2% - 0.2%. Und das entspricht im wahrsten Sinne des Wortes dem maximal möglichen Augenmaß.

Currency kann hier geeignet sein, muß aber nicht (wegen der festen 4 Nachkommastellen). Man kann schon mit Double/Extended arbeiten und die Ungenauigkeiten des Datentyps in Kauf nehmen, denn diese bewegen sich i.A. weit jenseits der geforderten Darstellungsgenauigkeit. Sofern man also keine aufwändigen Iterationen betreibt oder sich in der Atomphysik tummelt (wo mit sehr großen und sehr kleinen Zahlen hantiert wird), kann man sich auf Double verlassen. Iterationen würden die Rundungsungenauigkeiten 'nach links verschieben' und beim Rechnen mit sehr großen und (absolut) sehr kleinen Zahlen passiert das Gleiche.

Man muss nur wissen, das Vergleichsoperationen immer im Kontext der Genauigkeit durchgeführt werden müssen, in der man sich gerade befindet.

Bei Geldbeträgen ist die geforderte Genauigkeit 1 Cent. Ergo werde ich auf 2 Stellen nach dem Komma runden und Vergleiche so formulieren, das die Ungenauigkeit von 0.5 ct berücksichtigt wird. Also ist ein Wert 0.00$, wenn er kleiner als 0.005$ ist (absolut), und A>B genau dann, wenn A-B > 0.005 ct ist usw. Das reicht vollkommen aus.

Bei der Berechnung von Zinsen, Steuern usw. wird gemäß den Vorgaben des Finanzamts auf Centbeträge gerundet. Wenn nach dem Runden die o.g. Vergleichslogik angewandt wird, kann nichts passieren. Pfennigfuchser können noch den arnof-Trick verwenden, der zwar innerlich wehtut, aber genau die datentypbedingte Ungenauigkeit bedingt, mit der man (im Übrigen in allen Programmiersprachen, die Fließkommazahlen verwenden) leben muss.

Eine Alternative dazu ist der Datentyp 'Currency', der jedoch einen limitierten Wertebereich besitzt und fest vier Nachkommastellen hat. Dafür rechnet man damit punktgenau. Für jegliche Geldberechnungen sollte dieser Datentyp ausreichen, denn 50 Stellen reichen für sämtliches auf der Welt befindliche Geld, egal in welcher Währung.

Allgemein gesehen wäre der BCD-Datentyp hier ideal, aber soweit ich das sehe, existiert hier kein nativer Datentyp in Delphi (in C# existiert 'decimal'). Allerdings kann man sich mit Klassen behelfen, die mit beliebig großen Zahlen umgehen können.