Une personne encaisse 10 $, mais 9.87 $ sont déduits. Personne n'est en infraction. Le système fonctionne comme prévu. La raison se trouve juste en dessous de l'écran.
Comment fonctionne le processus de paiement dans PrestaShop ? La plupart des questions se résument à une seule réponse : quels éléments sont exécutés et quelle est leur priorité ? Une fois ce point éclairci, les totaux qui semblaient erronés s’avèrent prévisibles. Ce qui suit décrit le déroulement du processus de paiement PrestaShop, du panier à la commande, en se basant sur le code utilisé pour l’expédition et non sur les indications de l’écran des paramètres.
1.0 Ce qui se passe en interne lors du processus de paiement de PrestaShop
Lorsqu'on demande le total d'un panier, PrestaShop confie le calcul à une classe de calcul. Pas une seule formule. Trois passes distinctes, toujours dans le même ordre, chacune s'appuyant sur la précédente.
D'abord les lignes, puis les frais, puis les remises. Il est impossible de les réorganiser.
Les articles sont affichés en premier. Chaque article a son propre prix, sa propre quantité et son propre taux de TVA, ce qui explique la plupart des informations suivantes. Viennent ensuite les frais : livraison et emballage cadeau, calculés séparément des articles afin qu’un bon d’achat puisse être utilisé pour l’un sans affecter l’autre. Les réductions sont appliquées en dernier.
Cette troisième position est cruciale. Elle permet de résoudre la plupart des problèmes de calcul du panier PrestaShop , car un bon de réduction n'affecte jamais les prix d'origine. Il s'applique à l'ensemble des lignes, y compris aux codes de réduction appliqués précédemment.
2.0 Comment PrestaShop calcule-t-il le total du panier ?
Le total n'est pas un chiffre fixe enregistré par le magasin. Il est calculé à la demande, et le client précise ce qu'il souhaite : les produits seulement, les remises seulement, le tout, ou le tout sauf les frais de port.
Il est bon de le savoir, car les choses ne se passent pas toujours comme on s'y attend. Prenons l'exemple du seuil de livraison gratuite. Il demande le total hors frais de port, mais avec les réductions déjà appliquées. Si vous posez une question différente, vous obtiendrez une réponse différente. Les deux sont correctes.
Il est donc possible qu'une donnée affichée à l'écran diffère de celle d'un rapport. Aucune des deux n'est erronée. Il se peut simplement qu'elles concernent différentes parties du même chariot ; vérifiez donc lesquelles avant de conclure à une panne.
3.0 Comment fonctionnent les règles du panier dans PrestaShop ?
Les règles du panier PrestaShop englobent à la fois le bon de réduction saisi par le client et les remises automatiques appliquées sans code. Dans l'interface d'administration, ces deux éléments constituent un seul et même objet. C'est pourquoi ils apparaissent sur la même page et sont regroupés dans le même chemin d'accès au code.
Les règles sont appliquées une à une, par ordre de priorité, de la plus basse à la plus basse. La priorité est un simple nombre que vous attribuez à la règle. Elle ne sert pas uniquement à les ordonner : lorsqu’il est impossible de combiner deux règles, la priorité détermine laquelle est conservée.
Chaque règle considère le panier tel qu'il a été laissé par la règle précédente. Ainsi, deux bons de réduction de 10 % sur un panier de 100 ne déduisent pas 20. Le premier bon déduit 10. Le second déduit 10 % des 90 restants, et le client économise 19. Ce comportement est normal et ne résulte pas d'un arrondi.
Les conditions en elles-mêmes sont celles que la plupart des marchands connaissent déjà : périodes de validité, montant minimum, limites par client et exclusions par pays, groupe, transporteur ou produit. La documentation de PrestaShop relative aux règles du panier détaille chaque champ ; il est donc inutile de les réécrire.
4.0 Comment les bons d'achat sont-ils appliqués dans PrestaShop ?
C'est là que le système de bons d'achat de PrestaShop devient intéressant. C'est aussi de là que vient ce 9.87. Les remises en pourcentage et les remises à montant fixe sont gérées de manière très différente, et la différence est loin d'être anodine.
Le principe du pourcentage est simple. Chaque ligne perd un pourcentage de sa propre valeur ; ainsi, un bon de réduction de 10 % s’applique à la fois au livre et au casque audio. Chaque ligne conserve son propre taux de taxe, sans que personne n’ait à s’en soucier.
Un montant fixe ne peut pas fonctionner ainsi, car le panier doit d'abord déterminer sur quelles lignes la réduction doit être appliquée. PrestaShop la répartit proportionnellement : chaque ligne reçoit une part de la réduction correspondant à sa part du panier.
Le chiffre 10 est réparti en fonction de la contribution de chaque ligne, et non de manière égale entre les lignes.
C'est le principe du calcul des remises sur les bons d'achat PrestaShop . Il est important de comprendre que chaque ligne conserve son propre taux de TVA. Par conséquent, la TVA déduite dépend des produits sur lesquels la remise est appliquée. Si vous déplacez le même bon de 10 € dans un panier dont la pondération est différente, le total des taxes changera, même si le client a économisé exactement le même montant.
Un deuxième paramètre est également important : le montant du bon d’achat est-il indiqué TTC ou HT ? Ce paramètre détermine la base de calcul des parts ; ainsi, dans un cas, les 10 % sont déduits du prix TTC, et dans l’autre, du prix HT, ce qui change légèrement l’économie réalisée par le client.
5.0 Comment PrestaShop calcule-t-il la taxe lors du paiement ?
Le calcul des taxes dans PrestaShop s'effectue ligne par ligne, et non sur l'ensemble du panier. Chaque produit est associé à un groupe de règles de taxe ; ce groupe détermine le taux applicable à l'adresse de livraison, et la ligne est taxée à ce taux.
Le montant d'une commande correspond donc à la somme de plusieurs petites taxes. Il n'existe aucun système permettant de calculer « la taxe sur cette commande » en une seule fois. C'est pourquoi le détail des taxes sur une facture peut s'étendre sur plusieurs lignes, même pour une petite commande, et pourquoi ces lignes sont rarement divisibles par un seul chiffre.
Les frais de livraison sont à nouveau taxés séparément. La taxe appliquée est celle du transporteur, et non celle des produits, ce qui peut induire en erreur les clients dont le panier contient des articles exonérés de taxe, mais pas la livraison.
6.0 Pourquoi PrestaShop calcule-t-il un total de panier différent ?
Deux totaux diffèrent d'un centime ? La cause habituelle est l'arrondi, et PrestaShop vous propose trois solutions.
Les trois mêmes éléments se retrouvent dans deux totaux différents selon un seul paramètre.
Les prix sont stockés en interne avec six décimales. La seule question qui se pose est donc de savoir où l'arrondi a lieu. Arrondissez chaque article : le prix unitaire est arrondi avant toute multiplication. Arrondissez chaque ligne : la précision est conservée jusqu'au total de la ligne. Arrondissez le total : aucun arrondi n'est effectué avant la toute fin.
Aucune de ces trois méthodes n'est fausse. Elles divergent simplement. Arrondir chaque ligne est généralement conseillé aux boutiques qui exigent des factures au total exact, car cela garantit la cohérence interne de chaque ligne tout en assurant un calcul précis du total. Les notes de calcul des prix de PrestaShop expliquent ce raisonnement plus en détail.
Avant d'incriminer l'arrondi, écartez les explications les plus simples. Un total qui varie en fonction de l'adresse correspond à la taxe, et non à un arrondi. Un total qui change lorsqu'un bon d'achat est simplement dû au fonctionnement normal du calcul de la commande PrestaShop . Les différences d'arrondi sont minimes. Toute différence plus importante a une autre cause.
7.0 Comment PrestaShop calcule-t-il simultanément les remises et les taxes ?
En résumé : les remises s’appliquent après le calcul de la taxe par ligne, et une remise réduit proportionnellement à la fois la ligne et sa taxe.
C’est cet ordre qui rend la logique de paiement de PrestaShop prévisible. La taxe n’est jamais recalculée après une réduction. Chaque ligne connaît déjà son taux ; supprimer une partie de la ligne supprime donc la taxe correspondante.
Cela répond aussi à une question fréquente : pourquoi le total des taxes sur une commande avec des bons d’achat n’est-il pas simplement le taux de taxe appliqué au total après réduction ? Parce qu’il s’agit de la somme des montants conservés par chaque ligne, et que ces lignes avaient initialement des pourcentages différents.
8.0 Création d'un module offrant une réduction
Tôt ou tard, un client demande une réduction que PrestaShop ne peut pas appliquer automatiquement. Dépensez un certain montant et recevez un produit gratuit. Un niveau de fidélité. Un avantage lié à une valeur que la boutique ne suit pas. La tentation est grande de calculer soi-même le total et de le soustraire à un endroit approprié.
Résistez à cette tentation. Une réduction appliquée en dehors du système de gestion du panier est invisible pour tous les éléments qui consultent le panier. Le récapitulatif de commande n'en tiendra pas compte, la facture ne l'affichera pas et le détail des taxes sera erroné, car les taxes sont calculées par ligne et votre soustraction n'a jamais concerné les lignes.
Créez plutôt une véritable règle de panier. Votre module détermine quand elle s'applique et quel est son montant, puis transmet la réduction à PrestaShop comme une règle appropriée. Tout fonctionne ensuite automatiquement : le récapitulatif, la facture, la taxe par ligne et le classement prioritaire par rapport aux autres bons d'achat.
Le module doit encore répondre à une question à laquelle le noyau ne peut répondre : cette règle est-elle toujours censée exister ? Une règle créée par votre module devrait cesser de s’appliquer dès que le module est désactivé. PrestaShop n’en a pas connaissance, car, pour lui, la règle n’est qu’une ligne de plus dans le tableau.
9.0 Surcharge de checkValidity en toute sécurité
Le point d'entrée pour cela est la fonction CartRule::checkValidity() . PrestaShop l'appelle lors de l'ajout d'un bon d'achat, puis à nouveau par autoRemoveFromCart() sur les paniers contenant déjà des règles. C'est ce second appel qui est utile : il renvoie une erreur, et la règle est automatiquement supprimée du panier.
La procédure de remplacement est donc simple. Vérifiez si la règle appartient à votre module, si celui-ci est activé et, le cas échéant, indiquez-le. Le reste est transmis directement au module parent.
Trois éléments sont importants dans la manière dont vous l'écrivez.
Pour tous les autres cas, contactez le système parent. Une dérogation qui prend la parole automatiquement, au lieu de différer l'intervention, ignore systématiquement toutes les vérifications effectuées par PrestaShop : dates, limites de quantité, montants minimums, restrictions liées au pays et à l'opérateur. Ces informations sont faciles à oublier et leur perte peut s'avérer coûteuse.
N'agissez que selon vos propres règles. Identifiez-les par un élément durable, comme un préfixe de code propre à votre module ou un enregistrement dans votre table. Une dérogation qui s'applique à toutes les règles de l'atelier représente un risque global pris par un seul module.
Respectez l'indicateur « déjà dans le panier ». PrestaShop ignore volontairement les vérifications de validité et de date pour les règles déjà appliquées ; ainsi, un bon d'achat valide lors de son utilisation par le client ne disparaît pas en cours de paiement. Votre vérification est différente : un module désactivé doit supprimer la règle, même d'un panier où elle est déjà présente. C'est précisément le rôle de la suppression automatique.
Veillez également à respecter le format de retour. La méthode renvoie `false` si une règle est valide et un message d'erreur dans le cas contraire. Si vous renvoyez une valeur incorrecte, les appelants interpréteront votre refus comme une approbation.
10.0 Nettoyage et mise en garde concernant la priorité
La désactivation du module devrait également empêcher la création de nouvelles règles. La gestion des règles en cours est prioritaire ; le module lui-même devrait cesser de générer de nouvelles règles lorsqu'il est désactivé, et lors de sa désinstallation, il devrait désactiver ou supprimer celles qu'il a créées plutôt que de les laisser en attente pour que la personne suivante puisse les déchiffrer.
Un point important à souligner : une seule surcharge d'une classe peut être active à la fois. Par conséquent, si deux modules surchargent tous deux CartRule , un conflit surviendra, et le second module installé sera généralement prioritaire. Si votre remise peut être exprimée via des conditions déjà prises en charge par le noyau, utilisez-les et évitez complètement la surcharge. N'y recourez que si la règle dépend d'un élément que PrestaShop ne peut pas consulter.
11.0 Qu'est-ce qui a changé entre PrestaShop 1.7 et 9 ?
Il est bon de le savoir si vous suivez un guide ancien ou si vous consultez des réponses de forum datant de plusieurs années. Certaines informations sont toujours valables, d'autres non.
La calculatrice décrite ci-dessus est apparue dans la version 1.7, et l'ordre des trois passes est resté inchangé depuis. En comparant directement le code des versions 8.2 et 9, la séquence est identique. Les règles sont toujours appliquées par ordre de priorité. Les remises sont toujours réparties proportionnellement. Les trois modes d'arrondi fonctionnent toujours comme auparavant.
Ce qui a changé, c'est l'interface. PrestaShop 9 poursuit la migration des pages d'administration vers Symfony ; les écrans ont donc été reconstruits et certains champs se trouvent désormais à un autre emplacement. Le chemin d'accès aux menus de réductions reste inchangé. Cependant, une capture d'écran d'un tutoriel pour la version 1.7 ne correspondra pas forcément à ce qui s'affiche sur votre écran : les conseils concernant les calculs restent valables, mais les indications sur les clics peuvent ne plus l'être.
12.0 Déterminer pourquoi un total semble incorrect
Voici une procédure rapide pour vérifier les éléments. Chaque étape élimine les suivantes, ce qui évite de devoir rechercher un paramètre d'arrondi lorsque la réponse est une remise automatique dont personne ne s'est souvenu.
Commencez par examiner les règles du panier. Lesquelles s'appliquaient et par ordre de priorité ? L'explication la plus fréquente est qu'une règle automatique avait été oubliée.
Vérifiez ensuite si le bon de réduction est un pourcentage ou un montant. S'il s'agit d'un montant, vérifiez s'il inclut ou exclut les taxes. Ce seul détail explique souvent les signalements indiquant que la réduction est légèrement inférieure à la réalité.
Ensuite, examinez les taux de taxe sur chaque produit individuellement plutôt que sur le total du panier. Il est tout à fait normal que différents taux apparaissent dans un même panier. Cela rend simplement les calculs plus complexes qu'ils ne le sont réellement.
Envisagez l'arrondi seulement dans ce cas. Et uniquement si l'écart est minime, car une différence plus importante indique un autre problème. Vérifiez le mode d'arrondi dans vos paramètres par rapport au total attendu de la facture.
13.0 La version courte
Le processus de paiement de PrestaShop est plus prévisible qu'il n'y paraît. Les prix et les taxes sont calculés en premier. Les frais viennent ensuite, les remises en dernier, et chaque remise s'applique au montant restant de la précédente.
Les bons d'un montant fixe sont répartis sur plusieurs lignes en fonction de leur poids, chaque ligne conservant ainsi son propre taux de taxe. Les pourcentages sont plus simples et s'appliquent directement à chaque ligne. Et lorsqu'il y a un écart d'un centime entre deux totaux, il s'agit généralement d'un problème d'arrondi plutôt que d'un bug.
Merci pour la lecture.
Pour toute question ou assistance concernant les performances ou la migration de votre site web, nos experts sont à votre disposition. Contactez l'équipe Knowband à l'adresse [email protected] dès aujourd'hui pour obtenir des plugins e-commerce fiables et adaptés à vos besoins.
