Stock & Inventory

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.

Why not just store a quantity

A quantity column that anything can update is a quantity column 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 the 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. This is the same principle the ledger applies to journals, for the same reason.

The balances cache

Summing a long movement history on every screen would be slow, so a balances table caches the current position. It is only a cache. It holds no information the movements do not, and it can be rebuilt from them at any time.

That matters practically: if a balance ever looks wrong, rebuilding it is safe and loses nothing. Contrast a stored quantity, where a rebuild is impossible because there is nothing authoritative to rebuild from.

Getting stock in to begin with

Opening balances are movements like any other — a receipt per item and location, dated to your go-live. Do not write opening quantities into the cache directly. They would be correct until the first rebuild and then vanish, which is a genuinely confusing failure.

Locations

Movements record where stock went as well as what moved, so a transfer is an issue from one location and a receipt into another. Model locations at the granularity you will actually count at — bins you never physically verify are administrative fiction.

Reservations and Availability

Two different questions get confused in stock systems: how much is here, and how much can I promise. Reservations are what separate them.

Reservations are movements in a reserved state

A reservation is recorded as a movement, but in a reserved state rather than a completed one. It does not change what is physically present — the goods are still on the shelf — but it does change what is available to promise to the next customer.

Recording reservations as movements rather than as a separate mechanism means the same ledger answers both questions, and a reservation is as auditable as a despatch.

On-hand versus available

• On hand — what is physically in the location.
• Reserved — committed to orders not yet despatched.
• Available — on hand less reserved, which is the figure a salesperson should be shown.

Showing on-hand where you meant available is the direct cause of overselling. Ten in stock and ten already reserved is not ten to sell.

When to reserve

Reserve at the point the business genuinely commits — usually order confirmation rather than quotation. Reserving at quotation ties up stock against speculative demand and produces artificial shortages; reserving at despatch is too late to prevent the overselling it exists to stop.

Releasing

Reservations must be released when the order is cancelled or fulfilled, otherwise availability drifts downward and the system reports a shortage that does not exist. Fulfilment converts the reservation into a completed issue. Cancellation releases it. Make sure both paths exist before going live — an unreleased reservation is much harder to spot than a missing one.

Checking availability at the right moment

Check availability when the commitment is made, not when the order was first keyed. In a busy system stock can be committed elsewhere in the interval, and a check performed against a figure fetched several screens ago is a check against history.

Valuation and Cost Layers

Knowing how many you have is only half the question. Valuation answers what they are worth, and what an issue cost you.

FIFO layers

Receipts create cost layers — this many units at this cost, received on this date. Issues consume the oldest layer first, and record what they actually consumed. If an issue spans two layers because the first was exhausted part-way, the cost reflects both.

Why the issue stores its cost

Because it makes margin permanent. An issue that recorded what it consumed at the time will report the same margin next year. An issue valued by looking up a cost at report time will report a different margin every time the cost changes, which means the reported profit on a historical sale is not a fact but a function of when you asked.

This is the same reasoning as storing three currency amounts on a ledger line, and as storing a bill rate on a time entry. A figure that describes a past event should be captured when the event happens.

What this gives you

• A stock valuation that ties to the movement history rather than to a separate calculation.
• Cost of sales per document, and therefore margin per line, order and customer.
• The ability to explain a margin figure by pointing at the specific layers an issue consumed.

Getting opening costs right

Opening movements need realistic costs, not zero. A zero-cost opening layer produces spectacular margins until it is exhausted, and those figures will be reported before anyone notices. Take the cost from your previous system.

Adjustments

A stock adjustment changes quantity, and therefore changes value. Decide the cost basis for adjustments deliberately — writing stock off at zero and writing it back on at zero will balance the quantity while quietly destroying the valuation.

Posting to the ledger

Where stock movements post to the general ledger, valuation is what supplies the amount. Confirm the accounts before going live: getting the quantity right and the value posted to the wrong account is a reconciliation problem that surfaces at the worst moment, which is close.