Missing BOM Number in Database When "Do Not Explode" is Enabled

[nikolas-beckel]

Description

When creating a BOM (Bill of Materials) and adding items that also have their own BOM, an issue occurs when enabling the "Do Not Explode" option.

If "Do Not Explode" is enabled for a BOM item, the corresponding BOM number is not stored in the database. However, if "Do Not Explode" is not enabled, the BOM number is correctly stored.

Impact

This behavior leads to two major issues that significantly affect our business processes:

1. Loss of BOM Tracking and Traceability

In many countries, businesses must comply with legal documentation and traceability requirements. If a product defect, safety issue, or recall occurs, companies must be able to prove exactly which components and BOMs were used for manufacturing a specific product with a certain serial number.

Currently, because the BOM number is not stored for subassemblies with "Do Not Explode" enabled, this traceability is lost. Without this information, it becomes impossible to verify which BOM version was applied to a particular subassembly at the time of production.

This lack of traceability can have serious legal and financial consequences for companies. If an issue arises that requires a product recall or an official audit, and the company cannot provide a clear history of the components used, it could face fines, legal penalties, or liability claims.

2. Incorrect BOM Pricing Updates

When updating BOM prices, the system does not update prices for nested BOM items where "Do Not Explode" is enabled.

• Since the BOM number is missing in the database, the system does not know which BOM version applies to that item.
• As a result, the price update process always uses the originally saved price from the BOM creation date rather than the current price.
• The only workaround we have found is to create a new BOM version, remove the item, and add it again—this is inefficient and impractical.

Code Investigation

I believe the issue originates in the file bom.py, specifically in the methods set_bom_material_details and get_bom_material_detail.

• There is a double check in these methods to see if "Do Not Explode" is enabled.
• If enabled, the bom_no is explicitly set to an empty string ("").
• This happens first in set_bom_material_details and then again in get_bom_material_detail, which is also called within set_bom_material_details.

Suggested Fix

I am not fully aware of all the potential side effects, but would it be possible to remove this condition and allow bom_no to be stored regardless?

It is possible that some later business logic depends on whether a bom_no is assigned or not. However, perhaps a better approach would be to modify the condition to check whether "Do Not Explode" is enabled and handle it accordingly rather than completely discarding the BOM number.

Would this be a feasible solution?

Questions

• Is this behavior intentional?
• If so, could you provide the reasoning behind it?
• If not, would it be possible to fix this so that the BOM number is stored even when "Do Not Explode" is enabled?
• Are there any known side effects of storing the BOM number in this case? If so, what would be the best way to handle them?

We appreciate any insights or potential fixes for this issue.

Thank you!

Module

manufacturing

Version

Frappe: v14.94.0
ERPNext: v14.82.2

Installation method

docker

Relevant log output / Stack trace / Full Error Message.