ERPNext Foundation ERPNext Cloud Chat Blog Discuss Frappé* Donate

ERPNext for process manufacturing

manufacturing

#1

I just want to use ERPNext for process manufacturing business which require Formula instead of BoM since the input/output is not known at each workstation. Most businesses are process based and I don’t understand why all of the open source ERP system chooses discrete over process. If process manufacturing feature is incorporated into this great system, it will be a big win in the competition. inoERP has done it but they stopped developing the software since then. In real business, continuous quality test, assortment, batch splitting/merging, variable inputs, changing requirements, and so are common. And process manufacturing and formula based BoM is an answer.

I hope the community will listen and act accordingly!

Thank you all.


#2

Hi welcome to ERPNext,

Thanks for your comments and support!

Yes folks listen stay tuned for eg New Feature? Process Manufacturing

Thanks to Ranjith Remembering Ranjith Kurungadam


#3

@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.


#4

Quick note: All of the following is an initial spec and a work-in-progress. :slight_smile:

Gap Analysis:

We need the following elements of process manufacturing in the system:

  • Process orders (equivalent to a Work Order; maybe integrate into Work Order itself)
    • Operations -> Phases
    • Process -> Set of operations -> subdivided into phases
    • Lot inspections after decided phases
    • Having continuous tracking and reporting is almost necessary for multi-process manufacturing, in order to have real-time control and manage proper yield.
  • Recipe formulation (equivalent to Bill of Material, but different; maybe a new DocType called Formulation / Formula / Recipe)
    • Ingredients and estimated yields
    • Same as in BOM, a multi-process formulation can have raw ingredients, or ingredients made from other processes.
    • Handle proportion of ingredients
    • Mainly for scalability purposes.
    • Handling of mixed units of measure and conversion
    • A conversion engine already exists in ERPNext, that can be used to manage variations in units.
  • Raw material calculations
    • Since multiple inputs can create multiple outputs, joint costs come into play. More info at 1, 2 and 3.
  • Forward and backward lot traceability
    • Important for reporting.
  • Recording of manufacturing steps and production notes
    • This is not too critical, since we can attach SOPs to each Formulation as a workaround. But eventually we may want to let users define each step for the process in the document itself.

Recipe / Formulation doctype structure

Goal: Master record for describing the process, i.e, bulk input -> bulk output.

  • Operation / Process (primary key; equivalent to item in BOM)
  • Inputs
    • (Child Table) Raw Materials (Mandatory)
      • Items or Item Groups
      • (Optional) Quantity or Proportion
    • (Child Table) Catalysts / Secondary Materials (not directly used for manufacture)
      • Items or Item Groups
      • (Optional) Quantity or Proportion
  • (Child Table) Phases (Mandatory?; link to other Operations; maybe convert Operation to NestedSet for tree structure)
    • Estimated Times
    • Workstations
    • Equipment
  • Outputs
    • (Child Table) Products (Mandatory)
      • Items or Item Groups
      • (Optional) Quantity or Proportion
    • (Child Table) Waste
      • Items or Item Groups
      • (Optional) Quantity or Proportion
  • Quality Assurance (currently underdeveloped; will need a separate project, or to adapt existing repos for recording quality)
    • Inspection at Phases
    • Acceptance Criterias
    • Reporting on Deviance

Thoughts and suggestions are appreciated!