What does AI do in store replenishment? Automatic dispatch proposals, constraints and explainable decisions

From forecast to dispatch quantity: what are the steps of the calculation?

The dispatch quantity is not the forecast itself; it is derived from the forecast in four steps. First the target stock is found: what the branch will sell until the next delivery arrives plus the safety stock held against unexpected demand. Then the branch's stock on hand and in transit is deducted; what remains is the net requirement. The net requirement is rounded to the case pack, because the warehouse does not open cases to dispatch. Finally the result is capped by the branch's free shelf and backroom capacity: goods that fit neither on the shelf nor in the backroom wait in the aisle or go back to the warehouse.

The cover period comes from the delivery schedule: the number of days until the next delivery, plus the lead time. How safety stock is calculated is covered in the safety stock guide, and how delivery frequency affects store stock and shrinkage in the store delivery schedule guide. What matters here is that each of the four steps is a rule, and the rule works the same way for every line.

In the example below, 1 litre UHT milk is dispatched from a central warehouse to four branches. A case holds 12 units and the cover period is 4 days. The branches sit in different clusters by size and customer profile; B3 is a small neighbourhood branch with a narrow milk shelf.

Target stock

Daily forecast × Cover period + Safety stock

Net requirement

max(0, Target stock − Stock on hand − Stock in transit)

Case pack rounding

Round(Net requirement ÷ Units per case) × Units per caseRounded to the nearest whole case.

Capacity cap

Dispatch ≤ Shelf and backroom capacity − Stock on hand − Stock in transitThe cap is rounded down to a whole case.

If warehouse stock runs short, how is limited stock rationed?

In a promotion week, when a supplier is late or ahead of a religious holiday, warehouse stock does not cover the total of branch requirements. The rationing rule is then the most contested decision on the dispatch list, because every case given to one branch has been taken from another. If the rule is not written in advance, rationing is left to the instinct of whoever prepares the list that day, and the same situation gives two different results in two different weeks.

The common rules are in the table below. Equal allocation gives every branch the same quantity; stock piles up in the small branch and the shelf empties in the large one. Allocation in proportion to need cuts every branch's requirement by the same ratio; it looks fair but cuts the stock that will be sold and the safety stock by the same ratio. Priority allocation first covers what each branch will sell until the next delivery, the no-stockout share; safety stock is topped up only after that, starting from the highest-demand branch. Safety stock is not used every day, the selling share is; this is why priority allocation is usually the one that cuts lost sales most.

The cost of an empty shelf is the reason for this order. According to the global study released by GMA, FMI and CIES in 2002, of shoppers who meet an out-of-stock, 31 per cent go to another store and 9 per cent buy nothing; for the store these two shares are certain losses. When the shelf empties in a high-demand branch, the same loss touches more customers.

No-stockout share

max(0, Daily forecast × Cover period − Stock on hand − Stock in transit)Rounded to the case pack and capped by capacity.

Remainder to ration

Warehouse stock − Σ No-stockout share

If warehouse stock does not even cover the first step, selling shares are cut as well. The rule for that case must also be written down (for example, cutting in proportion to demand), and the list of branches cut goes to the buying team: the gap is not a rationing problem but a supply problem.

Branch clustering and first allocation for new products and new branches

Clustering similar branches instead of treating each one on its own does two jobs. First, the more stable sales pattern of the cluster is used instead of one branch's noisy data. Second, where there is no history (a new product, a new branch) there is a reference to rely on. In the M5 competition almost all of the best methods learned from the series together, and the organisers wrote that this eased the problem of series with a short history. Clustering criteria should reflect what a branch sells and to whom: turnover, floor area, customer profile and sales curve.

First allocation is the first shipment to branches of a product that has no sales history yet, and it is the hardest dispatch decision because there is no data to rely on. In the forecasting literature the answer to this problem is forecasting by analogy: Forecasting: Principles and Practice recommends starting from similar cases where there is no history, and relying on several analogies rather than one, because a single analogy can create bias. In a grocery chain the analogy is the first weeks of products in the same category, at a similar price and size, in the same branch cluster.

For a new branch the situation is reversed: the products have a history, the branch does not. A new branch is started from the first weeks of branches in the same cluster, scaled by floor area; as actual sales come in, the branch's own data replaces the cluster assumption. For both new products and new branches the error of the first allocation is corrected by transfer; this is why first allocation is deliberately cautious and the remaining stock is held in the warehouse.

First allocation (per branch)

Cluster average weekly sales of similar products × Branch coefficient × First period (weeks) + Shelf display quantityThe result is rounded to the case pack and capped by shelf capacity.

Branch coefficient

Branch's category sales ÷ Cluster average category sales

Why should quantities be calculated by defined formulas rather than a black-box model?

In systems where a model produces the dispatch quantity directly, the list arrives as a result: asked why 60 units went to B3, the answer is 'that is what the model calculated'. In a list calculated by defined formulas the answer is a single line: target 106, on hand 10, free capacity 62, binding constraint capacity. In a grocery chain this difference matters for four reasons.

The first is auditability. When a promotion ends, whether leftover stock came from the proposal, from an override or from a wrong forecast can only be found if every line's calculation can be traced. The second is reproducibility: a calculation run with the same parameters gives the same list; when a parameter changes, for example the safety stock coefficient, it is known why the list changed. The third is correctability: if the error is in a rule, the rule is fixed and the fix applies in every branch at once; in a black box the same error lasts until the next training run and nobody knows where it came from.

