You run a Work Order for two units, transfer material against the Job Card, and the operator reports one good unit and one lost to process loss. Then ERPNext refuses to create the finished-goods Stock Entry — the transferred quantity does not appear to support the quantity you are finishing. Nothing about your data is wrong. This is a defect in how the material-transferred quantity was computed, it was fixed in ERPNext v15.47.0,. This guide tells you whether your version carries it and what to do if an upgrade is weeks away. This guide on erpnext job card process loss is written for Indian SMEs, with code samples, ERPNext / Medusa recipes, and step-by-step fixes you can copy into a real project.
A validation that refuses a legitimate entry is worse than one that lets a wrong one through, because the operator's next move is to falsify the numbers until it submits. I lead enterprise ERPNext and Frappe implementation programmes at MithTech, a 35-person enterprise software engineering and integration practice in Bengaluru, and this fault reliably produces exactly that behaviour on the shop floor.
What actually breaks
ERPNext tracks, on each Work Order, how much raw material has been transferred for manufacturing. That figure gates the finished-goods entry: you cannot receive more finished quantity than the transferred material supports. It is a sensible check, and on a normal job it is invisible.
Process loss disturbs the arithmetic. When an operator reports that of two units started, one was completed. One was lost in process, the material for both was genuinely consumed — the loss is not material that came back. The defect fixed in PR #44823 was that the material-transferred quantity was computed without properly accounting for the process-loss quantity recorded against the Job Card. The result is a Work Order that believes it has less transferred material than it does, and therefore refuses a finished-goods entry that is perfectly legitimate.
The original report is precise about the shape: a BOM containing a single operation, a Work Order for quantity 2 with Transfer Material Against set to Job Card, and a Job Card completing one unit with one unit of process loss. That configuration is not exotic — it is how any shop that tracks operations records a partial yield.
Enter your ERPNext version to find out whether it predates the v15.47.0 fix, and what that means for your instance.
Five symptoms, five different issues
Process loss in ERPNext manufacturing has had several distinct faults across v15. V16, and they are easy to conflate because the operator-facing symptom — "it will not let me finish the job" — is identical. Pick what you are actually seeing.
Select the symptom you are seeing to get the underlying cause, the tracking issue, and whether the v15.47.0 fix applies.
The important separation is between the v15 defect this post is about and the v16 cluster around semi-finished-goods tracking in #52028, where Complete Job stops responding and the process-loss quantity cannot be entered in the Job Card quick-entry form at all. Those share a symptom and nothing else. Upgrading a v15 instance fixes the first; moving to v16 with Track Semi-Finished Items enabled can hand you the second.
There is also a longer-running friction that is not a bug at all: Job Card quantity validations assume a batch is completed whole, and shop floors rarely oblige. Completing partial quantities and creating stock entries against them is raised repeatedly (#49149, #50118) and is better treated as a batch-sizing decision than a defect to wait out.
How do you fix it?
Copy-paste diagnosis steps, the bench upgrade sequence, the exact reproduction to verify the fix, and the habits that avoid the adjacent issues.
Establish your version and the trigger
Help > About for the exact version string. Then confirm on the failing Work Order that Transfer Material Against is Job Card, the BOM has an operation, and a Job Card carries a process-loss quantity above zero. All three must hold for this to be the right diagnosis.
Confirm the signature
Compare Material Transferred for Manufacturing with Qty to Manufacture on the Work Order. If the transferred figure is short by exactly the process-loss quantity, you have found it. If the numbers look right and the entry still fails, the cause is elsewhere.
Upgrade on staging first
Back up the site with files, then update the erpnext app on the version-15 branch and run bench update --patch. Do this on a staging copy and run the reproduction before touching production. Version 15.47.0 was released on 25 December 2024, so for most instances this is a routine point-release move rather than a major upgrade.
Verify with the original reproduction
Build a BOM with one operation, raise a Work Order for quantity 2 with Transfer Material Against = Job Card, transfer material, then complete the Job Card with one unit completed and one unit of process loss. Create the finished-goods entry. It should now succeed for one unit.
Hold correctly if you cannot upgrade yet
Record the loss on the manufacture Stock Entry rather than the Job Card. It gets the job closed with the right stock outcome. Be clear about the trade-off: the loss is no longer attributed to the operation, so operation-level yield analysis is blind for every job you handle this way. Note which Work Orders were processed like this so you can explain the gap later.
When production and IT are different people
The operator hits this at 11pm on a shift, and the person who can authorise a bench update is asleep. What happens next decides how much damage the bug does.
Left to solve it alone, the reliable operator behaviour is to make the numbers agree: reduce the process loss to zero, inflate the completed quantity, or transfer extra material that was never issued. Each of those submits successfully and each puts a permanent lie into your yield data. The bug blocks one entry; the workaround corrupts the reporting the entire Work Order exists to produce.
The pattern that holds is a documented holding action plus a queue. Give the shop floor one sanctioned workaround — record the loss on the manufacture Stock Entry — and a place to log that they used it. A saved report on Stock Entry filtered to entries carrying that flag gives production and finance a list to revisit after the upgrade, and gives the operator permission to do the right thing at 11pm rather than inventing one.
Draft policy for your production and IT leads to ratify. Job Cards recording process loss on an instance below ERPNext v15.47.0 use the sanctioned workaround only, and never an adjusted completed quantity. Every use is logged with the Work Order reference on the shift handover. Upgrade to the current v15 point release is scheduled within one calendar month of this being identified, and process-loss yield reporting is treated as unreliable for the affected period rather than quietly restated. Thresholds and the upgrade window are a starting point — set them against your own change-control process and confirm with whoever owns your ERPNext instance.
Should you choose Upgrade now, or hold and work around?
| Process loss is routine on your lines | It has happened twice this year |
| Operation-level yield reporting is used | Yield is tracked at the Work Order level anyway |
| You are several point releases behind regardless | You upgraded recently and change control is heavy |
| Operators have already started adjusting quantities | One supervisor handles every Job Card personally |
| You are on v15 and want the accumulated fixes | You are mid-migration to v16 and this is moot |
How do you At a glance — quick reference?
| Aspect | What to know |
|---|---|
| When to use erpnext job card process loss | 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. |
Common questions from the shop floor
+Why can't I create the finished goods entry after recording process loss in ERPNext?
On ERPNext versions below v15.47.0, the Work Order's material-transferred quantity is computed without correctly accounting for the process-loss quantity on the Job Card. The Work Order then believes there is not enough transferred material to support the finished quantity, and blocks the Stock Entry. The data is fine; the calculation is not.
+Which ERPNext version fixes the Job Card process-loss bug?
+Does this affect ERPNext v14?
The fix landed on the version-15 line and was not carried back to v14. If you are on v14 and reproduce the symptom, treat it as one more reason to plan the v15 upgrade rather than attempting a cherry-pick into a branch you will not be maintaining.
+Is ERPNext v16 affected?
v16 contains the fix, but it has its own separate problems around Job Card completion and process-loss entry when Track Semi-Finished Items is enabled (#52028). Moving to v16 to escape this bug can hand you a different one, so stage semi-finished tracking before enabling it.
+How do I close the job if I can't upgrade right now?
Record the process loss on the manufacture Stock Entry instead of the Job Card. The stock outcome is correct and the Work Order closes. The cost is that the loss is no longer attributed to the operation, so operation-level yield reporting is incomplete for those jobs — log which ones so the gap is explainable.
+What happens if we just let operators adjust the quantities instead?
You trade a blocked entry for permanently wrong yield data. Zeroing the process loss or inflating the completed quantity makes the document submit and makes every downstream yield, variance and costing report wrong in a way nobody can reconstruct later. The bug is temporary; falsified quantities are not.
Can I set process loss on the BOM instead of per Job Card?. Yes, and where the loss is a known, routine yield characteristic that is the better model — it is declared once and applied consistently. Per-Job-Card process loss is for genuinely variable losses, and it is where the validation edge cases in v15 and v16 cluster.
What related issues might you also hit?
- ERPNext has no rework Work Order, so returned finished goods re-consume raw materials (our guide, tracking #54663).
- False process-loss validation on Stock Entry when the BOM declares no process loss (#52454).
- How ERPNext calculates finished-goods cost — where process loss lands in the unit cost.
- Multi-level BOM in ERPNext — operations and routings on nested BOMs.
What is the bottom line?
This is one of the easier ERPNext faults to deal with, because the fix exists, shipped in a point release, and needs no code from you. The part worth attention is not the upgrade — it is the fortnight before it, when the shop floor is deciding on its own how to get jobs closed. Sanction one workaround, log its use, and the bug costs you a maintenance window instead of a quarter of untrustworthy yield data. The same upgrade discipline applies to the wider ERPNext product the rest of your operation runs on, not just the manufacturing module.
Manufacturing entries failing and nobody's sure which version fixes what?
MithTech maps your instance against the open and fixed issues on your version, sequences the point releases safely, and stages the manufacturing flows before anything touches production. The scope covers the ERPNext product the rest of your operation runs on, not just the manufacturing module.