On hand
What is physically recorded at the location now?
An inventory system becomes unreliable when the current quantity is simply a number that users can overwrite. A trustworthy system explains every change through a receipt, issue, transfer, return, reservation, or adjustment.
PHPRunner can build the operational pages and reports, but the essential design choice is to record stock movements as facts and derive the available balance from them.
Store inventory movements, not unexplained balances. Each movement should identify the item, location, quantity, direction, time, user, and business reason. Calculate on-hand and available quantities from that history, and treat corrections as new adjustments rather than rewriting the past.
A product table describes the item. A location table describes where stock can exist. A movement table records what changed. Orders, shipments, transfers, and adjustments provide the business references. This model makes today’s balance traceable and lets reports reconstruct inventory at an earlier date.
What is physically recorded at the location now?
What quantity is committed but has not yet left?
What remains after valid reservations and other commitments?
Do not use one ambiguous “quantity” field for all three. Define the calculation and the exact moment each movement or reservation affects it.
Two users may attempt to reserve or issue the same stock at the same time. Recheck availability when saving and perform dependent updates inside a database transaction. Permissions should also distinguish routine receipts and issues from high-impact adjustments or backdated corrections.
PHPRunner can create item, location, movement, and transaction pages from the inventory database, then add role-based access, barcode-oriented entry, dashboards, low-stock alerts, and custom validation. Events and SQL can enforce movement rules and present calculated stock without making the balance an uncontrolled editable field.