GuillaumeCW Posted March 5, 2016 Share Posted March 5, 2016 (edited) Suivi du rapport d'erreur équivalent à ce beug : http://forge.prestashop.com/browse/PSCSX-7566 Message d'origine : Quote Bonjour, Dans une boutique avec une TVA à 21% sous Prestashop 1.6.1.4, j'ai un produit à 150 € TTC, avec une déclinaison ayant un impact sur le prix de 10 € TTC. Sur la page du produit en front (et dans le générateur de déclinaisons), le prix affiché avec cette déclinaison sélectionnée est 159,99 € TTC, au lieu de 160,00 € TTC. L'erreur vient de l'arrondi qui est effectué sur le prix HT, qui est assigné dans la variable smarty $combinations[], au lieu d'effectuer cet arrondi sur le prix TTC. En effet, la valeur enregistrée dans la base de données est 8.264463 pour un impact TTC renseigné de 10 €. Arrondie, via le contrôleur Produit, l'utilitaire Tools et sa méthode ConvertPriceFull, cette valeur devient 8.26. Avec la TVA appliquée, 8.26 devient 9.9946. Le prix TTC affiché est ainsi 159,99. Le problème est le même pour l'affichage dans le générateur de déclinaisons. Si l'on y indique 10 € TTC et qu'on génère les déclinaisons, 9.99 est affiché sur la page du générateur après la génération. Cet arrondi semble s'effectuer autrement pour le calcul du panier, où le prix est bien de 160 € TTC. De la même façon, en éditant individuellement la déclinaison, l'impact sur le prix affiché est bien 10 € TTC. Edited March 6, 2016 by GuillaumeCW (see edit history) Link to comment Share on other sites More sharing options...
Eolia Posted March 6, 2016 Share Posted March 6, 2016 Sauf que dans le cas présent, ce n'est même pas un problème d'arrondi mais de truncate, car 125,00 (HT) + 8.333333(HT) = 133.333333 133.333333 + 20% = 159.999999 Un arrondi aurait donné 160,00 TTC Link to comment Share on other sites More sharing options...
GuillaumeCW Posted March 6, 2016 Author Share Posted March 6, 2016 On 3/6/2016 at 7:59 AM, Eolia said: Sauf que dans le cas présent, ce n'est même pas un problème d'arrondi mais de truncate, car 125,00 (HT) + 8.333333(HT) = 133.333333 133.333333 + 20% = 159.999999 Un arrondi aurait donné 160,00 TTC Non, la boutique utilise une TVA à 21%. Link to comment Share on other sites More sharing options...
erouvier29 Posted March 6, 2016 Share Posted March 6, 2016 Depuis son introduction (feue 1.6.0.10 ?) _PS_PRICE_COMPUTE_PRECISION_ est faux ?!? define('_PS_PRICE_COMPUTE_PRECISION_', _PS_PRICE_DISPLAY_PRECISION_); N'y a-t-il pas eu un "Et pendant ce temps là chez #prestashop" ? Mettez plutôt 6... (/config/config.inc.php) Link to comment Share on other sites More sharing options...
GuillaumeCW Posted March 6, 2016 Author Share Posted March 6, 2016 (edited) On 3/6/2016 at 8:23 AM, erouvier29 said: Depuis son introduction (feue 1.6.0.10 ?) _PS_PRICE_COMPUTE_PRECISION_ est faux ?!? define('_PS_PRICE_COMPUTE_PRECISION_', _PS_PRICE_DISPLAY_PRECISION_); N'y a-t-il pas eu un "Et pendant ce temps là chez #prestashop" ?Mettez plutôt 6... (/config/config.inc.php) Ça marche effectivement. Moment de fatigue hier soir, car il m'avait alors semblé que sur cette déclaration de globale, j'allais modifié la précision d'affichage des prix, et non celle de calcul. Mon expérience est encore très courte avec Prestashop. Mais j'ai effectivement trouvé un post centralisant les tests sur les arrondis, censé aboutir à des résolutions à rendre disponible dans une version 1.6.0.10 qui n'a jamais vu le jour. Je n'ai pas poussé la curiosité à aller connaître le mot de la fin. Bref, une modification du fichier config.inc.php est-elle considérée comme une solution pérenne, ou faut-il attendre une MAJ, et donc faire un rapport de beug autre part que sur ce forum ? Merci pour cette aide dans tous les cas. Edit (oups...) : Quote Fichier config.inc.php La plupart des données de ce fichier sont mises en place lors de l'installation de PrestaShop, et ne devraient donc pas être éditées à la main. Modifiez ce fichier à vos risques et périls. http://doc.prestashop.com/pages/viewpage.action?pageId=26148921#Guidedel'administrateursystème-Fichierconfig.inc.php Edited March 6, 2016 by GuillaumeCW (see edit history) Link to comment Share on other sites More sharing options...
erouvier29 Posted March 6, 2016 Share Posted March 6, 2016 Le risque c'est que votre boutique marche mieux. Le péril, je vois pas... Link to comment Share on other sites More sharing options...
GuillaumeCW Posted March 6, 2016 Author Share Posted March 6, 2016 Le péril ne peut-il pas être de voir ce fichier écrasé par une mise à jour ? Quote DISCLAIMER * * Do not edit or add to this file if you wish to upgrade PrestaShop to newer * versions in the future. [...] Link to comment Share on other sites More sharing options...
erouvier29 Posted March 6, 2016 Share Posted March 6, 2016 Pardon, je n'avais pas lu votre commentaire en entier... Oui, cette modif manuelle sera écrasée à la prochaine mise à jour. A moins que la PR https://github.com/PrestaShop/PrestaShop/pull/5131 ne soit acceptée d'ici là. Il faut parfois plusieurs années... Link to comment Share on other sites More sharing options...
GuillaumeCW Posted March 6, 2016 Author Share Posted March 6, 2016 Merci. J'ai indiqué le sujet "résolu" et dans le premier message, votre solution provisoire et le lien vers votre PR sur Github. Link to comment Share on other sites More sharing options...
Eolia Posted March 6, 2016 Share Posted March 6, 2016 le souci du patch proposé, c'est que si cela va corriger votre problème d'affichage en front, cela va faire planter les calculs au niveau des paiements et des cartrules... genre classe PaymentModule: $order->total_paid_tax_excl = (float)Tools::ps_round((float)$this->context->cart->getOrderTotal(false, Cart::BOTH, $order->product_list, $id_carrier), _PS_PRICE_COMPUTE_PRECISION_); $order->total_paid_tax_incl = (float)Tools::ps_round((float)$this->context->cart->getOrderTotal(true, Cart::BOTH, $order->product_list, $id_carrier), _PS_PRICE_COMPUTE_PRECISION_); $order->total_paid = $order->total_paid_tax_incl; $order->round_mode = Configuration::get('PS_PRICE_ROUND_MODE'); $order->round_type = Configuration::get('PS_ROUND_TYPE'); // Amount paid by customer is not the right one -> Status = payment error // We don't use the following condition to avoid the float precision issues : http://www.php.net/manual/en/language.types.float.php // if ($order->total_paid != $order->total_paid_real) // We use number_format in order to compare two string if ($order_status->logable && number_format($cart_total_paid, _PS_PRICE_COMPUTE_PRECISION_) != number_format($amount_paid, _PS_PRICE_COMPUTE_PRECISION_)) { $id_order_state = Configuration::get('PS_OS_ERROR'); } Sauf que pour Paypal, par exemple: $currency_decimals = is_array($this->currency) ? (int)$this->currency['decimals'] : (int)$this->currency->decimals; $this->decimals = $currency_decimals * _PS_PRICE_DISPLAY_PRECISION_; $fields['L_PAYMENTREQUEST_0_AMT'.$index] = Tools::ps_round($product['price_wt'], $this->decimals); et $fields['L_PAYMENTREQUEST_0_AMT'.$index] = Tools::ps_round($shipping_cost_wt, $this->decimals); ... Link to comment Share on other sites More sharing options...
GuillaumeCW Posted March 6, 2016 Author Share Posted March 6, 2016 (edited) Ok. J'édite le sujet et le premier message.J'ai retrouvé le commit avec le changement de méthode, consistant à arrondit le HT de la combinaison, plutôt que son TTC. Je lirai ça plus tard, mais je pense que dans l'immédiat, je me pencherai vers une surcharge du ProductController. https://github.com/PrestaShop/PrestaShop/commit/40717fa6ec33427084bf3ec4a9c26f2c77acbdbchttp://forge.prestashop.com/browse/PSCSX-7021Edit : j'ai également trouvé un report de ce beug sur le Forge Prestashop. http://forge.prestashop.com/browse/PSCSX-7566 Convertir ceci : $combinations[$row['id_product_attribute']]['price'] = (float)Tools::convertPriceFull($row['price'], null, Context::getContext()->currency); ... et ceci : $combinations[$row['id_product_attribute']]['unit_impact'] = Tools::convertPriceFull($row['unit_price_impact'], null, Context::getContext()->currency); ... en respectivement cela : $combinations[$row['id_product_attribute']]['price'] = (float)Tools::convertPrice($row['price'], null, Context::getContext()->currency); ... et cela : $combinations[$row['id_product_attribute']]['unit_impact'] = Tools::convertPrice($row['unit_price_impact'], null, Context::getContext()->currency); ...permet effectivement de résoudre le problème. Edited March 6, 2016 by GuillaumeCW (see edit history) Link to comment Share on other sites More sharing options...
erouvier29 Posted March 6, 2016 Share Posted March 6, 2016 On 3/6/2016 at 9:49 AM, Eolia said: le souci du patch proposé, c'est que si cela va corriger votre problème d'affichage en front, cela va faire planter les calculs au niveau des paiements et des cartrules... Tu as complètement raison ! (Et personne n'en doutait ;-) En étant de totale mauvaise foi, je dirais qu'avant que le patch soit intégré, ça laisse un peu de temps pour reprendre toutes les occurrences de _PS_PRICE_DISPLAY_PRECISION_ (une trentaine en décompte rapide) et de _PS_PRICE_COMPUTE_PRECISION_ (une centaine de plus) et utiliser la bonne constante aux bons endroits... On devrait aussi éviter de vendre en Belgique via PrestaShop un produit à 150€ avec un surcoût de 10€ pour une déclinaison particulière ! GuillaumeCW, vous exagérez, je trouve... Link to comment Share on other sites More sharing options...
erouvier29 Posted March 7, 2016 Share Posted March 7, 2016 Ce patch, très localisé, limite l'impact: https://github.com/PrestaShop/PrestaShop/pull/5135 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now