Je cherche à corriger un BUG PS1.3.7 : Erreur de calcul de 1 ct avec prix dégressifs, taxe desactivée provoque une erreur paiement Paypal

[jolvil]

EDIT: Une modif semble fonctionner, voir post [ # 9 ]
--------------------------------------------------------------------------------------

Bug confirmé sur PS 1.3.7,
Ce bug rovoque une erreur de paiement avec le paiment Paypal

Install toute fraiche,

Thème de base

Taxes desactivées

J'ai créé 2 produits:
Produit A 2.50 euros reduction par quantité 5% à partir de 2
Produit B 1.80 euros reduction par quantité 5% à partir de 2

Si on met 2 produits A et 3 produits B dans le panier on a une erreur de 1 ct sur le total ce qui provoquera une erreur de paiement Paypal.

Si on réactive la taxe, le total est bon
Si les réductions par quantités sont en montant fixe (et non en pourcentage) le calcul est bon

Il y a donc une erreur dans l'addition faite par Prestashop dans ce cas mais pas par Paypal, d'ou l'erreur de paiement.
Le probleme doit se situer au niveau des arrondis.

Voir la capture ( ou l'on voit que le total du panier 16.88 est faux, il devrait afficher 16.89 )

Si l'un d'entre vous avait une piste ou un patch.... :cheese:

[jolvil]

Si je choisi arrondi classique, supérieur ou inférieur, le total reste le même: 16.88. Un des prix avec la reduction en pourcentage change, soit 2.37 ou 2.38.

Mais quelque soit le mode d’arrondi le total est faux, soit il y a 1 centime de plus, soit il y a 1 centime de moins.

C’est comme si le total était calculé sans tenir compte des arrondis, dans mon cas un des prix réduit est de 2.50 × 5% soit 2.375, si on prend en compte ce chiffre tel quel , le total est bon, si on l’arrondi a 2.37 ou 2.38, le total est faux.

[prosilver]

Jolvil,
ahhhh, ce fameux bug, j'ai longtemps planché sur cette .......@#"$ de *!?¤^< (modéré par moi-même !)
Je n'ai pas tout à fait la même config mais pour ma part ce probleme est résolu.

[jolvil]

Ouf je ne suis pas seul !!

Tu me dis avoir résolu ton probleme

aurais tu un correctif pour en faire profiter tout le monde?

Pour l'instant la seule solution que j'ai est de passer mes reductions par quantité en montant fixe au lieu de pourcentage. C'est dommage car ca prend du temps et enleve une possibilité à Prestashop et oblige à tout recalculer et changer à chaque changement de prix du produit.

[prosilver]

Salut jolvil,

mes reductions par quantité en montant fixe au lieu de pourcentage

Effectivement, quel boulot !

Premièrement,
si cela peut t'aider, c'est avec plaisir mais pourquoi n'installes-tu pas directement
la nouvelle version ? Elle ne règle toujours pas ce problème ? Nonnnnnnn !
Deuxièmement,
qui n'a rien à voir avec toi mais pourquoi n'écris-tu pas ton sujet en gras majuscule et aussi en rouge,
avec pour titre du genre ' A L'AIDE-AU SECOUR-HELP JÉ EFACÉ MA BASE DE DONÉ COMMENT L'A REQUPERER '
Visiblement, ces messages ont plus de chance d'avoir une réponse, regarde ici,
plus de 700 lectures et pas une réponse...... , pardon, ah si une.........
J'apprécie cette communauté mais parfois j'ai du mal à comprendre !
Voila ça c'est vu aussi.

Il y a bien un problème d'arrondi mais je ne sais plus quel fichier j'ai modifié,
si tu peux me remettre sur la piste.

+

[jolvil]

Le truc c'est que je ne suis pas programmeur, je bricole avec les infos du forum mais mes compétences sont plus que limitées. Pour le forum, rassure toi ca fait 2 ans que je suis Prestashop et j'ai posté une multitude de messages qui sont souvent restés sans réponses et j'ai souvent fini par trouver les solutions seul... donc je ne me fais plus beaucoup d'illusion... mais on sait jamais :cheese: .

En attendant de trouver le bug je me demande si je peux éviter le message d'erreur pour le centime de différence. Le client paye et il n'y a pas un warning pour dire que tout va mal.

Dans classes/PaymentModule.php on a

            // Amount paid by customer is not the right one -> Status = payment error
           if ($order->total_paid != $order->total_paid_real)
               $id_order_state = _PS_OS_ERROR_;

Si je commente ces lignes pour éviter le message d'erreur, est ce que je ne vais pas créer d'autres problèmes?

surce post http://www.prestashop.com/forums/viewthread/83291 je peux lire ca mais il n'y a pas de solution

In “modules/paypal/redirect.php” the order total cost is set like this:

‘total’ => floatval($cart->getOrderTotal(true, 3)),

In “classes/PaymentModule.php” the following two values are used:

$order->total_paid_real = $amountPaid;
$order->total_paid = floatval(Tools::ps_round(floatval($cart->getOrderTotal(true, 3)), 2));

So theoretically, both should return the same amount

[prosilver]

Re,
alors déception également de mon coté, j'ai une erreur de calcul quand le produit est
remisé mais apparemment pas quand il y a des remises par quantité !

Un correctif pour la facture pdf HT vers la ligne 773, classes>PDF.php:

$product['priceWithoutTax'] = Tools::ps_round(self::$_priceDisplayMethod == PS_TAX_EXC ? floatval($product['product_price']) : $product['product_price_wt_but_ecotax'] / (1 + $product['tax_rate'] / 100), 2) * (int)($product['product_quantity']);
           $amountWithoutTax += $product['priceWithoutTax'];

par

$product['priceWithoutTax'] = (self::$_priceDisplayMethod == PS_TAX_EXC ? Tools::ps_round((float)($product['product_price']), 2) : ($product['product_price_wt_but_ecotax'] / (1 + $product['tax_rate'] / 100))) * (int)($product['product_quantity']);
           $amountWithoutTax += $product['priceWithoutTax'];

Bon je te rassure, nous ne devons pas avoir les mêmes systèmes de calcul lors de
la conception de code, va si la démo en ligne, tu as plein d'amis à qui tu veux faire
plaisir et tu achètes 30 iPod Nano remisé à 5%.
Je te laisse faire le calcul du HT et de la TVA !!!

[jolvil]

Bon je te rassure, nous ne devons pas avoir les mêmes systèmes de calcul lors de
la conception de code, va si la démo en ligne, tu as plein d’amis à qui tu veux faire
plaisir et tu achètes 30 iPod Nano remisé à 5%.

Rappel: J'ai fais mon test sur une 1.3.7 réinstallée spécialement, toute vierge! taxe desactivée - Mon bug est reproductible: 1 produit à 2.50 avec une reduction par quantité de 5 %, j'en mets deux dans mon panier et j'ai une erreur sur le total de 1 ct. le prix discount a 3 decimal, il y a un probleme d'arrondi causant l'erreur - Avec 2 produit B, pas de probleme, dans ce cas le calcul du discount n'a pas besoin d'arrondi, il n'a que 2 decimale.

Pour la demo sur le site Prestashop.com, bien que le site indique une version 3.3, on voit bien que le panneau de connection au back office est celui de la 1.4 !

[Broceliande]

Bonjour,
Je crois avoir corrigé ce bug sur une 3.1.1 il y a un petit moment pour un client qui avait des erreurs paypal , je vais fouiller pour voir. De mémoire j'avais du toucher au core mais ou.... je vais regarder.

[jolvil]

J'ai fait une modif qui semble resoudre le problème, le total devient bon avec les prix par quantité, taxe desactivé... à voir si ca pose pas d'autres problemes.

dans class/cart.php

j'ai changé ligne 664

                $price = Product::getPriceStatic(intval($product['id_product']), $withTaxes, intval($product['id_product_attribute']), 6, NULL, false, true, $product['cart_quantity'], false, (intval($this->id_customer) ? intval($this->id_customer) : NULL), intval($this->id), (intval($this->id_address_delivery) ? intval($this->id_address_delivery) : NULL));

en

                $price = Product::getPriceStatic(intval($product['id_product']), $withTaxes, intval($product['id_product_attribute']), 2, NULL, false, true, $product['cart_quantity'], false, (intval($this->id_customer) ? intval($this->id_customer) : NULL), intval($this->id), (intval($this->id_address_delivery) ? intval($this->id_address_delivery) : NULL));

...['id_product_attribute']), 6,... devient ...['id_product_attribute']), 2,...

