Skip to main content

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

OperationoperationTypeEffect on stock
SaleSALESSalesStock decreases
ReturnRETURNReturned increases — not SalesStock. What happens to it next is a separate, explicit operation: see the stock model
Goods receivedGOODS_RECEIVEDSalesStock increases; if the line references a purchase order, InOrder decreases accordingly
Purchase orderPURCHASE_ORDERInOrder increases — incoming goods are visible before they arrive
Order responseORDER_RESPONSEInOrder is adjusted to what the supplier confirmed it will deliver
Supplier returnSUPPLIER_RETURNSalesStock decreases — goods sent back to the supplier
Stock countSTOCK_COUNTSalesStock moves by the difference between the counted and the expected quantity
Stock correctionSTOCK_CORRECTIONSalesStock moves by the correction — damage, waste, or anything that cannot be sold
Synchronize stockSYNCHRONIZE_STOCKSalesStock is set to an absolute quantity — see Synchronizing stock
ReservationRESERVATIONReserved, or ReservedInOrder when reserving against goods not yet received
DepreciationDEPRECATIONquantity unchanged; the cost of the remaining stock is adjusted
Stock transferSTOCK_TRANSFERsending store: SalesStock decreases, InTransit increases · receiving store: InOrder increases
Stock transfer receivedSTOCK_TRANSFER_RECEIVEDsending store: InTransit decreases · receiving store: InOrder decreases, SalesStock increases
Store transfer initiatedSTORE_TRANSFER_INITIATEDsending store: Reserved increases · receiving store: InOrder increases
Store transfer completedSTORE_TRANSFER_COMPLETEDsending 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 SalesStock when 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.

Click here for details

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.


Return