Cédric Krier a écrit 124 commentaires

Tryton de base faisait déjà de la conversion d'unité de mesure sans problème (ex: kg -> gramme) tant que le facteur de conversion est clairement définit (ex: SI).
Ici les unités secondaires sont des conversions entre unité qui n'ont pas de facteur de conversion générale. Par exemple: une conversion de poids en volume. Le facteur dépendra à chaque fois du produit pour lequel la quantité est exprimée.
Donc ces modules permettent d'acheter ou de vendre des produits dans une unité qui n'est pas convertible avec l'unité de stockage à condition qu'un facteur de conversion soit définit sur leur fiche. Exemple: une société achète du sable au volume (10 m³) et le vend au poids (2 kg).

Il y a aussi Tryton qui a un module pour la comptabilité française et aussi une interface vers Chorus Pro en plus des fonctionnalités comptables classiques.

Tu peux essayé juste les modules timesheet et project de Tryton (écrit en Python/Javascript/PostgreSQL et sous licence GPL-3).
Avec son système de module et d'extension, il est possible du customiser les modules standards très fortement pour correspondre aux besoins particuliers.
Il y a également un addons web Chronos qu'on peut installer dans son navigateur pour encoder rapidement ses "timesheets".

Et bien il manque un test avec un model qui a un champ Function et un champ related pour 'currency' comme l'indique le commentaire.

Ce lien concerne un module qui ne fait pas partie de Odoo, un module tiers de l'OCA. Je n'ai pas creusé plus que cela, mais probablement un bug dans leur code qui court-circuite l'ORM standard. L'ORM Odoo traite bien les décimal correctement.

Je ne pense pas que ce soit un bug dans le code de l'OCA. En fait, il y a même un commentaire dans le code d'Odoo qui explique le bug: https://github.com/odoo/odoo/blob/12.0/odoo/fields.py#L1334 Dommage que le bug n'ait pas été corrigé depuis sa découvert il y a 3 ans (le 12/4/2016).

Voici un test fait rapidement (sur une branch master-nochange-fp, mais le comportement est le même depuis les premières versions de Odoo): http://tinyurl.com/y263r7cx

J'aurais préféré voir un test unitaire qui garantie la conformité dans le temps et pour tous les cas limite.
De plus j'imagine que le test est fait avec un champ Float et un nombre de décimal hard codé.

Faire cela amène les même désavantages que d'utiliser un float; si tu ne travailles pas avec la bonne précision, il faut alors quantize() manuellement à certains endroits dans le code. (e.g.lors de comparaisons, ou avant de storer, calcul de taxes, …)

Pas nécessairement, par exemple le cas classique de:

>>> 0.3 - (3 * 0.1)
-5.551115123125783e-17

n'existe pas avec decimal et sans arrondir:

>>> Decimal('0.3') - (3 * Decimal('0.1'))
Decimal('0.0')

Mais pour moi, c'est une bonne chose que le développeur arrondisse explicitement quand il le veut et doit et que le framework lui dise quand il a oublié.

Le débat revient juste à choisir quel côté du trade-off on préfaire:
- float: performance, flexibilité / facilité de code
- decimal: permettre de gérer des nombres avec plus de 16 chiffres

Pas vraiment. Déjà Decimal n'est pas tellement plus lent (environ 2x) que float en Python3 puisque c'est écrit en C. Pour la flexibilité, Decimal l'est plus puisqu'on peut configurer le context comme on veut alors qu'avec float ça dépend du hardware. Pour la facilité de code, je pense qu'il est justement plus simple que le framework lève des exceptions quand on fait quelque chose de pas correcte qu'il n'essaie de corriger implicitement.
Mais bon, je ne pense pas que j'arriverai à te convaincre car nous ne mettons pas la priorité sur les même objectifs. Je préfère l'exactitude qui peut être quelque fois contraignante à la facilité qui cache des approximations.

PS: je t'invite a chercher sur google "tryton issue quantize" pour prendre du recul --> les deux approches ont leurs inconvénients.

Cette recherche ne donne (à part l'issue Odoo où justement les gens prennent Tryton en exemple pour demander qu'Odoo utilise les Decimal) que 2 issues.
La première est invalide car c'est quelqu'un qui appel quantize sur un dict (on peut parler typage statique avec Python 😉)
La seconde est justement le cas de quelqu'un qui veut utiliser des nombres avec plus de décimal que ce que le context par défaut de Python ne supporte. Donc dans ce cas, il suffit de changer le context pour que ça marche (évidement au détriment de performance).

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

Ça n'a pas l'air d'être vraiment le cas: https://odoo-community.org/groups/contributors-15/contributors-136015

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

Ce n'est pas limité à seulement la comparaison à 0 mais à n'importe quelle chiffre et opérateur (>, <, >=, <=).

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

En fait, le contexte de decimal ne doit pas être mis à jour pour chaque variable. Dans le pratique on définit une fois la précision des calcules intermédiaires (les valeurs par défaut prec=28, Emin=-999999, Emax=999999 sont bien dans la majorité des cas). Et on arrondit le résultat final à la précision attendue.

Le risque de bug par un développeur de module est pour moi beaucoup plus grand si Odoo n'utilisait que des decimals

Ça dépend ce qu'on appel un bug. Si ne pas avoir d'exception mais un résultat incorrect n'est pas un bug alors oui. Mais à mon avis, il est préférable de détecter les bug en levant une exception mais si le résultat pour le cas courant n'est pas faux.

En fait utiliser des Decimal permet d'avoir un vrai test sur la précision du nombre stocker dans un champs et donc d'éviter la découverte trop tard de problème d’arrondi comme https://odoo-community.org/groups/contributors-15/contributors-136015

