Sortie prochaine de la version 1.6.0.11

[doekia]

Je continuerai aussi à te répondre gentiment et honnêtement sur Skype et à t'appeler avec le sourire quand tu le souhaites (jour de Noël ou pas, hein ? ) malgré tes propos un peu blessant quant à mon travail avec vous, membres de la Communauté qui êtes au centre de mes priorités.

Et moi a répondre un jour de Noël ou pas, gentiment, et sur Skype et continuerai a chercher pourquoi la solution bug sur une Ubuntu 14.04.01 LTS avec PHP 5.5.9-1ubuntu4.5 (cli) (built: Oct 29 2014 11:59:42), y passerai du temps, vous trouverai le bon patch et vous continuerez à l'ignorer ...

https://www.prestashop.com/forums/topic/385844-sortie-prochaine-de-la-version-16011/page-4?do=findComment&comment=1919044

La pre 1.6.0.12 a le même problème lié à Archive_Tar que la .11 malgré le patch fourni ... ... ... ce sera pour la 1.6.0.13?

[Atch]

Bonjour,

 

Je ne pige plus ou placer les bugs, j'en signale un ici. Voir capture d'une 1.6.0.11 vierge, produits démos et thème dupliqué en cours de modif css.

Total faux et le pourcentage délirant de 5.01% de remise alors qu'en BO nous avons 5%

 

[coeos.pro]

Je viens de tester et effectivement il y a 5.01% de remise affiché dans la page "RÉCAPITULATIF DE LA COMMANDE" alors que sur la page produit, sur la page catégorie, dans la base de données c'est bien 5% : 

[Kreasite]

haha LOL c'est le 35ème test qu'ils ne font pas pour la migration sur leur cloud.

Mince vais être ban.

[djfm]

 

Bonjour,

 

Je ne pige plus ou placer les bugs, j'en signale un ici. Voir capture d'une 1.6.0.11 vierge, produits démos et thème dupliqué en cours de modif css.

Total faux et le pourcentage délirant de 5.01% de remise alors qu'en BO nous avons 5%

 

 

 

Bonjour Atch,

 

Pour ce problème là, au moins la partie 132.57, c'est une question de configuration.

 

Si vous allez dans "Préférences" > "Paramètres généraux", et que vous choisissez "Arrondir pour chaque ligne" dans "Type d'arrondi", la somme sera bien égale à 132.57.

 

Le coeur du problème, c'est que les prix hors-taxes ont ici plus de deux décimales (beaucoup de logiciels empêchent pour cette raison de saisir des prix avec plus de décimales que les décimales affichées pour la devise). Il y a donc un arrondi à chaque ligne pour l'affichage. Or, lors du calcul du total, l'arrondi est fait en dernier, d'où la différence.

En mode "Arrondir pour chaque ligne", le total du panier est bien égal à la somme des lignes.

 

C'est le paramètre "Type d'arrondi" qui détermine quand les arrondis sont faits.

 

"arrondir pour chaque article" => tout va être cohérent dans le panier, mais des écarts risquent d'apparaître dans le récapitulatif de TVA des factures

"arrondir pour chaque ligne" => le prix de la ligne ne sera pas forcément égal au prix unitaire affiché x la quantité, mais la somme des lignes sera égale au total à payer. De légers décalages sont possibles dans le récapitulatif de TVA sur la facture.

"arrondir le total" => le total à payer ne sera pas forcément égal à la somme des lignes, mais les erreurs d'arrondi seront globalement minimales.

 

Si vous avez la possibilité d'utiliser des prix hors taxes à deux décimales uniquement, alors vous devriez observer beaucoup moins de problèmes.

[doekia]

Si vous avez la possibilité d'utiliser des prix hors taxes à deux décimales uniquement, alors vous devriez observer beaucoup moins de problèmes.

Heu ... à moins de demander aux états du monde entier de faire des taux de TVA compatible avec Prestashop, des prix hors taxes à 2 décimales uniquement ne changerons rien.

 

Exemple: 3.00 € HT avec une TVA de 5.5% donnent 3.165€ TTC à arrondir donc

On tente avec une TVA à 2.1%?

 

D'ailleurs une réduction de 30%,15%,5% sur une produit déclenche le besoin d'un arrondi

 

--

 

Par ailleurs il y a une problème fondamental dans cette histoire de réglage du type d'arrondi. En migrant une version inférieure, je ne peux pas régler par avance une variable qui n'existe pas. La migration va donc prendre en compte le réglage "par défaut" et me reventiler les lignes de commandes en fonction de ce réglage, ma commande existante devient encore plus fausse après migration qu'avant.

[coeos.pro]

@djfm : l'arrondi est une chose mais le problème est que dans la bdd il y a bien marqué 5% (voir l'image dans mon précédent message, tout à droite) et là il y a marqué 5.01%

[Atch]

Merci DJFM pour le retour

 

Oui j'avais testé avec les autres modes et certains passent mieux.

C'était juste pour souligner le coté réglage par défaut de Prestashop.

 

Le mode d'arrondi configuré nativement et recommandé par Prestashop est celui qui génère ce petit décalage de 1 ct. Sachant que cela va être la configuration de 80% (j'avance ce chiffre au hasard, mais je pense que pas bcp d’utilisateurs vont trifouiller cette option)  des boutiques , cela risque très vite d'être problématique.

 

Oui comme le souligne Coeos.pro, c'est les 5.01% qui m'ont surpris, à savoir comment cela est ce possible ?

 

Bon courage à la team

 

V++

 

Atch

[djfm]

Par ailleurs il y a une problème fondamental dans cette histoire de réglage du type d'arrondi. En migrant une version inférieure, je ne peux pas régler par avance une variable qui n'existe pas. La migration va donc prendre en compte le réglage "par défaut" et me reventiler les lignes de commandes en fonction de ce réglage, ma commande existante devient encore plus fausse après migration qu'avant.

 

Hello doekia, les commandes existantes conservent leur type d'arrondi, migration ou pas migration (si vous générez une facture en mode "Article", puis changez le type d'arrondi en mode "Total", alors la facture en mode "Article" reste en mode "Article").

[Atch]

J'ai trouvé le coupable de l'arrondi

On refait le calcul inverse dans le tpl pour trouver le pourcentage... (et vu les problèmes d'arrondis, on reporte cet arrondi dans le calcul qui se retrouve faussé)
 
c'est dans le tpl :
 

{assign var='priceReduction' value=(($product.price_without_specific_price - $product.price_wt)/$product.price_without_specific_price) * 100 * -1}

Pourquoi  ne pas réutiliser un truc du style :
 

{$product->specificPrice.reduction*100}%

V++

 

Atch

Edited January 29, 2015 by Atch (see edit history)

[djfm]

@Atch, @Coeos.pro : pour les 5.01%, si l'explication vous intéresse, c'est parce que le template essaye de calculer la réduction en pourcentage à partir de la différence entre prix après réduction et prix avant réduction, en ignorant donc le fait que ce coup ci, on savait déjà que c'était une réduction de 5% qu'il fallait afficher. Comme les prix sont arrondis, on ne retombe pas forcément sur les 5% initiaux... mais c'est bien une réduction de 5% qui est calculée. On va corriger ça dans la 1.6.0.12 ! 

[djfm]

J'ai trouvé le coupable de l'arrondi

On refait le calcul inverse dans le tpl pour trouver le pourcentage... (et vu les problèmes d'arrondis, on reporte cet arrondi dans le calcul qui se retrouve faussé)

 

c'est dans le tpl :

 

{assign var='priceReduction' value=(($product.price_without_specific_price - $product.price_wt)/$product.price_without_specific_price) * 100 * -1}

Pourquoi  ne pas réutiliser un truc du style :

 

{$product->specificPrice.reduction*100}%

V++

 

Atch

 

Exactement On est arrivés à la même conclusion en même temps.

[Eolia]

C'est quand même fou cette histoire, qui a pondu cela ?

 

j'ai un produit, je lui applique une ristourne de 5% (je le sais, hein!) et bien je recalcule cette ristourne pour l'afficher (avec toutes les erreurs d'arrondi que ça va créer).

 

Le problème se retrouve sur d'autres pages où des calculs sont effectués au sein du tpl d'une manière différente que celle utilisée dans le contrôleur correspondant...

 

Je pense que Smarty n'est pas utilisé à bon escient dans ces cas là. Smarty doit gérer l'affichage des données, pas leur génération.

[djfm]

C'est quand même fou cette histoire, qui a pondu cela ?

 

j'ai un produit, je lui applique une ristourne de 5% (je le sais, hein!) et bien je recalcule cette ristourne pour l'afficher (avec toutes les erreurs d'arrondi que ça va créer).

 

Le problème se retrouve sur d'autres pages où des calculs sont effectués au sein du tpl d'une manière différente que celle utilisée dans le contrôleur correspondant...

 

Je pense que Smarty n'est pas utilisé à bon escient dans ces cas là. Smarty doit gérer l'affichage des données, pas leur génération.

 

Après avoir regardé de plus près, il semble que cette approche ait été retenue pour gérer le cas où on a plusieurs réductions sur le prix : on peut avoir une réduction pour le groupe de client et en plus un prix spécifique par exemple. Donc on ne peut pas simplement regarder le prix spécifique, c'est un tout petit peu plus compliqué que ça.

 

Bien sûr, il y a de meilleures solutions, et on va traiter ça.

[Atch]

J'en profite qu'un dev est sur le sujet pour signaler une autre erreur ( peut etre n'est elle pas si grave)

 

(toujours install vierge 1.6.0.11 , theme par défaut sur ce coup )

Notice: Undefined index: id_cart_rules in A:\wamp\www\prestashop16011stable\classes\Cart.php on line 2096

V++

 

Atch

Edited January 29, 2015 by Atch (see edit history)

[Eolia]

Après avoir regardé de plus près, il semble que cette approche ait été retenue pour gérer le cas où on a plusieurs réductions sur le prix : on peut avoir une réduction pour le groupe de client et en plus un prix spécifique par exemple. Donc on ne peut pas simplement regarder le prix spécifique, c'est un tout petit peu plus compliqué que ça.

 

Bien sûr, il y a de meilleures solutions, et on va traiter ça.

Oui bien sûr qu'il faut gérer le cumul des réductions, mais une fois de plus, cela doit être fait en amont, pas dans le tpl

 

Je me répète mais tpl = rendu d'affichage, certainement pas calcul.

 

Enfin, vous m'avez l'air raisonnables et enclins à l'écoute c'est donc une bonne nouvelle. Je suis bien conscient que vous n'êtes pas responsables des erreurs imputables à vos prédécesseurs et je sais qu'il est pénible (parfois cela frôle la crise de nerfs) de débugguer le code d'un autre.

 

Sachez que nous sommes plusieurs à avoir remonté nos manches pour nos clients et mis les mains dans ce fameux code. Certains points sont à conserver, d'autres à améliorer/modifier, d'autres enfin, sont à supprimer simplement.

 

Mais le plus urgent à l'heure actuelle est d'avoir une solution de base qui fonctionne pour ce qu'on lui demande : pouvoir vendre des produits en respectant les règles du métier.

Inutile de mettre des médailles ou d'envoyer des fusées pour cacher la misère.

Soyons francs, il y a plusieurs problèmes (qui ne sont pas récents, cela remonte aux débuts de la 1.5) et qui ont été patchés plutôt que repensés.

 

Alors, je ne sais pas quelle serait la meilleure méthode, livre blanc, conférence, ou autre, mais il serait intéressant de savoir ce que vous voulez vraiment faire, quelle est la roadmap et que l'on puisse donner notre avis, soumettre nos idées avant de vous lancer dans de nouvelles initiatives où l'on ne pourra plus vous suivre.

 

C'est une main tendue, n'attendez pas la crampe

[Xavier du Tertre]

Tu as très bien résumé la situation. 

 

Alors, je ne sais pas quelle serait la meilleure méthode, livre blanc, conférence, ou autre, mais il serait intéressant de savoir ce que vous voulez vraiment faire, quelle est la roadmap et que l'on puisse donner notre avis, soumettre nos idées avant de vous lancer dans de nouvelles initiatives où l'on ne pourra plus vous suivre.

 

C'est une main tendue, n'attendez pas la crampe

 

On va faire en sorte qu'une telle discussion ait lieu très bientôt. Selon nous, l'idéal serait une journée entière consacrée à plusieurs sujet clés qui nous sont chers, à vous comme à nous. Vous êtes quelques uns à avoir une eu proposition de ma part pour que nous nous réunissions en février, j'essaye en ce moment même de mettre ça en place.

 

Merci encore pour ces discussions qui vont de l'avant, c'est super important.

[olea]

Oui bien sûr qu'il faut gérer le cumul des réductions, mais une fois de plus, cela doit être fait en amont, pas dans le tpl

[...]

Soyons francs, il y a plusieurs problèmes (qui ne sont pas récents, cela remonte aux débuts de la 1.5) 

[...]

 

Déjà, lors de la sortie de la 1.4, j'avais pas mal discuté avec Franck B. sur toutes ces problématiques de gestion de prix dans le TPL (et dans les PDF aussi tant qu'à faire)

A l'époque, c'était déjà un véritable casse tête : prix par quantité, prix par client/par groupe/par pays, réduction de groupe, application des TVA...

 

J'ai même encore des tickets dans la forge qui ne sont pas fermés.

[Atch]

Déjà, lors de la sortie de la 1.4, j'avais pas mal discuté avec Franck B. sur toutes ces problématiques de gestion de prix dans le TPL (et dans les PDF aussi tant qu'à faire)

A l'époque, c'était déjà un véritable casse tête : prix par quantité, prix par client/par groupe/par pays, réduction de groupe, application des TVA...

 

J'ai même encore des tickets dans la forge qui ne sont pas fermés.

 

Faisons confiance à Xavier, il va réussir à faire changer les mentalités des Piliers de Prestashop !!!

 

PS : Il y a du travail, d'autres ont essayé bien avant et ont quitté le navire depuis... C'est dommage

 

V++

 

Atch

[DevNet]

En route pour l'auto-réponse avec le fix.

C'est bien en relation avec ubuntu 14.04 LTS et ce bug et surement un autre car je ne suis pas en 64bit sur la machine incriminée:

http://pear.php.net/bugs/20246

 

Pour faire simple, récupérer http://download.pear.php.net/package/Archive_Tar-1.3.13.tgz

Exploser l'archive et récupérer le fichier Tar.php a renommer pour remplacer tools/tar/Archive_Tar.php

 

Editez l'include comme ceci:

//require_once 'PEAR.php';
require_once(_PS_TOOL_DIR_.'pear/PEAR.php');

ATTENTION: si vous ne comprenez pas entièrement ce message ne faites rien et demandez a quelqu'un ayant assez de compétence de le faire. La team va surement faire un patch d'urgence là dessus donc si vous pouvez patienter un peu c'est aussi une option.

 

Nikel, merci @deokia,

 

Ca fonctionne à merveille pour moi.

 

J'ai enfin pu récup l'ensemble des traductions du back-office.

 

A+

[doekia]

Je me doute mais je crois pas que la team l'ai testé... en tout cas la .12 en test ne l'intègre pas