Je serais intéressé d'avoir un feedback sur vont besoins qui n'ont pas été couverts par le standard. Pouvez-vous m'envoyer une liste par email (fp AT odoo DOT com)? On va justement définir notre roadmap v14, dans qq semaines.
Voici l'explication de notre choix pour l'implémentation des floats: Odoo gère bien les chiffres comme des decimal au niveau de PostgreSQL (numeric), mais comme des floats en mémoire (ORM). C'est pour moi le meilleur compromis car:
- tout est bien stocké en decimal après chaque opération dans la DB (tronqué correctement en fonction de la devise / UoM / ...). C'est pratique car un champ a bien un contexte défini (précision, rounding), alors que les variables intermédiaires dans le code n'en ont pas nécessairement.
- cela ne pose strictement aucun problème d'arrondi pour des use cases business (les float Python sont des double C --> 11 bits exposant, 52 bits valeur), le seul risque est de ne pas faire une comparaison correcte à 0, lorque vous développez un module custo.
Utiliser le type decimal en Python serait en fait beaucoup plus compliqué, principalement à cause des getcontext() -> on ne ferait que déplacer le problème (comparaison à 0) à toutes les opérations arythmétique (mise en place du bon contexte à chaque calcul, au lieu de s'appuyer sur la définition du champ lorsque l'on stocke la valeur).
Par exemple, lorsque vous faites: Prix TTC = Pric HTVA * Quantité * Discount * TVA, chacune des variables ont des précisions différentes, il faudrait alors démultiplier les appels à decimal.getcontext().prec = X. Calculer en float, et tronquer à la fin (lorsque la variable Prix TTC est ensuite écrite dans le champ amount_total pour qui une précision est définie) est à la fois plus performant, et beaucoup plus simple. On considère le risque d'erreur négligeable car il faut un montant à 1016 chiffres pour avoir un risque de un cent. (ce que probablement aucune société au monde n'a dans ses comptes, sur un seul document)
Le risque de bug par un développeur de module est pour moi beaucoup plus grand si Odoo n'utilisait que des decimals, au lieu de cette approche mixte (à cause des multiples définitions de contexte, alors qu'ici c'est délégué à la définition du champ de l'objet). Sans compter les multiples exceptions TypeError lorsque l'on multiplie un vrai float (discount/quantity) par un decimal.
[^] # Re: odoo est-il encore libre ?
Posté par pinky . En réponse à la dépêche « Scale‐Up! » : un jeu éducatif pour apprendre la gestion d’entreprise. Évalué à 8. Dernière modification le 22 juillet 2019 à 17:18.
Je serais intéressé d'avoir un feedback sur vont besoins qui n'ont pas été couverts par le standard. Pouvez-vous m'envoyer une liste par email (fp AT odoo DOT com)? On va justement définir notre roadmap v14, dans qq semaines.
Voici l'explication de notre choix pour l'implémentation des floats: Odoo gère bien les chiffres comme des decimal au niveau de PostgreSQL (numeric), mais comme des floats en mémoire (ORM). C'est pour moi le meilleur compromis car:
- tout est bien stocké en decimal après chaque opération dans la DB (tronqué correctement en fonction de la devise / UoM / ...). C'est pratique car un champ a bien un contexte défini (précision, rounding), alors que les variables intermédiaires dans le code n'en ont pas nécessairement.
- cela ne pose strictement aucun problème d'arrondi pour des use cases business (les float Python sont des double C --> 11 bits exposant, 52 bits valeur), le seul risque est de ne pas faire une comparaison correcte à 0, lorque vous développez un module custo.
Utiliser le type decimal en Python serait en fait beaucoup plus compliqué, principalement à cause des getcontext() -> on ne ferait que déplacer le problème (comparaison à 0) à toutes les opérations arythmétique (mise en place du bon contexte à chaque calcul, au lieu de s'appuyer sur la définition du champ lorsque l'on stocke la valeur).
Par exemple, lorsque vous faites: Prix TTC = Pric HTVA * Quantité * Discount * TVA, chacune des variables ont des précisions différentes, il faudrait alors démultiplier les appels à decimal.getcontext().prec = X. Calculer en float, et tronquer à la fin (lorsque la variable Prix TTC est ensuite écrite dans le champ amount_total pour qui une précision est définie) est à la fois plus performant, et beaucoup plus simple. On considère le risque d'erreur négligeable car il faut un montant à 1016 chiffres pour avoir un risque de un cent. (ce que probablement aucune société au monde n'a dans ses comptes, sur un seul document)
Le risque de bug par un développeur de module est pour moi beaucoup plus grand si Odoo n'utilisait que des decimals, au lieu de cette approche mixte (à cause des multiples définitions de contexte, alors qu'ici c'est délégué à la définition du champ de l'objet). Sans compter les multiples exceptions TypeError lorsque l'on multiplie un vrai float (discount/quantity) par un decimal.