[Asenar]

Bonjour,

Merci d'avoir posté donc

Dans mon passé de développeur, je me suis arraché les cheveux à cause des problèmes d’arrondis, avant de trouver que le problème venait d'un bug de conversion de type entre mysql (le type de champ "float" ou "double" n'est pas recommandé pour les prix) + un bug de php (qui doit être toujours présent je crois).

Pouvez vous vérifier (et confirmer) que le type des champs pour les prix et les pourcentages est bien decimal ?

Si le problème est résolu complètement avec ça ( la modification ligne 664 ), ça va être à faire dans la 1.4.1 qui sort

[jolvil]

Pouvez vous vérifier (et confirmer) que le type des champs pour les prix et les pourcentages est bien decimal ?

Je ne vois pas comment faire cela

Si le problème est résolu complètement avec ça ( la modification ligne 664 ), ça va être à faire dans la 1.4.1 qui sort

Attention je n'ai pas trouvé ce problème avec la 1.4. J'ai testé la 1.4 avec la même configuration (taxe desactivée, prix par quantité, arrondi classique) et il n'y a pas de problème d'erreur de total.
Il y a une différence quand même: au lieu d'arrondir à 2.38 comme le fait PS1.37, la 1.4 arrondi à 2.37 pour 2.50*5% (2.375), le total du panier semble correspondre au total du module Paypal ...tant que l'on est juste, il n'y a rien à redire.

