Hallo Richard!
Diese Werte sind aber immer nur annähern gleich, solange die Zahlen nicht ohne Rest teilbar sind. Das kannst du nicht durch andere Rundungsregeln lösen, sondern nur durch genaueres Rechnen. Wenn dir für den Vergleich 5 Nachkommastellen ausreichend sind, spielt es doch keine Rolle, wenn bei der 7. Nachkommastellen keine Übereinstimmung mehr besteht.
Ja, so langsam denke ich dass es doch daraus hinaus laufen wird. Eigentlich hatte ich es auch so gemacht, mich hatte aber eine Tatsache verwirrt:
Der Anwender hat gesagt, es würde in der Software genau so gerechnet, wie SAP, wenn die Daten dort eingelesen werden. Ich war dabei davon ausgegangen, dass SAP nur diese 5 Nachkommastellen bekommt, womit dort ein anderes Ergebnis rauskommen muss, gegenüber meiner Software, die ja tatsächlich mit 14 Stellen rechnet.
Ich ging weiter davon aus, dass wenn man in der Software mit Taschenrechner nachrechnet, dass mit den auf 5 Stellen gerundeten Werten das korrekte Ergebnis herauskommt.
Inzwischen zweifele ich, dass das so ist. Angenommen die Daten werden per Excel in SAP importiert, und in Excel werden 5 Nachkommastellen dargestellt, aber in Wirklichkeit 10 Stellen gespeichert, und angenommen auch SAP rechnet dann mit diesen genaueren Werten, dann passt ja wieder alles zusammen.
Kein Mensch wird das mit dem taschenrechner nachrechnen, sondern nur mit Excel. Und wenn das funktioniert, kann ich den Anwender verstehen wenn er sagt "bei uns gibt es keine Rundunksfehler, das geht alles auf...". Kann mir zwar nicht so richtig vorstellen dass SAP so viele Nachkommastellen verwendet, aber mal sehen.
Ich werde mir mal die ungünstigsten Konditionen überlegen, und so viele Nachkommastellen in der DB, in PHP und im Excel-Export verwenden, dass es keine Probleme mehr gibt. Ich hatte zwar gehofft dass man es irgendwie anders lösen kann, aber ich wüßte nicht wie.
Allenfalls hättest du noch die Möglichkeit in umgekehrter Reihenfolge zu rechnen, also den Stückpreis durch Division aus dem Gesamtpreis zu errechnen. Dann weicht der Gesamtpreis wenigstens nicht voneinander ab.
Ich hoffe dass es ausreicht entsprechend viele Nachkommastellen zu verwenden. Ich überlege wie gesagt auch den "originalen" Preis in der Fremdwährung zu speichern, denn dann speichere ich nicht schon einen krummen Wert, sondern maximal 5 Nachkommastellen. Dann kann ich auf dieser Basis Rechnen, dabei sollte es in der Fremdwährung keine Probleme geben, und die Umrechnung in EUR kann ich dann von dem dynamisch zusammengrechneten Gesamtpreis in Fremdwährung ausrechnen. Hätte also dieselbe Genauigkeit beim Gesamtpreis, und die Garantie dass der Eingegebene Preis nicht einem Rundungsfehler zum Opfer fällt, und so evtl. anders angezeigt wird als tatsächlich eingegeben.
Nur würde dadurch die Berechnung zur Laufzeit aufwändiger, und nicht nur hier, sondern auch für jede spätere Auswertung die mal aus den Daten gezogen werden soll.
Bleibt mir wohl nichts anderes übrig als das ein bisschen auszutesten (oder ist hier irgendein Mathe-Student der mir mal eben berechnen/beweisen kann, wieviele Nachkommastellen ich im ungünstigsten Fall bei der jeweiligern Variante benötige... der Teil von Mathematik war noch nie meine Stärke ;-))
Grüße
Andreas
[remote-signature:http://knet-systems.de/tmp/rand_sig.php]