Inventory management system requirements should explain what each quantity means, which events change it and who may authorize those events. “Track stock in real time” leaves important questions unanswered: stock where, in which unit, available for what action, and as of when?
This guide follows a fictional distributor's BOLT-M8 stock in Warehouse A, measured in each. It provides a deliberately small model and proposed acceptance checks, not an inventory implementation or a customer result. Use the inventory requirements workbook (Markdown) to adapt the definitions and record evidence.
Start with ownership, units and locations
Assign an owner to the item catalogue and its stable identifiers. Decide whether quantities can be fractional and how purchasing packs convert into the stock unit. In this example, quantities are whole individual bolts; a supplier's box count cannot be posted directly as an each count.
Define the location boundary before adding totals. Warehouse A's available stock cannot silently satisfy a dispatch from Warehouse B. If bins, lots, serial numbers or expiry dates affect eligibility, include those dimensions in the requirements and acceptance data. This worked ledger has one warehouse and no transfers.
Name the authority for each record. Purchasing owns the supplier order; warehouse operators record actual receipts and dispatches; inventory applies accepted stock movements; sales owns customer commitments. Finance retains its own invoice and payment process. These are proposed responsibilities to agree, as described in the ERP modules and data ownership guide.
Give each quantity one controlled update path, even if several screens display it. For every stock view, show its item, location, unit and last accepted update time. State how delayed imports and pending movements are exposed rather than presenting stale information as current.
Define availability before calculating it
For this example, on-hand means the recorded physical quantity, including blocked or quarantined units. Reserved means usable physical stock committed to orders. Blocked means physically present stock that cannot currently be reserved or dispatched. Reserved and blocked are disjoint subsets of on-hand: the same unit cannot occupy both.
Our rule is available now = on-hand − reserved − blocked. It excludes incoming purchase orders, future receipts and backorders. It is a defined physical-stock rule for this example, not a universal available-to-promise formula. Moving reserved stock into quarantine would require an explicit decision about its existing commitment.
Product fields can mean something different. Microsoft's Dynamics 365 on-hand documentation distinguishes available physical stock from quantities that include ordered supply; some reservation settings can include expected receipts. Compare the definitions and dimensions, not just a field named “available.”
Walk through the events and their balances
The opening 20 reserved units belong to other orders and remain reserved throughout. Sales order SO-104 requests 12 units. Each row below is the state after the named event has been accepted; all quantities are each for BOLT-M8 in Warehouse A.
| Event | On-hand | Reserved | Blocked | Available now |
|---|---|---|---|---|
| Opening balance | 100 | 20 | 5 | 75 |
| Receive 30 usable units | 130 | 20 | 5 | 105 |
| Reserve 12 for SO-104 | 130 | 32 | 5 | 93 |
| Dispatch 8 against that reservation | 122 | 24 | 5 | 93 |
| Cancel and release SO-104's remaining 4 | 122 | 20 | 5 | 97 |
| Receive 3 returned units into quarantine | 125 | 20 | 8 | 97 |
| Release 2 units after inspection | 125 | 20 | 6 | 99 |
| Approve adjustment for 1 missing usable unit | 124 | 20 | 6 | 98 |
Reservation changes the commitment, not the physical quantity. Dispatch reduces both on-hand and SO-104's reservation by eight, leaving four reserved for that order. Releasing those four does not create a receipt. Microsoft's reservation documentation likewise distinguishes reserving inventory from withdrawing it, though the article's physical-only policy is our own choice.
The three returned units increase on-hand and blocked equally, so availability stays at 97. Inspection releases two into usable stock without recording another receipt. One of the three remains quarantined alongside the opening five blocked units. Microsoft's inventory status documentation provides a product-specific example of blocked items remaining physical inventory while their use is restricted.
Keep the return linked to the original eight-unit dispatch. Do not rewrite that shipment as five units. Any refund or credit is a separate financial decision; the stock event alone does not authorize it.
Require an event record that explains the change
Each accepted event needs a stable identifier, event type, source system, actor, occurrence time, recording time and business reference. Include the SKU, location, unit and quantity, plus the relevant order, receipt or inspection reference. Preserve the accepted outcome so an operator can connect a displayed balance to its movements.
Define the identifier's scope, such as source system plus event ID. A retry must retain that identity and the same business payload. Specify which fields are compared; a transport retry timestamp should not silently become a different stock movement.
Record corrections as attributable actions linked to the original event, with a reason and approval where required. Keep rejected and pending events visible without counting them as accepted movements. After an uncertain integration response, look up or retry the original event identity instead of creating a fresh receipt blindly.
Turn exceptions into acceptance checks
The following are proposed checks for a configured product or custom change. The sequential ledger demonstrates arithmetic only; it does not establish concurrency safety, permissions or production capacity.
| Case | Required observation |
|---|---|
| Same receipt ID, same payload | Repeating the 30-unit receipt returns its recorded outcome; on-hand increases only once. |
| Same receipt ID, different payload | A changed quantity, SKU or location is rejected as a conflict; no second movement or silent overwrite occurs. |
| Competing reservations | With 10 available units, simultaneous requests for 7 and 6 use an all-or-nothing, no-backorder policy. At most one is accepted; availability never becomes negative. The availability check and reservation update must be atomic. |
| Wrong or excessive dispatch | Reject a shipment against another order, SKU or location, or above that reservation's remaining quantity. Leave stock and reservations unchanged. |
| Return awaiting inspection | Three returned units enter quarantine. Attempting to reserve or dispatch them is rejected until an authorized release. |
| Unauthorized action | A user without permission for the action and Warehouse A cannot adjust stock or release quarantine. Rejected attempts do not alter balances. |
| Partial physical receipt | Record the actual received quantity. Show the supplier order's open remainder separately; do not count expected units as on-hand. |
Assign permissions by action and scope: receiving, reserving, dispatching, inspection release and adjustment approval need explicit owners. Decide whether the person proposing an adjustment may approve it. Include removed permissions in the acceptance plan; hiding a button alone is not the required authorization boundary.
Reconcile quantities and their references
At the end of the example, reconcile each balance independently:
- On-hand: 100 + 30 − 8 + 3 − 1 = 124.
- Reserved: 20 + 12 − 8 − 4 = 20.
- Blocked: 5 + 3 − 2 = 6.
- Available now: 124 − 20 − 6 = 98.
A matching total is necessary but insufficient: two incorrect movements can offset each other. Check source references, accepted event identities and SO-104's remaining reservation, which is zero. The surviving 20 reserved units must still be attributable to their unrelated orders.
For a physical count, agree the location, unit and cutoff, and how movements during counting are handled. The final adjustment here records one missing usable, unreserved unit after approval. It does not remove a reservation or a blocked unit. An unexplained difference needs investigation before someone overwrites the balance.
Give the first release a reviewable boundary
Use the workbook to name the requirement owner, expected result, evidence and unresolved decisions. Start acceptance with a bounded set of items, locations, users and interfaces. Agree measurable freshness and operating-volume requirements for that scope; this small ledger supplies no performance target or load evidence.
The business and functional requirements guide connects operational goals to these checks. The cloud ERP guide helps decide whether the required behavior belongs in configuration, integration or custom work.
Bring the definitions, acceptance cases and unresolved ownership questions to a software development discussion. They give the team a concrete boundary to estimate and demonstrate before expanding the system.