Skip to main content

Run a planning cycle

A planning run is the step that turns demand, stock, recipes and lead times into dated suggestions. It reads what you owe, opens up every recipe underneath it, subtracts what you already hold and everything already on its way, and hands back planned orders: make this, buy that, move the other — and start each one on this date.

Nothing it produces is real. A run creates no purchase orders, no manufacturing orders and no transfers, which is exactly what makes it safe to run as often as you like. Run it after demand moves, after you change policies, or every morning out of habit.

Where planning lives​

Manufacturing → Planning opens the Overview page. It's a map rather than a screen you work in: a short Where to start note, and a card for each page in the area with what that page is for. Use it the first time, and any time you're not sure which page answers the question you have.

A button bar sits at the top of every page in the area — Overview, Workbench, Exceptions, MPS, Capacity, Compare Runs, ATP / CTP, Policies and Distribution Network. All of them read whichever run you have selected on the Workbench, so the run comes first and everything else follows from it.

Before you begin​

  • Items need a planning policy. The engine plans nothing for an item that has none — those items are skipped, not planned with sensible defaults. See Set item planning policies.
  • An item planned as Make needs an active recipe. Without one the run can't work out what the build consumes, and raises No Active BOM against the item instead of planning it. See Create a recipe (BOM).
  • The run needs demand to plan against. Open customer orders count automatically. Anything you intend to build that no order carries yet has to come from a master production schedule, or from the forecast you can switch on when you start the run.
  • You need permission to run planning. Reading the plan and starting a run are separate permissions, and carrying orders out is a third. See Exports, imports and permissions.

Steps​

  1. Go to Manufacturing → Planning and open the Workbench.

  2. Click Run MRP in the page header.

  3. Set the options you want. The defaults — a regenerative run, weekly buckets, 90 days, forecast demand included — are a reasonable first run for most accounts.

    FieldWhat it decides
    ModeRegenerative throws away the previous plan and recalculates everything in the horizon. Net change recalculates only what's affected by what changed since the last run — faster on a large catalogue, and suited to a frequent run between full regenerations. Regenerative is the default and the one to use when policies, recipes or demand have moved.
    Bucket sizeThe period the plan is grouped into: Day, Week or Month. Smaller buckets give you a more precise picture and a much larger plan; weekly is the default and suits most planning cycles.
    Horizon (days)How far ahead to plan, counted from today. It defaults to 90 and accepts a whole number from 1 day to 1,095 days. Type something outside that and the field says why — for example "The horizon cannot exceed 1095 days (3 years)." — and Run MRP stays unavailable until you fix it.
    Include forecast demandOn by default. Leave it on to plan against forecast demand as well as real orders; switch it off to plan from firm demand only. It's a plain on/off switch — there is nothing else to configure.
    Scope (optional)Warehouses and Products, both empty by default, meaning everything. Choosing either narrows the run — see below.

  4. Click Run MRP.

    The dialog closes straight away and a message names the run it started, such as "MRP run #14 started — track progress in the job tray". The run happens in the background, so you can leave the Workbench, work elsewhere in SKU.io, or close the tab.

  5. Follow it in the job tray in the toolbar. The tray entry is named for the run and its mode — "MRP Run: #14 (regenerative)" — and moves through three stages: checking the planning scope, netting requirements and planning orders, then summarising results.

  6. Wait for the tray entry to report completion. It names the run and says how much it produced — how many planned orders, across how many items.

    The Workbench switches to the new run by itself — you don't need to pick it out of the list.

The Planned Orders table is now the plan. Work it from Read the time-phased plan and Work the exceptions inbox.

note

A nightly regenerative run can also be switched on for an account, in which case the newest run in the picker is usually last night's rather than one you started. It's off unless someone turns it on.

Narrowing a run to part of the catalogue​

Scope (optional) exists because a full regeneration across a large catalogue is expensive and usually unnecessary. If you've changed policies on one product family, or you only care about one site, name them and re-plan that slice.

Pick any warehouse or product and the dialog shows what you're about to do:

Partial run — 2 warehouses · all products. Only the warehouses and products above are re-planned. Everything else is carried forward from the most recent completed run, so the plan stays complete.

That last part is the important one. A scoped run is a partial run, but not a partial plan: everything outside the scope is carried through from the last completed run, so the Workbench, the exceptions inbox and the time-phased plan still show a whole picture. What you lose is freshness outside the slice, not coverage.

