Currency oder Double

[mm1256]

Zitat:

Zitat von bernau (Beitrag 1294006)

Bisher hatte ich in meiner Laufbahn noch keinen wirklichen bemerkbaren Fehler entdeckt und kein Kunde sagte, daß meine Software falsch rechnet.

Wenn eine SW falsch rechnet, dann war bzw. ist die Ursache ja meistens der Programmierer. Das Problem sitzt ja bekanntlich meistens vor dem PC :cyclops:
Darum denke ich, dass es - bei richtiger Anwendung - keine Falschberechnungsunterschiede (blödes Wort) zwischen Currency und Double gibt.

Zitat:

Zitat von bernau (Beitrag 1294006)

Wie haltet Ihr es mit Geldbeträgen. Nehmt Ihr Currency oder Double. Seid ehrlich. ;-)

Ich nehme generell Double, weil ansonsten manchmal Abweichungen entstehen können. Speziell bei Berechnungsketten wie z.B. bei Artikelpreisen: Listenpreis abzüglich Händlerrabatt, zuzüglich Rohstoffzuschlag, zuzüglich Aufschlag, abzüglich Mengenrabatt, zuzüglich Märchensteuer....

Da speichere ich in den Stammdaten alle Nachkommastellen die der Double hergibt. Runden tu ich dann erst bei der Fakturierung.

[Blup]

Abrechnung in der Datenbank mit Numeric() also Festkomma, deshalb keine Probleme in dieser Beziehung.
Im Programm selbst wird Double verwendet, aber dort wird eigentlich nur addiert oder mit Ganzzahl multipliziert.
Die Ausgabe wird natürlich gerundet. Probleme sind nicht bekannt.

Das einzig bekannte Rundungsproblem hat nur indirekt mit dem Datentyp zu tun.
Wir erstellen in der Regel Ausgangsrechnungen abei denen die Einzelpositionen Brutto ausgewiesen werden.
Die Mehrwertsteuer wird auf den Gesamtbetrag je Mehrwertsteuersatz berechnet.

Brutto MwSt. Steuer Netto
10,00 19% 1,60 8,40

Da sich dieser Betrag aber aus unterschiedlichen Leistungen zusammensetzt,
sollen die Teilbeträge in die Buchhaltung getrennt für verschieden Erlöskonten übergeben werden.

Brutto MwSt. Steuer Netto
06,60 19% 1,05 5,55 Erlöskonto1
03,40 19% 0,54 2,86 Erlöskonto2

Es gibt verschiedene Möglichkeiten das Problem zu umgehen (separate Steuerbuchung, Zwischenkonto), damit zumindest die Steuersumme stimmt.
Diese sind nicht bei jeder Buchhaltungssoftware auf die gleich Weise anwendbar.
Das Problem verschiebt sich dadurch nur, von welchem Erlöskonto zieht man jetzt den Steuer-Cent ab?

[mm1256]

Zitat:

Zitat von Blup (Beitrag 1294053)

Das Problem verschiebt sich dadurch nur, von welchem Erlöskonto zieht man jetzt den Steuer-Cent ab?

Lösbar ist das Problem ja nicht. Also schlucke ich die kleinste Kröte und nehme immer das (Erlös-)Konto mit dem höchsten Betrag, weil dadurch die Fibu insgesamt am wenigsten verfälscht wird. Der Anwender kann noch einstellen, ob und wie er informiert werden möchte. Im Logfile steht es aber generell.

[p80286]

!currency!
Ohne Currency gab es im Zusammenspiel von DB, Frontend und erstellten Briefen (Word mit ein paar Macros) immer wieder Abweichungen im Cent-Bereich, die nervig bis peinlich waren.
Jetzt herrscht Ruhe!

Gruß
K-H

[himitsu]

Da viele Textausgabefunktionen (Float->String) eher abrunden/abschneiden, müsste man beim Double entweder "runden" oder vor Anzeige 'nen 1/100stel oder 1/1000stel traufrechnen, damit meistens richtig "abgerundet" wird.

[mm1256]

Zitat:

Zitat von p80286 (Beitrag 1294066)

!currency!
Ohne Currency gab es im Zusammenspiel von DB, Frontend und erstellten Briefen (Word mit ein paar Macros) immer wieder Abweichungen im Cent-Bereich, die nervig bis peinlich waren.
Jetzt herrscht Ruhe!

Gruß
K-H

Kann es sein, dass diese Abweichungen auch was mit der Datenbank zu tun haben? Ich verwende NexusDB - die ja bekanntlich in Delphi programmiert ist - und hatte diesbezüglich noch keine Probleme.

