Well you just have to say that each product needs at least one variant.
They should duplicate a variant only if they want another variant.
This is the reason of the naming to acknowledge the user that he is working on variant (not product).
I do not see how this will solve the problem in relation of product/variant.
You will still have variant that if they are copied will still be linked to a template and shared fields will still not be editable.
I do not see how it can be proper. How will you know which field of variant should be on the “override” by the template? How will you manage edition of such shared field from the variant form?
The way that I look at it is - to give an example - if my company stocked shoes, then the template would represent a type of shoe. That shoe may then come in three different colours, black, brown and navy, and each of these would be a variant. This allows you to set some of the properties for the shoe in the template, as still be able to differentiate between the different codes, colours, etc for stock levels etc.
I’m sure most companies don’t structure their products in this way, but this extra flexibility (confusion?) is there for the ones that do.
There is a nantic module that I think is used to ensure one template per product trytond-product_variant_unique that you may want to look at?
And they say ‘Why? I don’t need a variant, I just want a product’. This will be an endless discussion but what I’m saying is that there has to be a very clear description about what is a product and what is a variant. And why it is working this way. What’s the reason behind this? Why can I not create just a product, why should be there always an variant?
It’s about removing the template completely so only variants exists. The product / variant implementation is a TinyErp / OpenERP / Odoo implementation which caused in the days a lot of trouble. Tryton have it now kind of ‘solved’ by only using variant thoughout the rest of the system. It’s also a followup on your idea MagicPoint presentation foils of a better product model.
I’m completely with you here, but most of the companies don’t need that extra layer. So users should be able to create just a product without a variant or a variant without a product.
Because a variant is used throughout the rest of the system (all modules take there information from product.product = variant) IMO user should be able to create variants without a product. This means that the fields on the product have to move to the variant. Looking on database level this means moving all the fields to product.product.
That’s an option, but it doesn’t do anything about the complaints from my users (which I’m taking very serious because happy users are your marketing people inside the company).
I’ve created a special module with a lot of Function fields (added only the needed fields) with getters and setters. In that way users are able to CRUD products on one form / list view and they are really happy about it. So I thought it’s time to see how others are thinking about this.
Currently there is a TemplateFunction implementation on product.product which read the fields from the template. Probably enabling a setter method will simplify your use special module.
This is what I usually explain but for me it’s hard to explain to users how to create a template directly from the sale order. Normally I recommend opening to the “Products” option to directly create the template and a variant (which is implicitly created by default).
I like this proposal but only if we move the product template to a separate module which is only activated when the database requires products and variants. This will simplify things for the all the setups which use a single variant for each template. It seems to me that they are more than with multiple variants. Of course, the new module can be added as extra_depends for the modules that may require it.
Having said that I think the new module will be responsible of creating the template with all the fields to be reused and add the template on the product.product. Other modules can add fields on template by using the extra depends. If a template is set on a product we can make the fields defined on template readonly at product level and use the values from the template. Probably it can be similar to the “Override Template” functionality of the account module.
This will also avoid the duplicity of the Template and Product fields on the Product Supplier and Customer Product models.
This will be a big refactor for Tryton, so it has to be though carefully.
I still do not understand how you manage where the data is stored.
For me, I see no answer how to deal with the ambiguity of having field duplicated at each level. It sounds just like the old OpenERP design which we have run away because of this very ambiguity (non explicit).
For me, the account template can not be used as example because the goals are very different. The accounts are updated on demand at once. The product must always have the correct values.
I do not agree. We will always need the current design. We must be able to define those properties at both level.
I do not see the real benefit but I see a lot of drawbacks (migration, complexity, duplicate data etc).
That’s also what I tell them to do. But then the fun begins and they start asking about the difference etc. For example why is list_price on the template and cost_price on the variant? Shouldn’t this be swapped? It turns out that sometimes variants also can have different list_price and cost_price. How are those going to be managed in the current situation?
That’s what I meant. Eventually make Template and Variant separate modules.
For me the a template will not be more than a set of fields with a value or values. The field is taken from the product.product table by the user and a value is added to it. I was thinking of storing this data in a Dict with the field name as the key. Extra information like ‘required’ or ‘blocked by template’ etc can also be added. When a new product is created the user can add the template which then fills the different fields based on the data in the template. Creating templates can also be restricted to a group, so a predefined set of templates is available for the user.
The idea is kind of the same as for product attributes.
Variants can have a same kind of design, but I haven’t thought that through very well yet. Because variants are actual products.
I think that complexity will decrease because of just one place where the actual product data lives. This makes is for module owner easier to create a module which extends products. You only have duplicate data for the values you want to add to a new product based on the template. You can ask yourself if that’s duplicate data.
But for me, the real benefit is that new users can adapt Tryton much easier because it makes Tryton more straightforward. Also users who don’t use Tryton much often (say twice a year they do something with products and they open the client once a month) don’t have to fight anymore with the product. I’m seeing this in reality. They have no problem with sales or invoices, but they always complain about products.
The design also follows the rest of Tryton like sale / purchase / invoice. They all have one list and view where users can do their work.
I don’t understand where the problem is.
If you use the product then you get only one form, with all the fields of product and variant and the possibility to create a second variant if needed.
If you hide the menu entry ‘variant’, then you shouldn’t get any question.
What did I miss ?
If you use the template menu there is no possiblity to search and see the product code but its shown on the sale/purchase/shipments. A little bit weird.
If you use the production modules the BOM information is on the Variant form (only accessible there) so you end up having to edit the information on two diferent tabs. This causes a big confusion because the user never knows where he has to edit the data.
If you have to edit some product information directly from the sale/purchase order the variant form is opened. Most of the fields readonly and you have to dig into the template to edit. So there is one strange screen without any real usage adding complexity for the user.
Yes, but only if the “template functionality” is activated on the module. Currently you go to Products under the supplier tab and create a new record. The first field presented is the “Variant” one, which if you don’t use a variants you do not know which value to set.
I’ve seen it recently with a user that was starting to tryton. He was creating historical sale orders and creating new products while it finds they do not exist on the system.
All the fields are defined on product and by default only records of product.product are used.
On a separate module the product.template model is defined, and each module can add the required fields on the template model (for example the attribute set of product_attribute). Once the template is set on a product all the template values are copied from the template, the fields are set to readonly and updated when the template values are set.
Most of the current fields from template should be moved to product and then they can be customized per implementation to decide which fields are syncronitzed. It’s what we do know but the other way arround.
The benefit is that we simplify the system for the users that do not use product variants and we implement the variant functionality as an option. Currently is activated by default which makes the system more complex.
I do not see a big issue about migration it’s just a mather of moving data from template to product. For me the property one was a more complex migration and we did it very weel.
Could you elaborate on the complexity and duplicate data that you find?
Sorry but synchronization on the fly is the worst design possible. It is the best way to have “unsynchronized data”. Such bugs are the worst to fix because they are detected way after the real problem happened.
Also I do not see how MultiValue would be correctly synchronized.
I do not see for which use case we simplify. The only use case shown for now is probably the weird migration process I ever heard of.
Also simplification of UI should not come at such complexity expense on the code-side.
Except that you do not care about existing usage of variants.
Synchronization is always a nightmare. It took us more than 10 years to get it almost right for account. And this is just for on-demand synchronization.
Synchronization is a by definition a duplication of data.
Just to add to the list, having the active field on the template and on the variants is currently a nightmare. If you deactivate the template and not the variant the product is still usable.
Ok so we may use the following function to avoid syncronization:
class Product:
def __getattr__(self, name):
if self.template:
try:
return getattr(self.template, name)
except AttributeError:
pass
return super().__getattr__(name)
Of course this should be only activated on the product template value.
Just add the templat as MultiValue mattch pattern and you have it.
Values used on variants can be skipped if the new product_template module is activated. So it’s just a mather of activating the module when it’s required and taking in account this values on migration.
Indeed it can be a requirement for the product_attribute module, which is a clear use case of variants, so it will be automatically activated when required.
These variants already live in the product.product table. With migration the fields can be filled based on the data from the template. I doubt if there are a lot of templates with more then one variant. You can’t give your variant a name, because that one is taken from the template.
I use it for product specifications like dimensions and weight. But I don’t use variants. Also in the current situation the set is defined on the template and adding the attributes is done on the variant. So when you have added the wrong set, you have to go back to the template. For a long-time or ‘heavy’ user not a big problem, but for first-time or ‘not-so-heavy’ noob user it is. And they will complain about it which is bad because they should be telling how nice Tryton is. Happy users are the best marketing people. So changing the product module is a challenge, but I think it’s worth doing to get more (happy) users on board.
I do not understand. In your design MultiValue should be on both template and product and be synchronized used the proper pattern each time. For me, this adds again complexity.
No, I do not agree. This is not so simple. If I have code to use variant as it is designed in Tryton since version 1.0. There is not easy migration to this new proposal. You can not just skip values, there are proper migration to do for each case (and probably synchronization to perform during update, for sure a nightmare).
You can not thing only about standard module. Almost all Tryton setup are customized and we advise on a specif variant customization since more than 10 years. You can not now just say, we change all over and you have to make a migration yourself for all the customization you did following our advise.
But it is more valuable to keep existing users than make happy newbie that just need to learn the system.
I agree here. But I don’t have any idea how much Tryton is used. My intention is that the current behavior would be still possible.
You have to keep the existing user also happy, but when you want to grow and attract attention and with that more users you have to put yourself in their seat. Users who don’t like computers, middle aged and now their boss said he want a new software program and made already some choices. Now they can choose between the several ERP-packages including Tryton. You can talk what you want, but they will choose the system based on UX and which feels comfortable.
I’m talking from experience. Now with the special module which hides the template and variant and just shows them the products, failures went to zero, after 2 months not using Tryton at all they wanted to add some new products and had no problem to do so.
That said, I’m going to make a ‘proof of concept’ based on my idea to see how it will work out.
Just to add my 2¢ to have more opinions on the issue:
The expectations of our customers are very different depending on the business segment they are coming from. Those coming from the clothing industry and likewise business fields are familiar from the beginning with the concept of products and variants. They would definitely say there is missing something in Tryton if the product/variant concept would be missing. Others indeed just have or prefer for simplicity the 1:1 relation of product/variant.
While I think a module like your special module can be of great value (there exist others as already pointed out), I definitely wouldn’t merge it into base.
Nevertheless I very much agree that there is room for improvement.
The separation of list price on the template and cost price on the variant was a shortcoming in design in the first place. Almost all of our customers using variants have distinct list prices for variants, so we move it currently to the variant.
I also agree that the UX mixing readonly informational fields from the template and editable fields on the variant can be very much improved by separating them visually. A first improvment is Improve product form with no template (#9020) · Issues · Tryton / Tryton · GitLab. I would additionally suggest to separate the editable fields on one area of the form and the informal fields on another area to have a clear notion for the user which fields are inherited and which are really part of the variant. Eventually best would be to put the informal fields on a separate tab.
Thanks for your work on this topic. The issue (and other related) improved the UX.
While testing the proposed patch I’ve found another issue: Domain inversion is not working on template. So when creating a new product from sale order it is possible to create a template without the salable flag. This issue is not raised until you save the sale order which then it’s probably too late
Also providing a solution for:
Will also improve the usage when not using variants.
I used to use my modified Tryton (versions 4.X) without variants. I was very nice but every update was nightmare because I could not do this modification in separate module and after every update I must correct 5 or 6 stock modules. After transition to Tryton 5 I found my way how take advantage of using variants and I came back to stock Tryton. After two years I must say, that I dream to return to my old system without variants. It allowed me to save a lot of time and was more ergonomic, simple and error proof. The most of my goods don’t have variants and I’m not very happy to my rotation between Products and Variants. To change (or create) the name I must go to products, but to change the code - to the variants, the list price is in the product but the cost price in the variant, UOM is in the product, BOM is in the variant etc.
I understand that there are many cases of intensive use of variants and current behaviour is very appropriate for them. But if we can have possibility to eliminate variant for people don’t need it, it would be very useful, I think.
Also by my opinion it would be very useful to have the list price in variant. To give special price for the less popular (or on contrary for extremely popular) colour, size etc is common practice.
On other hand the price in the variant level let us to enlarge sphere of using of variant. For example, we can create variant for some goods with defects, goods with reduced (or extended) warranty, etc. It would be particularly comfortable if we have method to move the goods from one variant to other.
It’s every day procedure for the producers of the non-standard goods (furniture, metal works, windows, doors, stairs etc). Every order is a new product (or products) with his own name, code, list price, cost price, UOM, BOM, attributes etc.
but what I’m saying is that there has to be a very clear description about what is a product and what is a variant. And why it is working this way. What’s the reason behind this? Why can I not create just a product, why should be there always an variant?