Wie ist der Status von Rundungsproblemen in 1.7?

27

Wir verwenden Magento CE 1.7 und haben verschiedene Rundungsprobleme. Bei verschiedenen Berechnungen ergibt sich eine Differenz von 0,01 EUR.

Das Grundproblem könnte sein, dass die Artikelpreise inkl. Gesetzl. MwSt.

Co-Programmierer haben die Mage_Core_Model_Store::roundPrice()Berechnungsmethode mit einer Genauigkeit von 4 Stellen überschrieben. Dies scheint jedoch Probleme mit PayPal-Zahlungen zu verursachen.

Gibt es eine Lösung für diese Probleme?

BEARBEITEN:

Wir haben versucht , tatsächlich einen offiziellen Core - Patch , die im Grunde 4-stellige fügt eine Rundung auf \Mage_Tax_Model_Sales_Total_Quote_Shipping::_round, \Mage_Tax_Model_Sales_Total_Quote_Subtotal::_deltaRoundund \Mage_Tax_Model_Sales_Total_Quote_Tax::_deltaRounddas behebt ein Coupon Rundung Problem , aber nicht das PayPal Problem.

ce-1.7.0.2 rounding germany Alex
quelle
Soweit ich mich erinnere, speichert Magento die Preise mit 4 Nachkommastellen. Wenn also Preise mit 4 Nachkommastellen eingegeben werden, ist die Berechnung korrekt. Aber ich kann mich irren.
User487772
1
Was meinen Sie mit "Eingabe mit 4 Dez.-Punkten"? Die Magento-Rundung funktioniert aber mit 2 dez. Punkte. Auch ich denke das PayPal Interface funktioniert mit 2 dez. Punkte - hier scheint das Problem zu beginnen.
Alex
Wenn ich mich richtig erinnere, wenn Sie Preise in admin mit 4 Dezimalstellen eingeben, wird es in db mit 4 Dezimalstellen gespeichert. Dann wird es während der Ausgabe auf 2 Punkte gerundet, aber die Rundung ist korrekt, da der Preis mit 4 Dezimalstellen gerundet wird.
User487772
Sicher - aber wir haben hauptsächlich Probleme mit der Gesamtberechnung, insbesondere wenn es sich um prozentuale Gutscheincodes handelt.
Alex
Oh, dann habe ich deine Frage falsch verstanden. Es tut uns leid.
User487772

Antworten:

10

Wir sind uns einiger Rundungsprobleme innerhalb des Magento-Steuermoduls bewusst, die die beschriebenen Szenarien abdecken. Derzeit arbeiten wir an diesen Problemen für eine kommende Version 1.13. Diese Rundungsprobleme lösen eine einfache Paypal-Prüfung aus, mit der festgestellt wird, ob die Positionen im Einkaufswagen korrekt addiert wurden. Es sieht so aus, als würde sich Fabians Patch kurzfristig um den Paypal-Check kümmern.

Wenn Sie Fragen, Kommentare oder Vorschläge zur Verbesserung des Magento Tax-Moduls haben, zögern Sie bitte nicht, mich zu kontaktieren, da ich der für Steuern zuständige Produktmanager bin.

Grüße, Chuck

Futter
quelle
Groß! Gibt es eine Art Testsuite, die zeigt, welche Probleme angegangen werden?
Alex
1
Chuck, würde es Ihnen etwas ausmachen, Ihre Benutzerinformationen einzurichten, um dies zu überprüfen?
Benmarks
Die Tests sind nur intern. Soweit mehr Details zu bekannten Rundungsproblemen - das ist ein wenig interessant. Ein Kunde würde sie als mit bestimmten Steuerkonfigurationen assoziiert betrachten, indem er bestimmte Kombinationen von Preis, Steuersatz, Rabatten usw. verwendet. Unser Ansatz für 1.13 bestand darin, gemeinsame Steuerkonfigurationen zu identifizieren und sicherzustellen, dass # Kombinationen nicht zu Rundungsfehlern führen und bestimmte Tags setzen Konfigurationen (kleine Eckkoffer) als gefährliche Konfigurationen, die vermieden werden sollten.
Chuck
Ein bisschen vom Thema abweichend, aber heißt das, dass es auch eine CE 1.8-Ausgabe geben würde?
Sergei Guk
Ja - CE-Veröffentlichungen verzögern EE-Veröffentlichungen um etwa einen Monat. 1.13 ist die nächste EE-Version.
Chuck
7

