[RESOLU] PS 1.3.10 Problème d'arrondi ! encore et encore ce bug !!!!! coup de gueule !

[Olecorre]

deux produits dans le panier

1produit -> 9,87€HT x2 -> 23,60€TTC
2produit -> 9,03€HT x2 -> 21,60€TTC
Total produits TTC -> 45,21 € ???? ca devrait être 45.20

Autre essai :
1produit -> 17,53€HT ->20,96€TTC
2produit -> 16,68€HT ->19,95€TTC
total produits TTC -> 40,91€ la c'est juste !

On ne peux pas avoir une fiabilité dans les calcules ?

Je dis quoi à mon client ? Prestashop est pas fiable ? je dois passé plusieurs à corriger ce bug ?

Inutile de me répondre de faire un rapport de bugs vais le faire !

[Fabrice]

ah ouaip !
à l'époque, quand j'ai signalé ce bug à Presta, on m'a dit "on verra ça quand on aura le temps" - ça doit faire des mois maintenant.
sans compter que ça créé à coup sûr des incidents de paiement lors de la phase d'achat.
depuis, j'ai arrêté de mettre mon shop à jour avec les SVN et suivantes.

j'avais signalé à Presta que cela venait du fait que certaines parties du code considèrent le calcul avec 4 chiffres après la virgule et d'autres avec 2 chiffres après la virgule. ça me semblait assez simple de résoudre cette question.
ton coup de gueule (que je comprends à 1000%) me confirme que la nouvelle version n'est toujours pas fiable sur ce point.

[Olecorre]

Si Prestashop à la prétention un jour de jouer dans la cour de grand va falloir qu'ils se bougent ! enter ce bug, la gestion des déclinaisons merdiques etc... on en restera qu'a des petits projets

Le pire c'est que ce coup de gueule restera lettre morte ! et je dirai plus rien car la je vais finir par être des plus désagréables !

[Matthieu Biart]

Bonjour a tout les deux,

Ayant personnellement corrige ce bug, je me permets de vous repondre en personne.

ça me semblait assez simple de résoudre cette question.

Un probleme peut paraitre simple au premier abord, mais la partie qu'on apercoit est souvent seulement la face visible de l'iceberg.
Il faut savoir que la resolution de ce bug a necessite la reecriture du systeme de calcul de prix de PrestaShop !

Total produits TTC -> 45,21 € ???? ca devrait être 45.20

Sans plus de precisions je ne peux pas me prononcer.
Merci dans le rapport de specifier comment les prix et taxes sont configures (HT ou TTC dans le groupe de client, utilisateur identifie ou non, groupe par defaut du client, prix initial HT du produit, taxe associee, changement de devise active...).

Enfin, merci de tester avec le theme par defaut et non un theme specifique que PrestaShop ne peut pas "patcher" lors d'une mise a jour.

Je termine par le fait que j'ai annule votre rapport de bug car il etait poste en francais (et pire en double exemplaire). Inutile de rappeler pourquoi seuls sont acceptes les rapports en anglais.

Je reste dans l'attente d'un nouveau rapport de bug de maniere a pouvoir reproduire le bug ;-)

[Matthieu Biart]

Apres etude du screenshot fournit sur le rapport de bug fr, votre theme presente deja un comportement etrange.

Il liste un prix unitaire a 9.87E et un prix final (pour deux produits) a 23.60E. Malheureusement 9.87 x 2 = 19.74.

J'en conclu que le prix final est TTC. Or la version 1.3 de PrestaShop ne permet pas d'afficher un prix unitaire en hors taxe ET un prix final en toute taxe comprise (pour un meme article). Ce qui prouve bien l'incompatibilite de votre theme avec PrestaShop 1.3

J'attends votre retour avec le theme par defaut.

[planete.game57]

Bonjour,

Nous sommes également en production avec la version 1.2.5 et ce bug est là malheureusement avec les paiements PayPal la plupart du temps, j'ai aussi compris que ça vient du fait que les calculs ne sont pas faits avec le même nombre de chiffres (souvent 4 ou 6) derrière la virgule.

Je n'ai pas essayé en version 1.3 mais ça ne saurait tarder, j'espère que ça sera réglé.

Quelqu'un peut confirmer que ce bug est réglé depuis la version 1.3 ?

