TL;DR
Because Planning Optimization fires auto-firming on the order date — the start date — while the deprecated engine fired on the requirement date, the end date. Microsoft states both on two pages. A firming time fence carried across from the old engine still has lead time baked into it, so it firms weeks of orders early on day one.
Why does auto-firming fire at the wrong time under Planning Optimization?
Because it fires on a different date than the engine your settings were designed for. Planning Optimization [GA] auto-firms on the order date — the start date. The deprecated master planning engine [DEPR] auto-firmed on the requirement date — the end date. Microsoft states this on two separate pages, and the consequence is immediate: a firming time fence that was correct on the old engine has the item's lead time baked into it, and Planning Optimization does not need it there.
That is not a subtle drift. It is weeks of planned orders becoming real purchase, transfer and production orders on the first run after migration.
What Microsoft actually says
From the Firm planned orders page, verbatim:
"You can use both Planning Optimization and the deprecated master planning engine to auto-firm
planned orders. However, some important differences exist. For example, Planning Optimization uses
the order date (that is, the start date) to determine which planned orders to firm, whereas the
deprecated master planning engine uses the requirement date (that is, the end date)."
And on the Planning Optimization fit analysis page, in the Firming row for coverage groups. The item-coverage and master-plan rows carry the same text with one word changed — "auto firming is supported" rather than "firming is supported":
"In version 10.0.7 and later, firming is supported as a separate firming batch job after master
planning is completed. Auto firming for Planning Optimization is based on the order date (start
date), not the requirement date (end date). This behavior ensures that firming of planned orders
occurs in due time, without having to include lead time in the firming time fence."
That last clause is the design intent, stated by Microsoft: without having to include lead time in the firming time fence. Every fence you inherited from the old engine includes it.
Microsoft's own comparison, verbatim
The firming page publishes the difference as a table. Reproduced exactly:
- **Date basis** — Planning Optimization: "Auto-firming is based on the order date (start date)." · Deprecated master planning engine: "Auto-firming is based on the requirement date (end date)."
- **Lead time** — Planning Optimization: "Because the order date (start date) triggers the firming, you don't have to consider the lead time as part of the firming time fence." · Deprecated master planning engine: "To help guarantee that the system firms orders quickly, the firming time fence must be longer than the lead time."
- **Orders for the current week** — Planning Optimization: "To firm all orders that must start during the current week, the firming time fence must be one week." · Deprecated master planning engine: "To firm all orders that must start during the current week, the firming time fence must be the lead time plus one week."
Two rules, same objective, different arithmetic. Microsoft is telling you the old fence was supposed to be inflated, which is exactly why nobody looks at it twice after the migration — it was never a mistake, it was correct for its engine.
The arithmetic
Take a purchased component with a lead time of thirty days.
Substitute your own lead times: the over-firing is the lead time, item by item, and it is largest on exactly the long-lead parts where an early commitment costs the most.
The reverse error is quieter. A planner who cuts the fence below one week to stop the over-firing now under-firms — orders that must start this week stay planned, nobody firms them, and the shortage appears a lead time later with no order behind it.
Where the fence is actually set — three levels
The firming time fence is set in three places, each overriding the last. At coverage-group and item-coverage level Microsoft names the field Automatic firming time fence (days); on a master plan it is the Firming option on the Time fence in days FastTab. Microsoft's paths, quoted:
- **Coverage group (the default) — "go to Master planning > Setup > Coverage > Coverage groups, and select a coverage group. Then, on the Other FastTab, in the Automatic firming time fence (days)** field, enter the number of days."
- **Item coverage (overrides the group, per item) — "go to Product information management > Released products. On the Action Pane, select Plan, and then select Item coverage. On the General tab, select Override time fence, and then, in the Automatic firming time fence (days)** field, enter the number of days."
- **Master plan (overrides both) — "go to Master planning > Setup > Master plans, and select a master plan. Then, on the Time fence in days FastTab, set the Firming* option to Yes*, and enter the number of days."
Three levels means a migration review is three passes, not one. A tidy coverage group tells you nothing about an item-level override set during a go-live four years ago.
One wording difference worth knowing
The two pages describe when firming happens slightly differently, and it matters if you are designing a batch schedule.
The fit analysis says firming is "supported as a separate firming batch job after master planning is completed." The firming page says auto-firming "lets you firm planned orders as part of the master planning process" and that "during master planning runs, the system automatically firms planned orders if the order date is within the specified time fence for firming."
Our reading is that these describe one mechanism at two altitudes — a firming step that follows the calculation — and are not in conflict. That is our reading, not a Microsoft statement. If your batch design turns on whether firming is a distinct schedulable job, observe it in a sandbox rather than inferring it from either sentence.
Three ways auto-firming silently does nothing
All three are on the firming page, and all three present as "the fence is set but nothing firmed":
- Every fence is zero. "If you set all the previously mentioned time fences to 0 (zero), you effectively disable auto-firming for the relevant covered items."
- The item has no vendor. "You can auto-firm planned purchase orders only for items that are associated with a vendor." A new item without a default vendor never auto-firms, and nothing tells you.
- Planning was started from the wrong page. "If you don't turn on auto-firming for any coverage setup, or if you start planning from a specific page, such as the Net requirements page for a released product, the auto-firming process is skipped." Planners regenerate from Net requirements constantly. That run firms nothing.
And one adjacent trap, on the manual path rather than the auto-firming one: "When firming planned production orders that were created manually, Planning Optimization doesn't automatically trigger the explosion of items. You must manually trigger item explosions as needed" (Differences).
Where we would draw the line
We would not fix an inflated fence by moving everything to query-based firming. It is right for a subset — Microsoft says the two combine, and gives one case: "For example, a query-based firming job has a forward time fence that is longer than the time fence for a matching auto-firming coverage configuration. Therefore, the query-based firming job processes its planned orders before the auto-firming is triggered." But the same page carries a warning we would put on the wall:
"This feature firms all planned orders that match the filter criteria. Uncritical firming of planned
orders can cause massive numbers of unwanted purchase, transfer, and production orders to be
created. Before you continue, always use the Preview button to validate the records that the
process includes."
And we would not set a single firming fence across a whole item master. Firming horizon is a policy decision per replenishment personality, not a global constant — which is the same argument as coverage segmentation, one field along.
What to do this week
- Export Automatic firming time fence (days) from every coverage group, then from item coverage overrides, then from every master plan's Time fence in days FastTab. Three extracts.
- Put the item's lead time beside each fence. Any fence that is roughly lead time plus a week is an old-engine setting still doing old-engine arithmetic.
- Open Master-planning > Inquiries and reports > Master planning > Firming history — Microsoft's own path, hyphen included — and look at what was firmed on the last run against what you expected.
- Check that items which never seem to auto-firm have a vendor associated.
About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/
Worked example. Modelled from public documentation and typical operations.
Firming horizon is one of the four policy decisions the engine executes and never chooses. Book a fifteen-minute call and we will walk your fences and coverage policy with you on your own data — no deck. https://cognilium.ai
Sources
- Firm planned orders
- Planning Optimization fit analysis
- Differences between Planning Optimization and the deprecated master planning engine
Sources
Share this article
Muhammad Mudassir
Founder & CEO, Cognilium AI
Muhammad Mudassir
Founder & CEO, Cognilium AI
Mudassir Marwat's argument is that ERP systems record decisions they never optimise.
