Sales Orders
A sales order (SO) is a commitment to ship products to a customer. It is the demand side of finished-goods inventory: it reserves stock, then draws it down as the order ships. Unlike the buy-side orders it has no receipts, so status changes alone move the inventory, and it is single-sided: it only draws finished goods down, it never produces or consumes materials.
What it does
- Track the order. At its core a sales order is a record of a customer commitment: which customer, what they want, when it must arrive, and how far along it is. That record stands on its own, with editable dates and a timeline of status changes.
- Draw down finished-goods inventory. As the order advances it records what the customer wants (demand), what has been set aside for them (allocated), and what has actually gone out the door (consumed), all on the finished-goods ledger.
How it works
A sales order is always in exactly one status, and because there are no receipts, every status change is by hand. One chain carries the order from arrival to close, with a flag and an early exit beside it. The sections below cover the chain, then what it does to inventory and to the dates.
The statuses
| Status | Type | What it means |
|---|---|---|
| Planning | Manual | The order has come in from the customer. Their wanted quantity is booked as demand. |
| Placed | Manual | Acknowledged and committed, and the stock is allocated to them. |
| In Transit | Manual | Goods have shipped and are on their way, and the stock is consumed. |
| Invoiced | Manual | The order has been invoiced. |
| Paid | Manual | The invoice has been paid. |
| Completed | Endpoint | Closed. |
| In-Dispute | Branch (off Invoiced) | Raised from Invoiced when there is a problem with the invoice; no inventory effect. Clear it to return to Invoiced. |
| Rejected | Exit | Rejected before it ships (only from Planning or Placed), which reverses its inventory effects. Can be reactivated, returning to wherever it last was. |
The whole chain is set by hand and freely reversible to fix a mistake; there are no receipts, so the status is the only thing that moves inventory.
Moving between them
- By hand, both ways. The whole chain is yours to move along, forward or back. Since there are no receipts, the status is the only way to correct a step: stepping back from In Transit un-ships and removes the consumption, stepping back from Placed removes the allocation, and so on.
- Disputing. From Invoiced, mark the order In-Dispute, and clear it back to Invoiced once resolved. It does not touch inventory.
- Rejecting. Reject an order before it ships to stop it and reverse its inventory effects; reactivate it to bring it back to where it was. Once goods are in transit an order is no longer rejected, since the stock has already gone out.
Effect on inventory
| What you do | Ledger effect |
|---|---|
| The order comes in (Planning) | books the wanted quantity as demand |
| Place it | allocates the stock to the customer |
| Ship it (In Transit) | consumes the stock out of inventory |
| Reject | reverses all of the above back to zero |
Projecting forward inventory effects requires a fulfilment location to be set. Every entry carries the SO number as its reference.
One rule keeps the ledger tidy: anything you undo is erased, not stamped with a counter entry. Step the order back out of In Transit and the consumption is simply removed. The only lasting reversal is a rejection, and even that disappears if you reactivate the order. The ledger always reflects only what is true right now.
Dates
- Order date is yours. It defaults to today when you create the order and you can change it whenever.
- Must-arrive-by date is the customer's deadline, set by hand.
- Status dates (planning, placed, in transit, and so on) stamp themselves as the order reaches each status, but stay editable afterwards so you can correct them.
Each ledger entry takes its date from the status that produced it: the demand booking from the planning date, the allocation from the placed date, and the consumption from the in-transit date. These are business dates, so editing one moves its entry with it: change the in-transit date and the consumption re-dates, change the placed date and the allocation follows. 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 sales orders through the REST API or the MCP server.