Geldbeträge und die Datenbank

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

[haentschman]

Zitat:

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

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

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.

Was für eine Datenbank? Bei MSSQL umstellen auf numeric(xxx, 2)
Im Quellcode NUR "RoundTo" = kaufmännisch 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

[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