Werte (u.a. Geldbeträge) in Datenbank speichern und Rundungen?

[internet]

Hallo Community,

ich habe eine Frage, die nicht unbedingt direkt mit Java zu tun hat, würde gerne hier nachfragen, wenn jemand hierzu schon Erfahrung gemacht hat.

Folgendes Szenario:
Ich möchte Rechnungen erstellen, die natürlich einen Nettobetrag bzw. Bruttobetrag, Positionen haben.

Was mir nun nicht ganz klar ist, wie ich mit Rundungen umgehe bzw. in welcher Form ich die Werte in der Datenbank speichere.
Im Moment speichere ich die Werte als double:

double total =0;

Hier kommen dann aber bspw. Werte wie: 100,5649764 zusammen, welche ich derzeit auch so in der Datenbank abspeichere.
Beim googlen finde ich zB diesen Beitrage:
https://billwerk.zendesk.com/hc/de/...werden-Rechnungsbeträge-in-billwerk-gerundet-

Rechnungspositionen werden in auf zwei Nachkommastellen symmetrisch gerundet. Die Regeln der symmetrischen Rundung (Banker's Rounding / Round to Even) sind hier erklärt.
Die Gesamtsumme einer Rechnung wird aus den gerundeten Rechnungspositionen berechnet.

Daher meine Frage:
a) Soll ich nur die gerundeten Werte inkl. nur 2 Nachkommastellen in meiner Datenbank speichern, also zB 100,57 anstatt: 100,5649764?
b) Bevor ich etwas rechne, runde ich immer erst diese Werte und speichere dann den gerundeten Wert (mit mehr als 2 Nachkommastellen) in der Datenbank ab?
c) Ich speichere beide Werte (möchte ich aber eigentlich vermeiden), also den Wert inkl. mehr als 2 Nachkommastellen und den gerundeten Wert (mit nur 2 Nachkommastellen)

Nun doch noch etwas zu Java:
Wie würde ich das umsetzen:

Produkt A, Preis = 9,99 €
Rabatt auf Produkt A = 50,00 %
Zu zahlender Betrag = 9,99 € * 0,50 = 4,995 € = 5,00 €
4,995 € werden nach der dritten Regel der symmetrischen Rundung auf 5,00 € aufgerundet.

Was mir nicht klar ist: "nach der dritten Regel" ?

Danke

 

[mrBrown]

Double und Float (und Allgemein Fließkommazahlen) sind für Geld-Beträge ungeeignet 🙂 Dabei sollte man immer in Ganzzahlen oder expliziten Dezimalzahlen ohne Rundung rechnen. Statt in Euro rechnet man dann zB in Cent (oder zehntel-Cent, hundertstel-Cent, je nachdem was zu der Domäne passt).

Beim Runden kommt es auch auf die Domäne an. Wenn der Betrag gerundet und in Cent angegeben wird, würde ich den auch genau so speichern. Wenn er dagegen in zehntel-Cent angegeben wird, speichert man ihn dann eben in zehntel-Cent, usw.

 

[internet]

danke.

Das heißt im obigen Beispiel wäre dann folgendes zu tun:

1) Value ändern von double total =0 zu int total

2)
100,5649764 EUR
-> 100,5649764 * 100 = 10056,49764 Cent

10056,49764 würde ich dann eben noch runden auf 10056,50.

Der Wert, der dann in die Datenbank geschrieben wird, wäre: 10056,50 ?

 

[LimDul]

danke.

Das heißt im obigen Beispiel wäre dann folgendes zu tun:

1) Value ändern von double total =0 zu int total

2)
100,5649764 EUR
-> 100,5649764 * 100 = 10056,49764 Cent

10056,49764 würde ich dann eben noch runden auf 10056,50.

Der Wert, der dann in die Datenbank geschrieben wird, wäre: 10056,50 ?

Dann wäre es aber kein int mehr.

Du hast als Wert zwei Möglichkeiten, wie schon erwähnt
=> als int Wert. Dann musst du direkt runden, sobald du den Wert speicherst und hättest 10056 Cent. Keine Nachkommastellen mehr vorhanden. Das würde dann auch in der Datenbank landen.
=> Als Wert mit Nachkommastellen speichern. Dann aber nicht double/float, sondern einen Wert der die Genauigkeit garantiert. Das wäre in der Regel BigDecimal. Double/Float hat bei Geldbeträgen so gut wie nie was verloren (Ich habe bisher erst einmal mit double bei Geldbeträgen gerechnet, weil die Oeprationen mit BigDecimal nicht gingen)

Wann du rundest musst du selber wissen, dass kann dir niemand abnehmen. Das ist eine rein fachliche - keine technische Frage. Die Technik muss so sein, dass die relevanten Nachkommastellen bis zu der Stelle, wo fachlich gerundet wird, beibehalten kann. In der Regel gibt ja es interne Berechnungen und zu irgendeinem Zeitpunkt wird der Wert nach "außen" (z.B. dem Kunden) kommuniziert. In der Regel wird spätestens der Wert, der nach außen kommuniziert wird, gerundet - und dann auch nur entsprechend gerundet gespeichert.

Wenn man z.B. eine Tankstelle mal betrachtet - die Literpreise werden in der Regel mit 3 Nachkommastellen angegeben.
Sobald aber der Gesamtpreis für die Liter berechnet ist, kann (bzw. muss) man den auf 2 Nachkommastellen runden - den 10tel Cent kann man nicht bezahlen. Ich würde sogar vermuten, dass die Mehrwertsteuerberechnung auf dem gerundeten Betrag läuft, aber da kenne ich mich rechtlich nicht aus.

 

