MAVA Spirit, un de nos modestes et géniaux contributeurs, nous soumet le problème suivant:
Ils produisent des dizaines de recettes de rhums arrangés différentes;
Multipliées par autant de formats de produits finis (bouteilles 50 cL, 70 cl, 100 cL etc.);
Ce qui fait autant de nomenclatures que de produits, et le problème c’est qu’on se retrouve avec des centaines de nomenclatures qui peuvent avoir le même nom (contrairement au produits qui ne peuvent pas avoir le même code).
Est-il envisageable d’ajouter un code de nomenclature en standard (dans Tryton core), comme c’est le cas avec les produits, de façon à éviter les erreurs et pouvoir trier/filtrer/accéder un peu plus aisément et sûrement aux nomenclatures?
Sinon, pourquoi? (Comme par exemple des problèmes de perfs ou d’autres trucs qui ne servent à personne d’autre qu’à MAVA? – Je pourrai ainsi défendre cette position, notre position, auprès du client. )
The link you provided is the issue, which originates this feature.
The link Cedrik provided in the previous post is the merge request (MR), that’s the state of art of the development for this feature.
Inside the MR you can see the changes proposed. But as the MR is still open means that this is still not completed.
Today’s date the problem to continue with this feature seams to raise in this review lack of agreement.
You can take your own risk as this state is for development, and implement the same changes proposed to see if it works for you, find some bug, you miss something, test this feature…
If there is a community interest in having such module I do not think it will be so complex to extract the current review state and include it as a module in tryton.community repositories and publish it to Pypi under this umbrella.
If there is a community interest in having such module I do not think it will be so complex to extract the current review state and include it as a module in tryton.community repositories and publish it to Pypi under this umbrella.
Cool! Tant qu’à faire ce peu, est-ce que l’actuelle version candidate du phantom BOM fiel sera incluse, à terme, dans Tryton core, comme je le garantis le plus possible à mes clients métier? (C’est comme ça que nous avons orienté tous nos choix de développement entre les métiers – que nous représentons – et la techno – que la communauté Tryton représente.)
Par ailleurs, je suis nul en git, et je n’arrive pas à trouver de lien de téléchargement pour tester le module sur mon serveur: pourrais-tu m’indiquer la commande wget qui va bien stp?
Complément d’info: actuellement, nous sommes en v7.0.8: le module phantom BOM est-il testable en l’état sur cette version de Tryton? (Oui, je sais, à mes risques et périls, mais je vais vous faire un retour rapide dès que je peux l’installer, parce que c’est dans l’intérêt de mon client de ne pas se galérer avec des centaines de BOM difficiles à gérer et maintenir… )
Traceback (most recent call last):
File "/trytond/wsgi.py", line 109, in dispatch_request
return endpoint(request, **request.view_args)
File "/trytond/protocols/dispatcher.py", line 43, in rpc
return methods.get(request.rpc_method, _dispatch)(
File "/trytond/wsgi.py", line 75, in wrapper
return func(request, *args, **kwargs)
File "/trytond/protocols/wrappers.py", line 197, in wrapper
return func(request, pool, *args, **kwargs)
File "/trytond/protocols/dispatcher.py", line 204, in _dispatch
result = rpc.result(meth(*c_args, **c_kwargs))
File "/trytond/model/modelsql.py", line 240, in wrapper
return func(cls, *args, **kwargs)
File "/trytond/model/modelsql.py", line 928, in create
field.set(cls, fname, *fargs)
File "/trytond/model/fields/one2many.py", line 290, in set
Target.create(to_create)
File "/trytond/model/modelsql.py", line 240, in wrapper
return func(cls, *args, **kwargs)
File "/trytond/model/modelsql.py", line 886, in create
new_ids.extend(db_insert(
File "/trytond/model/modelsql.py", line 795, in db_insert
cursor.execute(*table.insert(
File "/trytond/backend/postgresql/database.py", line 68, in execute
cursor.execute(self, sql, args)
psycopg2.errors.UndefinedColumn: column "phantom" of relation "production_bom_input" does not exist
LINE 1: ...nput" AS "a" ("create_uid", "create_date", "bom", "phantom",...
^
Yes, we are working on the path but unfortunatly the review of such task is stalled. I’m wating for 10 months to get some feedback on how to move the review forward. It seems there is not enougth interest from the tryton maintainers to move it forward. For that reason we are proposing other alternatives to make it available to more person.
Yes, we have the MR deployed to 7.0 series on some environment without issues.
Great to know you managed to deploy the code!
As the review adds new fields on the production module you must update such module in the database to fix the error. You can achieve it with the following command:
trytond-admin -d <db_name> -u production
Once updated you will need to restart the server and thats it!
Use a diferent product for input (the phantom product).
Create a bom for the phantom product and then add it as default bom on the product form.
With this setup if you check the phantom bom checkbox, when using such bom on a production the bom of the phantom product will be used to compute the inputs, replacing the phantom bom product.
Je vois bien l’intérêt des phantom BOM, mais je ne suis pas certain de tout comprendre et je peux voir ça plus tard.
Est-ce que si on finance le rajout d’un code unique pour les nomenclatures (et comme pour les produits, avec une séquence optionnelle pour remplir le code), ça va dans le sens commun?
Dans un premier temps, si, en plus d’être une amélioration utile, c’est facile à maintenir, et ça ne rajoute pas d’adhérence inutile (de mon expérience, c’est rare les petites entreprises qui ont des nomenclatures complexes):
“Bon pour accord” VERSATIL (je ne te demande même pas de chiffrer, j’imagine que ça s’intègre en moins de 4h… )
Tu me dis si c’est bon pour toi: je vois avec MAVA (il en a besoin maintenant, et je souhaite lui faire la démonstration que la communauté Tryton est réactive quand les demandes clients sont pertinentes et qu’elles vont dans le sens des communs).
)
