Re: [Dolibarr-dev] Re: Dolibarr-dev Digest, Vol 46, Issue 58

[Yannick Warnier]

Le mercredi 31 janvier 2007 à 06:53 -1000, Tahiti Rimai (Jean) a écrit :

[...]
> > ------------------------------
> > 
> > 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.
> > 
> Ce serait encore mieux
> 
> > 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.
> > 
> Tu crois que le nombre de décimales peut changer ?

Ben tu en es l'exemple même. Tu parles français et tu veux un nombre de
décimales différent de ce qu'ils utilisent là d'où vient ton paquetage
de langues (tu utilises fr_FR dans Dolibarr, non?). De la façon dont tu
le présentes (c'est-à-dire faisant partie de la classe Translate), si tu
choisis fr_FR, tu auras 2 décimales (pas 0)

> > 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.
> >
> Oui effectivement, et on aurait les méthodes adéquates pour gèrer ces 
> variables
> 
> > Yannick
> > 
> 
> Par contre il faut penser à cela qui me créé des problèmes:
> 
>  >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 ?

En fait je crois que c'est une mauvaise idée. Ce qu'il faudrait plutôt,
c'est une fonction "somme()" qui somme les différents sous-constituants
en veillant que chacun ne soit représenté qu'avec un certain nombre de
décimales au moment de la somme.

Autrement dit, au lieu de 

  $somme = $article1 + $article2 (soit 7.57 = 3.25 + 4.32)

on aurait

  $somme = somme($legal->decimals, array($article1,$article2));

et somme() aurait l'air de ceci:

function somme($dec,$montants){
  if(isset($dec) && is_array($montants))
  {
    $somme = 0;
    foreach($montants as $montant)
    {
      $somme = $somme + round($montant,$dec); 
      //donc ici on arrondit bien avant d'ajouter à la somme
    }
  }
  else
  {
    return null;
  }
}


Ça me paraît raisonnable. Bien entendu, du coup on obtient un temps de
calcul considérablement plus élevé qu'avant, mais on garde la précision
ET la flexibilité, et en plus il n'y a pas tant de sommes que ça dans
Dolibarr lors d'un usage normal (rien de comparable à un gros site de
e-commerce en tout cas, et ce genre de choses tient très bien la charge
avec un petit serveur Apache+PHP).

Yannick