Le mardi 30 janvier 2007 à 13:08 -1000, Tahiti Rimai (Jean) a écrit : > Voici comment je propose de patcher la fonction price : > > création d'un variable NB_DECIMALES positionnée à 2 ajout de la > propriété nbdecimals à l'objet Translate et une méthode function > setDefaultDecimals($nbdec) > { > $this->nbdecimals = $nbdec; > } > > initialisation de l'objet global $langs dans master.inc.php > $nbdec=dolibarr_get_const($db, 'NB_DECIMALES'); > $langs->setDefaultDecimals($nbdec); > > modification dans functions.inc.php fonction price() > // On pose par defaut 2 decimales > $decimal = $langs->nbdecimals; > > ainsi en Polynésie on met la variable globale NB_DECIMALES à 0 et > l'affichage devrait être bon. > > Et c'est là qu'est le hic : On ne règle que l'affichage, dans la base de > données on stocke toujours les valeurs avec décimales et on calcule avec > les décimales donc on va tomber sur des cas comme l'exemple cité où > l'arrondi de la somme est différent de la somme des arrondis. 3.25 + > 4.32 = 7.57 et si tu arrondis à l'affichage (fonction price) : 3 + 4 = 8 > > Pourrait-on appeler la fonction price() avant l'insertion en base de > données, ou une fonction équivalente qui n'est pas liée à l'affichage ?
Salut Jean, Je ne crois pas que la classe Translate soit un bon endroit pour faire ça. En fait il faudrait plutôt une nouvelle classe Localisation ou un truc comme ça. Je m'explique. Dans certains pays, il y a plusieurs langues nationales (la Belgique, par exemple, en compte 3 + l'anglais qui est fort pratiqué mais n'est pas national). D'autres pays ont des réglementations différentes selon les états, comme les États-Unis, qui ont pourtant la même langue nationale. Par ailleurs, la langue que tu utilises dans Dolibarr n'est pas d'office la langue nationale du pays dans lequel tu pratiques (dans lequel ta société se trouve). La langue change aussi selon les utilisateurs, parfois, et ça ne doit pas changer le fonctionnement des décimales pour autant. Je suggère donc d'avoir une classe Localisation ou Legal ou quelque chose comme ça, qui soit en relation avec une ou deux tables dans la DB et qui définissent un certain nombre de règles par pays+état ou pays +région peut-être. Ces règles seraient donc stockées dans la base de données et permettraient, à la longue, d'avoir une superbe adaptation aux règles en vigueur en choisissant, à la configuration de Dolibarr, de quel pays+état on veut les règles. On aurait donc: - 1 table llx_pays (on l'a déjà) - 1 table llx_region (on l'a déjà, je crois) qui dépend de pays - 1 table llx_legal_var qui contient 1 id de région, 1 nom de variable et sa valeur. Elle contiendrait des variables comme: - decimal_precision (la précision des arrondis) - currency (la monnaie utilisée) (et peut-être aussi sa valeur par rapport à l'euro ou par rapport au dollar ou un truc qui permet de comparer plus ou moins) - tax_return_day (le jour de la fin de l'année financière et/ou du dépôt de la déclaration au bureau des impôts) ... (autres choses qui ne manqueront pas d'apparaître petit à petit) Franchement, ça m'a l'air nettement mieux comme ça, ça offre de la flexibilité et en même temps ça empêche le blocage plus loin. Je le mettrai dans la Roadmap pour la 2.2.0 après discussion et avis. De toute façon je suis déjà prêt à me lancer dans le développement du traitement des conversions multi-devises, alors ça n'est pas un gros problème de faire ce genre de truc-là en plus. Yannick PS: On sent qu'on a la moitié de l'effectif au salon Solutions Linux... _______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/dolibarr-dev