[Broceliande]

Bonjour,

Merci d'avoir posté donc

Dans mon passé de développeur, je me suis arraché les cheveux à cause des problèmes d’arrondis, avant de trouver que le problème venait d'un bug de conversion de type entre mysql (le type de champ "float" ou "double" n'est pas recommandé pour les prix) + un bug de php (qui doit être toujours présent je crois).

Pouvez vous vérifier (et confirmer) que le type des champs pour les prix et les pourcentages est bien decimal ?

Si le problème est résolu complètement avec ça ( la modification ligne 664 ), ça va être à faire dans la 1.4.1 qui sort

Je comprends ta douleur , les arrondis sont une spécialité abominable.

La modif de jolvil bien que très proche résout en partie le problème mais ne l'explique pas.

Je n'ai pas retrouvé ma modif, car après réflexion il y avait un cas particulier : les prix avaient été tous importés, et l'arrondi à 6 chiffre posait problème. Pour moi un update bien senti sur les champs prix ht de la table product avait fait la pige.
Mais j'ai retrouvé le bout de code qui m'avait semblé particulier :
Paypal utilise la fonction Cart::getOrderTotal pour le prix de la commande, dans laquelle une boucle crée, à mon sens , une incohérence d'arrondi :

        foreach ($products AS $product)
       {
           if ($this->_taxCalculationMethod == PS_TAX_EXC)
           {
               // Here taxes are computed only once the quantity has been applied to the product price
               $price = Product::getPriceStatic(intval($product['id_product']), false, intval($product['id_product_attribute']), 2, NULL, false, true, $product['cart_quantity'], false, (intval($this->id_customer) ? intval($this->id_customer) : NULL), intval($this->id), (intval($this->id_address_delivery) ? intval($this->id_address_delivery) : NULL));
               $total_price = $price * intval($product['cart_quantity']);
               if ($withTaxes)
               {
                   $total_price = Tools::ps_round($total_price * (1 + floatval(Tax::getApplicableTax(intval($product['id_tax']), floatval($product['rate']))) / 100), $this->id_address_delivery);
                   Product::applyEcotax($total_price, $product['ecotax'], true, $this->id_address_delivery ? intval($this->id_address_delivery) : NULL);
               }
           }
           else
           {
               $price = Product::getPriceStatic(intval($product['id_product']), $withTaxes, intval($product['id_product_attribute']), 6, NULL, false, true, $product['cart_quantity'], false, (intval($this->id_customer) ? intval($this->id_customer) : NULL), intval($this->id), (intval($this->id_address_delivery) ? intval($this->id_address_delivery) : NULL));
               if (!$withTaxes)
                   $total_price = Tools::ps_round($price * intval($product['cart_quantity']), 2);
               else
                   $total_price = Tools::ps_round($price, 2) * intval($product['cart_quantity']);
           }
           $order_total += $total_price;
       }

