Datenbanken

Nachdem die allgemeine Hype um den Euro verflogen ist, kommt jetzt auf alle Entwickler die heiße Phase zu. Denn nachwievor sind viele Anwendungen, speziell individuelle Lösungen, nicht komplett an den Euro angepaßt. Dies ist teilweise darauf zurückzuführen, dass manche Probleme der Euro-Umstellung im Detail liegen. Zwei der wichtigsten Aspekte sind hierbei:

• Rundungsdifferenzen, die Kontrollen erschweren
• fachlich bedingte Abweichungen

Beide Komplexe haben eines gemeinsam: Sie liegen außerhalb der Verantwortung des Entwicklers und können nur bedingt vom Entwickler beeinflußt werden. Man kann sich daher nur darauf beschränken, die Regeln exakt einzuhalten und die vorhandenen Fettnäpfchen möglich elegant zu umschiffen.

Problemfeld Rundungsdifferenzen

Das Problemfeld der Rundungsdifferenzen bietet gleich mehrfache Fehlermöglichkeiten auf verschiedenen Leveln.

Auf der untersten Ebene gilt es zunächst die Integerproblematik zu erkennen und deren Schaden zu begrenzen. Die Ursache des Problems bildet das interne Darstellen von Geldbeträgen im Integerformat um Differenzen bei normalen Rechenoperationen zu vermeiden. Kommt jetzt ein bei de Entwicklung nicht vorhersehbarer Euro-Umrechnungsfaktor mit vielen Nachkommastellen ins Spiel, so muß für die eingesetzte Integerarithmetik entsprechend oft nach links geschiftet werden, was dann sehr schnell zu einem Überlauf des Datentyps Integer führt. Diese Gefahr ist auch bei langen Integers gegeben, da der Euro-Umrechnungsfaktor grundsätzlich mit 6 Ziffern angegeben wird. Bei den aktuellen Umrechnungsfaktoren gibt es gleich mehrere, die 5 Nachkommastellen haben, was bedeutet, dass alle Werte um 5 Stellen anch links geschoben werden müssen, was einer Multiplikation mit 100.000 gleichkommt. Da kann es auch bei langen Integers eng werden, wenn große Beträge auftreten.

Integerproblematik

Wege aus dem Delema gibt es an dieser Stelle eigentlich nur einen: Sofern nicht die Genauigkeit reduziert wird, muß auf der algorithmischen Seite sichergestellt werden, das ausreichend viele Stellen verarbeitet werden können. Dies erfordert entweder spezielle Zahlenalgorithmen oder den Einsatz von BCD-Arithmetik, wenn wirklich mit voller Genauigkeit gerechnet werden soll.

Ausweg

Mit dem Euro kommen auf den Entwickler aber auch fachliche Abweichungen zu, die sich zwangsläufig aus den Vorschriften zur Umstellung ergeben. Ein bekanntes Beispiel hierfür ist die Abrechnung der Privatärzte nach der Gebührenordnung des Gesundheitsministeriums. Dort kommt ein Punktwert zum Einsatz, der bisher mit zehntel Pfennige arbeitete, demnächst aber mit tausendstel Cent. Dies ist nicht nur eine Stelle mehr, sondern führt auch bei der Konvertierung zu Rundungsdifferenzen, die sich zwangsläufig aus den Rundungsvorschriften ergeben.

Der einziger Ausweg für den Entwickler besteht hier darin, sicherzustellen, dass die erforderliche Genauigkeit unterstützt wird.

Fachliche Abweichungen

Ein systemimmanentes Problem stellen die Rundungsvorschriften darf. Die offizielle Vorgehensweise zur Umrechnung von Währungen laut EU erfolgt in zwei Schritten:

Zunächst werden alle Beträge nach dem amtlichen Kurs korrekt umgerechnet, der nicht gerundet werden darf, sondern alle Stellen des Umrechnungsfaktors berücksichtigt.

Der sich so ergebende Wert wird dann auf die für die jweilige Währungs gültige Anzeigegenauigkeit umgerechnet und dabei kaufmännisch auf- oder abgerundet. Für Euro oder auch DEM bedeutet dies: auf zwei Stellen hinter dem Komma, wobei bis 4 ab und ab 5 aufgerundet wird.

Rundungsvorschrift der EU

Es wird immer auf den ganzen Cent gerundet!

Merke

Ein Betrag von 15 € entspricht korrekt umgerechnet 29,33745 DEM. Nach der Rundungsregel ergibt sich ein Betrag von 29,34 DEM. Umgekehrt ergeben 30 DEM rein rechnerisch zunächst 15,3387564358 €, die auf 15,34 € gerundet werden.

In beiden Fällen ergibt die Kehrrechnung den korrekten Ausgangswert. Anders wird es jedoch, wenn DEM und Euro vermischt werden, wie ein Beispiel aus der Praxis zeigt.

Das Porto für einen Standardbrief kostet 1,10 DEM oder 0,56 €. Eine auf den ersten Blick völlig korrekte Berechnung. Multipliziert man das ganze jedoch mit 1000 so ergibt sich:

Dies mag zwar Kostensparexperten vorübergehend zu gedanklichen Höhenflügen verhelfen, eine Kontrollrechnung lassen diese Rundungsfehler jedoch zum softwaretechnischen Abenteuer werden. Werden beide Währungen im Laufe eines Arbeitsprozesses gemischt verwendet ohne dass später nachvollziehbar ist, was wann und wie, so lassen sich keine wirksamen Kontrollrechnungen einbauen und man muß sich zwangsläufig damit abfinden, dass eine Kontrolle der Ergebnisse Überraschungen bereit hält. Eine für Entwickler nicht gerade befriedigende Vorstellung, da man letztlich nicht sicherstellen kann, ob die Rundungsdifferenz durch Programmfehler oder durch Rundungen zustande kam. Solange die nationalen Währungen jedoch noch verwendet werden oder zumindest hilfsweise mit angezeigt werden, bleibt dem Entwickler nichts anderes übrig, als dieses Manko zu akzeptieren und entsprechend darauf zu reagieren. Und dies bedeutet, dass eine Anwendung nur in einer Wä#hrung rechnen sollte! Da der Euro letztlich die Bezugsgröße ist, sollten alle Berechnungen in Euro durchgeführt und erst am Ende in eine nationale Währung umgerechnet werden. Zieht man eine Summenbildung über zwei Währungen mit, kommt es zwangsläufig zu Abweichungen, wenn man die daraus resultierenden Endwerte umrechnet.

Beispiel

Als weitere Rundungsvorschrift ist die sogenannte "Bankenregel" zu beachten, die umgangssprachlich auch als "runden zur nächsten geraden Zahl" bezeichnet wird. Es handelt sich hierbei um eine aus dem Bankenbereich stammende praxis, die in die IEEE-Spezifikation Eingang fand und beispielsweise auch vom Coprozessor unterstützt wird. Sie lautet:

Die Ziffer 5 wird abhängig von der Ziffer links vom Dezimalzeichen gerundet. Ist diese Ziffer gerade, so wird die 5 abgerundet, ist die Ziffer ungerade, wird aufgerundet.

Diese auf den ersten Blick unsinnige Konvention findet ihre Begründung darin, dass durch diese Art des Rundens sichergestellt ist, dass die Rundungsdifferenzen sich auch bei vielen Durchgängen nicht zu großen Werten akkumulieren, was jedoch zwangsläufig der Fall wäre, wenn die Ziffer 5 immer aufgerundet würde.

Da es sich bei der Bankenregel um eine offizielle IEEE-Spezifikation handelt, verwenden auch Direktaufrufe des Coprozessors sowie entsprechende Emulationen diese Regel, was zu einer zusätzlichen Abweichung bei Berechnungen führen kann. Vergleiche von Fließkommazahlen sind von daher immer mit Vorsicht zu genießen.

Euro-Konvertierung in Access

Access selbst bietet seit der Version Access 2000 eine interne Konvertierfunktion EuroConvert, die nach den offiziellen Umrechnungsfaktoren Währungswerte umrechnet. Allerdings ist auch diese Funktion mit Vorsicht zu genießen, da es auch hier bei falschem Einsatz der Parameter dieser Funktion zu signifikanten Rundungsfehlern kommen kann.

EuroConvert kann sowohl zwischen einer nationalen Währung und Euro umrechnen als auch zwischen zwei natioalen Währungen indem der Euro als Zwischenwert verwendet wird (Triangulieren). Die Parameter der Funktion lauten:

Rundungsvorschrift der Banken

EuroConvert(number, 
            sourcecurrency, targetcurrency
            [, fullprecision, 
             triangulationprecision])

Im Parameter number ist die Zahl anzugeben, die Sie umwandeln möchten oder eine Referenz auf ein Feld, das die Zahl enthält. sourcecurrency und targetcurrency enthalten jeweils einen Zeichenfolgeausdruck oder eine Referenz auf ein Feld, das eine Zeichenfolge gemäß ISO-Standard als Bezeichnung für die jeweilige Währung enthält.

Die nachfolgende Tabelle stellt die ISO-Bezeichner der aktuellen Euro-Teilnehmer zusammen:

In der vorhergehenden Tabelle legt die Berechnungsgenauigkeit fest, auf welche Währungseinheit das Ergebnis, basierend auf der Umwandlungsgenauigkeit, gerundet wird. Wenn Sie beispielsweise in Deutsche Mark umwandeln, ist die Berechnungsgenauigkeit 2, und das Ergebnis wird auf den nächsten Pfennig gerundet, wobei eine Mark aus hundert Pfennig besteht. Die Anzeigegenauigkeit legt fest, wie viele Dezimalstellen in dem Ergebnisfeld angezeigt werden.

Da diese Vorgehensweise jedoch nicht immer erwünscht ist, legen die beiden optionalen Parameter fest, mit welcher Genauigkeit gerechnet werden soll.

fullprecision ist ein Boolean-Wert, bei dem Wahr (1) die währungsspezifischen Rundungsvorschriften (Anzeigegenauigkeit) ignoriert und den Umwandlungsfaktor mit 6 signifikanten Ziffern ohne anschließende Rundung verwendet. Falsch (0) verwendet die währungsspezifischen Rundungsvorschriften, um das Ergebnis anzuzeigen. Wird der Parameter nicht angegeben, ist der Standardwert Falsch.

triangulationprecision ist ein Integer-Wert größer oder gleich 3, der die Anzahl der signifikanten Ziffern in der Berechnungsgenauigkeit festlegt, die für den Euro-Zwischenwert verwendet wird, wenn zwischen zwei nationalen Währungen umgewandelt wird.

Funktion EuroConvert

Nachfolgende Nullen werden abgeschnitten und bei ungültigen Parametern wird #Fehler zurückgegeben. Sind ISO-Quellcode ISO-Zielcode identisch, wird der Originalwert der Zahl aktiviert, d.h. es erfolgt keine (überflüssige) Umrechnung, die Rundungsfehler verursachen könnte.

Ergebnis der Funktion

Setzt man Währungsfelder ein, mit deren Werte direkt gerechnet wird, ist man gut beraten, die Funktion EuroConvert zu verwenden. Anderenfalls sind bei der internen Darstellung der Geldbeträge als Integers die Genauigkeitsgrenzen exakt auszuloten und ggfs. spezielle Algorithmen zu verwenden, die eine hohe Genauigkeit sicherstellen.

Fazit