Afficher un prix TTC ou HT selon le pays de livraison

Un même produit ne s'affiche pas de la même façon selon qui le regarde. Un particulier français attend un prix toutes taxes comprises, un professionnel allemand un prix hors taxes, un client suisse un prix sans taxe européenne et une mention sur les droits d'importation. Le calcul du prix affiché dépend donc du pays de livraison, du statut du client, de son numéro de taxe intracommunautaire et parfois du canal de vente. Cette logique se pose une fois, proprement, ou elle se paie en incohérences entre la fiche produit, le panier et la facture. Nous ne sommes pas conseillers fiscaux et ce qui suit décrit une logique applicative, pas un avis fiscal.

Les paramètres qui entrent dans le calcul

Il faut d'abord recenser tout ce dont dépend le prix affiché, exercice qui surprend par sa longueur et qui doit être fait avant toute décision technique.

Le pays de livraison

C'est le paramètre principal : le taux applicable dépend du lieu de destination des biens, avec des règles différentes selon que la destination se trouve dans l'union, hors union ou dans un territoire particulier. Ces règles évoluent et comportent des seuils, sujet que nous traitons séparément. Ce qui compte ici est que le pays de livraison, et non celui de facturation ni celui de connexion, détermine le calcul, distinction que beaucoup de configurations confondent et qui produit des erreurs sur les commandes livrées à une adresse différente de celle du client. Le cas du cadeau expédié à une autre personne, banal en période de fêtes, suffit à révéler ce défaut.

Le statut du client

Un particulier et un professionnel disposant d'un numéro de taxe valide ne voient pas le même prix, le second bénéficiant sous conditions d'une exonération. Cette distinction suppose de connaître le statut avant l'affichage du prix, ce qui n'est possible que pour un client identifié. Sur un visiteur anonyme, il faut donc choisir un affichage par défaut, décision commerciale autant que technique et qui dépend entièrement du public visé par la boutique. Une boutique s'adressant aux deux publics gagne à afficher les deux montants, avec une mention claire de ce que chacun représente.

La catégorie du produit

Les taux diffèrent selon la nature du bien : produits alimentaires, livres, prestations de services, biens culturels relèvent souvent de taux réduits qui varient d'un pays à l'autre. Un catalogue mêlant plusieurs catégories fiscales doit donc porter cette information sur chaque produit, et non appliquer un taux unique. Cette donnée doit venir de la gestion commerciale plutôt que d'un réglage du site, seule façon de garantir sa cohérence avec la facturation. Un produit mal classé fiscalement produit un écart qui ne se voit qu'au moment de la déclaration, plusieurs semaines plus tard.

La livraison et les frais annexes

Les frais de port suivent en principe le régime du bien principal, ce qui complique le calcul lorsqu'une commande mêle plusieurs taux. La répartition proportionnelle est la méthode habituelle, et elle doit être appliquée de la même façon sur le site et dans la gestion, faute de quoi les montants divergent d'un centime et la comptabilité s'en plaint. Ce point de détail apparent est en réalité une source récurrente d'écarts qu'il vaut mieux traiter dès la conception. La règle retenue doit être écrite dans la spécification et testée, comme n'importe quelle règle de calcul.

Le canal de vente

Une marketplace impose souvent l'affichage toutes taxes comprises, un site professionnel affiche hors taxes, un comparateur exige le prix final livraison comprise. Le même produit doit donc être exposé sous plusieurs formes selon la destination, ce qui rejoint la logique décrite dans notre article sur la manière de vendre sur plusieurs canaux depuis un seul catalogue. Cette contrainte plaide fortement pour un prix de référence unique et des projections calculées. Une projection erronée sur un canal produit un rejet du flux ou, pire, une vente à un montant que l'on n'avait pas prévu.

La devise

Vendre en plusieurs devises ajoute une couche de conversion, avec la question du taux retenu et de sa fréquence de mise à jour. Deux approches coexistent : convertir à la volée depuis un prix de référence, simple mais produisant des montants peu commerciaux, ou définir un prix par devise, plus maîtrisé mais plus lourd à entretenir. Le second choix est presque toujours préférable dès que le volume le justifie, un prix rond restant plus efficace qu'un montant issu d'une conversion. Il impose en contrepartie de définir qui met à jour ces prix et à quel rythme, question qui relève du commerce et non de la technique.

Poser la logique de calcul

Une fois les paramètres recensés, la logique se construit autour d'un principe simple : un prix de référence unique et des transformations explicites.

Un prix de référence unique

