Je suis d'accord car il faut respecter l'aspect légale. Oui pour une 2.1 RC
Cordialement Yannick Warnier a écrit : > 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 > > >
_______________________________________________ Dolibarr-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