[Dejan Vu]

Also floating point ist floating point, egal wer mit wem und wo das programmiert wurde. Wenn Nexus-DB hier kein FP nimmt, sondern BCD, dann wäre das ja mal was, wobei 'Numeric(x,y)' zumindest in SQL-Server auch eine BCD ist.

FP und Währungen sind eine Qual. Wir haben ein Bankensystem, bei dem die Honks, die das programmiert haben, alle Währungen in der DB als 'float' abgebildet haben (SQL-Server) und nun müssen sie in jeder 2.Zeile die Werte krampfhaft runden. Und selbst dann kann ich von einem Konto, auf dem noch 9.99 Euro drauf sind, nicht immer 9.99 Euro abheben, weil der Dispo auf 0.00 ist und -0.0000000000000000123 eben weniger als 0.00 sind. :wall:

Zu den Argumenten: "Bei mir ist noch nie was passiert" fällt mir immer nur der Autofahrer ein, der ohne Sicherheitsgurt fährt, und das gleiche sagt.

Wegen interner Berechnungen von Zinsen etc. verwenden wir BCD, da ist Currency leider nicht genau genug. Aber in er DB würde ich nur noch 'money' verwenden. In der Darstellungsschicht würde ich allerdings auf Currency setzen, weil das irgendwie dem nahe kommt, was man darstellen will.

Vor Jahren haben wir mal eine Logistik- und Abrechnungssoftware mit Double gebaut, das war ähnlich krank. Da hatten wir zwar keine Probleme in der DB, aber dafür bei der Rechnungslegung. Was da für Rundungsprobleme entstanden sind, verstehe ich bis heute nicht, aber sie waren da.

[Lemmy]

Zitat:

Zitat von Dejan Vu (Beitrag 1294081)

FP und Währungen sind eine Qual. Wir haben ein Bankensystem, bei dem die Honks, die das programmiert haben, alle Währungen in der DB als 'float' abgebildet haben (SQL-Server) und nun müssen sie in jeder 2.Zeile die Werte krampfhaft runden. Und selbst dann kann ich von einem Konto, auf dem noch 9.99 Euro drauf sind, nicht immer 9.99 Euro abheben, weil der Dispo auf 0.00 ist und -0.0000000000000000123 eben weniger als 0.00 sind. :wall:

Drollig wird es dann, wenn die Programmierer angewackelt kommen und fragen, warum da -0.0000000000000000123 raus kommt - weil sie runden ja vorher (einen Double auf einen Double)...

Zitat:

Zitat von Dejan Vu (Beitrag 1294081)

Zu den Argumenten: "Bei mir ist noch nie was passiert" fällt mir immer nur der Autofahrer ein, der ohne Sicherheitsgurt fährt, und das gleiche sagt.

das hinkt... Das Problem ist doch: Es passiert immer wieder, nur fällt es nicht auf. Wie bei der Software die ich in meinem letzten Post beschrieben habe: Über Jahrzehnte wird da mit Double gerechent - die Unterschiede (und Rechenfehler) sind erst dann aufgefallen, als ich die gleichen Daten in eine XML schreiben musste - da aber halt als Cent-Betrag ohne Nachkommastellen und auf einmal hat sich Papierrechnung und XML unterschieden....

[Dejan Vu]

[QUOTE=Lemmy;1294082das hinkt... [/QUOTE] Das Wesen eines guten Vergleiches ;-()
Du kannst auch mal ohne Gurt auf deinen Vordermann stupseln. Aber klar. Im Grunde genommen ist die Einstellung, ohne Gurt ginge es auch, etwas fataler in der Auswirkung als 'Double als Währung'.

Grad gestern hat der 'Lead Developer' hier gemeint, wir sollten doch bitte auch in neuen Funktionen mit 'Float' und 'Double' arbeiten, sonst würde man ja ganz konfus.. :thumb:
:wall:

[bernau]

Zitat:

Zitat von Lemmy (Beitrag 1294082)

Drollig wird es dann, wenn die Programmierer angewackelt kommen und fragen, warum da -0.0000000000000000123 raus kommt - weil sie runden ja vorher (einen Double auf einen Double)...

Ja, ein Double ist ein Double. Und wenn ich weis, wie ich mit einem Double umgehen muss, dann passiert mir so etwas nicht.

Das soll jetzt kein Fürsprecher für Double sein. Aber auch mit Currency gibt es bestimmt auch Fallstricke. Man muss ich eben mit dem Zahlentyp auskennen.