I’m new to ERPNext and I’m looking for the best way to do item re-visioning in stock/inventory. Let me explain what we do, so you might still understand if I use the wrong or different terms.
We as mechanical engineers design parts / items that sometimes get altered due to new design features, mistakes or supplier changes (and many other reasons …) now to keep the track of these changes we would like to keep the item number (ID) the same but count the Version / Revision one counter up whether this are letters A B C … or numbers 00 01 02 or any other combination is not relevant for the moment.
I would like to know:
how to do this in ERPNext as currently I see no obvious way to do it but I’m pretty sure I’m not the first asking this as this is common in manufacturing industries
whats the best practice in ERPNext to set this up?
we currently use ERPNext v15 in a docker stack, I’m open for any ideas as I consider myself an ERPNext beginner but I used SAP R3 for some time an the depths of materials / BOMs and changes
You’re correct, this has been asked before (yet I’m struggling to find valuable content). You may want to expand your search with terms like “revision”, “version”, BOM, etc.
This is a complex issue and need planning and understanding of how your decisions now, impact worflows later.
Create client/server script that update the item code to the latest letter as soon the original is put in the custom field
This will create a lot of items. If you are planning to use them in manufacturing and BOMS you may face some issues down the line as per the links given by others
Alternatively you can experiment with item UoM, batch/serial numbers, variants, attribute, alternatives, brand and manufacturer each of which has their own use cases. Documents can be found at Item
Best Practice for Item Revision & Engineering Change Management (ECO) in ERPNext v15 (Coming from SAP background)
Coming from a heavy SAP R/3 background, one of the first missing puzzles I noticed when transition to ERPNext in manufacturing projects is the granular Item Revision / Version Control and time-phased Bill of Materials (BOM).
In discrete manufacturing (like mechanical engineering), item dimensions, drawings, and components change constantly due to design optimization or supplier shifts. Creating a new Item Code for every micro-iteration is a nightmare, but we must track what specific drawing or specification was used for a specific production run.
Here is an analysis of the current limitations in ERPNext and a proven architectural blueprint to implement robust PLM/ECM capabilities using a Custom App without touching the core code.
1. The Current Limitations in ERPNext
Static Item Master: The Item doctype is flat and unique. There is no native versioning or drawing history table driven by engineering changes.
Lack of Time-Phased BOM: ERPNext manages BOM versions by creating multiple separate BOMs and toggling the Is Default checkbox. It lacks From Date and To Date validations at the BOM header level.
The Planning Conflict: If you plan a Work Order today for next month’s production using a new design iteration, toggling Is Default today will accidentally ruin today’s running Work Orders. Leaving it unchecked means next month’s Work Order cannot fetch the correct data ahead of time.
2. The Blueprint: Engineering Change Management Solution
To bridge this gap elegantly in erpnext, we can leverage Frappe’s framework extensibility by creating a light-weight custom app.
Create a child Doctype Item Revision embedded in the Item master. Fields needed: Revision ID (A, B, C or 01, 02), Effective From/To, Attachment (CAD/PDF drawing), and Specification Changes.
Create a master Doctype Engineering Change Order (ECO) with a standard workflow/approval. Upon submission, a server script automatically appends a new row to the Item Revision table and locks down the old one.
Step 2: Fix the BOM Validity (Custom Fields)
Customize the BOM Doctype to add two vital fields:
From Date (Date)
To Date (Date)
Validation Rule (Before Save): Write a script to ensure no overlapping date ranges exist for active BOMs of the same finished item. When a new BOM version is activated, the script should automatically end-date (To Date) the previous BOM to the day before.
Step 3: Inventory Traceability via Batches
Instead of altering the core Stock Ledger Entry (which breaks accounting valuation), utilize Batch Management.
Force versioned items to be batch-controlled.
Generate batches with the revision ID as a prefix (e.g., REV-A-20260520-001). This naturally routes through standard FIFO, Quality Inspections, and Stock Moves while keeping perfect physical traceability of revisions in the warehouse.
Step 4: Dynamic Work Order Routing (Server Script)
Add a server script hooked to Work Order → Before Save or triggered by changes to Planned Start Date.
Instead of pulling the standard Default BOM, fetch it dynamically using this logic:
`Python# Quick snippet for hook.py / Server Script
def link_bom_by_date(doc, method=None):
if doc.planned_start_date and doc.production_item:
suitable_bom = frappe.db.get_value("BOM", {
"production_item": doc.production_item,
"docstatus": 1,
"is_active": 1,
"from_date": ["<=", doc.planned_start_date],
"to_date": [">=", doc.planned_start_date]
}, "name")
if suitable_bom:
doc.bom_no = suitable_bom
`
This approach maintains the integrity of the ERPNext upgrade path while granting full-scale PLM/ECM control for engineering enterprises.
Would love to hear how other manufacturing folks are tackling this!
The easiest way to manage it both on the ERP System as well as on the shop floor is to make a new item completely and disable the old item with the old revision number.
This way there is a clear clarity on which revision number we are using on the production floor. A lot of times, both revisions are being run at the same time during the phase out period and this makes it the easiest way to run the system.
The alternate method is to use the Batch Number or Serial Number Field to create some sort of differentiation but it’s not as fool-proof/safe as creating a separate item.
Wow that sounds like a solid plan. I do not try to recreate SAP but as you summarized correctly we in engineering need to trace and track items that are changing from time to time (sometimes more often than we wish).
okay since the Item model is flat and not intended to be versioned that explains why neither @volkswagner nor I could find any documentation and the topic is rather low here in the forum. And the Time-Phased BOM is even in SAP not well handled at least in the company I worked before but that’s the past. And the Planning conflict is even ahead of what I was thinking right now but yes makes totally sense when we come to that stage.
@szufisher thanks for also providing a solution I might read this post several times to fully comprehend the meaning of all the steps.
I fully understand Step 1, this is required to implement the missing fields in the Item model that are required to build that traceability. I understand the new ECO as kind of trigger to implement or activate the new revision of the Item, here my understanding is a bit fuzzy but I think i can figure this out.
The second step is kind of similar to 1 but for the BOM implementing the fields and rules required to handle versioned Items
You lost me on the third one, I do kind of understand what you mean and what it is used for. I think i need to “play” with this to fully comprehend the mechanics of how this works and what the limitations are… as more often I read it I think i get it.
Step 4 makes totally sense but as I’m currently not yet there and I have no clue to implement a server script in ERPNext I’ll definitely come back when I’m there.
As introduced I’m a ERPNext beginner and I hoped I had not to customize it in that depth to achieve Item revisioning but rather look in the right place to trigger the button to turn it on, but as not fining it in the documentation hinted that there will be more to it than just a button to trigger.
@szufisher I’m very grateful for your explanation, so next step will be to setup a sandbox system to try and implement this approach step by step without messing in the current system.
so be assured I’ll be back with new questions when I hit the wall
@zuron7 I thought of this and It is actually the way we will handle that “short coming” as actually we do the same in CAD (at the moment we cannot afford a PLM-System, prices are insane …)
But this means to re-crate the BOM’s every time we revision an Item and as soon as you have an Item in multiple BOMs this will create a lot of work or you end up with multiple Items for actually the “same” part and you loose the benefit of mass-production, as well confusion at our suppliers as they end up with literally the “same” part with different Item numbers
So yes it’s a possibility but not actually what I’m looking for.
What a great post. You make me want to build this custom app, and I’m not even using the manufacturing module! Posts like these make this forum an invaluable resource.
