Community: Inventory and MRP mailing list archives
Re: Reimagining bom_variant_multi for V10by
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.
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
Regards.Do you know mrp_product_variants from odoomrp-wip (https://github.com/odoomrp/odI think it's just what you need (porting it to v10). The base module is already ported in https://github.com/OCA/product
oomrp-wip/tree/8.0/mrp_product)? _variants -variant/pull/652017-07-27 1:55 GMT+02:00 Graeme Gellatly <email@example.com>: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.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 GlossaryAttribute: e.g. ColourAttribute Value: e.g. Red, Green, BlueProduct: May mean a product template or product variant depending on contextShared Attributes: An attribute in common with the product templates in questionUnshared attributes: !Shared AttributesWhy 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 https://github.com/odoonz/mrp/
tree/10.0-dynamic-lines. 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: mailto:firstname.lastname@example.org
Post to: mailto:expert-inventory@mail.