The Planning Worksheet Plans. It Doesn't Schedule.

Microsoft Dynamics 365 Business Central has two worksheets that run essentially the same planning engine for different audiences: the Planning Worksheet, aimed at manufacturing and assembly, and the Requisition Worksheet, aimed at purchasing and transfers. Both exist to answer the same question — given everything you’ve promised to sell and everything you already have or have on order, what do you need to make or buy, and by when? That’s genuinely valuable work, and Business Central does it well. It’s also a different job from scheduling, and the two get confused often enough that it’s worth being precise about where one stops and the other starts.

What running the plan actually produces

Planning in Business Central is a gross-to-net calculation. Demand comes from anything that consumes inventory or capacity — sales orders, forecasts, component needs on other production or assembly orders, outbound transfers. Supply comes from anything that replenishes it — existing inventory, purchase orders, production orders, inbound transfers. Running the Calculate Plan action nets these against each other and, wherever a shortfall exists, generates an action message: a suggestion to create a new order, or to reschedule, increase, or cancel an existing one, sized and dated to close the gap.

Here’s a small worked version of that calculation. Say an item has 40 units in inventory, a sales order due in three weeks for 150 units, and no other supply already on order. Netting demand against supply leaves a shortfall of 110 units — that shortfall is what drives the action message, sized to close exactly that gap, dated to arrive by the sales order’s due date. Change any one input — inventory on hand, an existing purchase order, the due date itself — and the next planning run recalculates the shortfall and the suggestion that closes it, from scratch.

For a manufactured item, the resulting suggestion is a planned production order, and its dates come from working backward through the item’s routing from when the order is needed — the same routing-driven, calendar-respecting walk covered in How Business Central Schedules a Production Order, Step by Step. That’s worth sitting with for a moment: a planned production order isn’t a rough guess with a placeholder date. It’s scheduled the same way any other production order is scheduled — against the calendar, operation by operation. What it is not scheduled against is every other order also competing for the same work centers, for exactly the reason covered in Business Central Is Infinite-Loading: nothing in the planning engine checks whether the dates it just computed for this order collide with the dates it computed for the last fifty orders it also planned this run.

Reorder policies, briefly

How aggressively the planning engine reacts to each individual demand line depends on the item’s reordering policy. Some policies replenish in a fixed batch size or up to a maximum inventory level on a rhythm mostly divorced from any one order — good for steady, predictable items. Others — commonly Lot-for-Lot or Order-based policies — generate a supply order sized and dated to exactly one demand line, which is the natural choice for make-to-order manufacturing where every sales order really does need its own production order. The policy you pick per item changes how many planned orders come out of a planning run and how tightly each one ties back to a specific piece of demand, but it doesn’t change the fundamental nature of what comes out: a dated quantity, not a sequence.

Regenerative vs. net change: how often you re-ask the question

Business Central gives you two ways to run the planning calculation. A regenerative plan recalculates everything from scratch — every item, every piece of demand and supply, reconsidered — and is the right tool for a full, periodic replan (weekly is typical) or whenever something structural changed, like a new BOM or a batch of new items. A net change plan only reconsiders items where demand or supply actually moved since the last run, which is faster and suits a daily touch-up between full replans, but it depends on a previous full plan as its baseline — it’s an update, not a from-scratch answer. Neither mode changes what planning produces; they only change how much of the shop’s data gets re-examined to produce it.

From planned to firm: carrying a suggestion forward

A planned production order is explicitly provisional — it’s Business Central’s best current estimate, and it gets deleted and regenerated wholesale the next time you run planning, which makes it unsafe to hand-edit or rely on as a commitment. Carry Out Action Message is the step that turns an accepted suggestion into something durable: it converts planned orders into firm planned orders, which survive the next planning run instead of disappearing into it, precisely because they’ve now been treated as a real intention rather than a computed guess. From there, an order moves to Released when it’s actually authorized to start consuming material and capacity — a distinct, deliberate step covered in Production Order Statuses in BC.

This gap doesn’t wait for separate planning runs to show up, either — it can appear inside a single one. If three different sales orders for the same item all land in the same regenerative plan, Business Central can generate three separate planned production orders in one pass, each independently scheduled backward from its own due date against the same work center’s calendar. Nothing in the planning calculation cross-checks those three suggestions against each other before presenting them; each one is individually correct against the calendar, and all three can claim overlapping time on the same resource. The plan didn’t do anything wrong by its own logic — it answered “what and when” three times, correctly, in isolation. Whether those three answers actually fit together on the shop floor was never the question it was asked.

Where planning ends and scheduling has to begin

Here’s the handoff, stated plainly: planning answers what and by when, in isolation — how many units, needed by which date, assuming this order is the only thing happening. Scheduling has to answer a harder question planning never touches: given everything else also competing for the same machines this week, in what order does work actually run, and does the plan planning handed you actually fit? A planning worksheet that tells you “start Monday” doesn’t tell you which job runs first on the CNC mill Monday at 07:00 when three other planned orders also say Monday. That gap — between a dated suggestion and an executable sequence — is exactly the gap a finite-capacity scheduler exists to close, and it’s why “run MRP more often” never fixes a sequencing problem: more frequent planning runs produce more frequent dates, not a resolved conflict between them.

In practice, this also tends to map to two different jobs, even when one person does both. A planner works from top-level demand — forecasts, sales orders, safety stock — deciding what quantity of what item needs to exist and roughly when, which is the Planning Worksheet’s whole domain. A scheduler works from the shop floor’s actual constraints — which machine is free when, what’s already committed, what changeover a sequence costs — turning a stack of dated orders into a sequence someone can actually run today. The same production orders flow through both roles; planning hands off a dated order, and scheduling is what decides where it actually lands on the calendar in relation to everything else.

The two roles also run on different clocks, and that difference is itself informative. A regenerative plan is typically a weekly or few-times-a-week event — it’s asking a slow-moving question about aggregate demand and supply across the whole item base. A scheduler’s view of the shop floor changes by the hour: a machine goes down, a rush order lands, an operator calls in sick, and the sequence that was correct at 7 a.m. may not be by 10. A planning worksheet running once a week was never going to be the tool that answers “what happens on MOLD-2 in the next four hours” — that’s not a gap in how well it’s configured, it’s a difference in what kind of question it was built to answer in the first place.

For the concept-level version of this same handoff — including why simply running MRP more often never substitutes for a sequencing layer — see Why MRP Is Not a Schedule.

For Microsoft’s own reference on planning parameters, action messages, and the regenerative/net-change comparison, see About planning functionality. For the full production order status lifecycle referenced above, see About production orders.