Ce bout de code ne tient, lui , absolument pas compte de la precision.
Au delà , il va même jusqu'à mixer les genres :

            else
           {
               $price = Product::getPriceStatic(intval($product['id_product']), $withTaxes, intval($product['id_product_attribute']), 6, NULL, false, true, $product['cart_quantity'], false, (intval($this->id_customer) ? intval($this->id_customer) : NULL), intval($this->id), (intval($this->id_address_delivery) ? intval($this->id_address_delivery) : NULL));
               if (!$withTaxes)
                   $total_price = Tools::ps_round($price * intval($product['cart_quantity']), 2);
               else
                   $total_price = Tools::ps_round($price, 2) * intval($product['cart_quantity']);
           }

On retourne un résultat arrondi à 2 decimales, mais en multipliant un prix à 6 décimales par la quantité.
La précision s'en trouve donc améliorée , dans l'absolu , sauf que order-detail crée un objet order et utilise la method getProducts de la classe Order,
si on trace , on se retrouve avec l'appel de setProductPrices(&$row) , ou les arrondis sont tous à 2 décimales, d'ou la différence et le fait que la modif de jolvil donne un résultat , mais insuffisant à mon sens

Brr , je me demande si je suis clair :s

[Broceliande]

Un petit exemple pour appuyer ma thèse :

        if ($row['reduction_percent'])
       {
           if ($this->_taxCalculationMethod == PS_TAX_EXC)
               $row['product_price'] = $row['product_price'] - $row['product_price'] * ($row['reduction_percent'] * 0.01);
           else
               $row['product_price_wt'] = Tools::ps_round($row['product_price_wt'] - $row['product_price_wt'] * ($row['reduction_percent'] * 0.01), 2);
       }

Si on lit bien :

pas de taxe = pas d'arrondi , une taxe = arrondi. Ce qui explique la différence notée par jolvil lors de la désactivation des taxes.

On peut donc supposer , le champ étant un decimal ,6 , qu'ici , une modification de

$row['product_price_wt'] = Tools::ps_round($row['product_price_wt'] - $row['product_price_wt'] * ($row['reduction_percent'] * 0.01), 2);

en

$row['product_price_wt'] = Tools::ps_round($row['product_price_wt'] - $row['product_price_wt'] * ($row['reduction_percent'] * 0.01), 6);

pourrait résoudre le seul problème rencontré par jolvil

[jolvil]

Bravo pour l'explication, moi j'y vais au pif avec une méthode très empirique et casse cou, ca passe ou ca casse, c'est quand même beaucoup mieux de comprendre ce que l'on fait... il faudrait que je me fasse greffer un cerveau de developpeur :cheese:

Par contre tu parles d'un problème d'arrondi avec Paypal alors que justement le montant Paypal était bien calculé alors que le total du panier lui était faux.

J'ai tenté la modif ligne 339 du fichier classes/order.php en changeat le 2 en 6

            if ($this->_taxCalculationMethod == PS_TAX_EXC)
               $row['product_price'] = $row['product_price'] - $row['product_price'] * ($row['reduction_percent'] * 0.01);
           else
               $row['product_price_wt'] = Tools::ps_round($row['product_price_wt'] - $row['product_price_wt'] * ($row['reduction_percent'] * 0.01), 6);
       }

mais cela n'a pas d'effet sur le panier, l'erreur du total est toujours présente. Ta modif se fait elle sur un autre fichier?

[Broceliande]

Sorry pour le détail ... plutôt destiné à Michaël Marinetti .
J'ai creusé un peu plus en amont , si je devais expliquer mon raisonnement de manière plus simple.
Ta modif fonctionne, parce qu'elle modifie un paramètre appelant . Elle est donc efficace, mais pas suffisante à mon sens si on parle de résoudre le véritable bug , qui se situe derrière.

Si tu veux bien , tu peux tester ce dont je parle en tout dernier :

soit modifier

 $row['product_price_wt'] = Tools::ps_round($row['product_price_wt'] - $row['product_price_wt'] * ($row['reduction_percent'] * 0.01), 2);

en

 $row['product_price_wt'] = Tools::ps_round($row['product_price_wt'] - $row['product_price_wt'] * ($row['reduction_percent'] * 0.01), 6);

dans /classes/Order.php , dans la fonction

setProductPrices(&$row)

et bien sûr remettre la ligne de code que tu as modifié tel qu'à l'origine (pour le test)

Quand je parle d'une erreur d'arrondi paypal , je n'implique pas le module paypal directement, je parle du résultat final : une erreur de paiement dans L'admin Orders, due à cette erreur d'arrondi.
Dans ce type d'erreur, on peut partir du principe que les deux arrondis sont justes. Simplement ils ne correspondent pas.
L'idée est de chercher au plus bas niveau ce qui crée la différence, pour que l'erreur native soit identifiée et corrigée, et non juste contournée.

