Skip to main content

Stock Transaction Processing

What the service does​

Stock Transaction Processing (STP) receives every event that changes stock — a sale at the POS, a delivery from a supplier, a stock count, a transfer between stores — and turns each one into one or more immutable transactions. From that ledger it maintains:

  • Stock quantities, per tenant, business unit, item and stock type.
    • Any Hii Retail service can request real-time quantities through the Query API.
    • External systems can receive them by subscription through External Events.
  • The cost of every movement, using the item's configured costing method.
    • This is what lets an accounting or reporting system calculate gross profit per sale.
  • A complete, queryable audit trail — every movement keeps its source document, its business date, and the resulting stock level, so "why is the quantity what it is?" is always answerable.

Note: STP does not have to be the master of stock. If an external system owns the stock, STP can be synchronized instead — see Synchronizing stock.

How a movement flows through​

Sales from the tills, deliveries, stock counts, corrections and store transfers reach Stock Transaction Processing from other Hii Retail services, and an ERP or warehouse system can send movements through the Input API. Item settings, purchase prices and bundle links come from PnP. Stock Transaction Processing keeps the ledger and the quantities, which the POS and apps read through the Query API, and publishes stock levels and processed transactions that your systems and Stock Count subscribe to.

Step 1 — interpret. The incoming event is validated, enriched with item master data, and split into the transactions it implies. One delivery line can become two transactions; a store transfer becomes three. See Multiple transactions.

Step 2 — apply. Each transaction is applied to the stock: the right batch is selected according to the item's costing method, the cost of the movement is calculated, the quantity is updated, and the resulting state is published.

The two steps are separate on purpose. Interpretation depends on master data and business rules; application depends on the current stock. Keeping them apart is what allows a movement that arrives late to be applied correctly against the state that existed when it happened — see Delayed transactions.

How one event flows through. A stock transfer of 10 coffees from Stockholm to Uppsala arrives. Step 1, interpret, uses the item’s settings from PnP and splits it into three transactions: Stockholm SalesStock minus 10, Stockholm InTransit plus 10, Uppsala InOrder plus 10. Step 2, apply, takes each one, picks the batch, works out the cost and updates the quantity. Each applied transaction is published as a processed transaction and a stock level update.

What it publishes​

EventContains
Stock level updatesthe new quantity and cost for one (business unit, item, stock type)
Processed transactionsthe full detail of one applied movement, including the resulting stock level

Both are available to external systems through External Events, and to Hii Retail services directly.

Return