Management games · Inventory timing
Inventory in management games: will stock arrive before you need it?
Your stock screen shows a delivery on its way, yet tomorrow’s jobs still lack materials. Count what can be used at each deadline before placing another order.
The short answer: put receipts and committed demand in time order. Start with usable stock physically present, add only deliveries that have arrived, and subtract each commitment once when it needs stock. An accepted order arriving after a deadline cannot cover that deadline.
The example below is an original planning exercise with invented units and rules. It does not describe Inquory World mechanics or report a gameplay test. Its demand is fixed and known; it is not a forecast or an optimal ordering policy.
A positive total can hide tomorrow’s shortage
At Monday’s close, a fictional workshop has 12 usable units on hand. A supplier has accepted an order for 20 more, arriving Wednesday at opening. Already accepted jobs require 8 units Tuesday at opening and 7 Tuesday at noon. Those are the only commitments. No further demand, damage, substitutions, transfers or production occur.
Every unit is identical. A receipt becomes usable immediately on arrival; where receipt and demand share a timestamp, receive first. Jobs consume their required materials immediately. Unfilled demand remains as backlog and is filled at the next receipt. These are explicit rules for our example, not defaults to assume in your game.
The aggregate calculation looks comfortable: 12 on hand + 20 incoming − 15 committed = 17 units after all commitments are eventually filled. But the incoming 20 arrive Wednesday. They cannot help either Tuesday deadline. After the first job consumes 8, only 4 remain for a noon requirement of 7.
Follow each event without subtracting commitments twice
This ledger starts with physical on-hand units. It subtracts demand only at its need time. The 15 committed units are not also deducted from the opening 12; doing both would count the same jobs twice. Backlog is tracked separately and physical stock never falls below zero.
| Event | Receipt / new need | Units used now | Usable stock after | Unfilled backlog after |
|---|---|---|---|---|
| Monday close | Opening stock: 12 | 0 | 12 | 0 |
| Tuesday opening | Need 8 | 8 | 4 | 0 |
| Tuesday noon | Need 7 | 4 | 0 | 3 |
| Wednesday opening | Receive 20; fill old backlog | 3 | 17 | 0 |
| Wednesday close | No further events | 0 | 17 | 0 |
On a phone, focus the table and scroll horizontally to read the backlog column. Tuesday noon serves 4 of the 7 units needed; 3 are late. Across both Tuesday jobs, 12 of 15 units are supplied on time. Wednesday clears that backlog without creating a second new demand for those same 3 units.
If the game loses unmet sales instead of backordering them, remove the lost 3 from future commitments. With no other demand, Wednesday would then end with 20 units, not 17, and the earlier sale would remain lost. Check cancellation, partial-fill and deadline-penalty rules before interpreting a negative stock display.
Check what can still change before the deadline
Ordering another normal Wednesday delivery cannot repair Tuesday’s gap. Look for a permitted earlier transfer, an actually earlier supplier arrival, or a change to the job’s timing. Verify the new arrival precedes consumption, and whether amendments are still allowed. If no feasible change exists, record the shortfall and its consequence instead of treating an unconfirmed rush order as available stock.
A buffer could cover a future gap, but this example does not establish its size. Unknown demand, variable delivery times, quality restrictions and storage limits change the calculation. Keep tentative orders separate from accepted receipts and distinguish accepted delivery estimates from actual arrivals. If materials are present but work still waits, inspect production bottlenecks and worker eligibility.
Copy an arrival-date check
Use paper or an existing notes app; this page collects no entries. Make one ledger per material and avoid adding incompatible qualities or items together.
- Starting point: game/version/mode ___; exact time ___; usable on hand ___; does the displayed balance already exclude reservations? ___
- Incoming: order ID ___; accepted quantity ___; usable arrival time ___; tentative or confirmed? ___; remaining amendment limits ___
- Commitments: job ID ___; quantity ___; need time ___; already counted elsewhere? ___; backlog or lost demand if missed? ___
- Event check: receipt/consumption order ___; first uncovered deadline ___; units late ___; closing stock and backlog ___
- Proposed change: earlier usable arrival or changed commitment ___; verified feasibility ___; remaining uncovered need ___
Then check payment timing and storage separately. This units-only ledger proves neither affordability nor available warehouse space. Use the cash-flow example to inspect payments; use the expansion comparison before buying capacity.
What the primary documentation supports
Paul A. Jensen’s University of Texas inventory-game explanation, copyright 2004, describes weekly order decisions and backordered shortages. Its worked timing is explicit: an order at the end of week 1 with a three-week lead time arrives at the beginning of week 5, after complete weeks 2, 3 and 4. That dated teaching model illustrates why a lead-time label needs an event calendar; its rules are not universal.
Zensimu’s MRP Game documentation, updated February 3, 2026, describes weekly cycles, supply lead times, frozen periods restricting order updates, and scenarios introducing batch sizes and minimum order quantities. These are developer-described planning constraints. They do not establish our invented delivery schedule, a tested result, or the right stock target for another game.
Sources and method
Primary documentation checked November 4, 2026, Toronto time. The timeline, arithmetic and arrival-date check are original editorial work. No game was installed or tested; no player outcome was measured. See our editorial method and corrections policy.