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 _______________________________________________ Dolibarr-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