When the run is too big to start​

Before anything is created, the plan sizes the work you've asked for. If it can't finish, it refuses up front and says so inside the dialog, which stays open so you can adjust the fields against the message. Nothing is queued, and no half-finished run appears in the list.

There are three ceilings, and the message always names the number you hit, the ceiling it crossed, and the lever that fixes it:

  • Too many item and warehouse combinations. The most common first-run refusal, and it's usually a warehouse problem rather than a product one: a run covering every product across every warehouse multiplies out fast. Narrow it to specific products or warehouses, or set Planning Method to None on items you never plan so they stop counting.
  • Too many time buckets. Shorten the horizon, or use a larger bucket size — a 3-year daily run is over a thousand buckets, the same span in weeks is under two hundred.
  • Too large a time-phased matrix. Items multiplied by buckets. Any of the three levers works: a shorter horizon, bigger buckets, or a narrower scope.
caution

Setting Planning Method to None takes the item out of planning entirely, not out of this one run. It stays out until you change it back. Narrowing the scope on the dialog is the reversible way to get a run to start.

What the run header tells you​

Under the page header sits the run card, and everything on it describes the run you have selected rather than the plan in general.

  • MRP Run — a picker listing runs newest first, each labelled with its number, its mode and when it started, with a status chip beside it. Selecting an older run makes every page in the area read that run, which is how you look back at yesterday's plan. Before your first run it reads "No runs yet — click Run MRP to generate one".
  • Status — Queued, Running, Completed, Failed or Cancelled.
  • Planned orders — how many suggestions the plan holds.
  • Make / Buy / Transfer — the same total split by supply type. A quick sanity check: a number far from what you expect usually means a Procurement Type is wrong on a policy, not that demand moved.
  • Horizon — the horizon and bucket size the run used, such as "90d / week". Worth reading before you trust a date near the end of the plan.

About this run​

An About this run notice appears under those figures when the run deliberately left something out. It's not an error — it's the run explaining a number that would otherwise look wrong.

The common case is a marketplace-fulfilment warehouse. Those locations are skipped, and the notice says why:

1 marketplace-fulfilment warehouse was not planned: FBA (Amazon) (Amazon FBA). MRP cannot raise a purchase order, manufacturing order or transfer into a marketplace-fulfilment location, and it cannot yet see the inbound shipments already on their way to one — so planning them would re-order over supply in flight. Replenish these from the channel's own inbound workflow.

A second Not planned list names each skipped warehouse individually. If every warehouse in a run's scope was one of these, the run plans nothing at all and says so — add a direct or 3PL warehouse to the scope.

The same notice carries anything else the run had to work around, such as a recipe it skipped because one of its components is consumed in a unit it can't convert to the unit that component is stocked in. Those are data faults worth fixing: the rest of the plan still ran, but that recipe contributed nothing.

Cancelling a run in progress​

Open the job tray, find the MRP Run entry, and use the stop control on it.

Cancelling genuinely stops the work rather than hiding it. The run checks at every stage boundary, so it stops at the next checkpoint instead of instantly, then ends as Cancelled and never writes a plan. The row stays in the picker with a Cancelled chip so you can see it happened.

Only a queued or running run can be cancelled. Once a run is Completed there's nothing to stop — and no need, since the next run replaces it.

Discarding a run​

Discarding a run removes it and everything it produced: its planned orders, its time-phased plan, its pegging and its messages. Three situations stop that, each for a reason worth understanding.

  • The run is still executing. Cancel it first, or wait for it to finish.
  • It has planned orders you already carried out. Those rows are the only link between the plan and the purchase, manufacturing or transfer order it became. Discarding the run would erase where those orders came from, so it's refused outright — there's no override. If you're cleaning up, discard a run from before you released anything.
  • It's the current plan and holds firm orders. Later runs count those firm orders as supply, so removing them would make the next plan re-order everything they cover. Unfirm them, or run MRP again so the commitment moves onto the newer plan, and the older run stops being protected.

Old runs are also tidied up on their own. A run is kept for at least 90 days, the ten most recent are kept whatever their age, and the newest completed run is never removed — that's where the live plan and every firm commitment live. A run holding released orders keeps its planned orders permanently, so the trail back to the real order survives even after its working detail is reclaimed.

Next steps​

Last verified: