Thanks Udo, it's good to get confirmation that someone else has successfully walked a similar path.
On Monday, 9 June 2014 00:17:15 UTC-6, Udo Spallek wrote: > > > your convention sounds reasonable to me. A customer uses something > similar, but based on product name == BOM name. They have the case to > be able to order a product instead of producing it. The internal product > code is other than the suppliers codes. So they base their naming > scheme on names instead of codes. > Based on my limited Tryton experience so far, I had understood a product code was the company's own code for a product, and the code in the Product Supplier form holds the supplier's code for the product. Is this correct? When you say "a customer", do you mean your customer (or client), and not a Tryton product customer in general? If you mean your customer, do they use the Product Supplier to identify the supplier they order the product from? If yes, why do they not use the code in the Product Supplier view? Is it more convenient for them to do it this way (and if so, why)? If not, am I misunderstanding the intent of the product supplier code? I would prefer a naming convention based on codes, as you suggest. > Because names may change over time, codes should not. > I agree. Once a product is created with a unique product code, the code and basic essence of the product must remain the same (a purist might say if it does change, it means it is a different product). However, a product name must be permitted to change because naming conventions often change over time. E.g. perhaps it was not important to include power dissipation (wattage) in the original name, but now it is important. The revision suffix is IMHO only needed, when you may have more > then one recipe (BOM) per product, or when your recipes changes over > time. > I am involved with design and manufacturing of high-tech-type products, where it is common to have BoMs change over time lifetime of a product as defects are found and corrected, and design changes are made to improve quality or reduce cost. Often there is a formal process (e.g. Engineering Change Order, or ECO) which must be followed to manage the change (as it can be quite complicated and involved). Are you aware of any modules which are particularly useful in this type of situation? Regards, Dale