Hmm je suis pas sûr d'avoir été plus clair là , lol

[jolvil]

Je suis désolé mais j'ai bien fait la modification dans classes/order.php comme tu l'indiques et cela n'a aucun effet sur l'erreur du total. :-S

[Broceliande]

ok , merci d'avoir testé et ne soit pas désolé , en débug on ne gagne pas à tous les coups...
Surtout que là je n'ai fais que tenter d'isoler la partie de code que je soupçonne 'verreuse' , si j'avais un peu plus de temps je pousserais plus loin , mais j'en manque cruellement :s

[jolvil]

Heureusement ma petite solution semble bien fonctionner sinon je ne serais pas trés avancé ;-) Merci pour la tentative

[blasto]

Solution ICI :
http://www.prestashop.com/forums/viewthread/66154/modules_tiers/probleme_paypal__quotobjet_incorrectement_formate_quot

Enfin je pense ...

Confirmé ?

[Broceliande]

C'est effectivement une solution, mais en aval, je cite :

avec ajout de l’arrondi (|round:2) sur le prix individuel de l’article

 <input type="hidden" name="amount_{$k+1}" value="{$product.price_wt|round:2}" />

Le correctif de jolvil est déja plus 'propre' car il agit en amont , en effet $product.price_wt devrait avoir un arrondi correct et il ne devrait pas être nécessaire d'agir sur le tpl.

Et au final , personne n'a encore isolé et corrigé le bug réel au plus bas niveau

Je n'ai pas poursuivi ma recherche d'ailleurs , mais si j'ai du temps ....

[Asenar]

Merci beaucoup jusque là, vos précisions nous aident beaucoup, dès qu'on trouve on postera le correctif ici, sauf si vous le trouvez avant !

[SimplyConcept]

bonjour a tous
je vois que le probleme n'est toujours pas résolu depuis 2008, ca fait un peu long, mais je pense que vous faites fausse route. Le probleme ne vient pas de Paypal, du panier ou même de order, mais il faut aller le chercher a la base. C'est à dire dans le back office .....
En réalité, il faut reprendre tous vos produits un a un et réduire le prix a 2 décimales et le probleme est résolu.
J'explique :
Lors de la création de votre article ou produit, vous entrez les prix d'achat et vente HT et TTC, après la mise a jour, il vous balance un prix avec 6 décimales. Corriger tout simplement en mettant que 2 décimales dans le TTC.

Ex : si vous avez un prix TTC comme cela : 14.387880
Mettre : 14.39 et faite la mise a jour
Vous obtiendrez un prix : 14.390001 TTC

en faisant cela plus de probleme lors de la multiplication de produit en quantité.

Sinon passer en mode supérieur avec cette modif :
Remplacer ces deux fonctions dans /js/price.js (dela ligne 10 à 26)

function formatPrice(price)
{
   var fixedToSix = (Math.round(price * 100) / 100);
   return (Math.round(fixedToSix) == fixedToSix + 0.000001 ? fixedToSix + 0.000001 : fixedToSix);
}

function calcPriceTI()
{
   var tax = getTax();
   var priceTE = parseFloat(document.getElementById('priceTE').value);
   var newPrice = priceTE *  ((tax / 100) + 1);
   document.getElementById('priceTI').value = (isNaN(newPrice) == true || newPrice < 0) ? '' : 
                                               formatPrice(newPrice).toFixed(2);
   document.getElementById('finalPrice')[removed] = (isNaN(newPrice) == true || newPrice < 0) ? '' : 
                                               formatPrice(newPrice).toFixed(2);
   calcReduction();
}

[Broceliande]

C'est probablement la meilleure piste jusque là . il est vrai que le js calcule lui même l'arrondi lorsqu'on entre le ttc.
Mais celà n'explique pas tout, le probleme rencontré par Jolvil n'intervient que sur les tarifs dégressifs.
Or ces tarifs dégressifs ne sont pas gérés en js
Il y a donc bien un bemol plus en amont , dans une des classes utilisée pour obtenir le prix produit.

En réalité, il faut reprendre tous vos produits un a un et réduire le prix a 2 décimales et le probleme est résolu

