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

[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 von TurboMagic:

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 von TurboMagic:

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.