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​

   source event                    STP                          consumers
─────────────────────    ──────────────────────────    ────────────────────────────
POS (PosLog)         ┐
Goods received       │   ┌──────────────────────┐      ┌─ Query API (POS, apps)
Stock count          ├──▶│ 1. interpret         │      │
Stock correction     │   │    one event becomes │      ├─ External Events
Store transfer       │   │    N transactions    │      │    · stock level updates
Input API            ┘   │                      │──────┤    · processed transactions
                         │ 2. apply             │      │
Item master data     ┐   │    calculate cost,   │      └─ Reporting / accounting
  from PnP           ├──▶│    draw down batches,│
  · items            │   │    update quantities │
  · purchase prices  │   └──────────────────────┘
  · item links       ┘

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.

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