Operations
Every movement STP processes belongs to one operation — the business event that caused it. The operation
determines which stock types move, and it is published on every transaction as
operationType, so a consumer can tell a sale from a stock count without inspecting anything else.
Supported operations
| Operation | operationType | Effect on stock |
|---|---|---|
| Sale | SALES | SalesStock decreases |
| Return | RETURN | Returned increases — not SalesStock. What happens to it next is a separate, explicit operation: see the stock model |
| Goods received | GOODS_RECEIVED | SalesStock increases; if the line references a purchase order, InOrder decreases accordingly |
| Purchase order | PURCHASE_ORDER | InOrder increases — incoming goods are visible before they arrive |
| Order response | ORDER_RESPONSE | InOrder is adjusted to what the supplier confirmed it will deliver |
| Supplier return | SUPPLIER_RETURN | SalesStock decreases — goods sent back to the supplier |
| Stock count | STOCK_COUNT | SalesStock moves by the difference between the counted and the expected quantity |
| Stock correction | STOCK_CORRECTION | SalesStock moves by the correction — damage, waste, or anything that cannot be sold |
| Synchronize stock | SYNCHRONIZE_STOCK | SalesStock is set to an absolute quantity — see Synchronizing stock |
| Reservation | RESERVATION | Reserved, or ReservedInOrder when reserving against goods not yet received |
| Depreciation | DEPRECATION | quantity unchanged; the cost of the remaining stock is adjusted |
| Stock transfer | STOCK_TRANSFER | sending store: SalesStock decreases, InTransit increases · receiving store: InOrder increases |
| Stock transfer received | STOCK_TRANSFER_RECEIVED | sending store: InTransit decreases · receiving store: InOrder decreases, SalesStock increases |
| Store transfer initiated | STORE_TRANSFER_INITIATED | sending store: Reserved increases · receiving store: InOrder increases |
| Store transfer completed | STORE_TRANSFER_COMPLETED | sending store: SalesStock decreases, InTransit increases, the reservation is released · receiving store: InOrder is reconciled |
Two further values may appear on the wire: TRANSACTION, for a movement submitted through the generic stock
transaction endpoint, and UNKNOWN. Treat operationType as an open enumeration — new operations are added
over time, so a consumer should handle an unrecognised value rather than failing.
Depreciation adjusts cost, not quantity
Worth calling out because it is the one operation that changes no quantity at all. A depreciation writes down the cost of stock still on hand — typically to take a loss up front on goods that will have to be discounted, whether or not they eventually sell. The quantity is untouched; subsequent sales are simply costed lower.
Stock transfer and store transfer are different flows
Both move goods between business units, and they are not interchangeable:
- Stock transfer is the direct flow — the goods leave, and the receiving store confirms receipt.
- Store transfer adds a reservation step first, so goods can be committed to an outgoing transfer while still
physically in the sending store, and only leave
SalesStockwhen the transfer is actually completed.
See Multiple transactions for both sequences step by step.
One operation, several transactions
Because a single operation can move several stock types — and in a transfer, in two different business units — one operation normally produces several transactions. They are published separately and linked to each other.
Which sale lines are processed
Sales arrive as PosLog transactions. Only lines that represent an item movement become stock transactions:
Sale, SaleForDelivery and Return. Cancelled lines are skipped, and lines that are not item movements —
deposits, tenders, discounts — are ignored. See Data sources.