Le catalogue doit porter un seul prix par produit, dans une base de référence choisie une fois pour toutes, généralement hors taxes pour une boutique professionnelle et toutes taxes comprises pour une boutique grand public. Toutes les autres valeurs se calculent à partir de celui ci. Stocker à la fois un prix hors taxes et un prix toutes taxes conduit inévitablement à des divergences, l'un des deux n'étant pas mis à jour lors d'une modification, et c'est l'erreur de conception la plus fréquente sur ce sujet. Le contrôle est simple : chercher dans la base s'il existe deux colonnes de prix, et vérifier ce qui les met à jour.

Décider où se fait l'arrondi

Arrondir à la ligne ou au total ne donne pas le même résultat, et l'écart d'un centime se manifeste immanquablement sur les commandes de plusieurs articles. La règle retenue doit être identique sur le site, dans la gestion commerciale et dans les documents de facturation. Ce point paraît anecdotique et il occupe régulièrement plusieurs jours de rapprochement comptable lorsqu'il n'a pas été tranché explicitement au départ, chacun ayant appliqué sa propre convention. Une convention documentée en une phrase, appliquée partout, coûte cinq minutes et évite ces discussions.

Calculer au moment de l'affichage

Le prix affiché doit être calculé à chaque affichage à partir du prix de référence et du contexte, plutôt que stocké dans une valeur dérivée. Cette règle garantit la cohérence lorsqu'un client change de pays de livraison en cours de parcours, situation banale. Elle a un coût en temps de calcul, largement absorbable par une mise en cache par contexte, et elle évite la catégorie entière des incohérences entre la fiche, la liste et le panier. La clé de cache doit alors inclure le pays et le statut du client, faute de quoi le premier calcul serait servi à tout le monde.

Traiter la promotion avant la taxe

Une remise s'applique sur le prix hors taxes, puis la taxe se calcule sur le montant remisé. L'ordre inverse produit des écarts de quelques centimes qui se retrouvent en comptabilité et qui, sur un volume important, deviennent visibles. Cette séquence doit être écrite explicitement dans la spécification, car les implémentations naïves appliquent volontiers la remise sur le montant affiché, qui est souvent le montant toutes taxes comprises. Le contrôle se fait sur un exemple chiffré, en vérifiant à la main le montant obtenu pour une remise de dix pour cent.

Gérer le passage professionnel

Lorsqu'un client saisit un numéro de taxe intracommunautaire valide, le prix affiché change en cours de parcours. Ce changement doit être visible, expliqué et répercuté immédiatement sur l'ensemble du panier, faute de quoi le client croit à une erreur. La validation du numéro doit se faire auprès du service officiel et non par un simple contrôle de format, et le résultat doit être conservé avec la commande comme justificatif, exigence que les organisations professionnelles connaissent bien. Ce justificatif doit être conservé avec la commande et rester consultable, y compris plusieurs années plus tard.

Prévoir l'indisponibilité du service de validation

Le service de vérification des numéros n'est pas toujours disponible, et une boutique qui bloque la commande dans ce cas perd des ventes. La solution habituelle consiste à accepter la commande en appliquant la taxe, puis à régulariser après vérification, ou à accepter en enregistrant que la vérification n'a pas pu être faite. Ce comportement de repli doit être décidé avec le comptable et non improvisé par le développeur un vendredi soir. Il doit également être journalisé, afin de pouvoir régulariser les commandes concernées une fois le service rétabli.

Assurer la cohérence sur tout le parcours

Le calcul correct ne suffit pas : il doit produire le même résultat à chaque étape, ce qui suppose de traiter les endroits où le contexte change ou se perd.

La liste et la fiche

Le prix affiché dans une liste de catégorie et celui de la fiche produit doivent être identiques, ce qui n'est pas garanti lorsque les deux gabarits emploient des fonctions différentes. Le symptôme est un écart visible que le client remarque immédiatement et qui détruit la confiance. Une fonction unique de calcul, appelée partout, supprime définitivement ce risque et constitue le principal argument en faveur d'une couche de calcul centralisée. Cette fonction doit être la seule à connaître les règles fiscales, tout le reste du code se contentant de l'appeler.

Le panier avant identification

Un visiteur remplit son panier avant d'indiquer son pays de livraison, ce qui oblige à afficher un prix provisoire. Ce prix doit être calculé selon un pays par défaut clairement mentionné, et le changement au moment de la saisie de l'adresse doit être explicite plutôt que silencieux. Un panier dont le total change sans explication entre deux écrans produit un abandon immédiat, réaction parfaitement rationnelle du client. Une mention indiquant que le montant sera ajusté selon le pays de livraison désamorce entièrement cette réaction.

