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

[Tahiti Rimai (Jean)]

> > PS: C'est bien qu'il soit pacifique, votre franc!  :-)
>
>
> Si tu aimes ça à ce point, je t'échange n'importe quelle quantité de
> francs suisse contre la même quantité de franc pacifique ;-)
>
> (désolé de polluer la liste avec ma blague à deux balles, mais je n'ai
> pas pu resister)

1 Franc Pacifique pour 1 Franc Suisse ?? Pas de problème, je t'en envoie 
combien ?

>
Plus sérieusement :
> ------------------------------
>
> Message: 3
> Date: Wed, 31 Jan 2007 09:46:31 +0000
> From: Yannick Warnier <address@hidden>
> Subject: Re: [Dolibarr-dev] gestion des arrondis
> To: Discussions sur le developpement de Dolibarr
>         <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-15
>
>
> 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 ?

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


> PS: On sent qu'on a la moitié de l'effectif au salon Solutions Linux...

PS : (pour voir si Gael lit jusqu'au bout ....   1 euro = 119,33 francs 
pacifique (à convertir en franc suisse) J'accepte toujours l'échange 1 
pour 1 !