Je réalise des tests pour évaluer la fiabilité de Lima. J'ai rencontré une erreur dérangeante. Une transaction dont la somme de ses entrées au débit est identique à la somme de ses entrées au crédit. Le logiciel marque comme valeur de solde de cette transaction (débit - crédit) : "-0". L'erreur viens du fait l'interface fais des arrondis à l'affichage. En regardant dans la bd, deux valeurs enregistrées ne sont pas précises 136973.47999999998 et 302.59000000000003. D'où le fait que le solde ne soit pas égale 0, mais arrondi à 0 du côté des négatifs. Le solde des transactions me sert à traiter les transaction équilibrés ou non. De ce fait avec cette erreurs la compta est fausse. Est-ce que dois appliquer à arrondi pour éviter cette erreur. Ou dois-je utiliser autre chose que Double ? J'ai une crainte, c'est que l'erreur ou la somme d'erreur finisse par être supérieur à 0.009, donc je n'aurais plus 0 ou -0, mais 0.01. Or si j'applique des arrondies trop important, LIMA va perdre des centimes ce qui est inadmissible dans un logiciel de compta…
On Fri, 6 Aug 2010 23:34:10 +0200 Jonathan Pepin <pepin@codelutin.com> wrote:
Je réalise des tests pour évaluer la fiabilité de Lima.
J'ai rencontré une erreur dérangeante. Une transaction dont la somme de ses entrées au débit est identique à la somme de ses entrées au crédit. Le logiciel marque comme valeur de solde de cette transaction (débit - crédit) : "-0". L'erreur viens du fait l'interface fais des arrondis à l'affichage.
En regardant dans la bd, deux valeurs enregistrées ne sont pas précises 136973.47999999998 et 302.59000000000003.
Certains chiffres decimaux ne sont pas representable en informatique (binaire) d'ou certaine fois des arrondis surprenant :(. Peut-etre que lima devrait passer en BigDecimal (pas de perte de precision). Mais je pense que le travail n'est pas anodin :(, mais il semble indispensable. Modification de tous les calculs, car on ne peut pas faire BigDec + BigDec il faut passer par une methode. Modification du type de stockage en base de donnees. Modification des renderer ? ou peut-etre pas ca depend de comment ils sont fait. -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
participants (2)
-
Benjamin POUSSIN -
Jonathan Pepin