Loading

Stock & Inventory

An append-only movement ledger with locations, lots and genealogy, where on-hand is always derived, plus reservations and FIFO valuation.

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.

Reservations, Lots and Genealogy

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

Where to find it

Architect Panel → ERP - Operations:

  • Stock — the console showing on-hand, reserved and available
  • Stock Lots — batch and serial identity, with expiry where relevant
  • Stock Genealogy — the movement trail linking lots to what they became

Reservations are movements in a reserved state

A reservation 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 — physically in the location.
  • Reserved — committed to orders not yet despatched.
  • Available — on hand less reserved, and the figure a salesperson should be shown.

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

When to reserve, and to release

Reserve at genuine commitment — usually order confirmation. Reserving at quotation ties up stock against speculative demand and manufactures shortages; reserving at despatch is too late to prevent what it exists to prevent.

Reservations must be released on cancellation and converted on fulfilment, or availability drifts downward and the system reports a shortage that does not exist. Confirm both paths work before going live — an unreleased reservation is much harder to notice than a missing one.

Lots and genealogy

Stock Lots gives a batch or serial its own identity, with expiry where that applies. Stock Genealogy is the trail linking a lot to what consumed it and what it became.

This is the recall question. When a supplier tells you a batch shipped between two dates was defective, genealogy tells you which of your outputs used it and which customers received them. Without it the honest answer is that you cannot tell, and the practical answer is to recall everything.

Capture the lot at receipt

Not later. A lot reconstructed after the fact from delivery notes is a guess, and a recall is precisely the situation where a guess is worthless.

Worked example

A food producer receives an ingredient in lots. Each production run records which lots it consumed. When a supplier issues a withdrawal notice for one lot, genealogy identifies four production runs, the finished batches they became, and the six customers who received them — in minutes, and defensibly.

Recommendations

  • Show available, not on-hand, anywhere a promise is made.
  • Reserve at confirmation, and test the release path.
  • Capture lots at receipt or do not claim lot traceability.
  • Rehearse a recall query once before you need it for real.

Valuation and Cost Layers

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

Where to find it

Architect Panel → ERP - Operations:

  • Stock Cost Layers — the FIFO layers and what each issue consumed
  • Standard Costs — a costed view of a structure, for quoting and variance

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. An issue spanning two layers because the first was exhausted 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 reports a different margin whenever the cost changes — so reported profit on a historical sale becomes a function of when you asked rather than a fact about what happened.

This is the same reasoning as storing three currency amounts on a ledger line and storing a bill rate on a time entry: a figure describing 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.

Opening costs

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

Adjustments

A stock adjustment changes quantity and therefore changes value. Decide the cost basis deliberately: writing stock off at zero and writing it back on at zero balances the quantity while quietly destroying the valuation.

Standard costs

Standard Costs holds a costed view of a structure, useful for quoting and for variance analysis against what production actually consumed.

It is a comparison baseline, not what the ledger posts — that comes from the layers. Confusing the two produces a valuation that agrees with nobody.

Worked example

A component is received at £4.10, then at £4.60. An order issues 150 against a first layer of 100, so the issue records £410 plus £230 — £640, not 150 × £4.60. The margin on that order is fixed at the moment of issue, and still reads the same after the next receipt arrives at £5.00.

Recommendations

  • Never open with zero costs.
  • Decide the adjustment cost basis before your first write-off.
  • Keep standard costs and actual valuation clearly separate in reporting.
  • Confirm the posting accounts before stock movements start hitting the ledger.