{"id":55000318,"date":"2016-10-01T00:00:00","date_gmt":"2020-06-24T16:34:57","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=318"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Waehrungen_runden","status":"publish","type":"post","link":"https:\/\/access-basics.de\/index.php\/Waehrungen_runden.html","title":{"rendered":"Währungen runden"},"content":{"rendered":"

Im Finanzsektor wird alles sehr genau genommen. Wird über kleinere Rundungsfehler an anderer Stelle gern einmal hinweggesehen, so sind hier Inkonsistenzen in der Regel absolut inakzeptabel. Einzelne Cent-Beträge können sich über Millionen von Datensätzen zu größeren Summen aufaddieren. Wohin Sie genau schauen müssen, um solche Umstände zu vermeiden, untersuchen die folgenden Ausführungen.<\/p>\n

Beispieldatenbank<\/h2>\n

Die Beispiele dieses Artikels finden Sie in der Datenbank 1605_Runden.accdb<\/b><\/p>\n

Geldbeträge im Tabellenentwurf<\/h2>\n

Für Zahlen mit Nachkommastellen kommen unter Access im Prinzip vier Datentypen infrage: Single<\/b>, Double<\/b>, Currency<\/b> und Decimal<\/b>, also Fließkommazahl einfacher und doppelter Genauigkeit, sowie Währungs- und Dezimaltyp.<\/p>\n

Single<\/b> scheidet wegen der geringen Genauigkeit aus. Hier werden zur Speicherung nur vier Bytes verwendet, während der Double<\/b>-Typ acht Bytes benötigt. Wie groß der Unterschied letztlich ist, können Sie mit einem kleinen Test im VBA-Direktfenster ermitteln. Lassen Sie sich die Ergebnisse dieser beiden Zeilen ausgeben:<\/p>\n

  CSng (Now)\r\n CDbl (Now)<\/pre>\n
Die Funktion Now<\/b> gibt das aktuelle Datum samt Uhrzeit aus, wobei diesem Date<\/b>-Typ tatsächlich ein Double<\/b>-Wert unterliegt. CSng<\/b> wandelt den Wert in einen Single<\/b>-Typ um, CDbl<\/b> in einen Double<\/b>-Typ. Sie erhalten nun etwa<\/p>\n
42516,4 (Single)\r\n42516,4020486111 (Double)<\/pre>\n
Wären dies Geldbeträge, so betrüge die Differenz bereits circa 0,2 Cent!<\/p>\n
Die große Zahl an Nachkommastellen lässt Double<\/b> als für Währungen geeignet erscheinen. Doch immerhin muss es einen Grund geben, warum der Typ Currency<\/b> zusätzlich zur Verfügung steht. Einerseits führt sein Einsatz dazu, dass in Tabellen auch gleich automatisch das Währungszeichen erscheint. Zudem ist die Zahl der Nachkommastellen gleich zwei. Andererseits speichert Currency<\/b> aber Zahlen auch nach einem anderen System. Liegt dem Double<\/b>-Typ mathematisch ein Exponentialsystem zugrunde, hantiert Currency<\/b> mit einer festen Zahl von ganzzahligen Stellen, nämlich 19<\/b>. Die Umwandlung in einen Fließkommatyp geschieht hier rein optisch durch Setzen des Kommas an die viertletzte Stelle, also über Division der Ganzzahl durch 10.000. Ergo stehen grundsätzlich vier Nachkommastellen zur Verfügung, während bei Double<\/b> und Single<\/b> die Zahl der Nachkommastellen variabel ist und von der Größe des Betrags abhängt.<\/p>\n
Decimal<\/b> schließlich ähnelt im Ergebnis Currency<\/b>, weil der angezeigt Wert sich durch Division mit einer Zehnerpotenz ergibt. Die Genauigkeit ist sogar noch höher, als bei Currency<\/b>. Doch auch hier gilt das gleiche, wie bei Double<\/b> und Single<\/b>: Die Anzahl der Nachkommastellen ist variabel. Außerdem kann VBA mit diesem Datentyp schlecht umgehen. Eine Variable vom Typ Decimal<\/b> lässt sich erst gar nicht deklarieren! Der Typ scheidet damit für Währungsrechnungen weitgehend aus.<\/p>\n
Für eine empirische Studie wurde die Tabelle tblBetraege<\/b> in der Beispieldatenbank angelegt, deren Entwurf sich aus Bild 1 ergibt. Sie simuliert eine Bestelltabelle, wo es zu jeder Position die Anzahl gibt, den eigentlichen Betrag und die Umsatzsteuer (Ust<\/b>, Prozentzahl, Double<\/b>). Der Betrag ist für unseren Versuch über drei Varianten abgebildet. BetragDbl<\/b> ist ein Feld vom Typ Double<\/b>, BetragCur<\/b> ist ein Currency<\/b>-Typ und BetragDez<\/b> von Typ Decimal<\/b>. Zur Kontrolle wurden noch drei Berechnete Felder<\/b> eingefügt. SummeDbl<\/b> ist dabei folgender Ausdruck hinterlegt:<\/p>\n
\"Entwurf<\/a><\/p>\n
Bild 1: Entwurf der Tabelle tblBetraege mit ihren drei Währungsfeldern, sowie darauf bezogenen berechneten Feldern<\/p>\n
[Anzahl] * [BetragDbl] * (1 + [Ust])<\/pre>\n
Ohne eine Abfrage bemühen zu müssen, wird damit die Positionssumme gleich im Datenblatt angezeigt. In produktiven Datenbanken sollten Sie von diesen Berechneten Feldern<\/b> aber eher absehen, weil die Anzeige direkter Tabelleninhalte dort zu vermeiden ist. SummeCur<\/b> und SummeDez<\/b> berechnen nach der identischen Formel, beziehen sich aber jeweils auf die Felder BetragCur<\/b> und BetragDez<\/b>.<\/p>\n
Um die Tabelle mit Daten zu füllen, gibt es die Prozedur GeneriereBetraege<\/b> in der Datenbank. Sie legt 10.000 Datensätze an und schreibt nach Zufallsprinzip Zahlen in die drei Felder Anzahl<\/b>, Betrag…<\/b> und Ust<\/b>. Beim Betrag wird über String-Verarbeitung darauf geachtet, dass nur exakt zwei Nachkommastellen generiert werden:<\/p>\n
Dim <\/span>dBetrag As Double<\/span>\r\nDim <\/span>sBetrag As String<\/span>\r\ndBetrag = 100 * Rnd\r\nsBetrag = CStr(Val(dBetrag * 100) \/ 100)\r\nrs!BetragDbl.Value = sBetrag<\/pre>\n
Die genaue Gestaltung der Routine interessiert hier weniger, als ihr Ergebnis, welches in Bild 2 dargestellt ist. Im Datenblatt wurde hier zusätzlich die Aggregatzeile<\/b> eingeblendet. An die Aggregatzeile kommen Sie über diese Schritte:<\/p>\n
Bild 2: Das ist die Datenblattansicht der Tabelle tblBetraege, unten mit der hinzugefügten Aggregatzeile für die Summen<\/p>\n
\"Das<\/a><\/p>\n