La page de validation

C'est le moment où le calcul devient définitif, et où il doit être recalculé côté serveur à partir des données réellement saisies. Faire confiance au montant transmis par le navigateur est une faille élémentaire, et pourtant on la rencontre. Le détail des taxes doit apparaître ligne par ligne, avec les taux appliqués, exigence à la fois réglementaire et commerciale, un client professionnel ayant besoin de ce détail pour sa propre comptabilité. Ce détail doit également figurer dans le récapitulatif envoyé par courriel, que beaucoup de clients archivent.

Les documents

La facture doit reprendre exactement les montants du panier validé et non les recalculer, sous peine d'écarts lorsque les taux ou les règles ont changé entre temps. Les montants doivent être figés à la commande et conservés avec elle. Cette règle simple évite la situation où une facture rééditée six mois plus tard affiche un montant différent de celui payé, incident qui déclenche systématiquement une réclamation. Les taux appliqués doivent donc être enregistrés avec la commande, au même titre que les montants.

Les courriels et les flux

Les notifications de commande, les flux vers les canaux de vente et les exports vers la gestion doivent tous refléter le même calcul. Une divergence entre le montant affiché sur la boutique et celui transmis à un comparateur produit un rejet ou une réclamation. Ces sorties doivent donc consommer la même fonction de calcul que l'affichage, principe dont la mise en œuvre suppose une architecture propre plutôt qu'un empilement de traitements.

Les interceptions personnalisées

Toute personnalisation du calcul dans le tunnel doit s'insérer au bon endroit, sous peine de produire des montants incohérents entre les étapes. Les points d'accroche disponibles et leurs effets sont décrits dans notre article sur les hooks du tunnel de commande WooCommerce. Une remise appliquée au mauvais moment se répercute correctement sur la fiche et pas sur la facture, défaut que seul un test de bout en bout révèle.

Vérifier et documenter

Ce sujet se prête bien aux tests automatisés, et son absence de couverture explique la plupart des incidents constatés.

Une matrice de cas

Un tableau croisant les pays, les statuts de client et les catégories de produits donne la liste des cas à vérifier. Une trentaine de combinaisons couvre l'essentiel des situations réelles pour une boutique européenne. Cette matrice se construit en une heure et elle sert à la fois de spécification, de plan de test et de documentation, ce qui en fait le livrable le plus rentable du sujet.

Des tests automatisés

Chaque combinaison de la matrice se teste par un appel à la fonction de calcul, avec un montant attendu. Ces tests s'écrivent en quelques heures et se rejouent à chaque modification, ce qui protège des régressions introduites par une extension ou par une mise à jour. C'est le type de code où les tests rapportent le plus, la logique comportant de nombreuses branches et les erreurs étant à la fois discrètes et coûteuses.

Tester le parcours complet

Au delà des tests unitaires, un parcours réel avec plusieurs profils de client permet de vérifier la cohérence entre les étapes. Passer une commande en tant que particulier français, puis en tant que professionnel allemand, puis avec une livraison hors union, révèle en une demi heure les écarts que les tests unitaires ne voient pas. Ce parcours doit être refait après chaque intervention sur le tunnel.

Rapprocher avec la comptabilité

Un rapprochement mensuel entre les montants de taxe calculés par la boutique et ceux enregistrés en comptabilité détecte les dérives avant qu'elles ne deviennent des régularisations. Cet exercice met souvent en évidence des arrondis divergents ou des taux mal renseignés sur quelques produits. Il relève de la collaboration entre l'équipe technique et le comptable, échange trop rare et pourtant très productif, comme nous l'évoquons à propos de l'intégration d'un ERP avec un site B to B.

Documenter les règles retenues

Les choix effectués, base de référence, règle d'arrondi, comportement par défaut pour un visiteur anonyme, comportement en cas d'indisponibilité du service de validation, doivent être écrits. Cette note d'une page évite que chaque intervenant ne redécouvre les décisions et n'en prenne d'autres. Elle constitue également le document que l'on présente lors d'un contrôle ou d'un changement de prestataire comptable.

Suivre les évolutions réglementaires

Les taux, les seuils et les obligations d'affichage évoluent, parfois avec des délais de mise en œuvre courts. Une veille, même sommaire, et un point annuel avec le comptable suffisent à rester à jour. Cette responsabilité doit être attribuée explicitement à quelqu'un, faute de quoi elle n'appartient à personne et l'on découvre le changement par un rejet de déclaration, situation dont le coût dépasse largement celui de la veille.