ERPNext Job Card Process Loss: Finished Goods Entry Fails (2026)

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 am Manoj, ERPNext and Frappe implementation lead at Mith Tech in Bengaluru, and this one 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 and 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.

Five symptoms, five different issues

Process loss in ERPNext manufacturing has had several distinct faults across v15 and 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.

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.

Fix it

1. Help > About  →  note the exact ERPNext version.
   Below 15.47.0 on the v15 line? You are affected.

2. Open the failing Work Order. Check:
     • Transfer Material Against = "Job Card"   ← the trigger
     • BOM has at least one operation
     • A Job Card exists with Process Loss Qty > 0

3. Compare these two numbers on the Work Order:
     • Material Transferred for Manufacturing
     • Qty to Manufacture
   If transferred looks short by exactly the process-loss
   quantity, that is the #44823 signature.

4. If "Track Semi-Finished Items" is enabled and you are
   on v16, stop — you are looking at #52028, not this.

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.

Upgrade now, or hold and work around

FAQ

Related issues you may 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.

Closing

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.