I still don’t fully understand navigating from a product to a BOM and then to another product (see earlier topic).
I first created a number of Products, then added an identifier, attachments, and a Source to the automatically created variants for each. I then created a BOM with lines which reference Products (iiuc).
Why do BOM lines reference Products and not Variants? Do I understand this correctly?
When I follow the link from a BOM line to the Product, the name of the tab that opens is “Product” (singular) and the Related Records includes BOMs (which it does not if I access the same product directly via Products > Products), which makes me think what I am actually looking at is a Variant. When I access the same product from Products > Products, the name of the tab is “Products” (plural).
Am I understanding this correctly? If so, why is it this way (“Product” vs “Variant” vs “Products”)?
What is your explanation for how it all works that you give to your ciients?
Thanks, I think I’m just not getting the big picture…
P.S. @edbo I think I should review your old posts, you seem to have it figured out from the perspective of mechanical product design.
BOM refers to variant (it will be great to support also template).
Because we use “Product/Variant” terms only inside the product management and only “Product” outside. This is mainly because most of the use case does not involve variants.
Most of the time, we give no explanation because they are using only products (with a single variant but they do not know).
Why do they not (or will not) know? Can you give some example use cases that apply?
Iiuc, concerning product management, and if I do not need product variants, the procedure is to:
create a product using menu Products > Products
for ever on, edit the (single) variant (menu Products > Products > Variants) to, for example, add an Identifier, add an Image (product_image module is activated), or add Suppliers with costs and quantity price breaks.
Outside of the Products menu, for example using Production, if I add a “Product” to a BOM (as a BOM line), I am actually adding the variant (the single variant), and if I understand the difference between product templates and variants, I know I am adding a variant because tab/window title/name is singular “Product”. Do I understand this correctly?
Are there any standard modules or use cases (outside of product management) where the distinction between model and variant is important?
Anyone I’m curious about your definitions and use cases.
My customers and I also don’t understand the product / variant thing. They get really confused and throw Tryton away. So the first thing I talk about is the products and the next thing I do is add a new module which moves both into one, which in my view should be the standard in Tryton because 90% don’t use variants. But they must use variants because those are the REAL products and the products are (in the database) templates. I wish that all the modules only linked to the REAL products, but they don’t.
The current design is a dinosaur from the OpenERP era and instead of killing it, we try to keep it alive.
In the past I tried to start a discussion about merging the Template and Product together and create proper modules for product templates and product variants. With a proper variants design you can have multiple levels of variance, something like you have a product with different colors and each color have several sizes etc.
So IMO there is no usecase to use Product throughout the rest of Tryton. The Variant is the REAL product which counts. And my hope is that in the future there will be a new design and maybe a sponsoring to get this through.
It’s a special module specific for each customer. Like I said several modules are linking also to products which has to be accounted for but not all customers use those modules so I can leave the changes out.
The main thing the module does is to kind of move the fields from product.template to product.product through Function fields with getters and setters. Also the module makes some changes to the views. The customers are really happy, even there are some views that are still linked to the product instead of the variant. But the customer doesn’t use them so no big deal.
To generalize this will take more time and digging deeper to make it really work well.
That discussion derailed pretty quickly, mostly I think I wasn’t to clear about the alternative, proper modules. Also in the meantime Tryton has evolved much more and I think making use of the JSON Dict field in some way will make it possible to build proper variants. Yes, the user interface will be different (I think), but is that a problem? There are other systems out there using a variant system. Let look at how they do it and learn from it.
Just wanted to add that I fully agree: the existing template/variant implementation sucks from a useability standpoint, specially when combined with production modules.
We’ll be willing to finance a core initiative that solves the current situation.
For example you could have the almost exact same BoMs to produce different variant versions, usually it will depend on the variant used as input of the BoM.
In this case you would not want to create x times the BoM for each cases but a single BoM based on product templates and have a table (or a procedure) that matches the input variants with the output variant.
Can you link to the suggestion? I’m interested on discovering all the proposals around this topic.
We also have struggled the same scenario with variants on most customers.
Recently Shopify also changed their variants approach to options, seams similar to me to what attributes in Tryton are. While reading the changes I realized that the Shopify implementation is similar to something what we have implemented for some Tryton customers.
Variants should be REAL products so no need to handle things separately. Mostly the specifications of the product changes (color, texture, sizes etc), the price and name? It’s the big question how to put that data in.
I have become more of a purist of late with regard to part numbers (aka identifiers) and now follow the rule that “a new identifier is assigned whenever a variation in attributes can have a meaningful effect on the item’s form, fit, or function in the application.” i.e. NO variants allowed. In the strictest terms, even a template-code-dash-variant-code is an “intelligent” part number, albeit a very simple intelligent part number.
This identification concept is more fully described on the website for PDXpert (a software application for managing parts and BOMs that exports a PDX interchange package in compliance with IPC-2570/71 and IPC-2578) .
However, a seperate but related concept I am struggling with is how to present internal identifiers to customers. Often “smart” part numbers are used to simplify customer ordering, and IMO this is where variants are helpful - e.g. just change the dash number to get the “same” t-shirt but in a different size or color.
In particular I struggle with how to map from a sequentially assigned fully unique identifier system to the very smart part numbers often expected by customers for industrial products. Here is an example “product matrix” for an industrial process flow controller. I could create unique identifiers for each of the potential part numbers in advance, but in this case, a custom “U-Length” leads to an almost infinite number of possibilities and it would be more efficient to create internal part numbers as products are ordered (or at least create only the expected popular part numbers in advance), but how can the mapping be managed? Fwiw, constructing a smart part number from a list of attributes is typically done using a “configurator” module in an ERP (or at least those I’m familar with).
I’m also struggling with this because it becomes messy very fast. Customers are generating unique codes for their products and most of the times those codes / numbers never leave the factory because they are only used internally. When purchasing the product it will be the product code of the supplier which is different for the different variants.
All those parts have different codes and are mostly follow-up numbers in a certain range. The customer orders that particular number. When doing this online, you can help the customer to ‘build’ the number by allowing the different selections like size and then color.
When you are a reseller, just use separate products. It’s the easiest way. When you are the supplier of that product, then it’s an assembly which can be completely configured. But when assembled you get one product which can be sold. Personally as I was the supplier, I probably would create the products on-the-fly when sold using the ‘configurator’. That configurator creates the desired BOM and production order etc.
So yeah this is a very complex topic and getting consensus about it will be hard. Nevertheless a very interesting topic though!
Perhaps it can be useful to use autocomplete record creation helper on Model product.product.
Then when you enter a product code, the default_get could parse the code and generate the right Variant for creation. But for this to work you would need to have all the logic to generate the right Variant, which seems unreasonable considering you probably want to generate Variants for multiple Templates where the code parsing differs.
I’m curious about your definitions and use cases.