Oui ça c'est donc vrai si et seulement si on a des pb d'arrondi sur le tarif produit standard .
Ca arrive facilement après un import ...
Mais une reqûete sql suffit à rétablir le tout en une fois sans avoir à éditer produit par produit , j'avais fais ça pour un client (7000 référence à éditer celà ne m'enchantait guère).
La requete ? pfioou faudrait que je la refasse, c'est vieux , mais si j'y pense je la posterais.

[jolvil]

Je rapelle que le probleme est présent dans mon cas quand les taxes sont desactivées, le calcul est correct avec les taxes.

Dans mon BO si je rentre un prix HT de 2.50, celui ci est converti en 2.500000, le prix TTC indique 2.5.

[Broceliande]

Je rapelle que le probleme est présent dans mon cas quand les taxes sont desactivées, le calcul est correct avec les taxes.

Dans mon BO si je rentre un prix HT de 2.50, celui ci est converti en 2.500000, le prix TTC indique 2.5.

Oui merci de préciser . mais je ne me trompe pas , pb avec les taxes , mais avec tarifs dégressifs ?

[Broceliande]

Au fait Jolvil , aurais tu un clone en ligne de ta boutique (pour tes tests) . Ce qui me freine jusque là est que je manque de temps pour me faire une 1.3.7 vierge sur laquelle je ne bosse pas déja et entrer un produit jusqu'à ce que je trouve des montants qui reproduisent le bug.
Donc si tu as ça sous le coude avec le bug bien présent , j'aurais pu tracer et ajouter un peu de débug pour isoler la pomme pourrie...

[Broceliande]

Bon j'ai trouvé ce qui causait la différence entre taxes activées et non activées.
Jolvil tu étais juste une ligne au dessus !
Ton correctif est sain , même s'il n'expliquait pas d'ou venait la différence.
Elle s'explique ici :
Autour de la ligne 650 dans cart.php on avait :

                if (!$withTaxes)
                   $total_price = Tools::ps_round($price * intval($product['cart_quantity']), 2);
               else
                   $total_price = Tools::ps_round($price, 2) * intval($product['cart_quantity']);

$withTaxes est à false si on a désactivé les taxes dans le BO ...

On voit ici que le prix du produit obtenu une ligne au dessus (celle que tu as modifié ) avec une précision de 6, est
tout d'abord multiplié par la quantité et ensuite arrondie à 2 décimales

La ligne en dessous , en revanche ,
l'arrondi à 2 décimales est fait avant la multiplication par la quantité

Il faut corriger ainsi :
if (!$withTaxes)
$total_price = Tools::ps_round($price, 2) * intval($product['cart_quantity']);
else
$total_price = Tools::ps_round($price, 2) * intval($product['cart_quantity']);

il est logique d'arrondir avant de multiplier , faute de quoi nous aurions la possibilité d'avoir un prix unitaire faux.

En temps normal , quand c'est la précision que l'on cherche , on arrondit seulement à la fin, ce qui bien plus précis.

C'est le cas pour les %ages de réduction , pour les taxes etc ... si on veut éviter les erreurs il faut faire les calculs avec la précision la plus élevée possible (6 dans presta compte tenu du type de champs , float )

Mais :

Ici ce qu'on cherche c'est que le résultat prix calculé * quantité soit le même que le prix unitaire affiché * quantité
Le prix unitaire que l'on affiche ayant une précision de 2 , l'arrondi doit se faire avant ...

J'espère que notre ami de la prestateam passera par là

[jolvil]

Si on modifie comme tu dis on a 2 lignes identiques: si il n'y a pas taxes if (!$withTaxes).. on fait une chose... sinon (else)...on fait la meme chose.. donc la condition n'a plus d'utilité.

if (!$withTaxes)
$total_price = Tools::ps_round($price, 2) * intval($product[‘cart_quantity’]);
else
$total_price = Tools::ps_round($price, 2) * intval($product[‘cart_quantity’]);

La condition (!$withTaxes) ne semble pas justifiée, on peut alors faire juste

$total_price = Tools::ps_round($price, 2) * intval($product[‘cart_quantity’]);

Avec juste cette ligne le calcul est bon

[Broceliande]

oui absolument ! je ne suis même pas allé jusque là dans ma logique , lol , honte à moi

[jolvil]

Ce que je me demande c'est pourquoi le developpeur chez Prestashop a différencier les 2 modes de calcul !

[Broceliande]

Ce que je me demande c'est pourquoi le developpeur chez Prestashop a différencier les 2 modes de calcul !

