Community: Inventory and MRP arquivos das listas de correio


Re: Reimagining bom_variant_multi for V10

Pedro M. Baeza
- 27/07/2017 02:56:03
Do you know mrp_product_variants from odoomrp-wip (

I think it's just what you need (porting it to v10). The base module is already ported in


2017-07-27 1:55 GMT+02:00 Graeme Gellatly <>:
Hi all,

I've done some early experimental work on porting bom_variant_multi to V10.  Literally about 1 day, mostly shouting 'F#$k that won't work either', and it seems the guts of MRP is as opaque as ever.

Quick Glossary
Attribute: e.g. Colour
Attribute Value: e.g. Red, Green, Blue
Product: May mean a product template or product variant depending on context
Shared Attributes: An attribute in common with the product templates in question
Unshared attributes: !Shared Attributes

For those who are unfamiliar bom_variant_multi (now mrp_dynamic_lines) assigned specific raw material variants to a production order based on some conditions.

Why does this matter:
In V10 standard, there is a condition to skip a line if it isn't a listed variant.  This works fine if you have say 2 colours and just create 2 lines.  But what if you have 50 colours?  Firstly, creating and maintaining your BoM is tedious (or else you make 50 BoM's), secondly, exploding them is time consuming as it goes over 50 lines.  If you are using JIT, sales orders take much longer as exploding the BoM is ~50 times longer.

Work to Date
First the good news.  Attributes (in this use case) are a lot easier to work with than product_variant_multi.  It means we can dynamically match attribute values where products share attributes (great for colours).  I've decided to limit the scope to shared attributes and do away with dimension maps.

Now the bad news. Bom lines work on product variants only, there are no easy hooks, no prepare methods, and the product being produced is disassociated from the raw materials moves to create them.  I've worked around this by making product_id a computed field and putting the product being produced in context of the result of explode method. 

So in usage when you define a BoM
- add a line with a template and a default variant -> that gets used.
- add a line with a template, default variant and match attributes checked -> dynamic match based on attributes - default variant if none, error if more than 1.
- required value_ids simply narrows the search to products containing values of  unshared attributes.

The experimental code is at . No tests, tidy domains, demo data etc, some views missing but its installable. 

FYI - I've also split out the weight scaling component into a separate module (it scales the quantity of raw material by the weight of the product, useful if you have different sizes that require different amounts of material).  It is in no shape to do anything atm, don't even know if it installs.

My questions are:
This seems too hard, am I going about this the right way?  What alternatives are there?
What gotchas am I going to run into that need consideration - I'm thinking where BoM's are used outside of production (costing, reports maybe)

Post to: