Production Orders
A production order subcontracts the full manufacture of a product. You place the order with a manufacturer, Pharus explodes the product's bill of materials down to raw materials, and the finished goods come back fully costed: the per-unit production cost plus the cost of the materials consumed.
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 production order is a record of an outsourced manufacture: which products you expect back, the materials they consume (exploded from the 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, fully costed. It demands and allocates the materials as the order commits and goes into production, then on receipt consumes those materials, valued under the organization's costing model, and produces the finished goods at material cost plus production cost. It writes to both the materials and finished-goods ledgers.
How it works
A production order 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
| Status | Type | What it means |
|---|---|---|
| Planning | Manual | Still preparing the order. Nothing is committed and inventory is untouched. |
| Placed | Manual | Placed with the manufacturer. The output products are booked as on order and their materials are demanded. |
| Production | Manual | Manufacture is underway, so the materials are allocated. |
| In Transit | Manual | The finished output has been produced and a pickup is scheduled or it is on the road, but it is not yet received into inventory. |
| Partial | Receipt-driven | The first delivery of finished product has come back and receiving is open. Every receipt lands here, whatever the quantity. |
| Received | Manual | Mark this when you are done taking deliveries, however much came back. Reverts to Partial to receive more. |
| Completed | Endpoint | The order is closed, from Received. |
| Cancelled | Exit | An order 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, Production and In Transit are yours. Step forward as the order 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 order is in Production. The first one moves the order 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 order was before anything was produced.
- Closing receiving. When you are done taking deliveries, mark the order Received by hand. This is yours to decide: it does not wait for the produced quantity to match the order, so an order can be closed short or over. Reopen it to Partial if more comes back.
- Completing. A received order can be marked Completed, and reverted to Received if that was a slip.
- Cancelling. Cancel stops an order any time before production starts coming back (any status before Partial). Once receipts exist it can no longer be cancelled. A cancelled order can be reactivated, and it returns to wherever it last was.
Effect on inventory
| What happens | Ledger effect |
|---|---|
| Place the order | books the output as on order and demands the materials |
| Move into Production | allocates the materials |
| Record a receipt | consumes the materials and produces the finished output |
| Cancel | reverses the demand-side bookings back to zero |
The receipt is what the costing reads: consumed materials are valued under the organization's costing model, and that per-unit material cost is added to the order's production cost to value each finished unit, derived on read rather than written down. Every entry carries the production-order number as its reference.
One rule keeps the ledger tidy: anything you undo is erased, not stamped with a counter entry. Step an order 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 order. The ledger always reflects only what is true right now.
Corrections follow the same idea. A receipt line's quantity, production cost, lot and expiration are editable in place: edit the quantity and the produce movement restates to the new figure while the exploded-BOM consumes rescale with it, because making more meant using proportionally more (no extra rows, no counter entries), and the order'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 order is closed for good; reopen it before editing or deleting its receipts.
Closing receiving settles the books on both sides. When you mark an order Received the booked output and the reserved materials rarely match what was produced, so the gaps are trued up with settle entries: the un-produced output stops counting as on order, and materials reserved but never consumed are released back to available. Over-runs settle the same way, output produced beyond the order or materials consumed beyond the reservation true back to zero too. Reopen the order to Partial and those settle entries are removed, restoring the open commitments.
Dates
Every order carries dates, designed to stay truthful with the least fuss.
- Order date is yours. It defaults to today when you create the order and you can change it whenever.
- Status dates (placed, production, and so on) stamp themselves as the order 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 order 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 material demand from the placed date, the material 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.
Work orders vs production orders
| Work order | Production order | |
|---|---|---|
| You are paying for | Conversion / labour | The whole manufactured product |
| Inputs | Materials and component products (BOM one level deep) | Raw materials only (BOM fully exploded) |
| Output cost | Conversion cost only | Production cost plus consumed material cost |
| Finished-goods valuation | Labour portion | Fully landed cost |
| Reach for it when | You own the materials and just need them assembled | You want a turnkey product costed end to end |
The distinction is what counts as an input and how the finished good is valued. Their status vocabularies are nearly identical now; the one difference is In Transit, which a production order carries (the goods travel back from the manufacturer) and a work order does not.
See also
Drive production orders through the REST API or the MCP server.