Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Problème d'arrondi dans les prix

XRoussel

Bonjour,

Nous constatons toujours un problème d'arrondi sur nos fiches produits, alors que nous sommes configuré sans décimale. Voir le PU HT Hr, qui apparait avec 4 décimales

Si on force ce champ PU HT Hr avec la valeur 17 063, voilà ce qu'on obtient, c'est alors le PU HT qui revient avec 2 décimales

Si on reforce ce champ PU HT avec la valeur 10 748, même problématique

Lorsqu'on force la marge sur achat ou sur vente, idem.

Le problème semble venir des unités d'achat et de vente car lorsque ces 2 unités sont identiques, le problème disparait effectivement.

Ce problème expliquerait sans doute le soucis de montant total que nous rencontrons dans certains de nos devis: la somme de tous les produits prix indépendamment diffèrent (de quelques francs XPF) du montant total affiché dans le devis. Gestan semble gardant en "mémoire" ces décimales pour ces calculs finaux, ce qui pour nous qui sommes configurés sans décimale, n'est pas correct

Gestan

Je confirme : même si le masque d'affichage n'affiche que 0, 1, 2 ou x décimales, la base les stocke, cela afin d'éviter (de diminuer ?) les erreurs d'arrondis.

Dans la prochaine version, le PU HT Hr sera bien affiché à 17063, mais la base stockera 17063.049 etc.

XRoussel

Oui c’est bien la notre problème. Du coup ça explique pourquoi certain de nos devis sont faux.

vous raisonnez en metropole toujours avec décimales car vous êtes en euros, mais lorsque le logiciel est configuré sans décimale vous devez stocker l’arrondi sans décimale et ça à chaque endroit où il y a des calculs, dans les fiches produits, les devis, etc ...

Un exemple simple: vous avez ci dessus une fiche produit avec un prix d’achat hors remise de 17.063 CFP. Vous appliquez 37% de remise fournisseur: votre prix d’achat est donc de 10.750 CFP et c’est bien 10.750,000 CFP qu’il faut stocker et non 10.749,69. Si dans ma fiche produit je lui indique une marge de 100%, mon prix de vente devrait normalement être de 21.500,000 CFP et non 21.499,380

Si maintenant je fais un devis avec cette pièce et j’en mets 5 à mon client, le résultat doit être de 21.500 x 5 soit 107.500 CFF et non de 21.499,380 x 5 = 107.497 CFF.

il faudrait donc stocker les chiffres arrondis dans toutes les étapes de calculs. Peut être que le nombre de décimales utilisées dans la base de calcul Gestan pourrait être paramétré indépendamment ?

Gestan

Nous ne le pensons pas : il est normal de stocker les décimales, même si vous n'avez pas d'arrondi. Par exemple, si vous vendez un produit à 950 balles avec une TVA à 8.5 ça fait un produit à 1031 et non 1030, le résultat étant à 1030.75. Théoriquement, ce n'est qu'en stockant le nombre de décimales nécessaires que les arrondis finaux peuvent être corrects.

Dans le cas que vous citez, le prix de vente affiché sera bien 21499, et non 21500, mais vous pouvez le corriger manuellement à 21500, ce qui passera votre marge sur achat à 100,01, et vous pourrez sans problème en mettre 5 dans votre devis client.

XRoussel

Dans votre exemple, si on utilise une quantité de 100 de votre produit dans un devis sans décimales, on doit bien obtenir un total de 103100. En conservant les décimales “théoriques” ou dans la mémoire de Gestan, notre devis est donc à 103075 et donc le résultat est faux puisque l’unité affichée est bien à 1031.

Nous devons donc corriger manuellement nos devis ou nos fiches produits pour forcer les produits à des prix ronds, je vous laisse imaginer la quantité de travail à faire si nous devons vérifier chaque total de chacun de nos devis.

Ce problème n’apparaît pas lorsque nous mettons manuellement notre prix de vente client dans la fiche produit. Il apparaît uniquement lorsque le prix de vente est calculé par Gestan, lorsque, par exemple, on saisi la marge sur achat ou vente pour le calculer ...

Gestan

Ce problème est hélas sans solution : les décimales qui vous perturbent sont nécessaires à d'autres entreprises 😪

XRoussel

Effectivement, nous en avons conscience, d'où dans mon message "Peut être que le nombre de décimales utilisées dans la base de calcul Gestan pourrait être paramétré indépendamment ?"

Gestan

Ce paramètre serait trop complexe à expliquer, et trop complexe à programmer, je pense