[résolu] Erreur d'arrondi dans le calcul de la TVA

[Oneday]

Bonjour à toutes et à tous,

 

Je suis sous Prestashop 1.5.3.1 et je constate une erreur d'arrondi dans le calcul de ma TVA pour certains de mes produits.

Evidemment, le constat du problème se fait sur un site en production... Mais du coup, vous pouvez voir le soucis par vous-même : Ajoutez une des déclinaisons de ce produit à votre panier, créez-vous un compte pour avoir les frais de transport et vous verrez que le calcul n'est pas bon.

 

En effet, pour prestashop, le total des taxes est : (139*19,6/100) + (9*19,6/100) = 29,008

Qui est arrondi à 29,02.........

 

J'ai essayé de jouer avec les options de règles d'arrondis, cela ne règle pas le problème (et c'est logique).

 

J'ai tenté la solution proposée ici, mais sans succès.

Il y a aussi ce post mais je n'ai testé la solution proposée qu'en partie car il concerne PS 1.3....... Bien que le problème semble très proche du mien voire exactement le même. Je n'aime pas la conclusion de cette constatation : le problème subsiste depuis un bon moment...

 

1 centime, c'est pas grand chose me direz-vous mais une erreur est une erreur, celle-ci touche le client et ce n'est pas professionnel.

 

 

Merci de votre aide

Edited April 3, 2013 by Oneday (see edit history)

[Gregory Roussac]

Hello,

 

En 1.5.4.0 il me donne 29.00 en TVA en arrondi classique.

 

 

 

[Oneday]

Merci Gregory, je vais voir si cette version règle mon problème.

[Oneday]

Gregory,

 

Avec un peu plus d'attention, je me rends compte que ton exemple ne fonctionne pas. L'arrondi ne doit pas être à 29.00 mais à 29.01 puisque le résultat exact est 29.008

 

Le problème reste entier...

 

Up les gens svp

[Damien Metzger]

Bonjour,

 

Le calcul de la TVA sur la facture respecte un ordre bien précis.

 

 

La ventilation de la TVA en bas n'est pas là pour faire le calcul, mais est un simple récapitulatif.

 

Cordialement,

[Oneday]

Bonjour Damien,

 

Merci pour l'info. Du coup, si je reprends la logique du calcul, avec un arrondi supérieur, voici ce que je devrais avoir :

calcul produit :

139*19.6/100 = 27.244 -> arrondi supérieur : 27.25

 

calcul frais :

9*19.6/100 = 1.764 -> arrondi supérieur : 1.77

 

total taxes : 29.02

 

Sauf que si le total des taxes se faisait avant l'arrondi, on aurait : 29.008 -> arrondi supérieur : 29.01€

Et c'est cet arrondi qui est juste puisqu'on fait l'arrondi sur une seule valeur plutôt que sur 2 valeurs, comme c'est le cas actuellement.

 

L'utilisation de l'arrondi inférieur ou l'arrondi classique donne comme résultat 29.00 donc pas fonctionnel non plus.

 

Comment peut-on corriger cela ?

 

 

Pour info, c'est mon client qui m'a fait remonter le problème car il utilise un logiciel pour ses factures et qu'il ne trouvait pas le même résultat entre son logiciel et la facture générée par Prestashop. Il est donc obligé de bidouiller les chiffres pour atteindre les mêmes résultats.

 

Merci de votre aide.

[Gregory Roussac]

Bonjour,

 

Prestashop fait une somme des arrondis et non un arrondi sur la somme.

 

Le calcul de TVA ne se fait pas ligne par ligne, mais produits TTC - produits HT + (transport TTC - transport HT). ((177-148) - (2.39 - 2)) Cette methode de calcul est valide au niveau du plan comptable. Votre logiciel peut peut etre egalement calculer de la sorte dans ces options.

 

Cordialement

[Oneday]

Merci de votre réponse.

Je vais parler le l'option du logiciel à mon client.

[sbret]

Bonjour

désolé de revenir sur ce sujet qui n'est pas compatible avec les usages des clients ....

Le mode de calcul d'une facture est

PU HT x Q = PT HT

PT TTC = PT HT x (1 + %TVA)

 

hors prestashop calcul un montant de TVA unitaire (cf table ps_order_detail_tax et le champ unit_amount) qu'il multiplie par les quantités et fait le calcul suivant

PU HT x Q = PT HT

TVA U = % TVA x PU HT

 

PT TTC = QxPT HT + Q x TVA U

 

Des que les Quantités sont importantes (> 100) les arrondis font leur effet ...

 

Cela n'est malheureusement pas compatible avec les logiciels d'achats des clients .... ni ces logiciels de compta classique

Merci d'avance si vous voyez une solution

[RD2NQ]

Yo !

 

J'ai eu le même problème aussi à cause du logiciel client...

 

Je propose ma solution simple (peut être pas très propre) autant que mes heures perdues servent à quelqu'un !

 

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
    );

 

