Quel est l'état des problèmes d'arrondi en 1.7?

Nous utilisons Magento CE 1.7 et avons divers problèmes d'arrondi. Dans divers calculs, il y a une différence de 0,01 EUR.

Le problème de base pourrait être que les prix des articles sont incl. impôt.

Les co-programmeurs ont écrasé la Mage_Core_Model_Store::roundPrice()méthode de calcul avec une précision de 4 chiffres. Mais cela semble causer des problèmes avec les paiements PayPal.

Existe-t-il une solution à ces problèmes?

MODIFIER:

Nous avons essayé un patch principal officiel qui ajoute essentiellement quatre chiffres arrondis à \Mage_Tax_Model_Sales_Total_Quote_Shipping::_round, \Mage_Tax_Model_Sales_Total_Quote_Subtotal::_deltaRoundet \Mage_Tax_Model_Sales_Total_Quote_Tax::_deltaRoundqui corrige un problème d' arrondi de coupon , mais pas le problème PayPal.

Nous sommes conscients de plusieurs problèmes d'arrondi dans le module principal de taxe Magento qui couvrent les scénarios qui ont été décrits. Nous travaillons actuellement sur ces problèmes pour une prochaine version 1.13. Ces problèmes d'arrondi déclenchent un simple contrôle Paypal qui détermine si les éléments de ligne du panier s'additionnent correctement. Il semble que le patch de Fabian s'occupe du chèque Paypal à court terme.

Si vous avez des questions, des commentaires ou des suggestions sur la façon dont nous pouvons améliorer le module Magento Tax, n'hésitez pas à me contacter car je suis le chef de produit responsable des taxes.

Cordialement, Chuck

Grâce à Andreas Vogt, j'ai construit un module pour corriger le bug rond de Paypal. Andreas m'a donné quelques fichiers de base piratés et j'ai créé le module. Il vérifie si les sommes sont correctes et sinon, il est corrigé.

Afaik le hack de base est testé dans la nature. Beaucoup de gens ont demandé le module, mais personne ne m'a dit si cela fonctionne. Mais il est testé à l'unité! (seulement si les réécritures fonctionnent, car je n'avais aucune idée du problème de paypal ;-))

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

Nous sommes confrontés aux deux, le bug d'arrondi paypal et le problème avec les codes de réduction de 100% de réduction. Nous n'avons que des problèmes de prix (comme Eur 3,99 TTC), où le prix net a sur le 3ème chiffre un 5 (3 325). De même, la taxe (ici avec 20%) a sur le 3ème chiffre un 5 (0,665). Donc, si vous arrondissez et ajoutez les deux prix (ce que font paypal et magento), le total est de 0,01 euro de plus que le prix de base (4,00 euros).

Le bon calcul devrait être Eur 3,32 net + Eur 0,67 taxe = Eur 3,99

Comme nous essayons également de trouver une solution générale, nous essayons le correctif d'arrondi paypal!

il existe une relation générale entre les prix, la quantité, la remise, la taxe et leurs précisions.

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.

La question importante est le sous-total arrondi que je calcule avec le max. Erreur. 2 chiffres fractionnaires signifie 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)<1 => every y

Si vous souhaitez calculer avec des remises ou des taxes et que vous souhaitez recalculer le prix, l'explication suivante peut être intéressante pour vous. S'il vous plaît soyez conscient que je ne connais aucun cas dans le front-end, il est possible qu'il y ait un calcul interne. A) Total => Taxe / Remise => Total B) Taxe / Remise => Total => Taxe / Remise

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

Avec une précision de 2 chiffres, vous devez avoir un taux SANS CHIFFRES FRACTIONNELS. Exemple: Total: 15,15 taux d'imposition: 0,3% => taxe 0,04545 => arrondi 0,0455 taxe: 0,0455 => total: 15,17

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

si a est la précision, alors doit être y inférieur à a + 2.

Veuillez noter si vous gérez des quantités. L'erreur sera multipliée. Donc, si vous avez un maximum de 10 ^ 5, vous devez avoir une précision de 7. Ce n'est inquiétant que si vous calculez avec offset!

ADDITION (9.10.2013 Magento Version 1.7.0.2) Brutto <=> Netto and Taxes // America <=> old Europe Les ensembles sont des entiers (Cents) et le mappage
f (x) = round (a * x) a> 1 est pas bijectif. Dans mes mots: Pas pour tous les prix incl. existe un prix excl. ou Il y a parfois 2 prix incl. pour un prix excl. ou Vous pouvez obtenir 2 résultats différents selon la façon dont vous calculez

Exemple concret de l'Allemagne:

Vous essayez d'entrer un prix incl. taxes: 19,95 Vous obtenez 16,76 (2 chiffres) comme vos prix excl. les taxes (19%). Si vous calculez les taxes de 19%, vous obtenez (16,76 * 0,19) 3,18. (Soyez conscient: 19,95 * 019 / 1,19 ~ 3,19)

Il y a donc une différence de 1 cent. 16,76 => 19,94 16,77 => 19,96

Il n'y a pas de prix 19,95 en Amérique - Terre de Netto.

Calculez donc avec les prix d'origine autant que possible. Pour inclure les prix, utilisez le prix entré et les taxes (numéro cassé).

PayPal a ce contrôle de fraude - maintenant je ne suis pas sûr - mais PayPal ajoute juste le numéro que magento lui donne. voir http://fabiankrueger.de/blog/magento-und-paypayl-rundungsfehler/ Si ce n'est pas le cas et que PayPal recalcule la taxe ou le total, ce problème n'est pas résolu, sinon les prix - faux ou corrects - sont affichés auparavant dans Magento . Résolvez-le là-bas. Pour moi, cela semble fonctionner.