Suitable model to configure production for company that sells products with the same BOM in different packages

The scenario is a company that sells produces products on demand sold in different sized packages.

The current setup is that there is a “base” product associated with a BOM that includes all the ingredients and steps required except for the packaging and one product record for each packaging size with a related BOM with the inputs being the “base” product and the packaging.

This means that there are 2 Production requests created when a packaged product is sold, but this is very confusing for the users.

For me it should be solved by implementing the “phantom BOM” feature which has been discussed on Supply on sale with production request - #8 by ced

1 Like

Jus to clarify: Phantom BOM is just calling the explode_bom of each input product if it is also producible. Isn’t it?

Maybe we can can just have a checkbox on the BOM input to indicate that that product is a Phantom BOM.

Yes but only for some of them.

But there is also the case which need to have a solution. Sometimes you will use phantom BOM but for products that do not really exist so it will be good to be able to avoid the creation of such fake product.

I’m wondering if it won’t be better to just add a BOM field on the input.

As we support to have diferent BOMs on a single product it will allow to know which bom should be used for exploding the product.

Also this will allow to use an BOM without any product, and thus supporting the case of the FAKE product.

We already have this choice when creating request production. For now we choose the first BoM (but this can be/should be customizable).

It could be an option but I think we also need the option that let the system choose the best BOM for phantom BOM.

So you propose that this should be a combination of the checkbox and the bom field?
I image we should only explode the bom when the checkbox is set and hide the bom field when not set. In case the user picks a bom this bom should be used otherwise we use the first Bom (but allowing customization).

Does it sound like a good solution?

I submited Issue 11160: Manage phanton BOMs on production - Tryton issue tracker with an early implemantion using the BOM field on the input. I will update it once we decided how to enable the phantom bom feature.

I do not think that having a single BoM field as input is a good design because it will rely on a non-explicit unit of measure. So for me we must always have a product (even if it is only used as partial parts) to ensure a base conversion for the measures.
And as product will be always required, I will prefer to let the system choose the BoM like it does in other cases. The only addition feature that will be a nice to have is to be able to specify on the production order all the BoM to use.

I updated the review fixing your remarks.

I leave this point as a future implementation as its a nice to have.