@prestashop : pour un correctif se serai cool d'avoir une précision pour les calculs et une autre précision pour l'affichage.

 

J'espère que ça te fonctionnera pour toi aussi !

++

[sbret]

merci pour le conseil

je suis en test et cela à l'air de marcher ....

yo !

[IllicoPresta]

Pour ma part cela ne fonctionnait pas, je propose donc une autre solution ici:

http://www.prestashop.com/forums/topic/258598-bug-calcul-total-ttc-errone-lorsquune-reduction-est-appliquee/

[Sire-Sam]

Merci à RD2NQ

 

Cette solution à fonctionner pour moi à quelque détails près:

 

1. Suivant mes test cette solution n'est applicable que pour les nouvelles commandes (du à des enregistrement en DB), ce n'est pas un gros problème en sois, mais le savoir évitera de croire que la solution est inefficace
2. Un problème d'affichage peut se présenter dans le récapitulatif du panier (Prestashop 1.5.3.1) 

Concernant le problème d'affichage dans le panier:

 

Problème:

Suite à la modification opérée plus haut, l’ensemble des produit sont considérés comme étant en réduction.
Voir valeur 'is_discounted' dans 'shopping-cart-product-line.tpl' (L:40 + ou -)

Dès lors le prix répond au comportement d'une réduction et est affiché une fois avec un line-through (barré) et deuxième fois sans être barré, mais avec la même valeur.

 

Solution:

Dans le fichier  \controllers\front\ParentOrderController.php (L:321) le code se présente comme suis:

if (Product::getTaxCalculationMethod())
    $product['is_discounted'] = $product['price_without_specific_price'] != $product['price'];
else
    $product['is_discounted'] = $product['price_without_specific_price'] != $product['price_wt'];

 Le problème d'affichage vient du fait que les structure conditionnel ternaires en viennent à compare un nomvre à  2 décimales  avec un nombre à 6 décimales (du à la proposition de modification de RD2NQ).

Les valeur sont donc considérée comme différent d'ou le 'is_discounted' à true.

Pour mon cas c'est la valeur 'price_wt' qui se présente sur 2 décimal suivant la configuration _PS_PRICE_DISPLAY_PRECISION_

 

Ce problème est facilement réglé en améliorant les ternaire comme suis:

if (Product::getTaxCalculationMethod())
     $product['is_discounted'] = round($product['price_without_specific_price'],_PS_PRICE_DISPLAY_PRECISION_) != round($product['price'],_PS_PRICE_DISPLAY_PRECISION_);
else
     $product['is_discounted'] = round($product['price_without_specific_price'],_PS_PRICE_DISPLAY_PRECISION_) != round($product['price_wt'],_PS_PRICE_DISPLAY_PRECISION_);

 

En arrondissant toutes les valeurs à _PS_PRICE_DISPLAY_PRECISION_ nombre derrière la virgule, on évite toute surprise sur des valeurs avec plus ou moin de décimal. Le problème venant justement que price_wt est au préalable arrondie avec cette valeur, et plus les autres valeurs.

 

En espérant que cela puisse aider l'une ou l'autre personne.

 

[natachaC]

Bonjour

je reviens sur le sujet des erreurs d'arrondi

 

je constate que le fait de saisir les prix TTC en laissant Prestashop calculer le HT pose un problème de calcul dans l’addition des taxes et en particulier si il y a des remises quantitatives

 

exemple je saisis en TTC 46.70 presta calcul le HT en 38.916667
ce qui est vrai et faux car si on supprime les 4 derniers  6667 et qu’on arrondi au centime supérieur on obtiens bien 38.92 HT pour toujours 46.70 TTC (pas de changement de la valeur)

 

