A customer sends back 50 units. The cartons are crushed, but the product inside is sealed and perfectly good — it needs new packaging and nothing else. You raise a Work Order to repack them,. ERPNext insists on consuming a full set of raw materials from the BOM, as if you were making the product from scratch. You set the required quantities to zero, save, and they come back. This is not a configuration mistake: ERPNext has no rework Work Order, and this guide covers the three ways round it that do not wreck your valuation. This guide on erpnext rework work order is written for Indian SMEs, with code samples, ERPNext / Medusa recipes, and step-by-step fixes you can copy into a real project.
ERPNext models making things and unmaking things. It does not model fixing things. I am Manoj, an ERPNext and Frappe implementation lead at MithTech, a 35-person engineering practice headquartered in Bangalore; rework shows up on most discrete-manufacturing programmes we run for clients operating multiple plants, dealer networks and field service teams.
Why ERPNext fights you here
A Work Order in ERPNext is a request to produce a quantity of a finished good against a BOM. The required_items table is not free-form input — it is derived from the BOM's component ratio multiplied by the quantity to manufacture. That derivation is the whole point of the document: it is what makes material planning, reservation and shortage reporting work.
Rework breaks the assumption underneath it. When you repack a returned unit, the finished good already exists. The raw material is physically sitting inside the thing you are holding. What you need is a Work Order whose input is the product itself, with the BOM's component list suppressed — and that is precisely what ERPNext will not let you express. Because a suppressed component list contradicts the BOM the Work Order is built from.
The feature request in #54663 asks for three things: a Rework purpose on the Work Order, the ability to freeze an individual required_items quantity so BOM recalculation leaves it alone, and a re-delivery linked to the original Sales Order. As of v16.12.0 with Frappe v16.13.0, none of them exist, and the issue carries no linked pull request or maintainer-assigned fix date. Treat it as a gap to design around rather than something to wait for.
Which situation are you actually in
"Rework" covers four quite different physical operations, and ERPNext supports two of them cleanly today. Establish which one you have before designing anything.
Select the return scenario you are dealing with to see what ERPNext does today, which issue tracks the gap, and the recommended approach.
A full teardown back to components is a disassembly, and a Stock Entry handles it — you issue the finished good and receive the components, which is a manufacture entry in reverse. Unusable returns are a write-off, closer in shape to the scrap handling covered in our scrap, wastage and by-product guide. Neither of those needs a Work Order.
The two that hurt are the partial ones: packaging replaced with contents intact, and a handful of components swapped while the rest stay put. Both want a Work Order whose BOM lies about what goes in.
What the wrong model actually costs
The reason this matters beyond tidiness is that a Work Order run against the production BOM issues real stock. Those components leave your stores, hit the manufacture entry, and land in the finished good's valuation. Nothing errors. The quantity is simply wrong, and it is wrong in a direction that inflates both your material consumption and your finished-goods value.
Enter your own rework volume and component costs to see how much material consumption the production-BOM approach overstates.
The figure it produces is not a benchmark — it is your own arithmetic. But the shape is consistent across the implementations I have seen: because the replaced component is usually a fraction of the product's value, running rework through the production BOM overstates consumption by a large multiple, and that multiple compounds every month it goes unnoticed. If you run standard costing, it surfaces as a persistent unfavourable material variance nobody can explain.
What are the three approaches?
Copy-paste steps for the rework BOM, the Repack Stock Entry, the traceability fields, and the three approaches to avoid.
Segregate returned stock
Create a Returns warehouse and receive every customer return into it, or use a distinct item code for returned units. Whichever you pick, the requirement is the same: a returned unit must not be sellable until it has been reworked. This is the step people skip, and it is the one that causes the "we sold a damaged unit" incident three months later.
Choose the model
If reworks are occasional and amount to a packaging swap, use a Repack Stock Entry — no Work Order, no BOM, done in a minute. If reworks are routine, or you need operation-level costing, Job Cards, or a routing, build a rework BOM. The dividing line is whether anyone needs to know how long the rework took.
Build the rework BOM
Create a BOM producing the sellable finished good, whose items are the returned unit (quantity 1) plus only the components genuinely replaced. Do not duplicate the production BOM and edit it down — start empty, so nothing is inherited by accident. This BOM is a permanent, versioned artefact, which is exactly what you want when an auditor asks how rework was costed.
Raise the Work Order against it
Because the rework BOM is already correct, ERPNext's recalculation produces the right required_items with no overrides. The behaviour in #54663 stops being a problem, because you have removed the reason for it rather than fighting it.
Verify the incoming valuation
Before submitting the manufacture Stock Entry, check the finished good's incoming rate. It should equal the returned unit's carrying value plus the replaced component — not a fresh material set. If it looks like a normal production cost, the Work Order picked up the wrong BOM. This check takes ten seconds and catches the whole class of error, in the same way the incoming-rate check does for multi-level BOMs.
When the rework crosses a role boundary
On most shop floors the person who receives the return is not the person who decides whether it can be reworked, and neither of them owns the BOM. That split is where the design leaks: production creates a Work Order against whatever BOM is to hand, because the correct one either does not exist yet or nobody told them about it.
The pattern that holds is a saved report rather than a permission rule. Build a Report Builder view on Work Order filtered to your rework BOMs, with columns for the original Sales Order custom field, quantity, status and creation date, and have whoever owns costing review it weekly. You are not trying to prevent the wrong Work Order — you are trying to catch it inside the period, while the entry can still be cancelled cleanly rather than corrected with a second entry that hides the first.
Give the BOM naming a convention that makes the mistake visible: prefix every rework BOM with RW-. A production Work Order carrying an RW- BOM, or a rework carrying a production BOM, is then obvious in a list view instead of requiring someone to open the document.
Draft policy for your production and finance leads to ratify. Returned finished goods are received into a Returns warehouse within one working day and are not sellable from that warehouse. Rework is processed against a BOM prefixed
RW-; using a production BOM for rework is a costing error, not a shortcut. Any rework batch above 25 units, or whose replaced-component value exceeds 15% of the finished good's standard cost, is reviewed by the costing owner before the Work Order is submitted. These thresholds are a starting point — set them against your own volumes and materiality, and have your auditor confirm them before they go into an SOP.
Should you choose Fix it now, or park it?
| Reworks are routine, not exceptional | This is the first return in months |
| You need operation cost or Job Cards on the rework | It is a packaging swap with no labour worth tracking |
| Standard costing shows unexplained material variance | Valuation impact is immaterial at your volumes |
| Warranty or claims need the trail back to the sale | The customer relationship is already settled |
| Someone other than the BOM owner raises Work Orders | One person does the whole flow end to end |
How do you At a glance — quick reference?
| Aspect | What to know |
|---|---|
| When to use erpnext rework work order | Standard fit for the common case; review edge cases against the table. |
| Typical effort | 1–4 hours for a small team; longer with custom data or multi-entity setups. |
| Main risk | Skipping reconciliation or running before the data is clean. |
| What to do next | Run the steps below, then verify against the checklist. |
FAQ
+Does ERPNext have a rework work order?
No. There is no Rework purpose on the Work Order in v15 or v16. It is an open feature request, #54663, raised against v16.12.0 with no linked fix. The workable approach today is a separate rework BOM whose input is the returned finished good.
+Why does ERPNext keep resetting the raw material quantities I set to zero?
Because required_items on a Work Order is derived from the BOM's component ratio, not entered by hand. When the BOM or the quantity to manufacture changes, ERPNext recalculates the table from the BOM, and your manual zeroes are replaced. The fix is a BOM that is already correct rather than an override.
+How do I rework a returned product in ERPNext without consuming raw materials again?
Build a BOM for the finished good whose items are the returned unit plus only the components actually replaced, and raise the Work Order against that BOM. For a simple packaging swap you can skip the Work Order entirely and use a Repack Stock Entry, issuing the returned unit and the new packaging and receiving the sellable good.
+Can I just set the returned item's valuation rate to zero?
Don't. It makes a single Work Order balance and then corrupts every FIFO layer for that item afterwards, because the zero-valued quantity sits in stock and gets consumed by later transactions at that rate. You end up with understated COGS on unrelated sales, which is far harder to unpick than the original problem.
+Which ERPNext version does this apply to?
The gap exists in v15 and v16. Issue #54663 was raised against ERPNext v16.12.0 with Frappe v16.13.0 and remains open. The BOM-ratio recalculation that causes it is long-standing behaviour, not a recent regression, so older v14 instances behave the same way.
+Will a rework Work Order link back to the original Sales Order?
Not on its own. ERPNext does not connect a rework or its replacement Delivery Note to the sale it replaces — that is the third part of the #54663 request. If you need the trail for warranty or claims, add a Link custom field on Work Order and Delivery Note and populate it at creation.
What happens if we keep running reworks through the production BOM?. Material consumption is overstated by roughly the ratio of full material cost to replaced-component cost, every time. It inflates finished-goods valuation, produces a persistent unfavourable material variance if you run standard costing, and leaves your stores balance lower than the physical count — which then surfaces as a reconciliation problem nobody connects back to rework.
Is a Repack Stock Entry safe for valuation?. It is, provided you check the target line's rate before submitting. Repack distributes the combined source valuation across the target items, so with multiple targets an unintended split silently changes your finished-goods value. With a single target — the reworked unit — the arithmetic is straightforward and the entry is safe.
What related issues might you also hit?
- Work Order cancellation failing when a draft Job Card is referenced by a Stock Entry (#56046) — relevant if you cancel a wrongly-created rework Work Order.
- The same missing-override problem in subcontracting, tracked separately in #51012.
- Scrap, wastage and by-products in ERPNext BOM — for returns that cannot be reworked at all.
- How ERPNext calculates finished-goods cost — where a mis-modelled rework ends up.
What is the bottom line?
The absence of a rework Work Order is a modelling gap, not a bug, and it will not be configured away. Decide deliberately whether rework deserves its own BOM or a Repack entry, keep returned stock out of the sellable warehouse, and check the incoming rate on every rework manufacture entry. Do that and the missing feature costs you a naming convention rather than a year of quietly wrong finished-goods valuation.
Returns piling up and no one trusts the finished-goods valuation?
We map your return and rework flows, design the BOM structure that costs them correctly, and set the review queue that catches the wrong Work Order inside the period.