Geldbeträge und die Datenbank

[haentschman]

Zitat:

die Felder in der DB auch so sind und der entsprechend alles mit 4 Nachkommastellen abspeichert.

...wieso? :roll:
Ich habe in einem Projekt auch eine DB mit 6 Nachkommastellen bei Geldwerten übernehmen müssen...:kotz:

Da kam genau das:

Zitat:

Insbesondere hast du ansonsten das Problem, dass du bei Summen in der Datenbank andere Werte bekommst als die, die auf der Rechnung stehen.

...raus. :cry:

Was für eine Datenbank? Bei MSSQL umstellen auf numeric(xxx, 2)
Im Quellcode NUR "RoundTo" = kaufmännisch :zwinker: https://docwiki.embarcadero.com/Libr...m.Math.RoundTo

Zitat:

Ich würde sofort runden, wenn die Daten nicht mehr weiter zur Berechnung benötigt werden.

+1 :thumb:

[TurboMagic]

Danke schon mal für die Antworten.
Evtl. kann ich heute Abend ein Beispiel liefern.

DB: Firebird, noch V2.5. Zugriff mittels FireDAC.

Grüße
TurboMagic

[haentschman]

Auch bei Firebird gibt es:
NUMERIC (precision, scale)
https://firebirdsql.org/file/documen...pes-numeric-de

[TurboMagic]

Hallo,

ja, FB stellt numeric mit definierbaren nachkommastellen zur Verfügung.
Habe jetzt nochmal etwas nachgeschaut und bin auf das gestoßen:

1. Die von mir in der DB definierte Anzahl Nachkommastellen entspricht der in der DSFinV-K festgelegten.

2. Diese legt für BON_BRUTTO, BON_NETTO und BON_UST in der Bonkopf_Ust jeweils 5 Nachkommastellen fest.
In der DSFinV-K steht dazu noch das:

Zitat:

Die Felder BON_BRUTTO, BON_NETTO und BON_UST beinhalten die auf dem Beleg
abgedruckten Beträge und werden deshalb in der Regel mit zwei Dezimalstellen dargestellt.
Nur aus technischen Gründen werden fünf Dezimalstellen zugelassen.

3. => ich sollte wohl immer dann, wenn ich was dafür errechne und rein schreibe schon direkt nach
dem Berechnen auf 2 Nachkommastellen runden. Richtig?

4. Und so sollte ich alle anderen Tabellen mal durchgehen und nochmal prüfen. Richtig?

5. UMS_BRUTTO aus der Bonkopf selber hat nur 2 Nachkommastellen...

6. In Bonkopf_Zahlarten gibt's jeweils nur 2 Nachkommastellen, man kann es also gar nicht
genauer bezahlen.

7. In der Bonpos und Bonpos_Ust sind diese Spalten wieder alle mit 5 Nachkommastellen.
Vermutlich auch wegen Tankstellenbetreibern die Preise gerne auf 3 Nachkommastellen angeben...

8. In Stamm_Abschluss gibt's auch immer nur 2 Nachkommastellen, in der Z_GV_Typ aber wieder 5
und in Z_Zahlart wieder nur 2, das ist ja aber logisch wenn Bonkopf_Zahlarten nur auf 2 Stellen
genau ist.

9. Z_Waehrungen ist folgerichtig auch auf 2 Nachkommastellen definiert.

Grüße

TurboMagic

[jaenicke]

Ja. Grundsätzlich muss klar sein, dass alle Beträge, die irgendwo gedruckt wurden, auch genau so gerundet in der Datenbank stehen. Mehr Nachkommastellen sind dabei durchaus förderlich, weil es dann keine Probleme mit Ungenauigkeiten durch die Gleitkommadarstellung gibt. Denn diese Ungenauigkeiten sind dann deutlich geringer als die gerundet in die Datenbank geschriebenen Werte. Dadurch sind auch Summen über größere Zeiträume unproblematisch.

Wenn du z.B. nach einem Artikelrabatt Rabatt 11,33333€ heraus bekommst, musst du das in der entsprechenden Zeile auch gerundet als 11,33000...€ in die Datenbank schreiben. Und du solltest z.B. schauen, dass du niemals Brutto, Netto und Steuer einzeln ausrechnest, sondern du musst immer den Bruttowert rabattiert usw. ermitteln, runden, daraus die Steuer, runden, und den Nettowert dann per Differenz ermitteln.

Man kann das aber auch anders behandeln und die Differenzen in Kauf nehmen. Sie dürfen nur nicht an den falschen Stellen entstehen. Was auf den Kundenausdrucken steht, muss auch so stimmen.

[TurboMagic]

Danke, das ist sehr hilfreich/gut zu wissen, auch wenn es bei mir noch keine Rabatte gibt... ;-)