mais les conséquences sont lourdes car le résultat multiplié par les quantités n’est pas le même en calculant à partir de
38.916667 HT au lieu de 38.92 HT

 

 

[croqueurdos]

Salut tous,

 

Je ne sais pas (plus) sur quel post répondre, il y a tellement de sujets qui traite de ce soucis d'arrondis...

 

CEPENDANT, je viens de faire qques essais, à priori il y a une nette amélioration après avoir appliqué les deux correctifs principaux connus (qui impliquent de travailler sur 6 décimales, que ce soit pour le calcul et le stockage en BD).

 

Mais ca ne fonctionnais toujours pas.

 

J'ai par contre fait une toute petite chose supplémentaire : dans la fiche produit (je n'ai quasi que des produits à déclinaisons), lorsque dans la case du prix TTC d'une déclinaison on revalide ce prix TTC (on resélectionne la case puis 'entrée'), le HT est alors recalculé sur 6 décimales, et il n'y a alors plus d'écart entre les différentes lignes et le total.

 

Reste maintenant à trouver une solution simple pour recalculer tous les prix HT sur 6 décimales a partir du TTC....

 

Fred

[lmstudio]

Bonjour à tous,

Toujours le même problème d'arrondi sur la dernière version PrestaShop 1.7. Est-ce que quelqu'un a une solution ? Merci

 

[HeineFR]

Tu as déterré un sujet qui a plus de 9ans 😝 

Tu aurais du créer un autre sujet et expliquer précisément ton cas car, personnellement, je n'ai aucun problème d'arrondi sur ma 1.7 et il y aurait beaucoup de post à ce sujet 🤔

[lmstudio]

Pourtant j'ai le cas. Nous travaillons avec des prix bas car nous travaillons au cm (vente de tissus) de ce fait nous arrivons avec des prix HT très bas

0,058333 HT par CM et si le client veut par exemple 10M de ce tissus:

Je pense que le soucis est que la TVA se calcule sur base de deux chiffres après la virgule et pas les 6 visibles dans le B-O
 

Ex:

1) Ce qui ne va pas:

0,058333 arrondi à 0,06 * 1,20 (TVA FR) * 1000 (10 mètres) = 72€

2) Ce qu'il faudrait

0,058333 * 1,20 * 1000 = 70€

 

Nous avons très souvent des différences sur la calcul de TVA, peut-on forcer le calcul de TVA sur les 6 chiffres après la virgule ou calculer une TVA uniquement sur le total des produits HTVA et par par produit.

 

Merci pour votre aide.

[HeineFR]

1 hour ago, lmstudio said:

Nous travaillons avec des prix bas car nous travaillons au cm

Je comprends mieux votre situation, que dis une facture au niveau HT / TVA / TTC ? est-elle "juste" avec ces mauvais chiffres ou c'est n'importe quoi?

[croqueurdos]

Bonjour,

J'ai eu le pb par le passé (j'ai la même typologie de produits que toi, à savoir des produits vendus à la coupe avec donc un tarif unitaire bas, mais avec des qtés potentiellement grandes), mais j'avoue que je ne sais plus si c'était sur l'ancien PS 1.5 ou suite à la migration sur une 1.7 (1.7.6.8 pour être précis).

De mémoire, j'avais je crois défini des tarifs HT sur deux décimales uniquement et c'était alors le TTC qui était arrondi. De fait, j'applique toujours cette méthode.

Donc pour reprendre ton cas de figure :

0.058333€HT  => 0.060000€HT

Evidement, ça fait un écart de prix de vente de 2.8%.

J'ai eu par ailleurs des soucis avec Paypal (erreur de paiement à cause de la différence de calcul), cela avait été résolu par la mise en place du module PS Checkout qui intègre Paypal.

EDIT : il y a aussi la configuration des "paramètres généraux" à regarder. je suis configuré ainsi et ça fonctionne :

 

Fred

Edited September 8, 2022 by croqueurdos (see edit history)

[lmstudio]

39 minutes ago, HeineFR said:

Je comprends mieux votre situation, que dis une facture au niveau HT / TVA / TTC ? est-elle "juste" avec ces mauvais chiffres ou c'est n'importe quoi?

C'est en effet n'importe quoi... Ca fausse tout le calcul.