Je pense qu'il y a eu de nombreuses retouches sur ce code , peut être par plusieurs personnes et avec des sacrés délais d'intervalle .
Ca peut expliquer d'autres bricoles que j'ai vu passer dans le code...
Pour avoir passer un sacré bout de temps à coder des précisions et arrondis en c# , je ne m'y perds pas trop , mais c'est vraiment un truc qui peut devenir cauchemardesque.

Dans un proche avenir , je vais m'intéresser à ce qui a été modifié sur la 1.4 . Si je vois passer les même trucs que j'ai repéré dans la 1.3.7 , alors je pense que j'irais jusqu'à suggérer une ou deux méthodes réécrites, histoire de rendre le code plus clair . J'ai vu passer énormément de round coup sur coup , lorsqu'un seul est nécesaire par exemple.

Lorsqu'on a un prix unitaire , voué à être multiplié , comme je l'ai détaillé plus haut, on a besoin d'arrondir ce dernier avant traitement. C'est le seul cas . Pour tous les autres , il est préférable de garder tout du long la précision par défault (6) , et n'arrondir que le prix retourné.

[Asenar]

oui, c'est pas "le développeur de PrestaShop", on est un paquet (on a même du mal a marcher dans les couloirs parfois ^^)

Désolé j'avais reçu la notification d'une réponse postée mais ce n'est que maintenant que je lis tout ça On (les dev') passe notre temps sur le bug tracker, le forum on a pas trop le temps en semaine (et le reste du temps ben ... y'a pas qu'Internet dans la vie non plus hein !)

Dites, est ce que ceci pourrait vous aider ? http://forge.prestashop.com/browse/PSCFI-1477

Broceliande, ce n'est pas encore le cas mais dans la forge il y aura un espace spécialement conçu pour ça (les propositions d'amélioration, les retouches directes, etc.. ).

Si l'anglais vous rebute trop, on a (très vaguement, genre bruit de couloir) parlé d'autoriser les rapports en français, mais pas pour tout de suite ...

merci à tous de vos contributions en tout cas !

(PS : si je répond pas dans les quelques jours qui suive une question qui m'est adressée, hésitez pas à m'envoyer un mp hein)

[Broceliande]

Merci pour ces infos Mickaël.

L'anglais ne me gène pas du tout , je crois même avoir un compte sur le tracker.
Il m'avais semblé que la personne en charge de ce bug (suivez mon regard ) passait dans ce coin là alors...

Bonne nouvelle qu'un tracker soit mis en place pour les suggestions. Nous avions ça pour le projet Mediaportal, notre équipe avait des membres en charge de surveiller les bonnes propositions , que nous contrôlions à notre tour, implémentions et faisions tester par nos testeurs avant de commit ça sur svn...

[Asenar]

Bah, on aimerait bien passer plus de temps sur le forum, mais il faut choisir entre le forum ou faire du dev' (et si tu t'y connais, tu sais bien qu'on ne peut pas dire "bon allez, je me fais mon petit quart d'heure de forum" car une réponse nécessite rarement qu'un quart d'heure (sans compter la relecture du sujet, le fait de quitter ce qu'on faisait avant, de s'y remettre après, ...).

Bon j'arrête de me plaindre

Mais ce que je disais plus haut aussi, c'est qu'on ne corrigeait plus la branche 1.3 (le svn est d'ailleurs fermé aux modifications pour cette branche je crois), j'essayai surtout de donner un coup de main (et d'ailleurs j'ai pas fait grand chose à part conseillé de faire ce sujet ^^ )

Il y a les bugs, les "choses à faire", les suggestions d'amélioration, les demande de nouvelle fonctionnalités, les traductions, les demandes de support, ..
Toujours dans la forge, la(les) roadmaps seront disponibles, l'historique de modification des fichiers, et pleins d'autres choses !

[jolvil]

Ce n'est pas pour ergoter mais quand on dit le developpeur, c'est pour parler du developpeur qui a ecrit cette partie de code. Evidement on sait bien que vous etes un certain nombre.
Pour la résolution du bug qui nous interesse la solution que Broceliande a trouvé est dans le post [ # 27 ], la question est pourquoi avoir différencier le calcul pour: avec taxe et sans taxe?

Autre chose il semble que dans le code !$withTaxes signifie en realité without taxes... ce qui peut amener a des erreurs d'interpretation (contresens)