The fourth is the planner's trust. An experimental study published in Management Science in 2018 found that people often stop using algorithms after learning they are imperfect, but are considerably more willing to use an imperfect algorithm when they can modify its forecast, even slightly. In dispatch the parallel is clear: a planner who cannot see or change the calculation of a list puts it aside at the first error and goes back to the spreadsheet. This is why AI creates the most value when it is placed not in the calculation of the quantity but in the explanation of the list.

A defined formula does not mean the forecast has to be simple too. The forecast can come from a statistical model or from machine learning; the line is drawn between forecast and decision. The forecast is an input and its accuracy is measured; the dispatch quantity is a decision and its calculation is open.

What does an AI explanation layer add?

A defined formula keeps every line's calculation open but does not make a list of thousands of lines readable. On a day when 40 branches receive dispatches from 6,000 products, the proposal list runs to tens of thousands of lines and the planner has to know which ones to look at. This is where the explanation layer's job begins: it reads the list, groups lines by their constraints and deviations and summarises them in natural language.

A good explanation answers three questions: which branch received less than it needed and why, which constraint was binding, and which lines should be checked. For the four-branch example in the earlier sections, on the day warehouse stock was short, the summary produced by such a layer could look like the one below.

The limits of the explanation layer must be written down too. The explanation uses only information that exists in the calculation and in past lists; it does not invent a reason that is not in the list, does not change a quantity and does not approve. Every figure in the explanation must be traceable to a line of the list; a sentence that cannot be traced is not an explanation but a guess. This separation makes sure that where AI can make a mistake, the mistake lands not on a dispatched case but on a sentence that is read and checked.

• The reason for the gap between requirement and proposal, by branch
• The binding constraint and how many lines the same constraint affects
• Lines left without a buffer, lines repeatedly hitting the same constraint and lines whose forecast changed sharply
• Why the list changed compared with the previous run: which parameter, which data

Approval flow and override log: how is deviation from the proposal measured?

The proposal list should not go straight to dispatch. The planner approves, rejects or changes the quantity of each line; the approved list becomes a dispatch order in the ERP. A change is often legitimate, because the planner may know something the calculation does not: a refurbishment at the branch, a local event, a faulty chiller. What matters is that the change is recorded with its reason: who changed which line, when, to what value and why.

The log does two jobs. The first is accountability: when a promotion ends, it shows whether leftover stock came from the proposal or from an override. The second is learning. According to the study published in the International Journal of Forecasting in 2009, which examined more than 60,000 forecasts at four supply chain companies, large adjustments generally improved accuracy while small adjustments often damaged it; upward adjustments were much less likely to improve accuracy than downward ones. Forecasting: Principles and Practice also recommends documenting every adjustment with its reason and keeping the results for feedback. On a dispatch list the same pattern shows up as the 'one more case, just in case' adjustment; with a log, it can be measured which kind of override improves the outcome.

Override rate

Changed proposal lines ÷ Total proposal lines × 100

Hit rate of upward overrides

Lines whose extra quantity sold before the next delivery ÷ Lines changed upward × 100

Cost of downward overrides

Lines that ran out of stock before the next delivery ÷ Lines changed downward × 100

The planner's change alters a line, not the list. The calculation itself (safety stock coefficient, cover period, capacity definition) is changed only by an authorised person, with a date and a record; otherwise the principle that the same inputs give the same list breaks down silently.

How do you judge an AI allocation claim?

The phrase 'AI-powered automatic dispatch' says nothing on its own. The value of the claim is decided by the questions asked in the demo with your own data. The questions below apply to any system, and every answer should be shown not with ready-made demo data but with your own branch, product and constraint structure.

In Mindpera this is Mind Send's job. First allocation, warehouse-to-branch replenishment and inter-branch transfer proposals are generated automatically on every run, by product and branch, from the demand forecast, current stock and constraints (branch shelf and backroom capacity, minimum shipment pack, warehouse stock); every line carries the constraint that affected it. Branches are clustered by turnover, floor area, customer profile and sales curve; for a new product or new branch the first dispatch quantity is calculated from the branch cluster, similar-product history and capacity. Ideal stock, unmet demand and dispatch quantity are calculated by defined formulas, and an allocation run with the same parameters produces the same list. The AI explains the list: it summarises why a branch received less, which constraint is binding and which lines need attention; the model does not set the quantity. The planner approves, rejects or edits line by line; every decision is recorded with who, when and for what reason, and the approved list becomes an ERP dispatch order.

1. Who sets the quantity?Is the dispatch quantity calculated by a defined formula, or is it the direct output of a model? If it is a formula, ask for it in writing; if it is a model, ask how the quantity of a single line is explained.
2. Do the same inputs give the same list?Have the calculation run twice with the same parameters. If the two lists differ, auditing and arguments start again every week.
3. Which constraint affected the line?For a line you pick at random, have them show which of warehouse stock, shelf and backroom capacity, case pack and safety stock was binding.
4. What is the rule when the warehouse runs short?Recreate a day of limited stock with your own data; ask whether the rationing rule is written down and which branch received less and why.
5. How do new products and new branches start?Ask which similar products, which branch cluster and which capacity definition the first allocation rests on.
6. How is forecast accuracy measured?Are forecast, actual and deviation reported by product and branch; is the model compared with the naive forecast; are stockout days flagged separately?
7. Where is the planner's change recorded?Is there a line-level log of approvals, rejections and changes, a reason code and a report measuring the outcome of changes?
8. Can the AI explanation be verified?Check whether every figure in the explanation traces to a line of the list; ask whether the explanation layer can change a quantity.

Our team does the installation: stock balances, sales movements, product hierarchy and case definitions from the ERP, together with branch cluster and shelf capacity definitions, are brought into one model during installation. The rationing rule and safety stock policy remain your dispatch team's decision.