Cédric Krier a écrit 111 commentaires

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.

Tryton se veut bien plus modulaire et flexible pour des développements spécifiques. Car le cœur ne possède pas de logique métier, tout est développé avec des modules. Les modules de Tryton peuvent littéralement modifier n'importe quel modèle (class) du système.
Or ERPNext a une démarche plus monolithique et fonctionne avec des hooks prévus. Il ne pousse pas la modularité au même niveau.

Il a tout ça, sauf la gestion de qualité, mais qui ne serait qu’une opération spéciale :

• http://doc.tryton.org/4.6/modules/production/doc/index.html
• http://doc.tryton.org/4.6/modules/production_routing/doc/index.html
• http://doc.tryton.org/4.6/modules/production_work/doc/index.html
• http://doc.tryton.org/4.6/modules/production_work_timesheet/doc/index.html

La revue se trouve ici: https://codereview.appspot.com/322730043/
On attend encore de pouvoir faire tourner les tests standard de trytond par ce backend. Ceci requière la possibilité d'ajouter/de découvrir des tests automatiquement.

Tryton a un modèle de plan comptable Français ainsi que les taxes les plus courantes. Mais ce n'est qu'un modèle, une fois une instance générée elle peut être complétée et/ou modifiée. Il a aussi l'export FEC
En ce qui concerne la loi finances 2016, B2CK va mettre en place un service de vente de Tryton avec attestation. Ce sera exactement le même logiciel qui sera vendu.

On a de temps en temps des demandes de POS pour Tryton.
Je me demande s'il est facile de remplacer le serveur Pastèque par un serveur spécifique ? Est-ce que l'API est standardisée ? Ou bien faut-il faire une passerelle avec le serveur ?

Et aussi les onglets pourraient être plus haut (dans la navbar en haut de l'écran), pour créer de l'espace avec les icônes de l'onglet.

J'ai fait un prototype https://bugs.tryton.org/issue6124. On va voir ce qu'en pense la communauté.

Dans les trucs "faciles" à faire, tu peux afficher/masquer le menu de gauche en cliquant sur le Nom d'entreprise ("Tryton" dans la démo) ou le masquer en partie à la façon de Wordpress.

Le menu se cache automatiquement si l'écran est trop petit (« responsive »).

C'est un pis-aller à mon sens — rien ne vaut la simplification.

Mais le menu est un point crucial de l'application sans ça on ne sait rien faire dans l'application. Si on le cache, je suis sûr qu'on va être assaillis de questions d'utilisateurs qui ne trouvent plus rien.

Par exemple, Gmail ou Dolphin (kde) sont des bons modèles d'interface simplifié car ce qui sert moins est retiré de la barre d'icône et regroupé dans des menus "plus".

C'est parce que tu a utilisé l'utilisateur de demo qui a accès quasiment à tout. Normalement, un employé est affecté qu'à certain groupe et donc ne voit que les entrées de menu correspondantes (3-4 généralement).

Et aussi les onglets pourraient être plus haut (dans la navbar en haut de l'écran), pour créer de l'espace avec les icônes de l'onglet.

C'est une idée à creuser. « Patch is welcomed » ;-)

La sobriété de l'interface est essentielle pour qu'ils soient capable de "découvrir" (sans chercher donc) les fonctions utiles.

J'y ai repensé et je pense que probablement un des problèmes serait que la « toolbar » soit trop présente avec tous ces libellés. J'ai donc proposé une amélioration qui réduit sa présence: https://bugs.tryton.org/issue6120 (inclus screenshots).

Des thèmes ont déjà été publié comme https://github.com/coopengo/sao/tree/master/theme/coog

Il y a quelques années, oui, pour voir. On a abandonné après quelques semaines.

En quelques années, le logiciel a fortement évolué. Je pense que le résultat de cette expérience ne peut plus être prise en compte.

Un second groupe a refusé de s'y engager, car ils percevait plus les contraintes que les bénéfices.

Toutes les structures ne sont pas nécessairement prête à passer à un outil de gestion ou bien la solution ne convient pas à leur métier (généralement on arrive à adapter Tryton).

Mais il y avait un fort sentiment de perdre du temps à s'y retrouver et de ne pas être capable de savoir ce que le logiciel pouvait faire.

C'est certainement par manque de formation et peut-être d'une mauvais configuration. Quand on met en place Tryton, on fait une petite formation d'½ journée et alors les utilisateurs sont opérationnels et efficaces sur tous le système car il y a une vrai cohérence d'ensemble.

C'est difficile de mieux expliquer ce qui n'est que ressenti.

Pour moi, j'entends que c'est une question de goût et de couleur (qui ne se discute pas). Par contre, un point que je n'ai pas signalé, c'est que délibérément la charte graphique du client web est réduit au minimum. On utilise le thème par défaut plus quelques règles CSS pour avoir un comportement correcte. L'objectif est que les intégrateurs ajoutent un thème bootstrap ou personnalise l’existant et ceci est d'autant plus facile que l'on part d'une base de départ la plus neutre et simple.

Du côté de Tryton, on tente de soit réutiliser des librairies existantes (ex: python-stdnum) soit d'en créer (comme par exemple: relatorio pour la génération de document).
Mais bon après la valeur ajoutée d'un module vient principalement de son design et de son intégration avec le reste du système, des points qui sont fortement différents chez chacun.

L'ergonomie je la base sur les réactions des utilisateurs

Donc je suppose que tu a mis des utilisateurs devant Tryton. Ce serait bien d'avoir un retour de cette expérience. De notre côté, quand on fait des formations utilisateurs, on explique une fois les quelques concepts utilisés dans Tryton et c'est parti. Car Tryton reprend toujours les mêmes concepts pour tous ces interfaces graphiques.

La sobriété de l'interface est essentielle pour qu'ils soient capable de "découvrir" (sans chercher donc) les fonctions utiles

C'est vraiment étrange car généralement, on reçoit des remarques sur notre interface trop sobre.

Quant à là communauté qui mène quelque part, ça n'empêche pas de préparer une vision des choses qui sorte de la technique. Debian, Gnome, KDE, etc. en ont une. C'est dommage de ne pas en avoir.

Ben en fait, on en a une, c'est sur la première page du site: modularity, scalability and security

Je doute fort qu'une convergence soit possible car la modélisation des objets métiers est fort différente. C'est d'ailleurs un des points historique de la divergence avec Odoo. Pour ERPNext, leur système de module est complètement différent car principalement basé sur des «hooks».

Si tu trouve l'interface web lente, le serveur doit être certainement surchargé pour l'instant (en plus ce n'est vraiment pas un machine puissante).
Pour l'ergonomie, je te conseil de regarder l'application bureau car elle est à des années lumières de l'ergonomie des deux précédents (tout peut être fait au clavier). Après il faut voir comment tu compare l'ergonomie car si tu le fait comme Odoo en comptant les clics, on ne sera pas sur la même longueur d'onde. Par contre, nous trouvons qu'avoir des onglets augmente grandement la productivité des utilisateurs.
A propos de l'encombrement, de base Tryton n'affiche que le strict minimum. Évidement si tu la compare à celle d'Odoo, au moins Tryton affiche les données importantes. Par exemple quand on encode une vente, on montre l'unité de mesure de la lignes au moins.

Finalement, Tryton est développé sur un modèle différent des deux exemples. Par exemple, la où les développements d'Odoo sont dirigés par la société Odoo, Tryton évolue au gré des contributions de la communauté et donc Tryton ira là où la communauté le mènera…