@yona and I were talking about this on github and I thought it would be better to bring the discussion here where it will get more views. (lightly edited)
There isn’t a simple fix to incorporate both discrete and process mfg and there are a couple of different designs that are possible.
- Make BoMs selectable as discrete or process, which means refactoring a lot of code in the BoM but it keeps the changes more or less isolated there. @RohanB is working on some variation of this now.
- Add infrastructure so that discrete and process are handled in separate workflows, with separate settings. This means modularizing the Manufacturing module by adding a “Manufacturing Line” doctype and reorganizing so that both workflows can be accommodated. I think this is a very realistic model of manufacturing in that most industries have some combination of discrete and process in their busines.
- Process mfg can be a nightmare for keeping track of things by UoM and I’m concerned that there isn’t a design that covers enough generic needs to be useful. In one case I’m working with a customer processing animals where the intermediate cuts of meat are kept on ice and it’s impossible to get an accurate tare for steps 2 through ~6 and you only know the outcome in the input UoM when it’s ready to be packed or go into cold storage. But there have been some set operations on that item that have reduced its weight with an uncertain percentage change. Currently the discrete BoM requires that the scrap percentage be identical each time, which is problematic for several reasons and needs a bit of redesign, and I’m not sure myself of all the downstream impacts. Anyway, this gets at the “continuous input” problem, which would have to be handled in a process BoM - if chemical X flows from the container in an unknown quantity per leather hide, how does one calculate its value?
- A workaround that exists today is to handle all these things all as stock-in/ stock-out transactions and adjust the valuation rate on the Item master with the Landed Cost Voucher. This keeps track of “what items” and “how much on average” but not “when” or “how much each (not average)”. If you are OK with taking inventory (measuring state) as your process control measure (and for most companies, that’s what they’re doing), LCV may be a solution. If you need more detail than that or want to commonify or specify the process, more work is required.
So, my thoughts since I wrote that a week ago are that the LCV or a LCV-like solution is the short term fix and first step. Then merging a “Process BoM” or “Process” or “Recipe” doctype into the existing workflow. Then the manufacturing line idea becomes less important or not important at all. Generally I think that separate workflows is cutting the baby in half and ultimately it makes more sense to be able to chain operations, something like:
Item 1 -> BOM -> Item 2 -> Process -> Item 3 -> BOM -> Item 4
The other problem that comes up in these discussions is the idea of a reverse BOM, where an input can be made into many outputs of unknown quantity. I propose that this be a feature/option of a “Process BoM” or whatever namespace gets settled on. It requires user input to complete, so there’s a challenge there that also has to be worked through.