Geldbeträge und die Datenbank

[TurboMagic]

Hallo,

ich habe gerade das Problem, dass meine Kassensoftware mit dem Datentyp Currency Arbeitet,
die Felder in der DB auch so sind und der entsprechend alles mit 4 Nachkommastellen abspeichert.

Wenn man aber davon ausgeht, dass man 2 Nachkommastellen haben sollte und darauf ggf. runden
sollte passt das ja nicht so ganz zusammen. Da gibt's dann immer mal wieder Abweichungen im
Centbereich.

Wie ist denn da korrekterweise (für Deutschland) vorzugehen?
Vor dem Schreiben der Daten in die DB kaufmännisch auf 2 Nachkommastellen runden?
Mit welcher Rundungs Funktion? Math.RoundTo?

Grüße
TurboMagic

[himitsu]

Ob Currenty oder Flioeßkommazahl ist dabei egal.
Es passiert auch, wenn du z.B. die Steuern ein-/ausrechnest.


Wie gerundet wird, nennt sich "kaufmännisches Runden". (nicht arithmetisches Runden)

Und wie aktuell gerundet wird, kann man entsprechend umstellen, falls es nicht das Standardverhalten sein sollte.
https://docwiki.embarcadero.com/RADS...eitkommawerten
SetRoundMode
SetFPURoundMode

Das Runden selber ist aber nicht das Problem, sondern wie man mit diesem Rundungscent umgeht,
sowie wann gerundet werden muß.
z.B. könnte man erst die Einzelpositionen runden und dann zusammenrechnen, oder erst zusammenrechnen und dann Runden.



Wiki sagt zwar was,
https://de.wikipedia.org/wiki/Rundung
aber bezüglich des Rundungscent sah ich da nichts.

Vielleicht helfen andere?
https://hilfe.sevdesk.de/de/knowledg...ettorechnungen
https://easywerkstatt.com/rundungsfe...ei-rechnungen/

Im Notfall eher zu Gunsten des Kunden runden, da sollte es weniger Probleme geben, falls sich wer beschwert.

[TurboMagic]

Naja, zugunsten des Kunden runden könnte Ärger mit dem Finanzamt geben...
Es ist halt die Frage, ob mit 4 Nachkommastellen in der DB speichern und erst bei der Ausgabe runden oder gleich wenn die Daten entstehen?

[TurboMagic]

Übrigens: die Uhrzeit auf dem Server hier hinkt 1h hinterher...

[himitsu]

Nja, wenn du speicherst dann besser das Endergebnis gerundet,
denn es wäre blöd, wenn du etwas verstellst und die Finanztype sich bei der nächsten Buchprüfung beschwert,
wenn ein anderes Ergebnis rauskommt, als irgendwann mal ausgedruckt/verschickt.

Ich weiß leider grade nicht, wie es bei uns gemacht wird, da andere immer damit rumkämpfen
und das regelmäßig.



Wenn Ausgeloggt, dann gibt es eine Standardeinstellung und ich glaub die war ohne Sommer-/Winterzeit, oder so

und wenn eingeloggt, dann hast du es in deinem Profil falsch eingestellt :zwinker:

[TurboMagic]

Kann im DP Nutzerprofil keine Zeitzonen Einstellung finden...

[himitsu]

https://www.delphipraxis.net/profile...eobj_uopt_date

[TurboMagic]

Ah! Der Server weiß wohl nix von Sommerzeit. Manuell umstellen ist mir aber zu müßig... ;-)

[himitsu]

Die ist ja auch abgeschaft worden beinah sein wollen.

[jaenicke]

Zitat:

Zitat von TurboMagic (Beitrag 1527284)

Es ist halt die Frage, ob mit 4 Nachkommastellen in der DB speichern und erst bei der Ausgabe runden oder gleich wenn die Daten entstehen?

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

Insbesondere hast du ansonsten das Problem, dass du bei Summen in der Datenbank andere Werte bekommst als die, die auf der Rechnung stehen. Wenn die Werte pro Zeile gerundet gespeichert sind, gibt es auch keine relevanten Rundungsdifferenzen mehr, weil die Datentyp-Ungenauigkeit einfach viel geringer ist, zumindest wenn man mit ausreichend Nachkommastellen speichert. Bei Currency und nur 4 Nachkommastellen im Speicher könnte das problematischer sein, das müsste man genauer anschauen.

Zitat:

Zitat von TurboMagic (Beitrag 1527279)

Wenn man aber davon ausgeht, dass man 2 Nachkommastellen haben sollte und darauf ggf. runden
sollte passt das ja nicht so ganz zusammen. Da gibt's dann immer mal wieder Abweichungen im
Centbereich.

Hast du vielleicht ein Beispiel? Die Differenzen können ja an verschiedenen Stellen entstehen und je nachdem wie du rechnest, müsste man an anderen Stellen ansetzen. Entscheidend ist auf jeden Fall, dass immer zeilenweise Brutto = Netto + Steuer passt und es da keine Differenzen gibt.

[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... ;-)