Brett vorm Kopf. Finde den Fehler nicht.

[Rolf B]

Hallo Tabellenkalk,

Banken benötigen für Zinsrechnungen weit mehr als Cent-Genauigkeit, möglicherweise reichen Hundertstel-Cent.

Ich bin damals bei der Euro-Konvertierung unseres Versichertenbestandes nicht beteiligt gewesen, ich weiß aber, dass der Standard-Eurorechner, den wir damals zugekauft hatten (sic!) mit Hundertstel-Cent gerechnet hat. Und ich meine mal irgendwo gelesen zu haben, dass im Buchhaltungswesen das Rechnen mit Hundertstel-Cent und genaue Vorschriften, wann wie zu runden ist, vorgegeben sind. Das mag aber jetzt Fake-Memory sein.

Euro und Cent getrennt zu verwalten, tja, das ist ggf als Workaround nötig und wird bei Punktrechnung umständlich. Aber nötig ist es nur bei alter Software. Der Klassiker ist hier COBOL mit dem COMP-3 Format, das früher maximal 18 Ziffern konnte (entspricht dem Umfang eines 64-bit Integer). Wenn man sich dem Billiardenbereich nähert, ist man bei 4 Nachkommastellen am Ende. Der IBM Compiler hat die ARITH(EXTEND) Option, dann wird der Code langsamer, kann aber 31 Ziffern verarbeiten. Der .net Decimal Typ kann 28 Ziffern. Mit diesen Grenzen hat vermutlich nur Venezuela ein Problem, aber die haben ja auch Übung in Währungsschnitten.

Java legt mit BigDecimal deutlich was drauf, und in JavaScript kann man immerhin BigInt verwenden.

IBM COBOLs Datenbankpartner DB2 speichert 31 stellige Decimals, MS SQL Server speichert DECIMAL bis zu 38 Ziffern und MySQL bis 65.

Also - machbar ist's auch ohne Cent-Quarantäne.

Rolf