Last time I wrote about coverage groups and the core planning parameters, the per-item settings that decide how master planning turns demand into planned orders. I promised to keep going with master planning, and before we follow planned orders forward into firming and messages, there is a structural question worth settling: the plan itself. When you run master planning, what is it writing into, and why do almost all real setups run not one plan but two? The answer is the difference between a static plan and a dynamic plan, and getting it right is the difference between a planner who trusts the plan and one who watches it change every time someone enters a sales order.
WHAT A MASTER PLAN ACTUALLY IS
A master plan in D365 is two things at once. It is a named configuration, a header that carries settings about how the run behaves, and it is the container that holds the results of the run: the planned orders, the action messages, and the futures messages. So when I say "the static plan" I mean both a set of parameters and the body of suggestions sitting under it. You can have several master plans defined, and you nominate which ones play which role in the Master planning parameters. Two roles matter: the current static master plan and the current dynamic master plan. Those two nominations are the quiet decision that shapes everyone's daily experience of planning.
STATIC VERSUS DYNAMIC PLANS
A static plan is the plan of record. It is recalculated on a controlled schedule, typically a full regeneration in an overnight batch, and then it sits still until the next run. That stillness is the point. A planner can open the static plan in the morning, see a coherent set of planned orders, and work through them (reviewing, adjusting, firming) without the ground shifting because someone three desks away just keyed a large order. The static plan is stable precisely because it does not react to every transaction the moment it happens.
A dynamic plan is the opposite by design. It updates continuously as supply and demand change, so it always reflects the very latest picture. The moment a sales order line is entered, the dynamic plan rebalances net requirements for that item. This is exactly what you want behind order entry and delivery date promising, where the business needs an up-to-the-minute answer to "if I sell this today, when can I have it." The dynamic plan is volatile, and that is fine, because nobody is firming orders from it; they are reading availability from it.
WHY MOST SETUPS RUN TWO PLANS
The reason two plans exist is that one plan cannot be both stable and live at the same time, and a healthy operation needs both qualities. Planners need stability to make decisions; order entry needs currency to make promises. Run a single plan and you are forced to choose which group to disappoint.
There is a specific trap here that catches people. If you nominate a current static plan but leave the current dynamic plan blank, D365 will update that single static plan dynamically as orders are entered. In other words, your "stable" plan of record quietly stops being stable, and planners start seeing it churn through the day with no obvious cause. The fix is simply to name both plans, so live updates flow to the dynamic plan and the static plan only changes when you deliberately regenerate it. I treat naming both as a baseline, not an optimization. A common pattern is a full regeneration of the static plan overnight, optionally a lighter net change update during the day if the business needs a mid-day refresh of the plan of record, and the dynamic plan left to maintain itself for promising.
PLAN-LEVEL SETTINGS, AND HOW THEY MEET THE COVERAGE GROUP
The master plan header carries its own settings, and it helps to be clear about which decisions live on the plan and which live on the coverage group, because the two have to agree. The plan decides the scope and shape of the run as a whole: which companies are included, whether on-hand inventory and existing inventory transactions are counted, whether the demand forecast is brought in (and through which forecast model), whether action messages and futures messages are generated at all, and the scheduling method the run uses. The coverage group, as covered last time, decides per-item behaviour: the coverage code, the time fences for that item, forecast inclusion, and the negative and positive days.
The interaction is where mistakes hide. Action messages are a good example. If you switch action messages off at the plan level, no planner will see a single reschedule suggestion no matter how carefully the coverage groups are configured, because the plan never generated them. Going the other way, a coverage time fence set short on a coverage group still caps how far that particular item is planned even when the overall plan horizon is much longer. The plan provides the frame; the coverage group fills in the per-item detail inside it; and item coverage handles the genuine exceptions such as a single item-warehouse safety stock. When the plan and the groups disagree, the more restrictive setting usually wins, which is why "I turned it on in the coverage group but nothing happened" almost always traces back to a plan-level switch.
A NOTE ON PLANNING OPTIMIZATION
The static and dynamic split is a concept from the built-in planning engine that many of us grew up with. If you have moved to Planning Optimization, the newer engine that Microsoft has been steering everyone toward, the mechanics differ: it recalculates incrementally and maintains the live picture in its own way rather than through a separately nominated dynamic plan behaving exactly as described above. What does not change is the principle. You still want a stable plan of record that planners work from, separate from the always-current view used for promising, and the plan-level versus coverage-group division of responsibility still holds. If you are mid-migration and running both approaches, be especially careful about which plan is the source of truth on any given screen, because that is exactly where confusion creeps in.
WHAT GOES WRONG
• Only a static plan named. With no dynamic plan nominated, the static plan updates live and stops being stable, so planners see it churn all day. Name both plans.
• Planners firming from the dynamic plan. The dynamic plan is built to move; firming from it means chasing a moving target. Firm from the static plan of record only.
• Plan-level switches forgotten. Action or futures messages turned off at the plan level silently override everything the coverage groups ask for. Check the plan before blaming the group.
• Forecast included in two places. Bringing the forecast in at the plan while the coverage group also consumes it, set inconsistently, either double counts demand or drops it. Decide once and make the plan and group agree.
• Regenerating too rarely or too often. A static plan regenerated only weekly drifts away from reality; one regenerated constantly never gives planners a stable surface to work on. Match the regeneration rhythm to how fast your demand actually changes.
TAKEAWAYS
The plan is not just where results land; it is a design decision. Define a static plan as your plan of record, regenerate it on a deliberate schedule, and have planners review and firm from it. Define a separate dynamic plan, name it in the parameters, and let it stay live for order entry and delivery promising. Never leave the dynamic plan blank unless you genuinely want your static plan to move in real time, which you almost never do. Then keep the division of labour straight: the master plan frames the run (scope, forecast, messages, scheduling) while the coverage group sets each item inside that frame, and the more restrictive of the two wins. Settle the plan structure first and the per-item tuning from last time finally behaves, because it is operating on a surface that holds still long enough to trust.
Next time I will follow the planned orders forward: firming them into real purchase and production orders, and reading the action and futures messages that tell you what to reschedule before the warehouse ever feels it.
In this series: previous article Master Planning in D365: Coverage Groups and the Core Planning Parameters
Last time I wrote about coverage groups and the core planning parameters, the per-item settings that decide how master planning turns demand into planned orders. I promised to keep going with master planning, and before we follow planned orders forward into firming and messages, there is a structural question worth settling: the plan itself. When you run master planning, what is it writing into, and why do almost all real setups run not one plan but two? The answer is the difference between a static plan and a dynamic plan, and getting it right is the difference between a planner who trusts the plan and one who watches it change every time someone enters a sales order.
WHAT A MASTER PLAN ACTUALLY IS
A master plan in D365 is two things at once. It is a named configuration, a header that carries settings about how the run behaves, and it is the container that holds the results of the run: the planned orders, the action messages, and the futures messages. So when I say "the static plan" I mean both a set of parameters and the body of suggestions sitting under it. You can have several master plans defined, and you nominate which ones play which role in the Master planning parameters. Two roles matter: the current static master plan and the current dynamic master plan. Those two nominations are the quiet decision that shapes everyone's daily experience of planning.
STATIC VERSUS DYNAMIC PLANS
A static plan is the plan of record. It is recalculated on a controlled schedule, typically a full regeneration in an overnight batch, and then it sits still until the next run. That stillness is the point. A planner can open the static plan in the morning, see a coherent set of planned orders, and work through them (reviewing, adjusting, firming) without the ground shifting because someone three desks away just keyed a large order. The static plan is stable precisely because it does not react to every transaction the moment it happens.
A dynamic plan is the opposite by design. It updates continuously as supply and demand change, so it always reflects the very latest picture. The moment a sales order line is entered, the dynamic plan rebalances net requirements for that item. This is exactly what you want behind order entry and delivery date promising, where the business needs an up-to-the-minute answer to "if I sell this today, when can I have it." The dynamic plan is volatile, and that is fine, because nobody is firming orders from it; they are reading availability from it.
WHY MOST SETUPS RUN TWO PLANS
The reason two plans exist is that one plan cannot be both stable and live at the same time, and a healthy operation needs both qualities. Planners need stability to make decisions; order entry needs currency to make promises. Run a single plan and you are forced to choose which group to disappoint.
There is a specific trap here that catches people. If you nominate a current static plan but leave the current dynamic plan blank, D365 will update that single static plan dynamically as orders are entered. In other words, your "stable" plan of record quietly stops being stable, and planners start seeing it churn through the day with no obvious cause. The fix is simply to name both plans, so live updates flow to the dynamic plan and the static plan only changes when you deliberately regenerate it. I treat naming both as a baseline, not an optimization. A common pattern is a full regeneration of the static plan overnight, optionally a lighter net change update during the day if the business needs a mid-day refresh of the plan of record, and the dynamic plan left to maintain itself for promising.
PLAN-LEVEL SETTINGS, AND HOW THEY MEET THE COVERAGE GROUP
The master plan header carries its own settings, and it helps to be clear about which decisions live on the plan and which live on the coverage group, because the two have to agree. The plan decides the scope and shape of the run as a whole: which companies are included, whether on-hand inventory and existing inventory transactions are counted, whether the demand forecast is brought in (and through which forecast model), whether action messages and futures messages are generated at all, and the scheduling method the run uses. The coverage group, as covered last time, decides per-item behaviour: the coverage code, the time fences for that item, forecast inclusion, and the negative and positive days.
The interaction is where mistakes hide. Action messages are a good example. If you switch action messages off at the plan level, no planner will see a single reschedule suggestion no matter how carefully the coverage groups are configured, because the plan never generated them. Going the other way, a coverage time fence set short on a coverage group still caps how far that particular item is planned even when the overall plan horizon is much longer. The plan provides the frame; the coverage group fills in the per-item detail inside it; and item coverage handles the genuine exceptions such as a single item-warehouse safety stock. When the plan and the groups disagree, the more restrictive setting usually wins, which is why "I turned it on in the coverage group but nothing happened" almost always traces back to a plan-level switch.
A NOTE ON PLANNING OPTIMIZATION
The static and dynamic split is a concept from the built-in planning engine that many of us grew up with. If you have moved to Planning Optimization, the newer engine that Microsoft has been steering everyone toward, the mechanics differ: it recalculates incrementally and maintains the live picture in its own way rather than through a separately nominated dynamic plan behaving exactly as described above. What does not change is the principle. You still want a stable plan of record that planners work from, separate from the always-current view used for promising, and the plan-level versus coverage-group division of responsibility still holds. If you are mid-migration and running both approaches, be especially careful about which plan is the source of truth on any given screen, because that is exactly where confusion creeps in.
WHAT GOES WRONG
• Only a static plan named. With no dynamic plan nominated, the static plan updates live and stops being stable, so planners see it churn all day. Name both plans.
• Planners firming from the dynamic plan. The dynamic plan is built to move; firming from it means chasing a moving target. Firm from the static plan of record only.
• Plan-level switches forgotten. Action or futures messages turned off at the plan level silently override everything the coverage groups ask for. Check the plan before blaming the group.
• Forecast included in two places. Bringing the forecast in at the plan while the coverage group also consumes it, set inconsistently, either double counts demand or drops it. Decide once and make the plan and group agree.
• Regenerating too rarely or too often. A static plan regenerated only weekly drifts away from reality; one regenerated constantly never gives planners a stable surface to work on. Match the regeneration rhythm to how fast your demand actually changes.
TAKEAWAYS
The plan is not just where results land; it is a design decision. Define a static plan as your plan of record, regenerate it on a deliberate schedule, and have planners review and firm from it. Define a separate dynamic plan, name it in the parameters, and let it stay live for order entry and delivery promising. Never leave the dynamic plan blank unless you genuinely want your static plan to move in real time, which you almost never do. Then keep the division of labour straight: the master plan frames the run (scope, forecast, messages, scheduling) while the coverage group sets each item inside that frame, and the more restrictive of the two wins. Settle the plan structure first and the per-item tuning from last time finally behaves, because it is operating on a surface that holds still long enough to trust.
Next time I will follow the planned orders forward: firming them into real purchase and production orders, and reading the action and futures messages that tell you what to reschedule before the warehouse ever feels it.
In this series: previous article Master Planning in D365: Coverage Groups and the Core Planning Parameters
No replies yet. Be the first to respond!
