When a master plan has a demand forecast set up to reduce forecasts by transactions, deprecated master planning reduces the forecast by invoiced and delivered sales orders but Planning Optimization doesn't. The Planning Optimization will lead calculated supply for quantities that have already been delivered and/or invoiced. Companies will be faced with significant oversupply that must be manually corrected. This is not an feasible option.
Suggesting to support the deprecated functionality of the legacy master plan to reduce the forecast by transactions again.
Comments
We are facing BATCHAOS crashes with the old master planning engine. So we really want to switch to planning optimization. But this bug is a big issue. We are now in the situation of chosing between pest and cholera.
Category: Planning
How many votes does this issue need to have before it is considered necessary by Microsoft?It most definitely is a hard stop for us moving to Planning Optimization.Thanks, Sheree
Category: Planning
The correct consumption of the forecast is necessary in order to use this module. Without this no correct forecasting and stock management can be made.
Category: Planning
Our current client is currently between a rock and a hard place without this feature. Has to stay with MRP functionality, but needs the performance of PO. Please consider making this a priority for an upcoming release.
Category: Planning
It is clearly a showstopper to use planning optimization
Category: Planning
Please make this urgent . . .
Category: Planning
MRP as a philosophy is designed to run you out of stock. I.e. to optimise the stock holding. The original X++ design in earlier versions of AX of course handled the invoiced orders case. As someone with 36 + years of experience with ERP/MRP systems I can't see that this is usable for any customer who wants to upgrade or a new customer. It seems that planning optimisation is not optimising the stock and although I can see the this is listed as a difference between the original engine and the PO engine (https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/planning-optimization/planning-optimization-differences-with-built-in) - I don't think Microsoft should be advertising that its planning engine is not designed in line with MRP philosophy and all other MRP products in the marketplace !
Category: Planning
MRP as a philosophy is designed to run you out of stock. I.e. to optimise the stock holding. The original X++ design in earlier versions of AX of course handled the invoiced orders case. As someone with 36 + years of experience with ERP/MRP systems I can't see that this is usable for any customer who wants to upgrade or a new customer. It seems that planning optimisation is not optimising the stock and although I can see the this is listed as a difference between the original engine and the PO engine (https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/planning-optimization/planning-optimization-differences-with-built-in) - I don't think Microsoft should be advertising that its planning engine is not designed in line with MRP philosophy and all other MRP products in the marketplace !
Category: Planning
This is a serious flaw in missing functionality in relation to Master planning and Sales Forecasting and a recipe for an oversupply disater. The sales forcast reduction must be corrected if planning optomisation is to be seen as viable alternative to the legacy master planning.
Category: Planning
Beatriz Nebot Gracia - the fact that Planning optimisation doesn't reduce the forecast by invoiced and delivered sales orders is a very serious omission, how can this not be an emergency update? When implementing Planning, the importance of having accurate planned orders cannot be overstated. Planners, in my experience, are a cynical audience by default and I cannot think of anything more likely to justify their concerns about how teh system cannot be trusted.
Category: Planning
Beatriz Nebot Gracia (administrator) on 4/5/2024 12:48:40 PM
Thanks for your input! If it gets voted, we will consider adding it to our long term roadmap.
Sincerely,
Beatriz Nebot Gracia
Senior Product Manager, Microsoft