Found trigger for bug that causes doubling of bom items on work orders and production plan

ERPNext
1

Version: v15.75.1 (and likely other recent versions)

Summary:

There is a core bug in the manufacturing module that incorrectly doubles the required quantity of a raw material in both Production Plans (via “Get Materials”) and Work Orders.

I have done extensive testing and have 100% confirmed the trigger:

The bug only happens if an item’s Item Code is identical to its Item Group name. (e.g., an item with Item Code Labor is assigned to the Item Group Labor).

Steps to Reproduce (on a 100% Clean Install)

This bug is present on a brand-new, un-customized installation (tested on a fresh Docker setup).

  1. Create Item Group: Create a new Item Group named Test Group.

  2. Create “Bad” Item: Create a new Item with the Item Code Test Group (the exact same name as the group). Assign this item to the Test Group Item Group.

  3. Create “Good” Item: Create a new Item with the Item Code Good Item and assign it to the same Test Group.

  4. Create BOM: Create a BOM for a finished product. In the materials list, add:

    • 1 unit of Test Group (the “bad” item)

    • 1 unit of Good Item

  5. Create Work Order: Create a new Work Order for 1 unit of the finished product.

  6. Observe Bug: In the “Required Items” table, the quantity for Good Item will be correct (1), but the quantity for Test Group will be incorrectly doubled to 2.

In-Depth Analysis & Proof

This is not a configuration, cache, or data error. This is a flaw in the application’s code logic.

  • Proof 1: The Trigger is Proven

    • If I rename the Item Code of the “bad” item from Test Group to Test Group-2 (but keep it in the same group), the bug disappears.

    • If I delete the item and recreate it with the exact same Item Code in the exact same Item Group, the bug comes back.

  • Proof 2: It is NOT a Caching Bug

    • Running bench clear-cache does nothing.

    • Running redis-cli flushall (to nuke the entire Redis cache) does nothing. The bug happens instantly when the data is re-fetched from the database.

  • Proof 3: It is NOT a Database Error

    • I did a full database diff by dumping the SQL rows for the “good” item and the “bad” item from the tabItem table.

    • I also did a diff on their parent tabItem Group records.

    • The records are 100% functionally identical. There is no “ghost” property, flag, or setting that is different.

Conclusion: The core manufacturing code is incorrectly checking if item.name == item.item_group (where item.name is the database field for Item Code). When this condition is true, it mistakenly treats the item as a sub-assembly and “explodes” it, which incorrectly doubles the quantity.

The Workaround (For Other Users)

The only solution is to ensure no Item has an Item Code that is identical to its Item Group name.

Renaming either the Item Code or the Item Group so they do not match will immediately fix the problem for that item.