Dank Andreas Vogt baue ich ein Modul, um den runden Paypal-Fehler zu beheben. Andreas gab mir ein paar Core-Hacked-Files und ich machte das Modul. Es wird überprüft, ob die Summen korrekt sind, und wenn nicht, wird sie korrigiert.

Afaik der Core-Hack wird in freier Wildbahn getestet. Viele Leute fragten nach dem Modul, aber niemand gab mir Feedback, ob es funktioniert. Aber es ist Unit-getestet! (nur ob das umschreiben funktioniert, da ich keine ahnung hatte, was das paypal problem ist ;-))

https://github.com/magento-hackathon/PaypalRoundBugfix

Fabian Blechschmidt
quelle
1
Hm .. welchen Bug genau behebt er? Sieht aus wie der Fehler beim Übertragen von Einkaufswagenpositionen. Wir haben den Cart-Transfer abgeschaltet. Und ist es mit dem 4-stelligen Rundungs-Patch anzuwenden?
Alex
Gibt es mehr als ein Problem? Wie gesagt, ich habe keine Ahnung, was genau es behebt - wenn es mehr als ein Problem gibt :(
Fabian Blechschmidt
5

Wir haben es sowohl mit dem Paypal-Rundungsfehler als auch mit der Ausgabe von Gutscheincodes mit 100% Rabatt zu tun. Wir haben nur Probleme bei den Preisen (wie Eur 3,99 inkl. MwSt.), Bei denen der Nettopreis auf der 3. Stelle eine 5 (3.325) hat. So hat auch die Steuer (hier mit 20%) auf der 3. Stelle eine 5 (0,665). Wenn Sie also beide Preise aufrunden und addieren (was Paypal und Magento tun), ist die Gesamtsumme 0,01 Euro mehr als der Grundpreis (4,00 Euro).

Die richtige Berechnung sollte 3,32 Euro netto + 0,67 Euro Steuer = 3,99 Euro sein

Da wir auch versuchen, eine allgemeine Lösung zu finden, versuchen wir es mit dem Paypal-Rundungsfix!

Walter Huber
quelle
Toll, sag mir, wenn du Probleme hast, ich bin gerne bereit, dir zu helfen und den Bugfix in freier Wildbahn zu sehen und ihn bei Bedarf zu debuggen!
Fabian Blechschmidt
1
Zu Ihrer Information: Das von Ihnen beschriebene Problem wurde in unserer kommenden Version (1.8 CE / 1.13 EE) behoben.
Chuck
@Chuck Ich habe dieses Szenario gerade mit Mage_Tax_Model_Sales_Total_Quote_Tax von 1.13.0.1 getestet und es sieht so aus, als hätte es das Problem als Ersatz in einem 1.12-Projekt gelöst. Vielen Dank. Gibt es schon eine ETA für 1.8CE?
Jonathan Day
4

Es besteht ein allgemeiner Zusammenhang zwischen den Preisen, der Menge, dem Rabatt, der Steuer und deren Genauigkeit.

Assume:
x is the price
y is the percentage
s is the rounded sub-total

2 Directions
A) incl. Tax => excl. Tax => incl. Tax
B) excl. => incl. => excl.

Das wichtige Problem ist die gerundete Zwischensumme, die ich mit der max berechne. Error. 2 Nachkommastellen bedeuten 5 * 10 ^ -3

A) x * 10 ^ 2 / (y + 10 ^ 2) // s * (y + 10 ^ 2) / 10 ^ 2

B) x * (y + 10 2) / 10 2 // s * 10 2 / (10 2 + y)

