[v11] BOM No. in Work Order - why is this Mandatory?

I am playing with Work Order and see that the BOM No. field is mandatory. I think this is fine as a default but it is not possible to unmark the “Mandatory” check box in customize Form with a “Not allowed to disable Mandatory for standard fields” error message.

From my point of view it is fine to have this as a default but don’t realy see why (from a business process point of view) it should not be possible to use Work order for item which do not have any BOM.
Can anyone shed some light on why this is required? If not, I’d think this restriction should be removed and the Work Order Document should be usable without a BOM.

1 Like

Maybe because WO is for production, shop floor, without bom defined what they are suppose to do?
For purchase ect there are other provisions, this will control unnecessary list of WO…
For what purpose you may need WO without bom?..

lets say we have a company situation that is not perfect yet and the staff on the floor know what to do because someone scribbled it on a piece of paper, or gave them a Spreadsheet with the instructions

… I don’t believe such a company should be excluded from using the workorder feature just because they have not reached perfection in regards to using BOM’s in ERPNext

1 Like

“Work Order” is a standardized function in manufacturing systems. They all follow the same path:

Raw Materials → Build of Materials → Work Order → Finished Product

The reason the BOM number is required in the Work Order is to add the ability to forensically check backwards into a process that was used to manufacture a finished product.

For example:

A chemical company makes a solution for rapid oxidizing of copper. The product has a shelf life of only 30 days. The process for mixing this oxidizing agent is sensitive to the seasonal conditions and the mix of ingredients is adjusted 4 times a year to match the seasonal environment changes.

The BOM number would be:
OXI-01579-01 for the spring season mix
OXI-01579-02 for the summer season mix
OXI-01579-03 for the autumn season mix
OXI-01579-04 for the winter season mix

Yet there is only one item number being OXI-01579 and because it has a short shelf life it is usually discarded or consumed by the time the expiry date is reached.

However, if it was necessary to figure out what ingredients were used and in what quantities for a particular batch of product, in this case the BOM number is critical.

A similar situation happens in prepared foods manufacturing. During some seasons certain ingredients are not available so appropriate substitutions are made as ingredients are “in season” and readily available. Even though the finished product might always be Chicken Cordon Bleu the ingredients used to create it may be slightly different during certain times of the year. So in being able to look backwards into how a product was made, the BOM number is critical.

In you use case, the manufacturing process is more flexible and it does not lend itself to a documented quality control system. If the small client using “scribbled notes” is going to grow their business they will eventually have to work within a more clearly documented and defined set of processes. That is exactly what ERPNext and other manufacturing systems are created to do.

The business using scribbled notes to make a product, is not ready for a manufacturing system until they are also ready to adopt some level of standardization. So show them something simpler until they are ready to get serious. Using ERPNext or any other similar system takes a concerted effort to both learn and implement. Someone that insists on working from scribbled notes is clearly not ready for that next step into a manufacturing or business management system.

Just my opinion (and you know what they say about opinions)… :wink:


That is all true from your perspective. however if there was a switch to turn off the dependency (which by default exists) would help companies who are ‘not ready yet’ to take one more step in the right direction without affecting anybody else.

I’d say each single step should be possible if it would not break anything. and in this scenario I can not see such a break.

I will only counter by asking this:

If such a switch existed and were used to allow such activity at the start of a clients use of ERPNext, then how would one EVER turn the switch back to normal operation and get all of those previous unconnected records (dependencies) to become part of the valid database again when the user decides they are ready to play along with the standard?

If you were to design and contribute the means to effectively go back and forth like this then I would be supportive of your idea. However, as it stands now, if what you suggest were an allowed path through the system then once started in this scribbled notes sort of way, there would never be a path to using the system as intended available to the user.

This would effectively create 2 completely different sub versions of ERPNext.

Who do you suggest would be the supporting developers for such a split implementation?

Aqain, my opinion here, but if you are going to adopt a business management system of any sort then you must also be willing to adopt the same accepted rules of operating the business as taught by most universities around the world.

There is nothing wrong with wanting to run a business by the seat of your pants and operate from a pile of notes on scraps of paper in your pocket. That is why I first suggested that you show your client some other simpler system to do what you suggest. Leave ERPNext to those that want to at least attempt to run a business following accepted standards.

It just doesn’t make sense to implement your suggestion in ERPNext because the ripple effect throughout the rest of the system would be massive and this is still an open source project, not a for profit one. The regressive refactoring needed to support your suggestion is just not an easy task and there are scant few resources to make it happen for such a small use case group.

My opinions only here…


Let me add one more thing…

I am speaking from experience here.

One of my first ERPNext clients was a manufacturing business that had been operating from an index card box on a shelf on the manufacturing floor. Work order were notes written on a white board also on the manufacturing floor. If the index card box were moved or if someone brushed up against the white board and erased part of the work list then all work on the floor stopped until they could figure out where they left off.

This group of people were extremely resistant to adopting some work standards and even the business owners were unhappy with anything that seemed to impede the wheels of progress.

I asked the owner one question:

If the foreman were involved in a car accident and laid up in the hospitel for 4 to 6 weeks or the index card box full of procedures fell into the nearby trash can and lost forever, then how would your business continue to run?

Three days later they discovered a jokester changing things on the white board in the manufacturing area that caused them to throw away a day and a half worth of finished product because it was made wrong and could not be fixed.

Suddenly the seemingly rigid guide rails imposed by ERPNext made a lot more sense and we were told to implement the system regardless of the push back from the general workforce.

BTW… that day and a half of production loss was at a cost of $39,000 US for the materials lost alone, and did not include the cost of restocking raw materisls at a much higher rate in order to get them faster than the normal lead times. It also did not include the lost labor and missed sales due to the finished product not being available. That was just the $39k for the cost of materials that day because they were manufacturing some things that they only make once per month on that day so the lost finished product was supposed to be a month worth of inventory.