ericko Posted December 10, 2014 Share Posted December 10, 2014 Bonjour à tous, J'ai une erreur récurente sur les commandes de nos clients et qui devient les jours de rush assez laborieux à gérer. J'utilise prestashop 1.6 et le module de paiement ATOS. Sur certaines commandes, nous avons des erreurs de paiement. Le client paie un montant différent de celui du panier. Ce montant peut être supérieur ou inférieur. Lorsque le client s'en rend compte avant nous, il repasse la même commande et tout se passe sans problème et règle le bon montant. Du coup, pour nous, c'est une grande perte de temps en remboursement ou pour contacter le client pour régler la différence. Est ce que quelqu'un peut m'aider à régler ce problème? Merci d'avance ! Link to comment Share on other sites More sharing options...
ericko Posted December 11, 2014 Author Share Posted December 11, 2014 Est ce que quelqu'un pourrait m'aider? Link to comment Share on other sites More sharing options...
arnolem Posted August 21, 2015 Share Posted August 21, 2015 Bonjour, Nous rencontrons actuellement le même problème avec le module SIPS/ATOS pour des commandes hors france métropolitaine (Suisse, réunion, etc). https://twitter.com/arnolem/status/634653926487420928 Est-ce également le cas pour vous ? Avez-vous trouvez des points communs entre toutes vos commandes en erreur ? Si jamais vous avez des pistes, nous sommes également preneur pour échanger. Merci par avance. Link to comment Share on other sites More sharing options...
PedroDelCargo Posted September 2, 2015 Share Posted September 2, 2015 Bonjour, Nous avons le même problème avec le module Ingenico (Ogone). Si quelqu'un à une piste pour régler ce problème, je suis preneur. Merci. Link to comment Share on other sites More sharing options...
Elitius Posted September 2, 2015 Share Posted September 2, 2015 (edited) Bonjour, Pouvez vous me donner ici ou par MP l'adresse de votre boutique ? J'ai une idée sur l'origine du souci.. Edited September 2, 2015 by Elitius (see edit history) Link to comment Share on other sites More sharing options...
PedroDelCargo Posted September 2, 2015 Share Posted September 2, 2015 Bonjour, Merci pour votre réponse, mais en lisant la modification proposée sur votre lien, il me semble que cela ne concerne pas le problème de "Erreur de paiement" dû à des montants panier/paiement différents. Il semble que cela soit plutôt pour empêcher la création d'un message sur la commande. Link to comment Share on other sites More sharing options...
Elitius Posted September 2, 2015 Share Posted September 2, 2015 Oups, j'ai inversé deux topics c'est corrigé. Link to comment Share on other sites More sharing options...
natachaC Posted September 3, 2015 Share Posted September 3, 2015 Et c'est quoi alors l'origine du soucis ?? ça serait sympa de partager la solution avec ceux qui rencontre le même problèmemerci d'avance Natacha Link to comment Share on other sites More sharing options...
PedroDelCargo Posted September 3, 2015 Share Posted September 3, 2015 (edited) Il semble que cela vienne des méthodes de calcul du total TTC et des arrondis qui donnent un résultat différent à l'étape du paiement et à la validation de la commande. Comme les montants dû et payé sont différents (de quelques centimes), Prestashop passe le statut de la commande à "Erreur de paiement". Pour le moment, je n'ai pas encore trouvé où et comment corriger ce bug. Si je trouve une solution qui fonctionne, je la partagerai volontiers. Edited September 3, 2015 by PedroDelCargo (see edit history) Link to comment Share on other sites More sharing options...
natachaC Posted September 3, 2015 Share Posted September 3, 2015 une solution bâtarde mais qui fonctionne pour l'instant dans mon casmais c'est à tester https://www.prestashop.com/forums/topic/234351-resolu-erreur-darrondi-dans-le-calcul-de-la-tva/la partie qui concerne le changement de décimale Dans la classe Product fonction getPriceStatic (override pour rester un peu propre) à la fin dans le return tu force la précision pour éviter les arrondies. (on la force par ce que si tu change la précision depuis le BO, tout ton front se retrouve avec x décimales, et c'est moche) return Product::priceCalculation( $context->shop->id, $id_product, $id_product_attribute, $id_country, $id_state, $zipcode, $id_currency, $id_group, $cart_quantity, $usetax, 6, //$decimals, // -> force decimal : hack for TVA calcul $only_reduc, $usereduc, $with_ecotax, $specific_price_output, $use_group_reduction, $id_customer, $use_customer_price, $id_cart, $quantity ); Link to comment Share on other sites More sharing options...
PedroDelCargo Posted September 3, 2015 Share Posted September 3, 2015 Merci pour cette solution. Je vais tester ça. Link to comment Share on other sites More sharing options...
ericko Posted September 3, 2015 Author Share Posted September 3, 2015 Bonjour, Je suis "content" de voir que je ne suis pas le seul. Je n'ai toujours pas de solution à ce problème. Néanmoins il semblerait qu'il existe plusieurs causes distinctes à ce problème: 1 er type d'erreur de paiement: les décimales, du coup nous évitons maintenant de mettre des prix dont les centimes ne sont pas des multiples de 5. En gros si on a en HT 12.90 ou 12.95 ca passe sans erreur. Si on a des prix HT : 12.98. On a des erreurs. 2e type d'erreur: Le client change ces quantités de produit sur la page "panier". Parfois Le navigateur va mouliner et prestashop semble avoir du mal à rectifier le montant total suite aà la modification. Par exemple: J'ai trois iphone. Je tape dans la case de quantité: 10. Prestashop (ou le navigateur) n'arrive pas à mettre à jour correctement donc le client va payé 3 iphone mais la quantité qu'il aura commandé sera de 10. Le cas contraire ou il réduirait ses quantités: il payera plus que ce qu'il a commandé. 3e type d'erreur: Je pense que cela provient plutot de Prestashop et d'Atos qui laisse passer l'erreur alors que les paiements en virement ou paypal passe sans problème. Il survient lorsqu'il s'agit de la première commande de certain client. Surement quand la création de l'adresse n'est pas faite au bon moment du processus. Cela ne laisse que 2-3 euros de taxes. Ensuite une fois que l'on valide prestashop comprend qu'il fallait ajouter des taxes mais le module de paiement a déjà passé le paiement avec seuelement 2-3 euros de taxe Voilà ce que nous avons pu constater de notre coté. Aujourd'hui, Prestashop n'est pas d'une grande utilité pour nous aider et ATOS, après 3 mois d'attente, veux nos identifiants pour se connecter à notre serveur avec toute les données sensible de notre business. Donc voilà pas de solution pour l'instant... Si vous avez quelques solutions nous sommes preneurs. Link to comment Share on other sites More sharing options...
PedroDelCargo Posted September 3, 2015 Share Posted September 3, 2015 Bonjour, Je n'ai pas de solution pour les 2 derniers points car je n'ai pas ces problèmes. En revanche, pour le premier point, je suis en train de tester la solution proposée par natachaC, et pour le moment, cela fonctionne bien : plus de problème d'arrondis qui passe la commande en erreur de paiement. Reste juste à espérer qu'il n'y aura pas d'effets secondaires à cette modification. Link to comment Share on other sites More sharing options...
richo Posted September 23, 2016 Share Posted September 23, 2016 Bonjour, Nous constatons egalement ce type de problème sur la version 1.6.1.0 de Prestashop. Pour ceux qui ont utilisé le hack de natachaC pouvez-vous nous faire un retour ? Merci Link to comment Share on other sites More sharing options...
VertNature Posted March 18, 2019 Share Posted March 18, 2019 Ce poste est ancien, mais toujours actuel: en version 1.6.1.18 et module ATOS, je confirme l’occurrence du 2eme type d'erreur signalé par ERICKO: Si l'on modifie une quantité directement au niveau du panier juste avant de passer au paiement (click direct sur un type de carte) donc sans rafraîchir le panier, le montant du paiement sur la page ATOS reste au montant du panier AVANT sa modif (alors que le total affiché juste avant sur le panier était correct). La commande est bien passée mais avec une erreur de paiement car le panier et le paiement indiquent alors 2 montants différents. il faut alors soit modifier la commande (si le client est OK) pour quantité+, soit rembourser le client pour repasser sa commande si Quantité - . C'est assez fastidieux... Difficile d'inciter le client à cliquer sur Panier pour rafraîchir la page avant de lancer le paiement !! Quelqu'un a t-il trouvé la solution depuis ces années? Link to comment Share on other sites More sharing options...
ggedu67 Posted May 21, 2020 Share Posted May 21, 2020 Bonjour, J'ai aussi ce problème. c'est complètement aléatoire: 33,35 € payé au lieu de 33,75 € 35,70 € payé au lieu de 49,05 € 79,50 € payé au lieu de 55,50 € 290,04 € payé au lieu de 278,14 € Les paniers sont souvent juste, c'est la somme payée qui est fausse. ça arrive 2-3 fois par mois sur 350 commandes. En général sur CB. Module paiement CIC de prestashop... une fois sur Paypal Version 1.6.1.20 y a-t-il qqc à faire ? Merci beaucoup, GG Link to comment Share on other sites More sharing options...
ericko Posted May 21, 2020 Author Share Posted May 21, 2020 2 hours ago, ggedu67 said: Bonjour, J'ai aussi ce problème. c'est complètement aléatoire: 33,35 € payé au lieu de 33,75 € 35,70 € payé au lieu de 49,05 € 79,50 € payé au lieu de 55,50 € 290,04 € payé au lieu de 278,14 € Les paniers sont souvent juste, c'est la somme payée qui est fausse. ça arrive 2-3 fois par mois sur 350 commandes. En général sur CB. Module paiement CIC de prestashop... une fois sur Paypal Version 1.6.1.20 y a-t-il qqc à faire ? Merci beaucoup, GG Essaie de voir si la différence ne correspond pas au prix d'un produit que le client aurait enlever ou ajouté au dernier moment. Par contre. A ajd. Je n'ai toujours pas trouvé de solution... Link to comment Share on other sites More sharing options...
ggedu67 Posted May 21, 2020 Share Posted May 21, 2020 Merci pour ta réponse, Oui, je suppose, je n'ose pas forcément demander. Ce n'est pas sérieux et pas très pro d'avoir ce genre de défaut sur le site. J'ai beaucoup lu ces derniers temps. C'est incroyable qu'un tel bug ne soit pas encore corrigé depuis 5-7 ans mais que font les développeurs ? Est-ce que c'est aussi présent sur des versions de la série 1.7 ? et y a-t-il des boutiques qui se sont pas affectées ? c'est inquiétant quand même... Link to comment Share on other sites More sharing options...
natachaC Posted May 22, 2020 Share Posted May 22, 2020 Bonjour à tous le hack proposé date des 1.5 et depuis j'ai installé des 1.6 et des 1.7 sans rencontrer à nouveau ce bug avec ce réglage Arrondir vers l'infini. Arrondir chaque ligne par contre j'oblige mes clients à ne surtout pas utiliser le système de calcul du ht en saisissant le ttc il faut ne surtout pas avoir des valeurs ht avec plus de 2 chiffres après la virgule et donc pas de valeur comme 8.79521 Link to comment Share on other sites More sharing options...
matmicha Posted February 15, 2022 Share Posted February 15, 2022 Bonjour à toustes, Je déterre un peu ce post, mais je rencontre le même souci en Prestashop 1.7.6.8, et ce avec le module Up2Pay du Crédit Agricole (même si j'imagine que le problème ne doit pas venir d'ici vu la diversité de modules de banques utilisés). La différence entre le montant payé et le montant exact à payer semble pour ma part correspondre à la réduction appliquée à la commande ; réduction qui, je pense, est seulement prise en compte après transfert du montant de la commande au service bancaire. Je suis en train d'investiguer où je pourrais corriger cet ordre de prise en compte, mais j'avoue tâtonner un peu ... 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