Re: [Dolibarr-dev] gestion des arrondis

[Yannick Warnier]

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...