A)
Subtotal precision 2 fractional digits:
5*10^-3*(y+10^2)/10^2 => (y+10^2)/10^2<1 => no y
3 fractional digits:
5*10^-4*(y+10^2)/10^2 => (y+10^2)/10^2<10 => y<900
4 fractional digits:
5*10^-5*(y+10^2)/10^2 => (y+10^2)/10^2<10^2 => y<90900
(must be a very bad country)

......

B)
Subtotal precision 2 fractional digits:
(5*10^-3)*10^2/(10^2+y) => 10^2/(10^2+y)&lt;1 => every y

Wenn Sie mit Rabatten oder Steuern rechnen und den Preis neu berechnen möchten , kann die nächste Erklärung für Sie interessant sein. Bitte beachten Sie, da ich im Frontend keinen Fall kenne, ist es möglich, dass es eine interne Berechnung gibt. A) Summe => Steuer / Rabatt => Summe B) Steuer / Rabatt => Summe => Steuer / Rabatt

A) x * y / 10 ^ 2 // s * 10 ^ 2 / y

B) x * 10 ^ 2 / y // s * y / 10 ^ 2

A) Subtotal precision 2 fractional digits:
(5*10^-3)*10^2/y => 10^2/y < 1 => y>10^2
Subtotal precision 3 fractional digits:
(5*10^-4)*10^2/y => 10^2/y < 10 => y>10
Subtotal precision 4 fractional digits:
... 10^2/y < 10^2 => y>1

Mit einer Genauigkeit von 2 Stellen müssen Sie eine Rate ohne gebrochene Ziffern haben. Beispiel: Summe: 15,15 Steuersatz: 0,3% => Steuer 0,04545 => gerundet 0,0455 Steuer: 0,0455 => Summe: 15,17

B) Subtotal precision 2 fractional digits:
(5*10^-3)*y/10^2 => y/10^2 &lt; 1 => y < 10^2

Wenn a die Genauigkeit ist, muss y kleiner als a + 2 sein.

Bitte beachten Sie, wenn Sie mit Mengen umgehen. Der Fehler wird multipliziert. Wenn Sie also ein Maximum von 10 ^ 5 haben, müssen Sie eine Genauigkeit von 7 haben. Dies ist nur besorgniserregend, wenn Sie mit Offset rechnen!

ADDITION (9.10.2013 Magento Version 1.7.0.2) Brutto <=> Netto und Steuern // Amerika <=> alte Europa-Mengen sind ganze Zahlen (Cents) und das Mapping
f (x) = rund (a * x) a> 1 ist nicht bijektiv. In meinen Worten: Nicht für jeden Preis inkl. existiert ein Preis zzgl. gesetzl. oder Es gibt manchmal 2 Preise inkl. gesetzl. für einen preis excl. oder Sie können 2 verschiedene Ergebnisse erhalten, je nachdem, wie Sie berechnen

Praxisbeispiel aus Deutschland:

Sie versuchen einen Preis inkl. MwSt. Einzugeben. Steuern: 19,95 Sie erhalten 16,76 (2 Ziffern) als Ihre Preise zzgl. gesetzl. die Steuern (19%). Wenn Sie die 19% Steuern berechnen, erhalten Sie (16,76 * 0,19) 3,18. (Achtung: 19,95 * 019 / 1,19 ~ 3,19)

Es gibt also einen Cent Unterschied. 16,76 => 19,94 16,77 => 19,96

Es gibt keinen Preis 19,95 in Amerika - Land des Netto.

Rechnen Sie so weit wie möglich mit Originalpreisen. Verwenden Sie für die Einbeziehung der Preise den eingegebenen Preis und die Steuern (gebrochene Zahl).

PayPal hat diesen Betrugscheck - jetzt bin ich mir nicht sicher - aber PayPal fügt nur die Zahl hinzu, die Magento ihm gibt. siehe http://fabiankrueger.de/blog/magento-und-paypayl-rundungsfehler/ Wenn dies nicht zutrifft und PayPal Tax oder Total neu berechnet, ist dieses Problem nicht lösbar, da sonst die Preise - falsch oder richtig - zuvor in Magento angezeigt werden . Löse es dort. Bei mir scheint es zu funktionieren.

Andreas Dyballa
quelle