Delayed transactions
For some types of transactions, the sequence of the transactions is important to get the calculations done correctly. However, since some transactions might be delayed for a reason, the system needs to handle this when processing the transactions.
The case that matters is a stock count, because a count does not describe a change — it asserts an absolute truth about a point in time. A sale that happened before the count but arrives after it must not be applied to the counted quantity, or the same goods are removed twice.
Example:
- 10:00, the system quantity is 12
- 11:00, business unit performs a stock count, counted quantity is 10
- System calculates a loss/gain based on whether the counted quantity deviates from the system quantity, in this case, it's a loss of 2 items
- System calculates new stock quantity = 12 - 2 (loss) = 10
- 11:05, receives a sale performed at 11:05, sales quantity is 1
- System calculates new stock quantity = 10 - 1 (sale) = 9
- 11:10, receives a sale performed at 10:30, sales quantity is 2
- The sales transaction is actually done prior to the stock count, so the transaction should not affect the current stock quantity.
- On the other hand, the stock count performed at 11:00 reported a loss of 2 items, so the system creates a gain of +2 items to adjust the previously reported loss. In addition, the sales transaction is stored, i.e. reducing the stock by -2 items, so the result for both transactions is no change in stock quantity:
- System calculates new stock quantity = 9 + 2 (adjust/nullify loss reported for stock count) - 2 (sale) = 9
Note: The transactions are immutable, so any adjustment of previously created transactions needs to be handled by creating a delta transaction.
What this looks like to a consumer
The correction is published like any other transaction, so a subscriber sees three transactions from the example above: the late sale, and the compensating gain, plus the original count from earlier. Two fields identify what is happening:
| Field | Use |
|---|---|
transactionDate | when the movement actually happened — 10:30 for the late sale |
linkIdDelayed | links the compensating transaction to the stock count it corrects |
transactionDate can therefore be older than that of a transaction you already received. A consumer that
assumes the stream is ordered by business date will misread this. Order by timestamp — when STP processed the
movement — and treat transactionDate as data. See
External Events.
Scope
This compensation applies to stock counts, which are the operation that asserts an absolute quantity. Ordinary movements — sales, deliveries, corrections — are deltas, so a late arrival simply applies its delta and the total comes out right regardless of the order in which they were processed.