Schon bekannt ist gut.... Die Rundung von Beträgen sind ein Dauerbrenner Thema, seit Jahren, immer wieder, und bei weitem nicht nur bei uns. Wir rechnen in aller Regel mit Floats, mit 4 Stellen nach dem Komma. Andere Systeme wie PayPal, DHL, und wie die alle heissen, rechnen auch gerne mal anders, dafür sind eine Vielzahl von Workarounds im Shop. Das wesentliche: Es gibt nicht die eine Rechenweise und Genauigkeit, die garantiert für alle passt. Wir können darum auch nicht alles auf einen Standard X umbauen. Dann geht einiges kaputt.
In PHP ist man bei dem Thema einigermaßen auf der sicheren Seite, sofern man PHP-Funktionen wie number_format() oder round() zum Runden benutzt. Eine blöde Fußangel ist z.B. printf(): PHP: php > $b = 2.25;php > echo number_format($b, 2);2.25php > echo number_format($b, 1);2.3php > printf("%.1f\n", $b);2.2php > printf("%.10f\n", round($b, 1));2.3000000000php > printf("%.10f\n", round($b, 1, PHP_ROUND_HALF_EVEN));2.2000000000 Ich würde eigentlich auch alles, was mit Geld zu tun hat, so gestalten, dass es Beträge in ganzen Cents speichert und so das ganze Getüddel mit den Fließkommawerten umgeht. Bei den osCommerce-/xt:Commerce-Ablegern wie dem Gambio-Shopsystem werden leider Fließkommawerte verwendet, das werden wir ohne riesigen Aufwand auch nicht mehr los.
Diese Datei hochladen in /system/classes/orders/ und die alte überschreiben, und dann soll es vorbei sein mit abweichenden Beträgen in JTL Wawi und Gambio. Das hat Timo Panitz von Itratos geschrieben. Keine Gewähr/Haftung. (Noch) nicht updatesicher... VG
Das sind die allgemeinen, ziemlich durchgängig verwendeten, Steuerklassen. Daran fummeln ist oberheikel.
Behalte Bestellabbrüche im Auge. Es kann unter anderem sein, dass der Shop dann anders rechnet als zum Beispiel PayPal und andere Zahlungsanbieter, und du Zahlungsabbrüche bekommst.
Bringt zumindest in Verbindung mit Amicron keine Verbesserung. Die Rundungsdifferenzen sind nach wie vor vorhanden.
Das Thema ist riesig, wir haben da auch schon unzählige Stunden mit dem suchen von halben Cents verbraten. Wir binden auch Systeme an, die da nicht homogen sind. Die eine und wahre Siegerlösung gibt es meines erachtens nach nicht.
Christian, ich stecke da auch nicht drin. Hinweise aber noch von Timo: Code: Behandelt Rundungsfehler in der ot_total. Wichtig ist das man die Versandarten/Zahlungsarten bzw. die Gebühren richtig konfiguriert, Du hast z.B. bei Nachnahme 7,56 eingetragen, so kommt gambio auf 8,9964 Euro und nicht auf 9 Euro. Richtig sind hier 7,563 Euro. Das erkennst Du bei allen Bestellungen die mit Nachnahme bestellt wurden oder in meinen ersten Testbestellungen. Je weniger Nachkommastellen genutzt werden, desto ungenauer wird der Bruttobetrag. Bei gambio gab es ausschließlich am Ende ein Problem in der Berechnung alle anderen Werte passten, also z.B. die Artikelpreise in der Bestellung - nur bei der letzten Berechnung gab es dann das Problem. Wenn du möchtest, kannst du dich gerne unverbindlich bei ihm melden, dann würde er sich per Teamviewer mal ansehen, ob das ein ähnliches Problem wie mit JTL ist. info@itratos.de