How a planning run works
You don't need to know this to use the plan. You do need it the first time the plan tells you something that looks wrong — a start date in the past, an order larger than you asked for, a part that appears twice. Each of those is the engine working correctly, and this page is why.
What a run reads
Three sources of demand, and you choose which ones count:
- Customer orders — open sales-order lines inside the horizon.
- A master production schedule — what you intend to build regardless of whether anyone has ordered it yet. See Build a master production schedule.
- A forecast — included only when you tick Include forecast demand when starting the run.
Against that it counts everything already coming toward you as supply: stock on hand, open purchase orders, open manufacturing orders, in-transit warehouse transfers, and any draft purchase orders a previous run created. Firm planned orders from the previous run count too — that's what stops two consecutive runs both planning the same shortage.
The order parts are planned in
A part can appear at several depths in your product structures. A screw might be a direct component of a finished item and also sit inside a sub-assembly of that same item. Planning it twice would order it twice.
So before netting anything, the run works out how deep each part can appear anywhere in your recipes, and plans strictly from the top down. Every part is planned once, at the deepest level it occurs, by which point every demand from every level above it has arrived. This is why a component's suggested order sometimes only makes sense once you look at the parent that caused it.
Netting, one item at a time
For each item at each warehouse, across each period of the horizon:
| The plan tracks | Meaning |
|---|---|
| Gross requirements | Everything wanted in this period, from all demand sources |
| Scheduled receipts | What's already arriving in this period, from orders that exist |
| Projected available | What's left on the shelf at the end of the period |
| Net requirements | What's still short, after the two above are taken into account |
| Planned order receipts | What the engine proposes should arrive in this period |
| Planned order releases | When you'd have to start it for that arrival to happen |
Projected available carries forward from one period to the next, so a surplus early in the horizon is used up by demand later rather than being ignored.
Safety stock is a floor, not a buffer
Net requirements are raised when projected available drops below a floor — and that floor defaults to zero unless you set Safety Stock on the item's policy.
This matters because safety stock isn't stock the plan is willing to consume. It's a level the plan refuses to go below: the moment projected available would fall under it, the shortfall is planned. If you set safety stock to 100, the plan works to keep 100 on the shelf, not to run down to zero with 100 spare.
Under Reorder Point or Min / Max planning the floor becomes the Reorder Point instead, and the plan replenishes up to the Reorder Up To Level rather than back to the floor.
Sizing the order
A net requirement of 240 does not automatically mean an order for 240. The item's Lot Sizing Rule decides — order exactly what's short, round up to a fixed quantity, buy an economic batch, cover a fixed number of days. The rules and the settings each one reads are in Planning policy settings.
Order Minimum, Order Multiple and Order Maximum are then applied on top, whichever rule produced the number.
Offsetting for lead time
Knowing an item is needed on the 14th isn't actionable. The run subtracts the item's lead time from the date it's needed to get the date you'd have to start — order it, or begin building it.
Where that lead time comes from is itself a setting: typed on the policy, taken from the recipe, quoted by the supplier, or measured from your own receiving history. Each falls back to the next when its source has nothing to offer. See Lead Time Source in Planning policy settings.
When the start date has already passed
Work backwards from a date that's too close and the answer lands in the past. You cannot start something last week, so the plan does two things instead of quietly pretending otherwise:
- It schedules the release for the earliest date you could act — never earlier than the run itself.
- It records how much lead time that costs you, and raises a message saying so.
An order whose backward maths wanted a start date before today raises Past Due. One that still fits, but only by compressing the lead time, raises Compression along with the number of days you'd have to make up. Both are covered in Action and exception messages.
This is the single most useful thing the plan tells you, and it's the reason the release date column is safe to act on: it never asks you to do something in the past, and it never hides that it wanted to.
Exploding down a level
When the run plans a Make order, the components of that item's active recipe become demand one level down — quantities scaled for how many you're building, and dated to when the build starts rather than when it finishes.
The explosion uses the planning quantities rather than the raw recipe: expected scrap and yield are applied, and component units are converted where the recipe consumes an item in a different unit from the one it's stocked in. A recipe that loses 5% to scrap generates demand for more than the nominal quantity, because that's what you'll actually consume.
An item set to Make with no active recipe can't be exploded. Rather than plan a build it can't substantiate, the run raises No Active BOM against it.
Regenerative and net change
Regenerative throws away the previous plan and recalculates everything in the horizon. It's the mode to use when policies, recipes or demand have moved, and it's the safe default.
Net change recalculates only what's affected by what's altered since the last run. It's faster on a large catalogue, and appropriate for a frequent scheduled run between full regenerations.
What a run does not do
- It creates no real orders. Everything it produces is a suggestion until you carry it out.
- It does not compare cost. Make or Buy resolves on whether an active recipe exists, not on which is cheaper or faster.
- It does not check capacity. Whether the hours fit is a separate question, asked in Check capacity.