Safety stock, reorder points, coverage groups and the buffer the planning engine plans TO but never recomputes.
Most ERPs hold a safety-stock number set once at go-live and never revisited. Here's why that quietly costs margin — and how a decision layer on Dynamics 365 recomputes it from your own demand history.
Ordered by chapter. Each post stands alone but builds on the one before it.
The safety stock journal recomputes minimum coverage from your own transaction history — over a window set by a lead time someone typed at go-live.
Master planning in Dynamics 365 is a calculation, not a decision. Microsoft ships the engine and leaves four replenishment-policy choices to you — coverage segmentation, safety stock method, forecast netting and time fences.
Reference build, not a delivered engagement: how a safety-stock minimum typed at go-live quietly becomes the number driving both overstock and stockouts.
Safety stock in D365 is a static field the planning engine never recomputes. The mechanism behind the gap, and the read-only diagnostic that finds the leak.
You have a running master planning engine on-premises, and it is the deprecated one — Planning Optimization does not support on-premises deployments. What "supported" means for the engine you are left with is described three different ways across three Microsoft pages. Here is each wording, quoted, and what each of the three honest options costs.
Microsoft's fit-analysis page currently marks three rows as Future wave — sales line reservation using explosion, intercompany planning execution, and requirement types for skills, courses, certificates and titles. But that page answers a narrower question than the one people ask, four other Microsoft pages carry real limits it never lists, and on three features Microsoft's own pages disagree with each other.
Because the volume is an output of your coverage configuration, not a measurement of how wrong the plan is. Four settings decide the count, and Microsoft documents every one of them — coverage segmentation, negative days, the time fences on the master plan, and turning action messages off where the answer is always "do nothing".
Two features in the Dynamics 365 demand planning app have near-identical names and opposite jobs. A time fence stops people editing a forecast. A time freeze stops the recalculation overwriting what people edited. Only one of them is on by default, and it is not the one that saves your adjustments.
In the Dynamics 365 demand planning app you do not pick an algorithm for intermittent demand. Croston's method is not selectable — it is a fallback the best fit model reaches for, it only exists inside a preview version of best fit, and Microsoft's preview terms say preview features are not meant for production use.
The near month is wrong because the forecast is not being consumed by the orders that arrived against it, so master planning covers the forecast and the orders. Four settings decide the netting, and two current Microsoft pages describe the carry-forward rule in opposite terms.
A qualified yes. Microsoft states Supply Chain Management "includes DDMRP with no additional license fees" — but DDMRP requires the Planning Optimization Add-in, which requires a Supply Chain Management licence, a tier-2 or higher Lifecycle Services environment, and a cloud deployment. The licence is the cheap part; the decoupling-point analysis is not.
Infinite everywhere, finite on the constraint, and the capacity time fence as the control in between. Turning finite capacity on globally on day one fails for reasons Microsoft's own documentation states plainly.
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.
Because you are measuring against the last confirmed date, and the vendor moved it three times. Dynamics 365 stores one confirmed date per line and overwrites it. The honest measure is the first confirmed date plus a change count, and both are recoverable.
Microsoft's coverage settings page lists six coverage codes, not four — Manual, Per requirement, Per period, Min/Max, Priority and Decoupling point — and three Microsoft pages disagree on the names. Here is what each one does, which items Microsoft says each fits, and where the recommendation is ours rather than Microsoft's.
Neither one owns it. The demand planning app calculates the forecast, master planning consumes it, and the object of record between them is a forecast model in Supply Chain Management. Here is the hop, the fields on both sides, and why "are we up to date" is a two-part question with two different version numbers.
Dynamics 365 Supply Chain Management documents no feature area called sales and operations planning. It supplies the demand engine, the supply engine and the capacity check. The consensus layer is the build, and it belongs on Power Platform rather than in the ERP.