Cédric Krier a écrit 125 commentaires

Tryton le pourra dans sa prochaine version: https://foss.heptapod.net/tryton/tryton/-/merge_requests/3412

Cette problématique me rappel un projet sur le quel j'ai travaillé où l'on a clairement dissocié la notion de variante pour l'ERP et l'e-commerce.
L'utilisation de variante dans l'ERP existe pour simplifier la création et partager les informations communes.
Or l'utilisation de variante pour l'e-commerce a un but différent qui est de proposer des choix/options différentes au client.

La solution utilisé pour ce projet a été de créer une application de gestion de produit (PIM) unique pour alimenter les différents site d'e-commerce. Le lien avec l'ERP se faisait uniquement via le SKU.

Je n'ai pas réussi à déplacer une variante d'un modèle de produit à un autre, bien que ça semble possible

Il est interdit de changer le modèle d'une variante sur Tryton (il y a trop de risque d'incompatibilité comme le changement de bien en service qui pose problème s'il y a déjà du stock etc.).
Par contre dans ce cas, je suggérerai de remplacer le produit/variant par un autre. Tryton se charge même de désactiver l'ancien une fois qu'on n'a plus de stock.

Si on peut aussi réunir des produits en variantes c'est tout ce que je souhaite!

Pareil j'utiliserai aussi le remplacement de produit.

Et si on veut convertir le stock existant, on pourra bientôt utiliser https://discuss.tryton.org/t/new-module-for-light-production-or-product-transformation/9184

Je ne vois pas pourquoi le site web ne pourrait pas désactiver les options des attributs non-compatibles avec celles déjà sélectionnée.

Pour ce qui est des fournisseurs, il me parait important de pouvoir définir au choix le/les fournisseurs sur le produit ou la variante.

Mes remarques correspondent à la modélisation dans Tryton. Les variantes et attributs ne sont pas vraiment liés. On peut créer des variantes sans le module d'attributs et on peut définir des attributs sans créer de variantes.

Il me semble que le problème est le lien fort entre les valeurs des attributs et les variantes.
Il faudrait que le système ne crée pas nécessairement une variante pour chaque combinaison de valeur possible d'attribut (surtout que ça peut vite exploser).

L'ajout du support des accises et de l'alcool vient de la contribution du projet Distilibre
La partie dans Tryton est très générique et correspond au minimum commun pour l'Europe.
Distilibre se focalise pour l'instant sur la gestion pour les distillateurs français avec un pré-paramétrage et des personnalisations des flux.

relatorio est basé sur Genshi qui est un langage de template XML.
Donc si relatorio arrive à compiler l'OpenDocument, il produira un XML valide.
Par contre comme ce sont des "Placehoders" d'OpenDocument qui sont utilisé, il est possible de créer un template qui ne compilera pas (ex: manque de balise fermante etc.)

C'est ça. relatorio ne fait que de l'ODF vers ODF. Il faut utiliser un autre outils pour transformer vers un autre format.

Avec relatorio, les champs dynamiques sont aussi opérationnelle car LibreOffice les met à jour à l'ouverture.

Il est vrai que l'inclusion de texte au format HTML est une fonctionnalité qui manque à relatorio. On aimerait avoir un XSLT pour convertir le HTML en ODF: https://bugs.tryton.org/2068

Disclosure: Je suis une des mainteneurs de Relatorio

De ce que je comprends, une différence importante est que LOTemplate a besoin de données statiques (un JSON) alors que Relatorio est une librairie qui peut être appelée sur des données qui seront chargées à la demande (par exemple d'un ORM).
Et une autre est que Relatorio n'a pas besoin d'une connexion à LibreOffice pour faire le rendu du template. D'ailleurs on publie une image Docker pour pouvoir faire uniquement la conversion en PDF sur un service externe.

C'est une démo partagée avec le droit administrateur donc il peut y avoir de temps en temps des gens qui la cassent. Elle est remise à zéro toutes les nuits.

La richesse de l'interface dépend du nombre de module activé et des droits d'accès de l'utilisateur.
Elle peut être très épurée s'il y a peut de fonctionnalité activée.

Il y a aussi Heptapod (fork amical de Gitlab) pour ceux qui veulent utiliser Mercurial

Le plus simple pour déployer et maintenir à jour un Tryton standard (sans code custom) est d'utiliser l'image Docker.
On fournit même un docker compose.yml près à l'emploi. Attention quand même à fixer la variable VERSION pour ne pas avoir d'upgrade surprise (idem pour PG_VERSION).

Sur Tryton on a décidé de lister les taxes, qui sont basées sur encaissement, sur l'année fiscale (et optionnellement sur la période fiscale). Ceci permet de planifier le changement de régime d'une année à l'autre. On liste aussi les taxes sur encaissement sur les fournisseurs. Le résultat des deux configurations devient une propriété de la ligne de taxe comptable sur la quelle on calculera la proportion du montant payé à chaque période.

Pour ça il faut activer le module stock_lot.

Il y a un effort en cours pour ajouter un module de point de vente: https://bugs.tryton.org/issue8737
Je ne sais pas ce qu'on entend exactement par "multi établissement" mais Tryton peut gérer plusieurs sociétés dans la même base de données et aussi plusieurs entrepôts.

C'était un problème de configuration du CDN qui bloquait les requêtes ne venant pas de discuss.tryton.org.
Ça devrait marché maintenant, sinon vous pouvez consulter la capture d'écran (et d'autres) depuis la page de l'annonce.

