Re: [Dolibarr-dev] Bug arrondis prix unitaires

[Yannick Warnier]

Le lundi 02 avril 2007 à 02:16 +0200, Laurent Destailleur (Eldy) a
écrit :
> Rodolphe Quiedeville a écrit :
> > Le 30.03.2007 01:25, Laurent Destailleur (Eldy) a ecrit :
> >   
> >> Yannick Warnier a écrit :
> >>     
> >>> Le mardi 27 mars 2007 à 10:22 +0200, Rodolphe Quiedeville a écrit :
> >>>  
> >>>       
> >>>> Yannick Warnier a écrit :
> >>>>    
> >>>>         
> >>>>> Salut,
> >>>>>
> >>>>> Pour ceux qui n'ont pas suivi le bug 17811
> >>>>> http://savannah.nongnu.org/bugs/?17811
> >>>>>
> >>>>> Je propose de faire la modification suivante dans le code, modification
> >>>>> qui pourrait (si mal configurée) apporter pas mal d'effets de bord dans
> >>>>> Dolibarr
> >>>>>       
> >>>>>           
> >> ATTENTION GROS PAVE DANS LA MARE.   :-)
> >>     
> >
> > PLOUF          :-)
> >
> >   
> >> Pour moi la modif proposée n'est pas bonne. En effet, la fonction price
> >> est une fonction qui formate un montant pour l'affichage. Cette ne
> >> fonction ne devrait en aucun cas modifier une valeur en base ou en
> >> mémoire au moment de l'affichage. Si la valeur réelle est 1.2345 alors
> >> la fonction price doit renvoyer 1.2345 sinon cela signifie que ce que
> >> voit l'utilisateur n'est pas ce que contient la base ou la donnée, et
> >> la, c'est super grave.
> >>
> >> La gestion des arrondis ne doit surtout pas se faire au moment de
> >> l'affichage (que ce soit écran HTML ou PDF) mais au moment du stockage
> >> en base, c'est à-dire au moment ou on insère un ligne détail dans une
> >> facture par exemple.
> >>     
> >
> > Je suis d'accord en partie seulement. Les décimales importent pour des
> > calculs sur des gros volumes plusieur milliers d'unité par exemple, le
> > prix peut donc dans certains cas etre affiché avec moins de décimales.
> >   
> J'ai donc ajouté une option MAIN_MAX_DECIMALS_SHOWN (qui vaut 5 si non 
> définis) dans la fonction price et qui détermine le nombre de décimal 
> maximum à afficher à l'écran (pour éviter les nombre à rallonge affichés 
> sur les pages web).
> C'est juste pour un besoin esthétique. Cette option d'ailleurs quand la 
> décimal est tronqué affiche 3 petits points pour signaler qu'il y a 
> approximation.
> 
> 
> Pour ce qui est des factures PDF, la facture doit afficher exactement ce 
> qui est en base. C'est donc à l'utilisateur qui réalise la saisie de 
> s'assurer au moment de la saisie que le montant ne dépasse pas le nombre 
> de chiffre après la virgule en vigueur dans son pays.
> Si l'utilisateur crée une ligne qui se retrouve avec un montant TTC de 
> 100.1234 euros par exemple, la facture demandera à payer 100.1234 euros. 
> C'est ce que l'on veut. Donc, si on ne veut pas cela, il faut au moment 
> de saisir la facture saisir un montant qui soit correcte dès la saisie. 
> Par exemple en saisissant via le TTC plutot que le HT (TTC de 100.13 
> euros par exemple). C'est le HT qui sera alors ajuster automatiquement 
> avec un nombre de décimal plus important. Mais ce n'est pas génant 
> d'avoir des lignes de facture avec un montant à plusieurs décimal, ce 
> qui compte ce qu'au final le TTC de la facture sera bien sur 2 chiffre 
> comme voulu par l'utilisateur.
> 
> Un modele qui modifie les chiffres à l'affichage peut en effet 
> techniquement réalisé mais dans ce cas, il faut complètement oublier de 
> pouvoir un jour faire de la compta ou utiliser les factures Dolibarr 
> pour faire ses déclarations, puisque les données qui sortiront des 
> rapports ou exports pour faire sa décla ne seront pas celle des factures 
> envoyées (vus que les factures envoyées étaient fausses).
> 
> Un control pourrait d'ailleurs etre ajouté pour empecher la validation 
> d'une facture si son TTC a une précision qui dépasse un nombre de 
> décimal qui serait un paramètre (2 pour la france par exemple, 0 pour ce 
> qui gere des francs pacifiques par exemple)...
> 
> 
> Laurent Destailleur.

Ton pavé dans la marre a le mérite d'être clair et de m'aider à décider.
Est-ce que la majorité des participants est d'accord? (et donc est-ce
qu'on peut fermer le bug et faire une 2.1 RC1 qu'on testerait pendant
1-2 jours avant de sortir la stable?)

Yannick