Community: Inventory and MRP arquivos das listas de correio


Re: Reimagining bom_variant_multi for V10

Pedro M. Baeza
- 27/07/2017 06:04:47
You have for sales, but if you have some issues with the module (although you won't finally use it), please comment on the PR itself.


2017-07-27 10:40 GMT+02:00 Graeme Gellatly <>:
Thanks Pedro,

I took a look (I actually checked odoomrp before I started and didn't see it) but it is quite different.  That case seems to be for using some kind of configurator (e.g. it refers to attribute values on the sale order line, and inserts itself into procurement and production models).  Also it depends on a lot of things I don't need, like no_create variants.

My case is far simpler.  Not create a BoM for every product and dynamically select the product based on shared attributes while touching as little as possible.  There's plenty of places it won't be suited where maybe something heavier is required.

The current working implementation is really just one computed field on bom_line and an inheritance of explode.  Interestingly, after some tougher testing today, my implementation worked perfectly with the BoM Cost Structure report scaling weights and using variant specific costs (although the report could use some work, returns product name instead of name_get).  I've got a couple of issues in some other modules to work through, direct sql queries in some reports but otherwise it seems I've gotten away with most of it, because nearly everything calls explode.  Will dig deeper tomorrow.

FWIW I also just tested the dependent module on runbot, ran into a few UI problems in variant creation adding a second attribute, not sure if its core, the module, or firefox, but got it to go eventually.  More UX issues following the instructions to create variants, but maybe thats because all the variants already existed.  I then tried a few other things..

From a UX perspective - I found the terms Don't create automatically and Create Automatically a bit confusing.  I thought Create Automatically meant generate on the fly as needed.  Maybe consider - Create products as required and Generate all products on Save - something like that (Note - I wrote this when I was expecting variants created on the fly). 

But perhaps a bigger issue is once you work out that you need Don't create automatically - when you press Create in product variant and select the template you get a list of attributes without any values.  I kind of expected it would tell you what options were left or at least what was available, but OK.  Then there is no label for the attribute values and also the field is not required. 

A few other little things -
the template list needs filtering to not show templates that already have all their options, and the value_ids list filtering to show only valid values (e.g. if template has Color and Memory don't show Wifi.

Template Smart Buttons
traceability broken if no variants created
sales broken if no variants created
purchases worked
variant sale prices seemed to work just right.
product labels printed blank pdf (maybe my template setup was wrong)

Sale Order
I guess I kind of expected to be able to create new variants on the fly in the sale order - maybe thats a different module - anyway I reread the description in detail and see it isn't functionality.  Anyway I changed it to create automatically, and got the grid thing editable and it seemed to do as expected.

I don't know, its definitely not a module I have use for, more for custom rather than volume manufacture.  Also seems to be for expert users in their domain - especially the variant creation part.  Unfortunately I don't have a lot of them.

On Thu, Jul 27, 2017 at 7:00 PM, Pedro Manuel Baeza Romero <> wrote:
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:

Post to:

Post to: