How Stock Movements Work
Stock is recorded as a ledger of movements. Every receipt, issue, transfer and adjustment is a row, and rows are never updated and never deleted. On-hand quantity is a sum over those movements, calculated rather than stored.
Where to find it
Architect Panel → ERP - Operations:
- Stock — the console — current position, transact, enquire
- Stock Movements — the append-only ledger itself
- Stock Balances — the cache, rebuildable from movements
- Stock Locations — where stock can be
- Stock Policies — reorder levels and rules per item and location
Why not store a quantity
A quantity column that anything can update is one that will eventually be wrong, with no record of when it went wrong or what changed it. Every stock system that has ever needed a stocktake to "fix the numbers" works that way.
Deriving the figure removes the possibility. If on-hand is the sum of movements then on-hand cannot disagree with the movements — and if a number looks wrong, the movements tell you exactly which transaction made it so, and when.
Corrections are movements
You do not edit a mistaken movement; you post a reversing one. Both remain visible, which is what lets you answer why a figure changed rather than merely observing that it did.
The balances cache
Stock Balances caches the current position so a screen does not sum a long history every time it loads. It is only a cache: it holds nothing the movements do not, and it can be rebuilt from them at any time.
That matters practically — if a balance ever looks wrong, rebuilding is safe and loses nothing. Contrast a stored quantity, where a rebuild is impossible because there is nothing authoritative to rebuild from.
Opening balances
Load them as movements — a receipt per item and location, dated to go-live. Do not write opening quantities into the balances cache. They would be correct until the first rebuild and then vanish, which is a genuinely confusing failure to diagnose.
Locations and policies
Model locations at the granularity you will actually count at; bins you never physically verify are administrative fiction that make counts harder rather than more accurate.
Stock Policies holds reorder levels and rules per item and location, which is what feeds requirements planning.
Worked example
A warehouse goes live with 1,200 lines. Opening balances are loaded as dated receipts against the main location with realistic costs. A week later a count finds one line short by three; rather than editing the opening receipt, an adjustment movement is posted with a reason. The history now shows the opening position, the discrepancy and when it was found — which is what the auditor asks about.
Recommendations
- Load opening balances as movements, never into the cache.
- Model locations you will actually count.
- Adjust with a reason, never by editing history.
- Rebuild balances freely if a figure looks wrong — it is a safe operation.