Währungen, Umrechnung und Genauigkeit

Alle Geldwerte werden im Programm als 32-bit-Integerwerte (rein ganzahlige Werte) dargestellt und zwar in sogenannten Internen Einheiten (IE).
Die Möglichkeit verschiedene Währungen zu verwalten, wird durch eine Umrechnung in IE realisiert, wobei für jede Währung ein anderer Faktor verwendet wird.
Die Umrechnungen beziehen sich immer auf die Basiseinheit der betreffenden Währung, beim Euro wären das z.B. Cent und der Faktor 100, womit ein Euro 10000 IE entspricht. Für DM wären das Pfennig und der Faktor 51,129, womit eine DM 5113 IE entspricht.
Da der genaue Wert 5112,9 sich nicht als IE darstellen läßt, sondern auf 5113 gerundet wird, ergibt sich bei der Rechnung rückwärts ein Wert von 5113 IE/ 51,129= 1,00002 DM, was natürlich bei der zweistelligen Anzeige wieder als 1,00 DM erscheint.
Da alle Rechnungen mit IE stattfinden, tritt diese Abweichung nur bei der Ein-/Ausgabe der Werte auf und kann sich daher nicht fortpflanzen. Anders gesagt, da die IE auf Hundertstel-Cent genau sind, werden Umrechnungsfehler weggerundet und die Werte stimmen im Rahmen der Eingabegenauigkeit, nämlich in diesem Fall auf den Pfennig. Bei ‘Querauswertungen’ addieren sich diese Abweichungen allerdings doch. Wenn z.B. 1000 Kunden je 1 DEM einzahlen, ergibt sich ein Fehler von 1000 * -0.1 IE = -100 IE = - 1 Ct, bei 1000 Kunden geht hier also 1 Ct verloren, das entspricht 0,001 % des gesamten Betrages. Und wenn die Kunden nun je 100 DEM einzahlen, gehen dann 100 Ct verloren?
Rechnen wir noch einmal:
100 DEM = 10000 Pfg * 51,129 = 511290 IE. Hier geht also gar nichts verloren, weil sich 100 DEM glatt in IE darstellen lassen.
Sollten die Kunden allerdings alle jeweils 101 DEM einzahlen, verschwindet wieder ein Ct. Bestimmen wir den schlimmstmöglichen Fall: Durch die Rundung kann sich höchstens eine Abweichung von plusminus 0.5 IE ergeben, womit wir 5 Ct pro 1000 Kunden als maximale Abweichung erhalten, also 0,005 % maximaler Fehler. Da in der Praxis diese Abweichungen immer plusminus auftreten, wird sich selbst dieser relativ kleine Fehler ausmitteln, so daß durch die Umrechnungsfehler auch keine ‘Drift’ der Einzahlungen auftreten kann. Trotzdem kann sich bei der Umrechnung z.B. von DM auf Euro ein Problem ergeben:
Da der Euro ‘grober’ ist als die DM, 1 Ct also ungefähr 2 Pfg entsprechen, lassen sich Pfennigbeträge nicht eindeutig in Euro umrechnen. Ein Beispiel: 1,32 DEM = 0,6749028 EUR = 0,68 EUR in der Anzeige
0,68 EUR = 1,329969 DEM = 1,33 DEM in der Anzeige Durch die Hin- und Herrechnung der Währungen, wurde in diesem Beispiel also ein Pfennig aufaddiert, genauso kann auch ein Pfennig verschwinden. Dieses Problem könnte in der Euro-Übergangszeit auftreten, wenn die Währungsbasis des Programms öfter umgeschaltet wird, allerdings ausschließlich in der Personenkartei:
Die ursprünglichen 1,32 DEM werden ja als 6749 IE verwaltet und bleiben unverändert, auch wenn sie als 0,68 EUR angezeigt werden. Erst, wenn diese 0,68 EUR wieder als Eingabe gelesen werden, ergibt sich ein Wert von 6800 IE, womit der Pfennig aufaddiert wäre.
Das wird verhindert, indem in der Personenkartei nur veränderte Werte zurückgelesen werden, womit es möglich ist, in der Übergangszeit das gesamte Programm beliebig zwischen den Währungen umzuschalten. Wie man an dem glatten Wert 1 EUR= 10000 IE sieht, ist dieses Programm intern auf Euro ‘geeicht’. Das hat den Vorteil, daß zur Definition einer Währung direkt der Umrechnungsfaktor auf Euro angegeben werden kann, womit sich auch die Kurse von Fremdwährungen, die nicht am Euro ‘festgezurrt’ sind, leicht anpassen lassen.
Weiterhin müssen die Währungszeichen und die Anzahl der Nachkommastellen bekannt sein, sozusagen der Basisfaktor. Die Währung DM hätte also die Definition "DM", "Pfg", "2", "1,95583". "1,95583" ist der Umrechnungsfaktor von Euro auf DM, der in den Beispielen verwendete DM-Faktor von 51,129 ergibt sich bei der Umrechnung von DM auf Euro als Kehrwert des Euro-Faktors mal Stellenwertigkeit der Vorkommastelle (hier 100, da sich die Umrechnung auf den Basiswert der Währung bezieht, also einem Pfg). Der Euro ist mit "Eur", "Ct", "2", "1" definiert, wobei man sieht, daß der interne Faktor von 100 IE = 1 Ct vor dem Anwender verborgen wird. Sonderfälle sind Währungen wie z.B. der Luxemburger Francs, bei denen in der Praxis keine Nachkommastellen angegeben werden, der LUF wird dabei z.B. so definiert: "LUF", "", "0", "40,33997", anhand der Null für die Stellenzahl erkennt der Rechner, daß diese Währung direkter Basiswert ist und der Stellenfaktor von 100 entfällt bei der Umrechnung. Abschließend noch ein Blick auf den Wertebereich unserer Währung: Die Geldwerte IE werden als binärer 32 bit Integerwert verwaltet, womit wir einen Wertebereich von - 214748 EUR bis +214748 EUR zur Verfügung haben - für ein Besonnungskonto und alle Operationen auf Einzelkonten oder Umsätze (Immobilien werden ja nicht im Sonnenstudio verkauft) sicher ausreichend, nur bei additiven Auswertungen wie z.B. Monats- oder gar Jahresumsätze muß ein größerer Zahlenbereich verwendet werden.
Der 'Nachteil' diese eingeschränkten Wertebereiches wird durch das kompakte Zahlenformat und das hohe Tempo von Integer-Berechnungen ganz klar wettgemacht, auch wenn bei der Definition von Berechnungen sorgfältiger als bei Fließkommazahlen auf die Abfolge der Operationen geachtet werden muß.