[lmstudio]

43 minutes ago, croqueurdos said:

Bonjour,

J'ai eu le pb par le passé (j'ai la même typologie de produits que toi, à savoir des produits vendus à la coupe avec donc un tarif unitaire bas, mais avec des qtés potentiellement grandes), mais j'avoue que je ne sais plus si c'était sur l'ancien PS 1.5 ou suite à la migration sur une 1.7 (1.7.6.8 pour être précis).

De mémoire, j'avais je crois défini des tarifs HT sur deux décimales uniquement et c'était alors le TTC qui était arrondi. De fait, j'applique toujours cette méthode.

Donc pour reprendre ton cas de figure :

0.058333€HT  => 0.060000€HT

Evidement, ça fait un écart de prix de vente de 2.8%.

J'ai eu par ailleurs des soucis avec Paypal (erreur de paiement à cause de la différence de calcul), cela avait été résolu par la mise en place du module PS Checkout qui intègre Paypal.

EDIT : il y a aussi la configuration des "paramètres généraux" à regarder. je suis configuré ainsi et ça fonctionne :

 

Fred

Idem, nous avons eu des erreurs avec PayPal au départ que nous avons résolu avec un dev spéficique pour que le prix soit validé idem avec Monetico. Je devrais voir en arrondissant le total plutôt que les articles si ça résout le problème.

[croqueurdos]

En lisant ta réponse, voila ce qui me revient : en configuration "Arrondir le total" j'avais le problème avec Paypal (certaines commandes étaient en erreur de paiement (80%...) voire même parfois pas créées du tout en B.O. ...) et si je mettais en "arrondir ligne par ligne" c'était la TVA qui était fausse...

Il est probable que si tu configure en "arrondir le total" que tu n'ai plus le problème...

Edited September 8, 2022 by croqueurdos (see edit history)

[lmstudio]

1 minute ago, croqueurdos said:

En lisant ta réponse, voila ce qui me revient : en configuration "Arrondir le total" j'avais le problème avec Paypal (commande en erreur de paiement voire même parfois pas créées du tout en B.O. ...) et si je mettais en "arrondir ligne par ligne" c'était la TVA qui était fausse...

 

Il est probable que si tu configure en "arrondir le total" que tu n'ai plus le problème...

Oui justement j'hésite à faire ça, je n'ai pas envie d'avoir des erreurs de paiement sur le site, je vais essayer sur une plateforme test et je te tiens au courant.

Merci pour ton aide précieuse.

[croqueurdos]

Lorsque j'avais des commandes en erreur de paiement, je contrôlais simplement sur Paypal si c'était bien crédité et je validais alors manuellement la commande en BO.

Bien entendu, selon tes volumes de vente, cela n'est p-e pas faisable...

Concernant les erreurs de paiement : il m'a suffit de mettre en place le module Prestashop Checkout dans lequel je n'ai configuré que Paypal, et depuis plus de problème.

Sacré château de cartes que ce PS, hein ^^

[lmstudio]

Hélas ça ne change strictement rien. Je pense que c'est parce qu'on travail au prix unitaire.

Je m'explique:

Nous avons fait un dev custom pour avoir ceci sur nos fiches produits (voir annexe) mais l'affichage que vous voyez à 8,50€ / m (TTC) est en fait le PRIX UNITAIRE + l'unité / M dans le B-O.

Cependant le champ prix du produit encodé dans le PrestaShop est de 0,085 / CM (TTC)

Je pense que la facture fait un mélange de tout ça... J'avoue être perdu sur le coup.

[croqueurdos]

Il semble qu'il n'y ait pas d'annexe à ton message =/

Et en mettant ce produit à tarif unitaire 0.070000€HT (plutôt que 0.070833 et bien remplir le champ "prix HT" de sa page produit ou déclinaison) et en vérifiant également que "nombre de décimales" dans configuration est bien sur "2" ?

Ca donne quoi ?

 

[lmstudio]

Ce qui veut dire que je dois travailler avec des prix ronds HTVA et pas des prix ronds sur le TTC mais 90% des clients sont des particuliers on verra des prix "bizarres"

Voir capture du problème dans le B-O

[lmstudio]

Et la facture me dit 5,80€ HTVA...

 

 

Edited September 8, 2022 by lmstudio (see edit history)