Jump to content

Arrondi De Prix Ht Sur Les Combinaisons De Produits


GuillaumeCW

Recommended Posts

Suivi du rapport d'erreur équivalent à ce beug : http://forge.prestashop.com/browse/PSCSX-7566

 

Message d'origine :
 

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 by GuillaumeCW (see edit history)
Link to comment
Share on other sites

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

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

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

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...) :

 

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 by GuillaumeCW (see edit history)
Link to comment
Share on other sites

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

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/40717fa6ec33427084bf3ec4a9c26f2c77acbdbc
http://forge.prestashop.com/browse/PSCSX-7021

Edit : 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 by GuillaumeCW (see edit history)
Link to comment
Share on other sites

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

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...