Skip to main content
Version: v1.0.0

Sales Orders

A sales order (SO) is a commitment to ship products to a customer. It's the demand side of finished-goods inventory: it reserves stock, then draws it down as the order ships, all driven by the order's status.

What problem it solves

A sales order tracks an order from the moment it arrives until it's paid, and keeps finished-goods inventory honest along the way — recording what customers want (demand), what's been set aside for them (allocated), and what's actually gone out the door (consumed). Unlike the buy-side orders, it has no separate receipts; status changes alone move the inventory.

Lifecycle

A sales order is Received when it comes in from the customer, Entered once acknowledged, Shipped when goods go out, then Invoiced, Paid, and Completed. Rejected and In-Dispute are off-ramps; rejecting an order reverses all of its inventory effects. Each status stamps an editable business date.

Fields and line items

  • HeadersoNumber, the customer, the order channel, a fulfillment location, the must-arrive-by date, optional broker and fee, and cost add-ons (freight, fulfillment, promo, other).
  • Line items — one row per product, with a quantity and unitPrice. A product appears at most once per order.
  • Timeline notes — a running log of status changes with optional notes, giving the order an audit trail.

There are no receipts; fulfillment is expressed entirely through status.

Inventory effects

WhenLedgerEvent
Received (and beyond)finished goodsDEMAND for each line
Entered (and beyond)finished goodsALLOCATE each line
Shipped (and beyond)finished goodsCONSUME each line
Rejectedfinished goodsall of the above are reversed

The order walks the line from demand → allocated → consumed as its status advances, and a rejection nets everything back to zero. Projecting new forward events requires a fulfillment location to be set. Every entry carries the SO number as its ref.

Relationships

See also

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