Jump to content
Oneday

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

Recommended Posts

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 by Oneday (see edit history)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Bonjour,

 

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

 

234351.jpg

 

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

 

Cordialement,

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Merci de votre réponse.

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

++

  • Like 1

Share this post


Link to post
Share on other sites

merci pour le conseil

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

yo !

Share this post


Link to post
Share on other sites

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.

 

  • Like 1

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More