Si vous voulez une capture d'écran montrant le problème, je peux vous la fournir.

Bonne soirée.

[Melki-Tsedeq]

Bonjour j’avais également ce bug sur une 1.3.
J’ai constaté que dans Admin / Préférence / Mode d'arrondi : étais sur supérieur et en le modifient sur classique cela a réglé le problème mais il me semble avoir aussi fait des modifications sur le nombre des chiffres après la virgule dans le calcule.

Pour le moment tout fonction correctement sur la 1.3 même pour les paiements. Le problème du centime n’apparait plus. Je me suis inspiré de ce sujet : [Résolu] Frais de port HT (arrondi faux)

Cordialement.
Melki-Tsedeq

[Olecorre]

Merci d'avoir répondu, je m'attendais pas un réponse !

Je vais préparer un rapport complet ! vais tenter de reproduire le bug avec un installation standard de prestashop 1.3.10. Mais la ce qui m'inquiète c'est "Ce qui prouve bien l’incompatibilite de votre theme avec PrestaShop 1.3" ca voudrai dire qu'un thème 1.2.5 est incompatible avec la 1.3 ? va y en avoir du support à faire sur le forum ! surtout que par souvenir mais j'irai vérifié y a pas de calcul dans les thèmes !

bon je vais préparer un rapport des plus complets !

[Fabrice]

Ah oui Matthieu ! ça c'est cool.
merci pour ta réponse. sympa ;-)

[planete.game57]

Bonsoir,

Merci beaucoup pour ta réponse Melki-Tsedeq !

Je vais tester ça très rapidement. Merci encore.
Ces bugs se produisent quand les prix des produits contiennent des centimes et non des prix tout ronds.

[Matthieu Biart]

Bonjour a ceux qui ont rejoint la discussion.

Merci d'avoir répondu, je m'attendais pas un réponse !

Quand on voit un post interessant on y repond

Je vais préparer un rapport complet !

J'attends ca avec impatience.

Mais la ce qui m'inquiète c'est "Ce qui prouve bien l’incompatibilite de votre theme avec PrestaShop 1.3" ca voudrai dire qu'un thème 1.2.5 est incompatible avec la 1.3 ?

Je vous laisse consulter les multiples posts du forum traitant du sujet, a savoir la compatibilite des themes non officiels PrestaShop avec ses differentes versions.

surtout que par souvenir mais j'irai vérifié y a pas de calcul dans les thèmes !

Non, pas de calcul dans la vue. Mais les themes peuvent utiliser de mauvaises variables, de mauvaises conditions, de mauvais formatages et j'en passe.

Je n'ai pas essayé en version 1.3 mais ça ne saurait tarder, j'espère que ça sera réglé.

Merci donc de ne pas "polluer" cette discussion qui est axee sur la version 1.3, mais plutot de la "suivre" pour etre tenu au courant de la situation ;-)

[neldasta]

ce problème et un problème d'arrondi on le rencontre sur plusieurs logiciels de facturation et de compta et ce n'est pas évident à résoudre
quand on affiche un prix avec 2 chiffres après la virgule . le mieux c'est de ne pas arrondir lors des calcul mais seulement sur le dernier résultat
car comme tout le monde le sais "la somme des arrondis n'est pas égale à l'arrondi de la somme" voilà bon courage aux matheux
encore merci à l'équipe de prestashop pour son travail et son aide
Nelson papy prestashoppeur

[Olecorre]

Voici un test qui en dira long !

J'ai installé Prestashop 1.3.10 ! installation normal, configuration de base, template officiel prestashop j'ai rien modifié !

J'ai été sur le premier produit (voir produit1.jpg) pour qui j'ai supprimer les déclinaisons et modifié le prix
J'ai été sur le deuxième produit (voir produit2.jpg) pour qui j'ai supprimer les déclinaisons et modifié le prix

J'ai ajouté les deux produits dans le panier, mis en quantité 2 pour chaque produit et hop le bug ! voir panier.jpg !

Je parle par couramment anglais mais vais tenter de faire un bug repport en anglais (vue que prestashop ne connait pas le français)

Explication ? ah suis sur wamp donc c'est ca le problème ? ou c'est le thème officiel ?

Pour moi bug toujours existant, thème 1.2.5 non compatible 1.3.10 ! bref pourquoi passer en 1.3 ?

