# Un total de commande qui ne colle pas : déboguer le calcul des taxes WooCommerce > Le total en caisse ne correspond pas à la somme des lignes affichées. Symptôme classique d'un arrondi de taxe mal configuré. Méthode de diagnostic pas à pas. - Auteur : Clément Hadrot - Publié le : 2020-07-16 - Mis à jour le : 2020-07-16 - Catégorie : E-commerce - URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/total-commande-ne-colle-pas-deboguer-calcul-taxes-woocommerce/ ## L’essentiel - L'écart vient presque toujours d'un réglage d'arrondi, pas d'un bug - WC_Tax expose des méthodes pour rejouer le calcul isolément - Un log temporaire sur woocommerce_calculate_totals révèle l'origine exacte Un client contacte le support un lundi matin : « le total de ma commande affiche 47,99 € mais si j'additionne les lignes, je trouve 47,98 € ». Un centime d'écart, presque invisible, mais suffisant pour qu'un client attentif ouvre un ticket, et suffisant surtout pour qu'un comptable refuse de valider un rapprochement bancaire. Ce type d'écart, loin d'être un bug aléatoire, a presque toujours une cause précise et reproductible dans le moteur de taxes de WooCommerce. Ce billet ne traite pas la configuration des classes de taxe elles-mêmes — taux standard, taux réduit, zones fiscales — mais la méthode pour diagnostiquer un total qui ne colle pas une fois ces classes déjà en place. ## Symptôme : où l'écart apparaît Avant de plonger dans le code, il faut isoler précisément où l'écart se produit : entre le sous-total et le total de ligne, entre le total des lignes et le total taxes, ou entre le total taxes affiché et le total réellement encaissé par la passerelle de paiement. Un tableur avec les valeurs affichées à chaque étape du panier permet souvent de repérer l'endroit exact en quelques minutes. ## Diagnostic : la piste de l'arrondi > L'essentiel à retenir : L'écart vient presque toujours d'un réglage d'arrondi, pas d'un bug ; WC_Tax expose des méthodes pour rejouer le calcul isolément ; Un log temporaire sur woocommerce_calculate_totals révèle l'origine exacte Dans l'immense majorité des cas, la cause se trouve dans le réglage *WooCommerce > Réglages > Taxes > Calculer la taxe sur* combiné au réglage d'arrondi *Arrondir la taxe à chaque ligne au lieu de l'arrondir en sous-total*. Ces deux options changent radicalement le résultat sur un panier à plusieurs articles : - Arrondi ligne par ligne : chaque ligne de produit calcule sa taxe et l'arrondit séparément, avant sommation. - Arrondi sur le sous-total : la taxe se calcule sur le sous-total global, puis s'arrondit une seule fois. Avec des prix comme 3,33 € x 3, les deux méthodes produisent des résultats différents au centime près, purement à cause de l'ordre des opérations d'arrondi. Ce n'est pas un bug : c'est un choix de configuration qui a des conséquences mathématiques réelles. ## Isoler le calcul avec WC_Tax Pour vérifier l'hypothèse sans reconstruire tout un panier de test, la classe `WC_Tax` permet de rejouer un calcul de taxe isolément, dans une console ou un script temporaire : ``` $rates = WC_Tax::get_rates( 'standard' ); $taxes = WC_Tax::calc_tax( 9.99, $rates, false ); var_dump( $taxes ); ``` Le troisième paramètre, `$price_includes_tax`, change complètement le résultat s'il ne correspond pas à la réalité du prix stocké en base. Une confusion fréquente : un prix produit saisi TTC dans l'admin, alors que la boutique est configurée en *prix HT*, ce qui décale tous les calculs en aval sans qu'aucune erreur explicite ne soit levée. ## Correctif : tracer le calcul en conditions réelles Quand le réglage d'arrondi n'explique pas l'écart, l'étape suivante consiste à intercepter le calcul réel du panier, en pleine session, via le hook `woocommerce_calculate_totals` : ``` add_action( 'woocommerce_calculate_totals', function( $cart ) { foreach ( $cart->get_cart() as $item ) { error_log( sprintf( 'Produit %s — prix ligne %s — taxes ligne %s', $item['data']->get_name(), $item['line_total'], wp_json_encode( $item['line_tax_data'] ) ) ); } }, 999 ); ``` La priorité élevée (999) garantit que ce log s'exécute après toute extension tierce susceptible d'altérer le panier avant le calcul final, un point souvent négligé quand plusieurs plugins de tarification cohabitent sur la même boutique. ## Un cas réel : coupon et taxe qui se marchent dessus Sur un projet de vente d'équipement de sport, l'écart provenait d'un coupon de réduction appliqué *avant* répartition de la taxe sur chaque ligne, combiné à un arrondi ligne par ligne. Le coupon réduisait le prix de la ligne de 0,015 €, une valeur qui s'arrondissait différemment selon l'ordre d'application entre la réduction et la taxe. Le correctif a consisté à repasser le réglage d'arrondi sur le sous-total, ce qui a supprimé l'écart sur l'ensemble du catalogue testé. ``` update_option( 'woocommerce_tax_round_at_subtotal', 'yes' ); ``` > Avant de toucher à ce réglage en production, il vaut mieux le tester sur un panier représentatif du catalogue réel : un changement d'arrondi modifie potentiellement le total affiché de commandes en cours, ce qui peut dérouter un client en plein paiement. ## Prévention : verrouiller le comportement en amont 1. Documenter explicitement, dans le cahier de recette du projet, le réglage d'arrondi choisi et la raison de ce choix. 2. Ajouter un test de non-régression qui vérifie le total d'un panier de référence avec plusieurs lignes et un coupon. 3. Éviter de multiplier les extensions qui recalculent elles-mêmes les prix de ligne, chacune pouvant appliquer sa propre logique d'arrondi. 4. Former l'équipe support à distinguer un écart d'arrondi légitime d'une vraie anomalie de calcul. ## En résumé Un écart d'un centime sur un total WooCommerce a presque toujours une explication rationnelle dans les réglages d'arrondi ou dans l'interaction entre coupon et taxe, rarement dans un bug du moteur lui-même. La méthode reste la même dans tous les cas : isoler l'étape où l'écart apparaît, rejouer le calcul avec `WC_Tax` pour confirmer l'hypothèse, puis tracer le calcul réel en conditions de panier avant de corriger le réglage en cause.