OK, je comprends. Ça dépend vraiment de qui va créer les "templates". Dans notre cas, on cherchait à avoir un outil plus ou moins WYSIWG.
Par contre, il n'y a pas besoin d'avoir LibreOffice pour générer des ODT avec relatorio. C'est seulement si on veut convertir dans un autre format. Du point de vue "templating", relatorio est basé sur Genshi et donc il y a vraiment toutes les fonctionnalités des moteurs de templating.

Étant un des auteurs de relatorio qui est un générateur d'ODT, je me demande pourquoi l'option ODT n'a pas été retenue ? Je n'ai pas retrouvé les raisons dans la vidéo.

Je devrais aussi préciser que notre CI lance les tests sur toutes les versions de Python supportées et avec les backend SQLite et PostgreSQL: https://drone.tryton.org/
Les tests avec SQLite, c'est surtout pratique quand on développe.

Oui l'export FEC est supporté: http://docs.tryton.org/projects/modules-account-fr/en/5.0/

Pour la plus part du temps, on a un contournement quand une fonctionnalité n'existe pas sur un "backend".
Et si un test requière une fonctionnalité spécifique qui n'est pas disponible pour le "backend" testé alors on le passe.

L'image docker peut être utilisée en production, elle utilise le serveur uwsgi. Mais il est conseillé de la mettre derrière un proxy inverse comme nginx ou lighttpd. Si la taille de l'entreprise est assez grande, il faudra probablement un peu de paramétrage comme augmenté le nombre de processus ou bien faire de la répartition de charge. Il est aussi conseillé par les développeurs de PostgreSQL de ne pas containériser la base de données.

Sauf qu’inversement c'est dans l'intérêt d'Odoo de ne pas communiquer dessus (si c'est vrai).

Il semble qu'ils aient trouvé un accord: https://medium.com/@parthivpatel_26549/the-great-copyright-suit-of-odoo-vs-flectra-and-the-conclusion-698c9f6facc7

Tryton a un module de base avec le plan comptable français et qui fournit aussi l'export FEC. Le module de rapport de taxe à l'encaissement a été développé entre autre pour des utilisateurs français.
Pour plus d'information, je conseillerais de voir sur la liste de diffusion française.

Attention si on fait des encaissements B2C (non soumis à la facturation), il faut avoir une attestation: https://linuxfr.org/news/point-d-etape-sur-loi-francaise-de-finances-2016-article-88-et-les-logiciels-libres-de-caisse

Voici un site qui regroupe les informations à propos de la boîte noire in Belgique: http://www.boîtenoire.be/

On pourrait imaginer avoir une "boîte noir" sertie en local qui signe.

Quand la loi couvrait aussi les logicielles de gestion comme Tryton, on était parti sur une solution d'horodatage d'une chaîne de hash. Il existe une norme ISO/IEC 18014 qui permet d'apposer un "timestamp" signé et il y a des sociétés qui fournissent un tel service. En plus on pourrait même faire signer par plusieurs fournisseurs afin d'avoir de la redondance.

Il n'y a pas de raison qu'il ne reste pas libre. Tryton est gérer par une Fondation privée Belge: http://www.tryton.org/foundation/ Le but de celle-ci ne peut pas être changé (garanti par l'état).
Par contre, il est important que le communauté continue à contribuer afin de rendre tous "fork" fermé obsolète.

Dans le stock, on peut réceptionner des commandes en kg et incrémenter le stock en mètres (coefficient de conversion) ?

Pas encore. Mais la fonctionnalité a déjà été évoquée et elle consisterait à utiliser un champs calculer.

On peut valoriser le stock suivant le PMP ou suivant le dernier prix d'achat ?

Les méthodes implémentées sont par prix fixe, prix moyen pondéré et le FIFO.
Le prix de dernier achat ne devrait pas être compliqué à faire (pas sûr que ce soit autoriser). Le problème principal serait de définir ce que ça veut dire précisément. Est-ce qu'on prend la date de l'achat, de la réception ou de la facturation comme référence etc.

Le PMP ne se met à jour que sur les mouvements adéquats (pas lors d'un changement d'emplacement par exemple) ?

Uniquement quand un produit est réceptionné depuis un fournisseur vers un emplacement de l'entrepôt.

La demo a le module production activé. Mais pour voir les nomenclatures, il faut se connecter avec admin:admin.

Oui c'est multi-niveau en passant par un produit intermédiaire. Et le calcul d’approvisionnement est récursif tant qu'il y a des nouvelles demandes crées.
Par contre, il faut configurer une période d'approvisionnement suffisamment long pour tenir compte de nombre de niveau et du temps de production de chacun.
Par contre, il n'y a pas de base le nomenclature fantôme mais ça ne devrait pas être trop compliqué à ajouter.

Est-ce que celui-ci a été installé ? Il ne vient pas de base avec le serveur: http://hg.tryton.org/sao/file/tip/README#l9

C'est vrai que ça peut perturber au début mais la configuration n'est pas strictement nécessaire, les valeurs par défaut doivent fonctionner dans la majorité de cas. Il n'y a vraiment que la connexion à la base de données qui soit requise si on utilise pas SQLite. Ensuite il faut initialiser la base de données.
Sinon une image Docker arrive sous peu.

La démo n'a que les modules les plus courant activés (26/118). En se connectant en tant que administrateur (admin:admin), on peut activer d'autres modules.
Sinon pour avoir une idée de l'étendue de ces fonctionnalités, on peut consulter les business cases.