Allocate scarce stock and publish a revised dispatch plan

Make the ordering rule and available quantity explicit before allocating units.

1. Establish the queue and the stock boundary

An allocation plan answers which requests can be served from a stated stock balance at a stated cutoff. Start with the boundary: the SKU, usable quantity and orders included in the run. Stock for another SKU is not automatically a substitute. A receipt after the cutoff cannot silently be treated as stock that was available before it.

Ordering is a policy decision that this exercise supplies. A lower priority number comes first. Within a priority, the earlier promised time comes first. An exact tie is broken by the alphabetically earlier order ID. Apply the whole rule rather than sorting only by time or selecting the largest order. A clear tie-breaker makes the same inputs produce the same allocation.

For each request, allocate the smaller of its requested units and the remaining stock. Subtract that allocation immediately, then move to the next request. This permits a partial fill when the next request exceeds the balance. Keep requested, allocated and short quantities separate: they answer demand, dispatch and follow-up questions respectively.

A balance check catches mistakes that a plausible-looking table can hide. Allocations plus unused stock must equal the starting balance. Allocations plus shortages must equal total requests. A zero allocation is still a decision that must appear in the plan. Leaving a field blank makes it unclear whether the line was reviewed at all.

Try it yourself

There are 9 usable X units. Apply priority, then promised time, then order ID. These requests are deliberately shown out of queue order.

One-SKU warm-up

Numbers use the units in each label. Blank answers are incomplete. ID lists can use commas, spaces or semicolons.

Apply the idea

If a colleague wants promised time to override priority, identify the policy change they are requesting rather than quietly changing the sort order.

Keep separate SKU balances and account for every unallocated unit.

2. Reconcile the dispatch and the exception list

The full case uses two SKUs. You can process their queues separately or process the whole ordered table while maintaining one balance per SKU. What matters is that an allocation from A never reduces B and that no balance becomes negative. Write down the opening balance before filling the first row.

Once the allocation is complete, create an exception list for every line receiving less than requested. Include partial fills and zero fills. A list containing only orders with zero allocation misses customers who will receive something but not everything. The quantity short is requested minus allocated, not the remaining stock balance.

Reconcile by SKU before combining totals. The A lines should use exactly the available A stock in this fixture; the B lines should do the same. Then reconcile total requests against total allocations and total shortage. This second calculation gives you an independent check on the line-level work rather than merely reading the same answers again.

The dispatch table and customer-support note have different audiences. The warehouse needs explicit quantities by order and SKU. Customer support needs the exception IDs, shortage quantities and the information still required before promising recovery. The fixture provides no receipt date, so do not make one up. Save the table and the explanatory note together to keep the decision traceable.

Try it yourself

Work through the published six-order case. Preserve explicit zeros and use the supplied balances and priority rule.

Available stock

Dispatch requests

Numbers use the units in each label. Blank answers are incomplete. ID lists can use commas, spaces or semicolons.

Apply the idea

Compare the sum of the three shortage lines with total requests minus total stock. If they differ, locate the omitted or overstated line before sending the plan.

Re-run a changed queue and label the resulting version before anyone acts on it.

3. Revise a draft without hiding its changed assumptions

A correct allocation is tied to its inputs and cutoff. When the input changes, first ask whether the plan is still a draft or has already been released to the warehouse. A new calculation cannot automatically revoke instructions that people may have acted on. The scenario below explicitly says the plan has not been released, so it permits a fresh allocation.

For this revision, only SKU B changes. A receipt of three usable B units is confirmed before the cutoff, raising its balance from 13 to 16. A new priority-1 request L7 for four B units, promised at 09:00, is also confirmed before the cutoff. The previous B requests remain. Re-sort the entire B queue; do not simply give the new stock to the last order from the old plan.

The priority and time rules put L7 ahead of L2, then L5 and L6. Recompute allocations from the new opening balance. The extra receipt does not guarantee that every old order receives more: the added higher-priority demand also consumes stock. A comparison should explain which allocation changed and why, rather than celebrating the receipt alone.

Version the result as a revised draft, state which inputs changed and reconcile its new totals. If the old version had already been sent, the next action would be to confirm execution status and coordinate a revision, not silently overwrite it. Your final portfolio saves both the baseline exercise and this independent revision so the difference remains inspectable.

Try it yourself

The baseline plan is still an unreleased draft. Re-run SKU B with 16 units and the four rows below. SKU A is unchanged and is outside this revision.

Revised B queue inputs

Numbers use the units in each label. Blank answers are incomplete. ID lists can use commas, spaces or semicolons.

Apply the idea

If you learn that baseline picking has started, name the operational confirmation needed before treating this recalculated draft as the warehouse instruction.