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

Feature Ideas
21

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
22

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.

23

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?

24

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.

25

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

26

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

1 Like
27

Mmmm… I’m going to study

28

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

29

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.

30

Nice! Thank you, Cédric.

31

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

2 Likes
32

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