New Multi Level Product Variants BOM functionality

Hello,

Based on your description above what I understood is:

You want to create Purchase order/Manufacturing order/tasks based on sale order items.
if sale order item has BOM defined then all BOM items should be generated as tasks and purchase order as per its configuration.

Is this the thing you want to ask?

well not exactly What I am suggesting is the BOM is virtually entity not actually defined until after the sales order line is confirmed.

in essence the virtual BOM consists on many possible items and task that could be used to create the Sale Item. Each of these Virtual BOM item have logic constraints the determine if they will be used in the manufacture of the product sold.

For example:

you have a product lets say a door.

it has variant Options for hinges, latches, finish, frame, door type.

You then would have a virtual BOM which has every possible item and task task that could be used.

for example HInges would be one line item on the door which could have the possibility or the options Chrome hinge, Brass hinge, White Hinge, Nickel Hinge now rather than having 5 BOM for these five options you have one Virtual BOM that has one virtual Hinge Item. when you configure the Item on the Sales Order it automatically asks the question of the hinge color and then selects the appropriate actual Item in Products base on the Sales persons selections and add it to the BOM. Think of it as Object oriented Products.

This functionality would require a new product type lets call it a virtual product which would have the ability to have table containing programmable code constraints which then use the variant Options and the logic in the code process them through a BOM generator to generate the actual BOMs

Now I realize this does not exist at this time It might be a proposal I should summit to the Community Addons but I am investigating if or how this could be done and if others have interest in such a project

Hello,

This would be a very nice feature to help manage the variability associated with custom built products as well.
We recently added in assembly_sales_bom - which added a true sales BOM to the mix.
We like the idea of the virtual BoM as well.

In discussions with a custom Bike manufacturer recently this was commented as a need.
Sales person orders a baseline bicycle X and they want to custom select the items associated with it based on a "template" - optional pedals, different components (e.g. shifters, saddle, stem).

One key to this is maintenance of the Virtual BoMs. If you update one of the BoMs - and substitute a component - you would want the ability for the manager to control whether the change applies through all of the BoMs or only apply to the one. And before the change applies you want to be able to manage the "exceptions". So I see it as Bike X - with combo 1 at revision 23 applied, etc. The groupings need to be managed.

It's one thing to setup the BoM and get it to work. It's another thing to make sure the management of the BoMs is easy and manageable. Nobody likes spending time on system maintenance and dealing with change. That would be an important step to add to the use case.

If you want to collaborate on this send me a quick email at <email address hidden>.

Hi,
  I have recently started work for a Car manufacturing center working on aligning the Virtual BOM to the CAD models which represent the component at the lowest level. There are also combined structures so that the virtual design can be visualised.

I am looking for a model that will allow me to roll back the built up conceptions of what the solution needs to be as people are focusing on what they have got.

I would like to look at the problem by assuming we are building Model-T fords with no variations allowed, no color or trim options..

Then add these layers and the business rule ro requirements that apply.

A couple of observations so far. The Virtual BOM could end up as a cartesian product of all variations of components and options which would be unmanageable.

There need to be rules built into the art of the possible such that if you have the deisel engine, then you must have the heavier suspension.

Getting back to the original question there are two BOM's ...the virtual BOM which is a list of all component variations.

The manufacturing BOM - could be a tree structure like:-

Door
    ---> Frame
    ---> Hinges * 2
    ---> Panelling * 2
    ---> Latch * 1
    ---> Handle * 2

The CAD package might model any number of Hinge options, Panels, Latches and frame materials. The vitual BOM could be implemented as

Door
    ---> Frame
           --------------> Oak
           --------------> Ash
           --------------> MDF
    ---> Hinges * 2
           -------------> Hinge type 1
           -------------> Hinge type 2
           -------------> Hinge type n
    ---> Panelling * 2
           -------------> Plain
           -------------> Embossed Panel
    ---> Latch * 1
            ----
            ----
    ---> Handle * 2

The manufacturing BOM would be a view filtered by the maketting options and the options chosen by the customer.

Regards.
Dave.

Hello,

I believe we are addressing this issue in the generic product configurator we are building here:
http://bazaar.launchpad.net/~akretion-team/openerp-product-configurator/trunk/files

The idea here is that instead of having all possible combo of possible BOM's, we use a generic configurator we can attach to any OpenERP root object (a sale order line, a project task, a purchase order line...) which will allow to dynamically select the BOM components according to sophisticated restrictions. At the end of this configuration process, the BOM is built on demand (this part is currently missing but should be done in in a few months).
The configurator is based on the JSON http://www.json.org/ grammar (which in my opinion can model virtually any configuration structure) but extended a bit to meet Openobject concepts (like a value can actually be a constrained many2one, things like that). It relies a lot on product_variant_multi modules, at least the for the terminal configurator module. Also please notice we got a few handy merges regarding product variants into OpenERP trunk (eg v7) a few days ago during our code sprint at OpenERP SA.

After we built the BOM, the best would be to manage the production using that module from Graeme Gellatly:
http://bazaar.launchpad.net/~gdgellatly/openobject-addons/o4sb-public-v61/files/head:/bom_variant_multi

I apologize, it's not documented yet and has some known evolution to be done to make it more generic. It should be done over the newt weeks if our beloved customer finally pay us as initially planned.

Hope this helps. Don't hesitate to collaborate on that.