Je dis ce que je pense ou je me tais ?

[Fabrice]

ben moi, je sais ce que tu en penses, mais je vais pas kafter... ;-)

[Fabrice]

n'oublies pas de préciser si ta config est HT ou TTC en BO (cf requête de Matthieu) :-)

[Olecorre]

config de base de Prestashop à l'installation, pas modifier une seule option ! mais vais aller faire une capture d'écran

[planete.game57]

@Olecorre

Bonsoir,

Tu a montré un bon exemple, il se passe la même chose avec notre boutique en production et ça arrive plusieurs fois par jour avec des décalages assez importants même sur une petite somme comme 30-40€.

C'est bizarre, d'où sort ce 11.21€ alors que ça devrait être 11.80€ ?

Je comprends pas ...
Espérons que ça sera corrigé dans les prochaines releases ou que l'équipe puisse y apporter une solution rapide dans la mesure du possible.

[scombrax]

Tout ceci minquiète et m'étonne. Moi qui attendais enfin cette 1.3 pour migrer ! sinon pour être constructif avec des calculs à 5 chiffres après la virgule et un affichage avec deux chiffres je n'ai quasiment jamais eu d'erreur de calcul avec virtuemart. En tous cas moins de 1%, et de plus ou moins 1 ct max (dans ce cas je corrige en modifiant les frais de port pour que le client ait une facture finale exacte).

[scombrax]

@Olecorre
C'est bizarre, d'où sort ce 11.21€ alors que ça devrait être 11.80€ ?

Cela vient des 5% de remise qui n'ont pas été enlevés dans le BO

Sinon de viens de faire un test avec les mêmes chiffres mais en entant les prix en TTC et au final le panier est correct. Il y a tout de même un comportement erratique ! pour le iPod shuffle je saisi 11.8 en TTC, me balade un peu pour voir les autres onglets et quand je repasse sur la page infos le prix ttc est devenu 11.799999 !!!

[Fabrice]

oui, pas top. moi, ça me donne dès fois des erreurs paypal - montants qui ne correspondent pas..

[Olecorre]

Cela vient des 5% de remise qui n'ont pas été enlevés dans le BO

Bien vue mais j'ai refait le test en enlevant ses 5% de remise et le résultat est pareil !

[scombrax]

Essaie de refaire le test en rentrant tes prix en TTC

[scombrax]

oui, pas top. moi, ça me donne dès fois des erreurs paypal - montants qui ne correspondent pas..

Là je ne pige pas comment c'est possible sauf si on laisse paypal refaire les calculs. Sous V.... le montant affiché par paypal reprend les infos suivantes qui lui sont communiquées. (Certes il n'y a pas le détail des produits mais le montant à payer est toujours identique à celui indiqué sur le site)

[Fabrice]

et pourtant, si... cela arrive.
écart d'un centime évidemment.

[chris1999]

Voyons voyons, un peu de calme par ici

Plus sérieusement, je me sens moins seul lol
J’avais fait le même topic dans la catégorie voisine en début de semaine.
Après avoir “perdu beaucoup de cheveux” et en faisant avec les bugs “restrictions” et le comportement de PS, j’ai résolu mon problème d’arrondi.
Tout du moins, j’ai pu faire quelques tests et jusque là, ça fonctionne.

http://tiny.cc/k37dw

(désole pour le lien pas très friendly mais il renvoie bien vers le forum PS)

(et mon rapport de bug consultable ici :
http://www.prestashop.com/bug_tracker/view/4623/
et
http://www.prestashop.com/bug_tracker/view/4624/
restés jusque là sans suite :/ )

De rien ^^

Pour répondre au message #4 de Matthieu.

Je t’invite à consulter mon screenshot ci-joint.

