Merge products / variants into one database table (one view / one list)

This will not change with this proposal.

Does not work for search, order or SQL query.

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.

FYI, I created Issue 9020: Improve product form with no template - Tryton issue tracker

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.

2 Likes

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.

Answering myself. I’ve just filled Add search_rec_name on templates (#9026) · Issues · Tryton / Tryton · GitLab which improves the behaviour when searching on templates.

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.

1 Like

I do not think it is the proper way of working in this case. First, the salesmen do not have the right to create products by default. Second the salesmen should not know all the property to fill like accounting, taxes, suppliers etc.
Indeed the case of selling non-standards goods should probably be about filling just the template on the sale line and some properties (like attributes). Then the sale on confirmation will create the product/variant if necessary.

We have the rights to give the rights to somebody

If he or she sells only non-standard windows (doors, beds, stairs etc) most likely there it will be only one type of accounts and taxes (and no suppliers for producing company) and if we have good default values what is reason to ask somebody to create variant? Particularly for small (but effective) business companies where all administrative and sales staff would be 1 or 2 persons?

Take it the other way, this case is exactly a use case for template/variant: Define the standard values on the tempate and only create variants.

It would be nice but the curent design don’t let to give the list price and the name to the variant

This is wrong. The module is specially designed to allow such customization.
You can override any template field on the product level.

1 Like

Mmmm… I’m going to study

Can you point me to some example how to do that?

I have no public example but the basic is to define the field on the product.product because it will get precedence over the field on product.template.
This field can be a computed field. For example it you want to have a different list price per variant which is computed from the template, you can do something like (no tested):

class Product(metaclass=PoolMeta):
    __name__ = 'product.product'
    list_price_formula = fields.Char("List Price Formula")
    list_price = fields.Function(fields.Numeric("List Price"), 'get_list_price')

    @classmethod
    def default_list_price_formula(cls):
        return 'list_price'

    def get_list_price(self, name, **context):
         context.setdefault('names', {})['list_price'] = self.template.list_price
         context.setdefault('functions', {})['Decimal'] = Decimal
         return simple_eval(decistmt(self.list_price_formula), context)

So user could write as formula on variant: list_price * 1.2 for 20% higher.

Nice! Thank you, Cédric.

Does it make sense to include this customization for default? I think this may be very usefull for everyone using variants.

2 Likes

I do not think it should be in product module.
But I guess we could collect some common usage in a product_variant module.

1 Like