Pas encore mais il y a un prototype en cour: https://bugs.tryton.org/issue8737
Après Tryton peut facilement être couplé avec un système de point de vente classique avec par exemple un import des ventes chaque jour.

Pour l'instant la liste présentée est construite sur le mérite, il faut participer activement au projet pour être listé.
Tryton n'étant pas chapeauté par une entité commerciale mais juste une fondation composée de bénévole. Il est difficile de mettre en place une certification. De plus comme les participants au projet sont également les intégrateurs qui devraient être certifié, il faudrait que ces "concurrents" se certifient l'un l'autre.
Pour un client, il est probablement préférable de demander des cas d'affaires pour juger de la compétence d'un intégrateur.

On utilise le thème Bootstrap par défaut exprès pour permettre à l'intégrateur d'utiliser le thème qu'il souhaite. C'est d’ailleurs le cas:
Kopen thème
Kalenis LIMS thème

Par contre, il ne faut pas confondre "eye-candy" avec ergonomie. Nous faisons un effort important à avoir et maintenir une bonne ergonomie dans Tryton. Par exemple: l'interface est manipulable entièrement via le clavier; le majorité des actions sont applicables sur un ensemble d'enregistrements d'un coup; l'auto-complétion est présente sur la plupart des champs; les messages d'erreurs essaient de toujours fournir une solution; etc. Évidement il y a encore beaucoup de choses qu'on pourrait (et qu'on va) améliorer mais pour pouvoir juger de l'ergonomie d'un logiciel, il faut l'utiliser un certain temps.

En ce qui concerne les intégrateurs nous maintenons une liste non-exhaustive. Comme c'est du logiciel libre écrit en Python et suivant assez bien les standards, il n'est pas trop difficile de trouver des développeurs qui peuvent y travailler.

Pour l'instant, on a 4 plans comptables: Belge, Français, Allemand et Espagnole (l’Espagnole reçoit ces derniers temps beaucoup d'améliorations). Il y a un plan en préparation pour l'Angleterre.
On voit que beaucoup utilisent Tryton pour faire le suivit d'une comptabilité de gestion et envoie les résultats chaque période au comptable. Du coup cette utilisation ne requière généralement pas d'un plan comptable ni de fonctionnalité spécifique pour le pays.
Mais cela n'empêche pas certain de faire toute leur comptabilité dans Tryton moyennant une bonne connaissance comptable.

La fonction existait aussi dans plusieurs modules extérieurs (implémentée de différentes manières). Mais l'intérêt de l'avoir de base est la garantie de montée en version, la compatibilité avec tous les autres modules de base, la maintenant et évolution collective.

je l'utilise chez mes clients depuis des années, des clients dans l'industrie pharmaceutique, ils achètent souvent dans des unités très différentes de celles de la vente.

Pour moi, la seul façon de faire avec Odoo c'est d'avoir des catégories d'unité de mesure différentes pour chaque produit. Car il y a bien une contrainte entre les deux unités de mesure: https://github.com/odoo/odoo/blob/72be63b592bfe5a7b21970b86955e84d5224b667/addons/product/models/product_template.py#L343-L347
Ceci pouvait se faire aussi sur Tryton depuis la version 1.0.

Ici les modules permettent d'utiliser des mesures de catégories différentes en définissant le facteur de conversion sur la fiche produit. Ainsi on ne démultiplie pas les unités de mesures.

j'ai essayé de tester GnuHealth, implémentation de Tryton dans la gestion médicale, sans trop de succès.

GNU Health cible les pays en voient de développement où la législation en la matière est moins contraignante. Le but de l'ONG est d'amélioré les soins de santé par une informatisation efficaces des établissements.

sinon, pour la fonctionnalité, je confirme que ca existe dans OpenERP/Odoo depuis au moins la version 6.04 (si ce n'est la 5).

L'a-tu testée ? Moi, en l'activant elle ne me permet pas de définir deux unités de mesure de catégories différentes.
Tryton aussi a cette fonctionnalité depuis la version 1.0 (avec même 3 unités différentes pour l'achat, la vente et le stockage).