Je pense que le thème utilisé par Olecorre dans son screenshot (celui dans son rapport de bug) n‘était rien d’autre que celui de PS 1.2.5 où seul le .css a été modifié (donc pas de variables ou autres qui auraient pus altérer l'affiche des prix).
Par défaut, ce thème affichait le prix unitaire en HT alors que le total juste à coté est TTC (d’où sur mon screenshot la modification pour afficher le prix unitaire TTC)
PS 1.3 affiche par défaut le prix unitaire TTC (et tant mieux)
Par contre PS 1.3 affiche par défaut les prix HT dans le panier !
Alors que PS 1.2.5 affichait bien le TTC.
La modif doit être mineure.

Pour résoudre ce soucis, je ne pense pas que l’important est de savoir quel prix est affiché (HT ou TTC). L’important est de savoir comment PS se comporte et comment PS effectue les calculs pour que le bon total soit affiché. Est-ce beaucoup demandé pour une solution de e-commerce ?

Par ailleurs, dommage que l’option affichage du prix (HT / TTC) ne soit plus dispo dans la 1.3.
Avec mon “système D”, cela ne posait pas de problème particulier d’affichage dans la mesure où j’ai finalement compris où PS allait pioché les données pour faire ses calculs.

J’espère que la team ne va pas modifier en profondeur le comportement de PS dans la mesure où “la précision légendaire à 6 chiffres après la virgule” de PS est, pour moi, derrière.
Vous pouvez même en mettre 10 après la virgule

Y'a plus qu'a trouver un autre "système D" pour les arrondis impliquant les réductions en %
Pour le moment je me cantonne aux réductions en valeurs.

[chris1999]

Pour un affichage correct du récap panier lorsqu'un bon de réduction en % est appliqué j'ai trouvé dans le lien ci dessous une solution.

http://www.prestashop.com/forums/viewthread/33467/P15/configuring___using_prestashop/solved_cart_and_paypal_not_adding_up/

Hier encore il y avait un décallage de l'ordre du centime entre le "total ligne (produit)" et le "total produits TTC".
Le lien ci dessus corrige le delta d'écart.

[Fluorite]

Bonsoir à tous
Merci chris1999 et Olecorre d'avoir trouvé le bug, moi qui est beaucoup de tarifs dégressifs ça faisait le gros souk.
J'ai testé la solution du post à chris1999 qui règle en partie le problème des 2 décimales du panier.
Bonne soirée à vous.
Yannick

[Patrick21]

Bonjour,

moi j'ai modifié dans la base de données le nombre de décimales sur tous les champs numériques à 2 au lieu de 6

cela à l'air de fonctionner, mais je n'utilise pas paypal

vous pouvez essayer en copiant votre base de données et donner votre avis

Patrick

[Olecorre]

Justement, le client utilise paypal ! j'ai pas encore eu le temps de voir les différentes solutions proposés et laquelle limiterai au mieux les dégâts mais j'attend plus une réponse de la Team Prestashop ! vont-ils faire quelques choses ou continuer à se moquer de la communauté ?

[Thierry Création]

Je pense que le thème utilisé par Olecorre dans son screenshot (celui dans son rapport de bug) n‘était rien d’autre que celui de PS 1.2.5 où seul le .css a été modifié (donc pas de variables ou autres qui auraient pus altérer l’affiche des prix).

Bonjour,

Pour avoir mis en place ce template je confirme que les modifications ne concerne que le CSS et les TPL

a aucun moment je n'ai modifié de variables php


... Mais de toute façon le thème n'est pas en question puisse que le bug est présent sur le thème d'origine de prestashop.

Cordialement, Thierry

[Matthieu Biart]

Je commence par une mise en garde :
Le bug denonce dans ce post n'est PAS en rapport avec la precision du stockage des prix dans la base de donnees. Vous changez celle-ci a vos risques et perils.

Ensuite, merci a Olecorre pour avoir reporte le bug via notre outil.
Le bug a ete corrige pour la page panier (comme reporte ici) ainsi que pour le detail de commande Back Office et la facture PDF
Par contre les tests avec le modules paypal ne viendront que prochainement.

Je parle par couramment anglais mais vais tenter de faire un bug repport en anglais (vue que prestashop ne connait pas le français)

Je vous invite a consulter le sujet suivant qui en dit long sur le sujet : Bug report : Coup de gueule

(et mon rapport de bug consultable ici :
http://www.prestashop.com/bug_tracker/view/4623/
et
http://www.prestashop.com/bug_tracker/view/4624/
restés jusque là sans suite :/ )

Oui, pas encore eu le temps de traiter ce bug, si vous voulez tout savoir Alain le responsable du projet est cloue au lit et on fait des pieds et des mains pour nous occuper des bugs, faire des releases... pendant son absence. Vous imaginez ca tete quand il a apprit qu'il ne pourrai pas faire la release de la 1.3 finale lui meme ?

Pour répondre au message #4 de Matthieu.

Je t’invite à consulter mon screenshot ci-joint.

Je pense que le thème utilisé par Olecorre dans son screenshot (celui dans son rapport de bug) n‘était rien d’autre que celui de PS 1.2.5 où seul le .css a été modifié (donc pas de variables ou autres qui auraient pus altérer l'affiche des prix).
Par défaut, ce thème affichait le prix unitaire en HT alors que le total juste à coté est TTC (d’où sur mon screenshot la modification pour afficher le prix unitaire TTC)
PS 1.3 affiche par défaut le prix unitaire TTC (et tant mieux)
Par contre PS 1.3 affiche par défaut les prix HT dans le panier !
Alors que PS 1.2.5 affichait bien le TTC.

C'est tout a fait possible, mais 9 bugs sur 10 viennent habituellement des themes personnalises, et il est bien plus simple pour le "reporteur" d'aller dans son BO >> Preferences >> Apparence >> Theme. de cliquer sur "prestashop", de faire "Enregister" et de rafraichir sa page en Front Office plutot que de notre cote de reproduire le scenario complet (encore qu'ici il soit "gentil").
Croyez moi, vous ne preferiez pas que l'on mette 10 fois plus de temps a stabiliser une release a cause des faux positifs.
Voila pourquoi nous insistons tant sur le fait de reporter des bugs avec le theme par defaut.

J’espère que la team ne va pas modifier en profondeur le comportement de PS

Non ce n'est pas prevu ;-)

dans la mesure où “la précision légendaire à 6 chiffres après la virgule” de PS est, pour moi, derrière.

Je n'ai pas compris la remarque.
Pourriez-vous developper ?

Y'a plus qu'a trouver un autre "système D" pour les arrondis impliquant les réductions en %
Pour le moment je me cantonne aux réductions en valeurs.

S'il y a un probleme avec ca, merci de le rapporter dans le Bug Tracker.

[chris1999]

Olecorre - 30 May 2010 10:37 AM
Justement, le client utilise paypal ! j’ai pas encore eu le temps de voir les différentes solutions proposés et laquelle limiterai au mieux les dégâts mais j’attend plus une réponse de la Team Prestashop ! vont-ils faire quelques choses ou continuer à se moquer de la communauté ?

Le problème avec Paypal c'était ce delta d'écart. Maintenant que c'est résolu, où est le problème ?
Dans la mesure où "ma méthode simplissime" ne touche pas une seule ligne de code de PS, je ne sais pas qu'elle réponse la team pourrait apporter.
(je dis ça je ne dis rien ; je n'ai jusque là fait que des simulations avec Paypal sans cliquer sur le dernier boutton pour confirmer mais l'affichage me semblait correct)

@ Matthieu.

Pour répondre à tes différents points.

1/Déjà, bon rétablissement à Alain
Sinon, pour ma part, seul le rapport de bug #4624 demeure mais n'est plus "indispensable".

2/ tout à fait. C'est bien pour cela que j'avais bien pris la peine de réinstaller une version toute propre de PS en local avant de rédiger mon topic dans la catégorie voisine où mes rapports de bugs.
Et parfois changer le thème ne suffit pas ; un .php à la racine de PS aurait pu être modifié

3/ Pour développer ma remarque, je disais simplement que l'origine du post ou des rapports de bugs étaient le delta d'écart entre le total théorique et le total calculé et affiché par PS (de l'ordre du centime)
L'origine de ce delta d'écart est une conséquence de "la précision légendaire à 6 chiffres de PS" (légendaire car les "6 chiffres" sont toujours sujets de débats et de coup de gueule dans de nombreux topic).
Et donc en appliquant "ma méthode" (mais qui n'en est pas vraiment une), le total théorique et le total calculé par PS sont dorénavant EGAUX ; il n'y a plus d'écart entre les 2 et donc de fait résolve nos problèmes d'arrondis.

Je suis tombé sur ce topic ce matin :

http://www.prestashop.com/forums/viewannounce/30565_6/

Je te cite :

The PrestaShop conception imposes to use 6 digits in price calculation*

*6 digits are required in order to display rouded-up to the nearest dollar/euro/… tax included prices. e.g., $15.00, 45.00 €

Amen (sauf qu'il fallait le prendre à l'envers)

(et c'est pour cela que je me suis permis de rajouter que 10 digits >>> "même pas peur" )

4/ il me semble déjà avoir vu un rapport de bug concernant un probleme de prix avec un bon de reduction en %.

[Matthieu Biart]

Le problème avec Paypal c'était ce delta d'écart. Maintenant que c'est résolu, où est le problème ?

Impeccable s'il n'y a plus de probleme :-)
Mais on va verifier quand meme pour etre sur. On est plus a un test paypal pres.

2/ tout à fait. C'est bien pour cela que j'avais bien pris la peine de réinstaller une version toute propre de PS en local avant de rédiger mon topic dans la catégorie voisine où mes rapports de bugs.

Ok, alors on est d'accord, je n'avais pas saisi correctement la remarque :-)

L'origine de ce delta d'écart est une conséquence de "la précision légendaire à 6 chiffres de PS" (légendaire car les "6 chiffres" sont toujours sujets de débats et de coup de gueule dans de nombreux topic).

Pour le "legendaire", oui j'avais bien compris l'humour ;-)

Et donc en appliquant "ma méthode" (mais qui n'en est pas vraiment une), le total théorique et le total calculé par PS sont dorénavant EGAUX ; il n'y a plus d'écart entre les 2 et donc de fait résolve nos problèmes d'arrondis.

Non pas vraiment... Je veux dire en 1.2 (comme enonce dans mon annonce citee plus haut) et 1.3 finale (comme demontre dans ce post) le bug des arrondis peut "creer" ce delta.
Par contre sur la version SVN (et bientot en release) ou j'ai corrige ce bug, la ca fonctionnera tres bien.

Pour ce qui est de votre probleme d'import, je ne veux pas discuter de ce point ici, non pas dans un desir de le faire passer a la trappe, mais de garder ce topic clair.
Votre rapport de bug a ce sujet a ete vu, et nous n'avons simplement pas eu le temps de le traiter pour le moment. Pas d'inquietude donc, nous allons nous en occuper.

4/ il me semble déjà avoir vu un rapport de bug concernant un probleme de prix avec un bon de reduction en %.

Je ne suis pas au courant (en meme temps je ne gere pas la totalite des rapports de bug ), mais tant qu'il est dans le Bug Tracker je ne suis pas inquiet. Il est soit "nouveau" et ca sera corrige, soit en attente d'informations complementaires, soit deja resolu (ou annule).

[Olecorre]

Pour avoir tester la release qui va bientot, je confirme que le bug d'arrondi est corrigé ! je vais mettre Resolu sur le post.

Merci à la Team pour leur réactivité ! faut dire que nous ne sommes pas habitué donc félicitation.

[planete.game57]

Bonjour,

Moi j'ai également testé dès vendredi soir et je l'ai confirmé à Patric immédiatement après.

Effectivement, c'est corrigé.

Merci beaucoup !

[planete.game57]

Bonjour,

Par contre, j'ai bien fait le retour à Patric Codron pour la release privé 1.3.2.1, mais je trouve incroyable qu'il n'ait toujours pas répondu à mes mails alors que pour ma part le retour a été fait.

Il est apparemment courant que l'équipe ne réponde pas, mais là c'est quand même lui qui demande de faire un retour rapide et il ne me répond même pas ?!

Que faut-il faire ?

Je lui ai envoyé un mail vendredi un autre ensuite et même un MP hier.

C'est pour quand la réponse ?

Merci.

[Olecorre]

Pareil, j'ai fait un retour mais bon j'attend pas de retour de leur part ! pour mon client c'est corrigé c'est le principale ! maintenant dieu seul sait quand sortira cette release !

[planete.game57]

Oui, c'est juste sauf que moi je lui ai posé deux-trois questions annexes par rapport à cette release, et toujours rien de sa part, c'est incroyable.

[planete.game57]

On vient de me répondre !

Mieux vaut tard que jamais.

Merci.

[yucom]

version 1.3.2.1 en service... tout nickel!

[mmomobis]

Salut,
Euh question idiote, on là ou cette version de presta, je passe bientôt en prod et même problème, je voudrais faire ma mise à jour avant cette date.
Merci +++

[Olecorre]

Bonsoir,

Faut attendre que cette release sorte officiellement, le projet de yucom a servi de test pour valider la correction du bug.

Cdt

[mmomobis]

Salut,
Merci de ta réponse, attendons alors, un peu dommage pour un bug de cette envergure qui impacte la facturation...

++

[Odjavel]

J'avais mis à jour ma 1.2.0.8 avec la 1.3.1, mais le problème persistait.

J'ai donc refais une MAJ avec la SVN 1.4.1, et là, ENFIN, le problème semble réglé !

Merci la team !

[Noxyd]

1- Je rajoute ma pierre à l'édifice : les paiement en erreur génèrent le non retrait du stock de l'ensemble de la commande, même en passant la commande en "acceptée", donc gare à vos stocks...

2- C'est bien d'avoir corrigé le bug en version beta, mais comme il est clairement stipulé sur le site : NE PAS UTILISER EN PRODUCTION...
Ce qui fait que l'on doit toujours rester avec ce problème sur les bras en attendant, car je ne me risquerai pas à utiliser cette version contre l'avis de la team.
Donc : à quand la version finale, svp? Ou au moins indiquez nous les modifs à réaliser pour régler ce défaut en attendant...

3- Merci beaucoup de vous être enfin penché sur le problème, bien que ne pouvant l'utiliser, je suis ravi qu'une solution ait été enfin trouvée :-) .

[MeluCrafts]

je suis passée de la 1.2.5 à la 1.3.1 ce we pensant résoudre ce problème d'arrondi sur les paiements paypal, je constate aujourd'hui que le problème est toujours le même... encore une décalage de 2cts aujourd'hui... j'enrage ! ça fait quand même pas très sérieux vis à vis des clients !!!

[planete.game57]

Bonjour,

J'ai dû m'absenter un petit moment.

Oui, en effet ce problème d'arrondi est vraiment de longue date et ce n'était plus supportable pour tous les commerçants, le développement nécessitait la réécriture complète du système de calcul ce que l'équipe ne pouvait pas faire depuis longtemps tout de même.

Et il y a un mois environ, à notre grande surprise ça été fait, je fais parti des membres ayant le problème et je confirme qu'avec la version 1.3.2.1 (release privé) le problème est corrigé.

Comme ils ont eu les bons retours, ça sera probablement bientôt diffusé.
Ils l'ont pas directement sorti à cause du Bercamp mais là ça ne devrait pas trop tarder.

J'espère que ces informations peuvent vous rassurer.

Bonne journée.

[MeluCrafts]

merci pour cette info, voilà une réponse rassurante effectivement, car ça devient vraiment gênant vis à vis des clients... personnellement 2 clients sur 3 paient par paypal, et certains ne sont pas compréhensifs...

[planete.game57]

De rien.

Je comprend tout à fait, j'ai été en stage dans une entreprise où le problème était là et effectivement c'est très problématique autant pour les clients que la comptabilité.

[Noxyd]

C'est sympa de répondre, j'espère que la version sera "finale" (j'entend par là pas une Beta) afin qu'on puisse l'utiliser en prod....

Le plus gros problème pour moi est surtout le problème de stock que cela génère (pour mémoire, les commandes en erreur de paiement ne sont pas déduites du stock, même après passage en "accepté").

Vivement la MAJ :-)

[Fabrice]

ouaip... bug signalé en novembre dernier... c'est trrrrrès long.
et pareil pour l'histoire du stock qui n'est pas répercuté après validation.
ça devrait être une priorité ce genre de problèmes...

[planete.game57]

Bonsoir,

Je confirme, un membre de l'équipe m'a bien dit que cette release corrigeant le problème de l'arrondi sera publiée, je pense prochainement.

Mais par contre, il me semble pas que le problème du gestion des stocks soit corrigé.
Enfin, je n'ai pas vérifié si ça l'était car le problème évoqué sur ce topic est l'arrondi donc j'ai bien peur que l'erreur de gestion des stocks ne soit pas corrigé, je vais tester pour qu'on soit fixé.

Pour le problème de l'arrondi, c'était long car ça nécessitait la réécriture totale du système de calcul. :ahhh:
Effectivement, il était temps.

Je vous tiens au courant.

Bonne soirée.

[Noxyd]

Planète : S'il n'y a plus d'erreur de paiement, il n'y aura plus de problème de stock, vu que ce dernier découle du premier... ;-)

[MeluCrafts]

je ne veux pas dire de bêtises mais... si le problème de l'arrondi est résolu, il ne devrait plus y avoir d'erreur de paiement... erreur qui impacte les stocks... et qui dit paiement validé dit stock ok non ???

maintenant il serait intéressant que les stocks soient mis à jour dès qu'on valide une commande manuellement suite à une erreur de paiement (comment ça je suis exigeante ? )

Perso, en attendant le correctif, j'ai désactivé l'envoi auto du mail au client lors de l'erreur de paiement paypal. Je prèfère vérifier et informer moi même que par un mail automatique qui parfois "énerve" quelque peu mes clientes...

sur ce, bon week-end à tous !

[planete.game57]

D'accord, c'est bon donc.

Espérons que ça soit publié prochainement.

[France]

Bonjour,

Je viens de vivre le même problème avec un paiement Paypal qui a une cenne de différence et les stocks qui n'ont pas été déduit de l'inventaire. Je suis en 1.2.5 et il n'est pas question que j'aille en 1.3.1. Je n'ai même pas encore fini de régler tous mes problèmes avec la 1.2.5.

J'espère qu'une solution sera apporté pour ceux qui sont en 1.2.5.


Merci

[planete.game57]

Bonjour,

Je ne crois pas que ça soit possible, enfin si vous pourriez faire toutes les modifications apportées à la 1.3.1 et les basculer dans la 1.2.5 mais ça risque d'être long et difficile.

Le mieux est de mettre à jour en 1.3.1 car c'est un problème majeur qui vient d'être corrigé et ces erreurs PayPal risquent de se reproduire.

Après, si vous avez une boutique en production je comprends qu'il n'est pas facile de mettre à jour tous les un ou deux mois. :cheese:

Bonne soirée.

[Noxyd]

La solution à ce problème n'est pas dans la 1.3.1 mais sera dans la 1.3.2.
Quant aux mises à jours de sécurité, il est très simple de les réaliser en suivant le tuto.
Le mieux est donc d'attendre la 1.3.2 qui devrait sortir d'ici la fin du mois si tout va bien...

[planete.game57]

Oui c'est ça, exact la 1.3.1 corrigent seulement des failles de sécurité.
Certains ont eu la release privé 1.3.2.1 comme moi depuis un petit moment (2 mois environ) donc je pense qu'ils vont quand même pas tarder à la sortir car les retours ont été très positifs.

Bonne journée.

[France]

Bonjour Planete-game57

Depuis le mois d'avril que je travaille 12 hrs par jour sur la boutique et toujours des problèmes à gauche et à droite et plusieurs ne sont pas réglés car pas de réponse. En mettant la version 1.3.2 c'est de tout recommencer et quand j'aurais terminé et même avant il y aura encore une autre version et encore tout recommencer.

Avoir une boutique ce n'est pas seulement le côté informatique. Faut faire les achats, ajoutés les nouveaux produits, trouver des nouveaux produits, s'occuper des clients et des commandes, la comptabilité etc... Là on passe la majorité du temps sur le côté informatique qu'il faut toujours recommencer et corriger. Ma boutique est toute jeune et il faudrait presque que j'engage quelqu'un juste pour le côté informatique tellement il y a plein de choses à faire de ce côté là. Je n'ai pas encore les moyens de me le permettre alors que d'installer et tout recommencer faut oublier ça.

Une boutique avec pignon sur rue une fois qu'elle est bâtie on peut se concentrer sur la vente, la promo , les clients etc.. et on oublie les murs et la bâtisse pour un temps. En ligne, c'est continuel que de surveiller les murs de la bâtisse car ça craque de partout et parfois un mur tombe. Donc que d'avoir juste un coup de main pour boucher les craques au lieu de refaire toute la construction ne serait pas une mauvaise idée. ;-)


Bonne journée

[planete.game57]

Oui, je suis conscient de tout ça, j'ai fais un stage dans une entreprise ayant une boutique PrestaShop et c'est pratiquement la même situation et le moins que l'on puisse dire c'est que c'est difficile à gérer.

PrestaShop ne facilite pas les choses car les mises à jour sont assez fréquentes tout de même.

En tout cas, bon courage et bon week-end.