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 whole reservation is released · receiving store: InOrder is set to the quantity shipped

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 sets a new cost per unit for the stock still on hand — typically lower, 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 costed at the new figure.

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 lines that carry an item id and were not voided on the receipt. Lines that are not item movements — tenders and discounts, for example — are ignored, and a cancelled or training-mode transaction is skipped as a whole. A receipt voided after it was completed (a post-void, status Voided) reverses the original: its SALES lines add to SalesStock and its RETURN lines take from Returned. See Data sources.

---

Return