[LimDul]

Noch ein Nachtrag:
Werte so speichern, wie sie kommuniziert werden
Wenn auf der Rechnung in einer Position 10,50 steht - dann haben in der Datenbank auch 10,50 zu stehen und nicht 10,499999. Letzteres wäre in 99% der Fälle falsch. Denn Rundungsdifferenzen summieren sich auf - sonst hat man nachher auf der Rechnung stehen 10-mal 10 Euro stehen - in Wirklichkeit ist aber jedes mal 10,005 gespeichert.

Und als Summe steht dann 100,05€ auf der Rechnung. Da würde ich als Kunde sofort der Rechnung widersprechen, weil die falsch ist.

 

[internet]

Noch ein Nachtrag:
Werte so speichern, wie sie kommuniziert werden

Und als Summe steht dann 100,05€ auf der Rechnung. Da würde ich als Kunde sofort der Rechnung widersprechen, weil die falsch ist.

@LimDul vielen Dank für die Aufklärung. Das war sehr hilfreich.

Am liebsten würde ich einen Wert mit Nachkommastellen nehmen....

=> Als Wert mit Nachkommastellen speichern. Dann aber nicht double/float, sondern einen Wert der die Genauigkeit garantiert. Das wäre in der Regel BigDecimal. Double/Float hat bei Geldbeträgen so gut wie nie was verloren (Ich habe bisher erst einmal mit double bei Geldbeträgen gerechnet, weil die Oeprationen mit BigDecimal nicht gingen)

Wäre mir deutlich lieber, da ich sonst verschiedene Logiken bauen muss. Beispielweise der User gibt einen EUR - Wert, ich will aber in Cent speichern. Wenn der User die Seite wieder öffnet, muss ich wieder den Cent Wert in EUR umrechenn usw. Das gäb ein ziemliches Gefrickel.

Noch eine Frage: wie würde das denn dann in JPA / Hibernate aussehen? Wäre das so richtig?

@Digits(integer=19, fraction=2)
@Column(name = "price")
private BigDecimal price;

Zusätzlich könnte ich das in die Entity einbauen:

@PrePersist
@PreUpdate
    public void pricePrecisionConvertion() {
        this.price.setScale(2, RoundingMode.HALF_UP);
    }

 

[mrBrown]

Wäre mir deutlich lieber, da ich sonst verschiedene Logiken bauen muss. Beispielweise der User gibt einen EUR - Wert, ich will aber in Cent speichern. Wenn der User die Seite wieder öffnet, muss ich wieder den Cent Wert in EUR umrechenn usw. Das gäb ein ziemliches Gefrickel.

Konvertieren zwischen Anzeige und interner Repräsentation musst du sowieso.

Noch eine Frage: wie würde das denn dann in JPA / Hibernate aussehen? Wäre das so richtig?

Ja, das könnte gehen (aber vorsichtig sein mit fraction=2!)

Besser wäre aber vermutlich, direkt sowas wie JavaMoney zu nutzen, das muss man ja nicht selbst nachbasten 🙂

Zusätzlich könnte ich das in die Entity einbauen:

Nein, besser nicht.
Runden sollte immer ganz expliziter Teil der Business-Logik sein, das ist nichts, was einfach so "nebenbei" passieren sollte.

Eine Variable sollte im Idealfall nur entweder immer einen gerundeten Wert oder immer einen nicht-gerundeten Wert enthalten, niemals zwei verschiedene Typen. Genauso wie eine Variable nicht "entweder String oder Integer" sein sollte (nur nimmt einem dabei das Typsystem das ganze ab).

 

[internet]

@Digits(integer=19, fraction=2)
@Column(name = "price")
private BigDecimal price;

Ich bin mir nicht ganz sicher, ob das mit integer=19 und franction=2 passt bzw. ich es richtig verstehe?
Heißt das, dass ich vor dem Komma maximal 19 Zahlen haben kann und nach dem Komma 2?

Also 1111111111111111111111,11

Besser wäre aber vermutlich, direkt sowas wie JavaMoney zu nutzen, das muss man ja nicht selbst nachbasten 🙂

Was genau meinst du mit nachbasteln?

Ich würde
1. Meine Preis - Felder in den Entities eben zu BigDecimal ändern
2. Eine Methode für die Rundung erstellen, die in meinen Service Layern entsprechend rundet.

 

[mrBrown]

Ich bin mir nicht ganz sicher, ob das mit integer=19 und franction=2 passt bzw. ich es richtig verstehe?
Heißt das, dass ich vor dem Komma maximal 19 Zahlen haben kann und nach dem Komma 2?

Ja, sollte so stimmen.

Was genau meinst du mit nachbasteln?

Ich würde
1. Meine Preis - Felder in den Entities eben zu BigDecimal ändern
2. Eine Methode für die Rundung erstellen, die in meinen Service Layern entsprechend rundet.

Es gibt bereits extra Typen für Geld, zB mit JavaMoney 🙂

Wenn man die Möglichkeit hat, den zu nutzen (und wenn man schon Hibernate nutzt spricht wenig dagegen), dann sollte man das gegenüber anderem bevorzugen 🙂

EDIT: ansonsten fängt man bald an, das nachzubauen, und das wird meisten schlechter als das, was es schon gibt. Ein Geldbetrag ist ja zB nicht einfach eine Zahl (auch wenn Zahlen genutzt werden, ums darzustellen), und drum herum braucht es eine Menge an zusätzlichen Dingen, zB Parsen und Formattieren.