Why On-Hand Is a Cache, Not the Source of Truth in EDGEBIC

The on-hand number you see in EDGEBIC is a cache, a fast display copy, while the authoritative on-hand is the sum of every entry in the append-only inventory ledger. In EDGEBIC by User Solutions, the ledger sum is the record and the cached figure is only a performance copy of it, recomputed every time an entry posts. Understanding this relationship is what keeps you from ever hand-editing an on-hand number, which is the one action that breaks it.

This post explains why on-hand is derived, why a cache exists anyway, and how drift is caught and reconciled. It sits under the EDGEBIC planning guide and builds on the inventory ledger explained.

Two numbers that should always agree

There are two on-hand figures in the system, and in normal operation they are identical.

The ledger sum is the authority: add up every signed entry for a product, receipts positive and issues negative, and the total is the true on-hand. This is what the scheduling engine nets against, what the projection opens from, and what an auditor can prove.

The cached on-hand is a stored figure on the product record, kept so a grid or a dropdown can show a number without re-summing the whole ledger every time it draws. It is recomputed from the ledger sum every time an entry posts, in the same transaction, so it tracks the authority automatically.

They should always agree because the same posting path that appends a ledger entry updates the cache. When they ever do not, the ledger sum is right and the cache is stale, because the cache is only a copy.

Why keep a cache at all

If the ledger sum is the truth, why not just compute it every time? Speed. A product with years of history has a long ledger, and summing it on every screen draw, every grid refresh, every dropdown, would be slow at scale. Caching the current on-hand and recomputing it atomically on each posting gives fast reads without giving up correctness, because the cache is never allowed to drift in normal operation.

This is a standard and safe pattern, with one hard rule: nothing writes the cache except the posting path. The moment some other code sets on-hand directly, the cache and the ledger can diverge, and the number on the grid stops meaning what everyone assumes it means.

How drift is caught

Because the posting path keeps the two in step, drift should never happen in normal operation. But the system does not assume; it checks. The anomaly report compares, per product, the cached on-hand against the sum of the ledger, and flags any product where they disagree.

A flagged product almost always means something wrote the cache outside the ledger, which is exactly the mistake the check exists to catch. This is why the discipline matters: the check is a safety net, not a routine reconciliation you should need. If it fires, treat it as a signal that on-hand was set somewhere it should not have been.

A worked reconciliation

Suppose the product grid shows 340 on hand for a bracket, but summing its ledger gives 325. The anomaly check flags the 15-unit drift. Which number is right, and what do you do?

The ledger sum of 325 is right; the 340 is a stale cache. The fix is not to type 325 into the grid, because that would repeat the exact mistake, writing the cache outside the ledger. Instead, post an adjustment through the ledger:

The adjustment appends a real ledger entry and recomputes the cache in the same transaction, bringing both to the reconciled figure. The audit trail now shows the correction as an honest entry, and the cache equals the ledger sum again. Reconciliation always flows through the ledger, never around it. This is the same append-only discipline described in why inventory transactions are append-only.

The one rule that keeps it clean

Everything about the cache reduces to a single habit: never hand-set on-hand. Every change goes through a ledger movement, an adjustment for a count correction, a receipt for incoming stock, an issue for consumption. Do that and the cache never drifts, the anomaly check never fires, and on-hand always means what everyone assumes.

This rule is also why opening balances go through the ledger rather than a field, as covered in how opening balances seed a new install. Seeding a product by posting an opening balance keeps the cache and the ledger equal from the first entry; typing a starting quantity into the cache would start the product in drift.

Why this matters downstream

The cache-versus-ledger relationship is not an implementation detail a planner can ignore, because everything downstream trusts the authoritative number. The scheduling engine nets demand against the ledger sum, not the cache, so a stale cache never causes an over-consume or an under-consume in the actual plan. The projection opens each window from the ledger sum. Available-to-promise promises forward from the ledger sum. The cache is purely for display speed; the decisions run on the truth.

That separation is deliberate protection. Even if a cache somehow drifted, the plan itself stays correct because it reads the ledger, and the anomaly check surfaces the display discrepancy so you can reconcile it. The result is that the number you glance at is fast, the number the engine acts on is authoritative, and the two are kept honest by a check rather than by hope. It is a quiet but real part of what makes EDGEBIC's inventory management for manufacturers trustworthy, and it is the same reason sound material requirements planning insists that on-hand be a computed record, not an editable guess.

See how the ledger drives every planning decision in the EDGEBIC platform overview, or contact US for a demo.