What a work order is
A work order (WO) is the ERP's instruction to the shop floor: make this quantity of this item, by this route, for this demand. It is the point where the commercial world — the released sales order and its exploded BOM — becomes physical work: material drawn from stores, machine hours consumed, operations completed, quantities booked. Everything the factory does between "order released" and "finished goods on the shelf" hangs off it.
Treated as paper, a work order is just a job card. Treated as a document inside an integrated ERP, it is a live ledger of the job: what was issued to it, which processes it has passed, how many pieces came through good, what went to rework, what was rejected and why, and when the completed quantity transferred into stock. That record is what makes delivery dates honest, costing real and traceability possible.
Work orders and sub work orders
Multi-level products need more than one instruction. The parent item's work order cannot start until its sub-assemblies exist, and those sub-assemblies are jobs in their own right. That is the role of the sub work order (SWO): subordinate work generated under a parent work order, typically for the intermediate items the BOM requires. Each level of the structure gets its own issueable, bookable, traceable document, while the reference chain ties every SWO back to the parent — and the parent back to the customer order.
The practical payoff is control at the right granularity. A delay on one sub-assembly is visible as that sub work order sitting in progress, not as a vague "the job is late"; and stock of intermediates made ahead of need is real, countable inventory rather than parts loose on a bench.
The route: process sheets and specifications
A work order without a route is a quantity with no method. The process sheet fixes the sequence of operations the item travels — cut, machine, weld, plate, assemble — and Fast ERP maintains process sheets both against the item and against the specific order, so an order-specific variant can carry its own method without disturbing the standard. Process specifications add the parameters each operation must hold, which is what in-process inspection later checks against.
The route is also where capacity meets the plan: each operation draws on the resource master — machines, labour, tooling — which is how the Gantt-style machine loading view in the Production & Planning module knows which hours this work order will consume, and when.
The lifecycle, stage by stage
| Stage | What happens | Status |
|---|---|---|
| Draft | Work order created from the released order or plan; quantity, item and route attached | Draft |
| Released | Approved for the floor; stores can reserve and issue against it | Released |
| In progress | Operations booked process by process; WIP quantities move along the route | In-Progress |
| Completed | Final operation passed; completed quantity ready for transfer | Completed |
| Closed / short-closed | FG transferred and the order closed — or short-closed if the balance will not be made | Closed |
The statuses matter because they are gates, not labels. Stores cannot issue against a draft; a completed order cannot quietly keep consuming material; and a short-close forces the shortfall into daylight instead of leaving a phantom open quantity that planning keeps counting on.
Material: reserve, issue, consume
Material meets the work order in three moves. Reservation earmarks stock for the job so another order cannot take it — reserved stock is excluded when MRP nets the next requirement. Issue moves it physically and financially out of stores against the work order, on a material issue slip with a return slip for what comes back. Consumption is what the WIP booking then accounts for, operation by operation.
All three post through the same store engine that handles receipts and dispatches, which is the quiet superpower here: shop-floor material is never "off the books" — it is a visible stage of one stock ledger, valued and traceable, from the bin to the job and back.
WIP booking — good, rework, reject
As the job moves down the route, each operation books its result on a production slip: how many pieces came through good, how many need rework, how many are rejected. The booked quantities drive three things at once: progress (which process the job is at, and how much of it), quality visibility (rejection rates by process, not just by job), and stock (WIP is a real inventory stage, not a guess).
In-process inspection sits on the route as a gate — process status entry with inspection means a job cannot flow past a checkpoint unrecorded. This is the same three-gate architecture the quality module applies across the business: incoming material at the GRN, work in process on the route, and outgoing goods at pre-dispatch.
Rework and rejection handled honestly
Every real factory makes bad parts; the difference is whether the system admits it. Rework quantities travel a rework route and, when recovered, enter stock through a rework-specific finished-goods transfer — so recovered parts are never silently mixed into first-pass figures, and first-pass yield stays a true number. Rejects are recorded as material rejection with reasons, feeding process-rejection analysis that shows which operations bleed the most.
Rejection also closes loops outside production: scrapped material can raise a purchase requisition for replacement, and a supplier-caused defect found on the line can raise a non-conformance that traces back through the issue and the GRN to the lot that caused it.
Is your shop floor a whiteboard your ERP can't see?
Bring one live job — we will run it as a work order end to end: issue, WIP booking, inspection gate, rework split and FG transfer, in a 30-minute session.
Completion and the WIP-to-FG transfer
The last act of a work order is a stock movement: the WIP-to-finished-goods transfer takes the completed quantity out of work-in-progress and into finished stock, where it becomes available to dispatch. From here the quote-to-cash spine takes over — pre-dispatch inspection, delivery challan, GST invoice — but the trace persists: the dispatched lot points back to the work order, the work order to its issues and bookings, and everything to the customer order that started it.
That unbroken chain is what a customer audit or a field-failure investigation actually needs: not a folder of paperwork assembled after the fact, but linked documents recorded as the work happened.
What the work order tells costing
Because every issue and booking posts against the work order, process cost reporting can state what each operation actually cost on the job — material drawn, work booked, scrap absorbed. Set against the BOM-costed should-cost, the comparison answers the question owners care about most: where did the margin go? A job that lost money to rework at one process is a fixable fact, not a mystery in the year-end accounts.
How Fast ERP runs work orders
Fast ERP implements the lifecycle above as one connected set of screens in the Production & Planning module:
- Work orders and sub work orders generated from the released Order Acceptance and its BOM explosion, with multi-job printing for the floor.
- Process sheets and specifications — standard and against-the-order — fixing route, parameters and the resources each operation loads.
- Production slips and process status — WIP booked per operation with good, rework and reject splits, and inspection entries on the route.
- WIP-to-FG and rework-to-FG transfers posting through the same store engine as every other stock movement.
- Rejection and rework analysis — material rejection with reasons, process-rejection MIS and rework process reporting.
- Process cost reports — actuals per operation against the job, closing the loop with BOM costing.
Because it all shares one database with sales, purchase, stores and quality, a work order is never an island: it descends from an order, consumes inspected material, and hands sellable stock to dispatch — the pattern proven in deployments like Nikhtish Engineering and Micro India.
Frequently asked questions
What is a work order in an ERP?
A work order is the ERP's instruction to the shop floor to make a specific quantity of a specific item, traced to the demand that caused it — usually a released sales order whose BOM has been exploded. It carries the item, quantity and route (the sequence of processes from the process sheet), and it is the document against which material is issued, work-in-progress is booked process by process, rework and rejection are recorded, and the finished quantity is transferred to stock.
What is the lifecycle of a work order?
Created from the released order or plan; routed via a process sheet that fixes the operations; material reserved and issued from stores against it; booked as WIP at each process with good, rework and reject quantities; gated by in-process inspection; completed when the final operation passes; and closed by a WIP-to-finished-goods transfer that puts the completed quantity into stock. Statuses in Fast ERP move through draft, released, in-progress, completed and closed, with short-close available for quantities that will not be finished.
What is the difference between a work order and a sub work order?
The work order (WO) makes the parent item; sub work orders (SWO) cover subordinate work generated under it — typically the sub-assemblies or intermediate items the multi-level BOM requires before the parent can be built. Splitting them keeps each level of the structure separately issueable, bookable and traceable, while the reference chain ties every sub work order back to the parent order that caused it.
How does an ERP handle rework and rejection on work orders?
At each process the booked quantity splits into good, rework and reject. Rework quantities travel a rework route and, when recovered, transfer to finished goods through a rework-specific FG transfer, so recovered parts are never confused with first-pass parts. Rejects are recorded as material rejection with reasons, feed the process-rejection analysis, and can raise a purchase requisition for replacement material or a non-conformance for investigation — so scrap becomes data, not just loss.
How do work orders connect to inventory and costing?
Every material movement a work order causes — reservation, issue, WIP booking, FG transfer — posts through the same store engine as receipts and dispatches, so stock always reflects shop-floor reality. On the cost side, process cost reporting accumulates what each operation actually cost against the work order, which can be compared with the BOM-costed should-cost to show where margin was made or lost on the job.