Suggested by Microsoft – Planned – 1
Category: Master planning
This is an enhancement that resolves a current showstopper, but it seems to be "as designed. When firming planned transfer orders to multi-line transfer orders, attempting to fill a truck, we need to filter on planned transfers with the same from-to warehouses. That is currently not possible. I cannot filter on the FROM warehouse.
Please consider adding the production pool to the planned orders form. One of our customers is requesting this feature.
The production pool is equal to the buyer group – it is the same idea – buyer group for purchase items - production pool for manufacturing items.
The Buyer group can be added to the planned purchase orders – the production pool is not available.
After planned purchase orders are firmed, the ‘Approval status’ is default to ‘Approved’ on purchase order screen, which is skipping the purchase order workflow. Suggest to default the ‘Approval status’ to ‘Draft’ while workflow is enabled; or have a parameter like 'require workflow' to control planned purchase orders. Then the workflow process should work the same way as any other manually created purchase orders.
The reason is: the 'approve' and 'firm' on the planned order screen is normally used by the planning / purchasing department, then workflow is still required from purchase authorisation / financial point of view.
How are we supposed to maintain the Demand forecast if many users need to maintain demand lines based on different dimensions, such as Allocation key, Item number, Customer group, Customer account, Country/region etc.?
In AX 2012 R3 it is possibly to manipulate the Demand forecast in Excel using pivot tables and other Excel tools and purplish the changes back to AX.
This is not an option in Dynamics 365, it is possibly to export the forecast to Excel, but the manipulation tools and the possibility to purplish the changes back to Dynamics 365 no longer exists.
This Whitepaper shows from page 13 to 27, the possibility to manipulate the Demand forecast in AX 2012 R3:
How is it intended to be done in Dynamics 365?
The current logic it is not possible to configure a logical approach to limiting vendor deliveries.
The vendor calendar is a restrictor for the ordering and delivery days. This means if you open a calendar for Wednesday each week D365O believes the vendor is only open on Wednesdays, so you can only send the order on a Wednesday and they can only fulfil it on a Wednesday. In reality this is not a reflection of what is happening, generally you can submit the order on any day, and the delivery day is either when you fit into the delivery schedule for them or what you insist upon due to transport management smoothing. The Wednesday is when you want it, not necessarily the only day the "vendor" can deliver.
Part of the issue is if you have a requirement appear on a Thursday it assumes you cannot order it until the following Wednesday, and if you have a leadtime of 3 days it will deliver the Wednesday after - this is a week after in reality when they order could be delivered. Restricting the order date by the calendar makess little sense, having a shared calendar for order and delivery even less. If you then tick the working days flag it gets worse, the "3" becomes 3 weeks because the vendor is only open one day a week.
This needs to be reassessed to reflect what is happening in the supply chain.
The Planned orders and also the lists on Master planning workspace should also have at least the possibility to add InventTable.SearchName. The best would be Product name translation of the current session language.
It doesn't have to be in the actual form, but the view used for the form should be able to reach this. So the user can do a personalization to find it...
There is no way of reserverving items considering the lead-time of items without having lots of coverage groups with different positive days representing the lead time.
The introduction of "dynamic positive days" will improve the damand planning Process as well as material availability.
For production orders the reservation strategy "Explosion" should also be available, so the reservation behaves the same as with sales orders.
Benefit of Explosion Reservation:
The Explosion reservation only reserves on-hand inventory within the dynamic positive days' time frame. If the dynamic positive days interval is bigger than the period between requirement date and master scheduling execution date, Dynamics AX reserves on-hand inventory, as there is no possibility to replenish stock. As long as items can be replenished (dynamic positive days' time frame) there should be no reservation by master scheduling.
Benefit of master scheduling calculations:
The dynamic positive time interval considers the lead times (purchase, production, transfer) of items, therefore Master scheduling generates only new planned order if a planned receipt is outside the dynamic positive time interval to fulfill the requirement. If the master scheduling execution date is within the dynamic positive days' time frame no new planned order is generated as long there is available on-hand inventory. Furthermore, the setup of Coverage groups is simplified and the number of Coverage groups could be minimized.
The setting of parameters “use dynamic negative days” and “use dynamic positive days” should be located in Coverage groups. The use of the functionalities would be more flexible, as there is the possibility to control the items differently.
The formula for calculating dynamic positive days:
Dynamic Positive days = Lead time + Positive days
Conclusion: The functionality (logic of calculation) of Positive days stays the same with the enhancement that the positive days are dynamically calculated considering the lead times (purchase, production, transfer).
Suggested by Microsoft – Under Review – 1
Category: Master planningWhen firming planned transfer orders, it would be very useful to see the total weight or total volume of the multi-line transfer order that is about to be created. In distribution companies it is often attempted to make one transfer order fill a truck, weight or volume-wise. After the user has marked a bunch of planned transfer orders with the same FROM and TO warehouse the total weight and total volume would show up in a fact box, or somewhere on the side. This nicely supplements the load planning workbench functionality.
In Dynamics AX 2012, we can run MRP regarding session date.
[For investigation of mistake in the past]
End users sometimes take mistakes.
They had an experience of lost the order regarding the mistakes.
Obviously, this was a critical issue for them.
For preventing that situation, the root cause analysis is demanded.
Using MRP in the past, they would like to investigate the issue.
If the result of MRP is correct, user missed while confirming, shipping/receiving or invoicing order.
If the result of MRP is incorrect, initial orders were wrong.
For achieving the investigation, they would like to change the execution date of MRP as same as Dynamics AX 2012.
[For future estimation]
At same time, for the future date, the functionality is also useful.
They can create rough plan of keeping resource in future with MRP if it regards session date.
We have recognized a GAP in the forecasting system for Companies using configured Products.
For certain product the number of configurations can be very high or unlimited. These products must therefore be forecasted on either a "planning item" with at BOM representing the different configurational outcomes or through an item allocation key which is composed of "typical configurations".
The problem is that if the product is sold in a new configuration which does not match the forecasted items exactly on configuration ID, the forecast will not be reduced.
My suggestion is to make a new parameter in Requirement Group called "Forecast reduction on product level": Yes/No.
If this parameter is set, the forecast reduction will work on the forecasted item INDEPENDENT of the sold product configuration. The effect of this will be that the "planning item" forecasted quantity will be properly reduced by all sold configurations for the product.