Yannick Warnier wrote: > Le jeudi 04 septembre 2008 à 23:50 +0200, Eldy a écrit : > >> Antoine Delvaux a écrit : >> >>> Bonjour à tous, >>> >>> >>> Comme signalé dans un des articles sur la nouvelle version, depuis ma MAJ >>> vers >>> la v2.4-final (j'étais à la beta6), j'ai rencontré quelques difficultés >>> pour le >>> calcul des prix des factures (prix des lignes, reste à payer, etc.). J'ai >>> résumé cela dans le bug #24143 >>> http://savannah.nongnu.org/bugs/?24143 C'est bien entendu le bug de la >>> locale >>> 'fr_BE' >>> >>> Le problème est que cette locale a comme séparateur de millier le '.' >>> (point) et >>> la ',' (virgule) pour les décimales. J'avais donc proposé un premier patch >>> pour >>> la fonction price2num (voir savannah). >>> >>> Cependant, suite à ce patch, d'autres problèmes en cascade surviennent. Je >>> pense que beaucoup d'appels à price2num() à divers endroits du code ne >>> devraient >>> pas être fait. Il ne me semblent pas respecter la séparation des couches >>> logique métier et présentation. Du moins, selon mon analyse. >>> >>> Un exemple. Lors de l'ajout d'une ligne de facture, dans le fichier >>> compta/facture.php on reçoit ou bien le id_prod, ou bien le montant donné >>> par >>> l'utilisateur. Dans le premier cas, le montant du produit est pris de la >>> BD, >>> dans le second, il est donné par l'utilisateur. Ensuite, on fait appel à >>> facture::addline avec ces montants. >>> >>> Dans addline() on trouve des appels à price2num(), ainsi que dans >>> calcul_total_price() et facture::insert(), autre fonctions et méthodes >>> appelées >>> par addline(). Pour moi, la fonction price2num() fait partie de la couche >>> présentation, alors que les autres sont dans la logique métier. Il me >>> semble >>> donc que leur utilisation ne devrait pas être mélangées. D'ailleurs, >>> lorsque >>> addline() est appelée pour un produit existant, les montants sortent de la >>> BD et >>> on ne doit alors pas faire appel à price2num, alors que pour un produit >>> définit >>> à la volée, il le faut. Je pense qu'il serait plus approprié d'avoir les >>> appels >>> à price2num dans facture.php uniquement. >>> >>> N'ayant pas encore une vue complète de l'architecture de Dolibarr, je >>> soumets >>> cette analyse à votre critique, semble-t-elle correcte ? >>> >>> >> Il y a du juste et du moins juste. >> Tout est bon sauf que price2num, est une fonction de la couche métier et >> non présentation. >> >>> Seulement, la solution n'est pas simple, car les appels à price2num() >>> colorent >>> très fort le code. J'ai pour le moment contourné le problème, en >>> commentant le >>> code récupérant le séparateur des milliers de la locale, L'autre solution >>> est >>> d'utiliser la locale 'fr_FR' mais aucune des 2 n'est une solution durable. >>> >>> Bref, qu'en pensez-vous ? Si je m'attaque au problème, quel chemin me >>> préconisez-vous ? Merci pour vos avis ! >>> >>> >> Je me suis attaqué au problème. >> Un gros boulot car le seul moyen de s'en sortir en l'état actuel avec >> fr_BE et que tout soit en fr_BE (PHP, OS, Mysql), ce qui n'est casiment >> jamais le cas surtout mysql qui garde quelquesoit la langue, le "." >> comme séparateur de décimal. >> Autre solution, passer tous les code Dolibarr et ne plus permettre la >> saisie ouverte (droit de saisir un nombre sans le séparateur de milliers >> qui emmerdent tout le monde et utilisation obligatoire de la virgule). >> Hors ceci me parait beaucoup trop contraignant juste pour avoir le droit >> de "voir" des nombres affichées au format Belgique. >> >> Il y a une solution beaucoup plus simple. >> Prendre la version CVS de la branche DOLIBARR_2_4_BRANCH ou la 2.5 dev >> dans laquelle on a modifié le fichier main.lang de fr_BE et la ligne >> SeparatorThousand=. >> par >> SeparatorThousand= >> >> On enlève le point. >> >> Avec cela, tout rentre dans l'ordre, hormis qu'a l'affichage les nombres >> longs n'ont pas de séparateur de milliers "." visibles sur les écrans. >> Mais cela me semble un moindre mal car alors tout rentre dans l'ordre. >> > > Si ça avait été un problème de virgule décimale (pour nous, les belges), > on aurait pu obliger tous les encodages de nombres à se faire en deux > cases séparées, pour éviter d'avoir à taper le séparateur décimal. C'est > ce que font la plupart des banques pour éviter les ennuis. > Et c'est particulièrement casse-pieds pour l'encodage, d'ailleurs. > Yannick >
_______________________________________________ Dolibarr-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
