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


27

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.


Pour autant que je me souvienne, les prix des magasins Magento avec 4 décimales. Donc, si les prix sont entrés avec 4 décimales, le calcul est correct. Mais je peux me tromper.
user487772

1
Qu'entendez-vous par "entrée avec 4 points de déc."? Mais l'arrondi de Magento fonctionne avec 2 déc. points. Je pense aussi que l'interface PayPal fonctionne avec 2 déc. points - cela semble où le problème commence.
Alex

Si je me souviens bien, si vous entrez les prix en admin avec 4 décimales, ils seront enregistrés en db avec 4 décimales. Il sera ensuite arrondi à 2 points lors de la sortie, mais l'arrondi sera correct car le prix avec 4 décimales sera arrondi.
user487772

Bien sûr, mais nous avons principalement des problèmes avec le calcul total, surtout si des codes de coupon basés sur un pourcentage sont impliqués.
Alex

Oh, alors j'ai mal compris votre question. Désolé.
user487772

Réponses:


10

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


Génial! Existe-t-il une sorte de suite de tests pour montrer quels problèmes seront abordés?
Alex

1
Chuck, cela vous dérangerait de configurer vos informations utilisateur afin de vérifier?
benmarks

Les tests sont uniquement internes. En ce qui concerne plus de détails sur les problèmes d'arrondi connus - c'est un peu intéressant. Un client les considérerait comme étant associés à certaines configurations de taxe en utilisant des combinaisons spécifiques de prix, de taux de taxe, de remises, etc. Notre approche pour 1.13 a été d'identifier les configurations de taxe courantes et de garantir que # combinaisons ne produiront pas mathématiquement des erreurs d'arrondi et marqueront certaines configurations (petits cas de coin) comme configurations dangereuses qui devraient être évitées.
Chuck

Un peu hors sujet, mais cela signifie-t-il qu'il y aurait également une édition CE 1.8?
Sergei Guk

Oui - CE publie un retard d'environ un mois sur les versions EE. 1.13 est la prochaine version d'EE.
Chuck

7

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


1
Hm .. quel bug corrige-t-il exactement? On dirait le bogue cart-line-items-transfer. En fait, nous avons désactivé le transfert par chariot. Et doit-il être appliqué avec le patch d'arrondi à 4 chiffres?
Alex

Y a-t-il plus d'un problème? Comme je l'ai dit, je n'ai aucune idée de ce qu'il résout exactement - s'il y a plus d'un problème :(
Fabian Blechschmidt

5

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!


génial, dites-moi si vous avez des problèmes, je suis impatient d'aider et de voir le Bugfix dans la nature et de le déboguer si nécessaire!
Fabian Blechschmidt

1
Pour info, le problème que vous avez décrit est résolu dans notre prochaine version (1.8 CE / 1.13 EE).
Chuck

@Chuck Je viens de tester ce scénario avec Mage_Tax_Model_Sales_Total_Quote_Tax de 1.13.0.1 et il semble avoir résolu le problème en tant que remplacement sans rendez-vous dans un projet 1.12. Merci beaucoup. Existe-t-il encore un ETA pour 1.8CE?
Jonathan Day

4

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)&lt;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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.