Skip to main content
Version: v1.0.0

Work Orders

A work order (WO) covers outsourced conversion: you send materials (and sometimes component products) to an external site, they assemble them, and you receive finished products back. What you are paying for is the labour, the conversion, because you supplied the inputs yourself.

Work order or production order?

Both turn inputs into finished goods through a subcontractor. The difference is the cost model. A work order prices only the conversion (you own the materials, the site provides labour). A production order prices the whole thing, the manufacturer's production cost plus the consumed material cost, so the finished good lands fully costed.

What it does

  • Track the job. At its core a WO is a record of an outsourced conversion: which products you expect back, the inputs those products consume (snapshotted from each SKU's bill of materials), and what has been produced so far. That record stands on its own, with editable dates and no inventory required.
  • Move inventory both ways. A WO consumes and produces. It demands and allocates the inputs as the job commits and goes into production, then on receipt consumes those inputs and produces the finished goods. It writes to both the materials and finished-goods ledgers.

How it works

Work order state machine

A WO is always in exactly one status. What changes that status falls into three buckets: some you control by hand, some happen automatically as production is received, and two are endpoints. The table below lists them by that grouping; the sections that follow cover what it all does to inventory and to the dates.

The statuses

StatusTypeWhat it means
PlanningManualStill preparing the job. Nothing is committed and inventory is untouched.
PlacedManualPlaced with the site. The output products are booked as on order and their inputs are demanded.
ProductionManualThe job is underway, so its inputs are allocated.
PartialReceipt-drivenThe first delivery of finished product has come back and receiving is open. Every receipt lands here, whatever the quantity.
ReceivedManualMark this when you are done taking deliveries, however much came back. Reverts to Partial to receive more.
CompletedEndpointThe job is closed, from Received.
CancelledExitA job stopped before production was received (only before Partial). Can be reactivated.

The manual statuses carry no receipts yet, so you can move between them freely in either direction to fix a mistake. Partial is the only one the receipts drive.

Moving between them

  • By hand, both ways. Planning, Placed and Production are yours. Step forward as the job progresses, or step back if you moved too far.
  • By receipts. Each delivery of finished product is a receipt with its own date and lines, allowed once the job is in Production. The first one moves the WO to Partial, whatever the quantity, and further receipts keep it there. Delete a receipt and the status walks back on its own, staying in Partial until the last one is gone, then returning to where the job was before anything was produced.
  • Closing receiving. When you are done taking deliveries, mark the WO Received by hand. This is yours to decide: it does not wait for the produced quantity to match the order, so a job can be closed short or over. Reopen it to Partial if more comes back.
  • Completing. A received job can be marked Completed, and reverted to Received if that was a slip.
  • Cancelling. Cancel stops a job any time before production starts coming back (any status before Partial). Once receipts exist it can no longer be cancelled. A cancelled WO can be reactivated, and it returns to wherever it last was.

Effect on inventory

What happensLedger effect
Place the orderbooks the output as on order and demands the inputs
Move into Productionallocates the inputs
Record a receiptconsumes the inputs and produces the finished output
Cancelreverses the demand-side bookings back to zero

Inputs route to whichever ledger they belong to: raw materials to the materials ledger, component SKUs to the finished-goods ledger. Every entry carries the WO number as its reference.

One rule keeps the ledger tidy: anything you undo is erased, not stamped with a counter entry. Step a WO back out of Production and the allocation is simply removed. Delete a receipt and its consume and produce movements are removed. The only lasting reversal is a cancellation, and even that disappears if you reactivate the job. The ledger always reflects only what is true right now.

Corrections follow the same idea. A receipt line's quantity, conversion cost, lot and expiration are editable in place: edit the quantity and the produce movement restates to the new figure while the input consumes rescale with it, because making more meant using proportionally more (no extra rows, no counter entries), and the WO's status recomputes as if the run had always said so. Lot and expiration travel with the produce movement the same way. Cost never sits on the ledger at all: it is read live from the receipt line, so a price fix needs no propagation. A Completed WO is closed for good; reopen it before editing or deleting its receipts.

Closing receiving settles the books on both sides. When you mark a WO Received the booked output and the reserved inputs rarely match what was produced, so the gaps are trued up with settle entries: the un-produced output stops counting as on order, and inputs reserved but never consumed are released back to available. Over-runs settle the same way, output produced beyond the order or inputs consumed beyond the reservation true back to zero too. Reopen the WO to Partial and those settle entries are removed, restoring the open commitments.

Dates

Every WO carries dates, designed to stay truthful with the least fuss.

  • Order date is yours. It defaults to today when you create the WO and you can change it whenever.
  • Status dates (placed, production, and so on) stamp themselves as the WO reaches each status, but stay editable afterwards so you can correct them.
  • Partial date comes straight from the receipts: the first receipt's date. Change that receipt's date and it follows. The Received date stamps when you mark the WO Received and stays editable like the other status dates.

Each ledger entry takes its date from the order event that produced it: the on-order booking and the input demand from the placed date, the input allocation from the production date, the consume and produce movements from their receipt's own date, and the settles written at close from the received date. These are business dates, so editing one moves its entry with it: change the production date and the allocation re-dates, change a receipt's date and its consume and produce follow. The record-of-entry timestamp never moves, so the stock history always reads in true business-date order, which is what positions and the cost model sort by.

See also

Drive work orders through the REST API or the MCP server.