Quantity on hand is the current physical stock figure for a product: how many units are actually present, before any deduction for what has been promised or planned. In EDGEBIC it is held on the product as a cached total, but the authority behind it is the inventory ledger, which means you never type it and it never drifts from the movements that produced it.
This entry defines quantity on hand and shows how it reads inside EDGEBIC by User Solutions. For the wider index of terms, see the manufacturing glossary; for the record that owns it, see EDGEBIC inventory ledger explained; and for the sellable position derived from it, see what is available to promise.
How It Works
There are two ways a system can hold a stock figure. It can store the number and let people edit it, or it can store the movements and derive the number. The second is slower to read and far more honest, and it is the model here.
Every stock movement, whether a receipt from a completed build, an issue consumed by a job, a manual adjustment after a count, or an opening balance for a new product, is appended to the ledger as its own dated, typed entry. The ledger is append-only: entries are added, never edited away. The true on-hand balance for a product is the signed sum of its entries.
Summing an entire ledger on every screen refresh would be wasteful, so the product also carries a cached total. The rule that keeps the cache honest is that only the posting path may write it. When a movement posts, one transaction reads the current ledger balance, appends the new entry, recomputes the total, and writes it back. Either the entry and the new total both commit or neither does, so the cache cannot record a movement the ledger does not have, or miss one it does.
That is why the on-hand figure is not editable on the product form. Editing it would mean asserting a number with no movement behind it, which breaks the reconstruction. The intended way to change stock is always to post a movement, including when the change is a correction.
A Concrete Example
Think of it the way you would think of a bank balance. The balance on the screen is convenient, but it is not the record. The record is the list of transactions, and the balance is what they add up to. Nobody expects to be able to type a new balance into their account; they expect to see a deposit or a withdrawal that explains the change.
A stocked part starts life with an opening balance of 40 units, posted as an entry so even the starting point has a reason. A build-to-stock job for 200 completes, and a receipt for 200 posts. The ledger now sums to 240, and the cached total reads 240 in the same commit.
A customer job then consumes 60 from stock instead of triggering a new build, and an issue for 60 posts. The sum is 180, and the total agrees.
A month later a physical count finds 168. The gap is not repaired by typing 168 over the total. An adjustment for minus 12 is posted with a reason naming the count. The ledger now sums to 168, the cached total follows, and the record shows what everyone needs to know: not only that stock is 168, but that a count on that date found 12 units missing.
How EDGEBIC Uses It
In EDGEBIC, quantity on hand lives on the product record and is maintained exclusively by the movement-posting path. That path opens a transaction, reads the current ledger balance for the product, appends the new entry, recomputes the on-hand total, saves both, and only then announces the change to the rest of the application. No other code writes the figure.
The product form deliberately offers no field for it. Stock is changed through inventory transactions so the audit trail stays intact, and on installations that do not use the inventory module, on-hand tracking is simply not used at all rather than half maintained.
Two automatic movements are worth knowing. When a build-to-stock job completes and the product is marked as stocked, a receipt posts for the built quantity in the same transaction as the status change. And when a job's demand is met from existing stock rather than by building, an issue posts to draw the units down. Both leave a ledger entry, so both are explainable later.
On hand is also the anchor for forward planning. The available-to-promise calculation deliberately starts from physical stock as it stands now rather than from a historical opening balance, because a promise has to reflect the shelf today.
For the entries behind the number, see what is an inventory ledger and what is an inventory adjustment. For where the figure begins, see what is an opening balance in inventory, and for the valuation that rides alongside it, see moving average cost.
Quantity on hand is the current physical stock figure for a product: how many units are sitting on the shelf right now, before any allowance for what is promised or planned. It is the starting point for every forward projection and the number a planner glances at to answer whether an order can ship today. In EDGEBIC it is stored on the product as a cached total, but it is owned and maintained by the inventory ledger rather than typed by a person.
Because a stock figure with no explanation behind it cannot be trusted or audited. Every change to on hand comes from a posted movement, so each unit that arrives or leaves has a dated, typed entry saying why. Typing over the total would break that chain and leave a number nobody could reconstruct. To correct a count, post an adjustment instead: the correction is recorded as a movement, the total updates from it, and the reason for the change survives.
No. On hand is what is physically present with no commitments deducted. Available to promise asks a harder question: how much can still be sold without breaking promises already made, so it nets existing firm demand against on hand and future supply. A product can have healthy stock on hand and nothing available to promise, because every unit is already spoken for. Read on hand as the physical fact and available to promise as the sellable position.
Post an inventory adjustment for the difference rather than trying to overwrite the total. Enter the movement as plus or minus 12 with a reason that names the count, and the on-hand figure recalculates from the ledger to match reality. That way the correction is a first-class event in the record, so anyone reviewing the product later sees not just the current number but the fact that a count found a discrepancy on that date and by how much. Repeated adjustments in the same direction are themselves useful information, usually pointing at a process that is not recording issues or scrap consistently. Chasing the total directly would fix the display and hide the pattern.
Start with whether the job was actually a build-to-stock order and whether the product is marked as stocked, because the automatic receipt on completion only fires when both are true. A job built against a specific customer order is not supposed to add to the shelf, so no receipt is posted, and the on-hand figure is right to stay put. If the order really was building into inventory, check the ledger for the product around the completion date: a receipt entry should be there, and if it is, the total will agree with it. If the ledger shows the receipt but the total does not reflect it, that is a genuine drift worth raising, because the total is meant to be recomputed from the ledger inside the same transaction that posts the entry.
Expert Q&A: Deep Dive
Q: A physical count disagrees with the on-hand figure by 12 units. What is the right way to fix it?
A: Post an inventory adjustment for the difference rather than trying to overwrite the total. Enter the movement as plus or minus 12 with a reason that names the count, and the on-hand figure recalculates from the ledger to match reality. That way the correction is a first-class event in the record, so anyone reviewing the product later sees not just the current number but the fact that a count found a discrepancy on that date and by how much. Repeated adjustments in the same direction are themselves useful information, usually pointing at a process that is not recording issues or scrap consistently. Chasing the total directly would fix the display and hide the pattern.
Q: On hand looks stale after a job completed. Where should I look?
A: Start with whether the job was actually a build-to-stock order and whether the product is marked as stocked, because the automatic receipt on completion only fires when both are true. A job built against a specific customer order is not supposed to add to the shelf, so no receipt is posted, and the on-hand figure is right to stay put. If the order really was building into inventory, check the ledger for the product around the completion date: a receipt entry should be there, and if it is, the total will agree with it. If the ledger shows the receipt but the total does not reflect it, that is a genuine drift worth raising, because the total is meant to be recomputed from the ledger inside the same transaction that posts the entry.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
The EDGEBIC Scheduling Glossary Index
A themed index to the EDGEBIC glossary: scheduling engine, capacity and calendars, materials and planning, shop floor, reporting, quoting, and data import terms, defined in plain language.
What Is the Critical Chain in Manufacturing Scheduling?
The critical chain is the longest dependent path through a plan once shared machine contention is counted, not just step precedence. Here is how it differs from the critical path.
What Does Finite Capacity Mean in EDGEBIC?
Finite capacity means the scheduler refuses to book more hours on a machine than that machine actually has. See exactly how EDGEBIC enforces it, day by day and shift by shift.