Suggested by Microsoft – Planned - Short-Term – 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.
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.
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.
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).
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.
We can set Quantity on Resource load in Route for using resources effectively.
However, the setting is not sufficient for the scenario which has "peak" orders.
- 10 quantities are created per 1 day by 1 resource.
- 1st April: 1 order with 3 quantities.
- 2nd April: 1 order with 4 quantities.
- 3rd April: 1 order with 4 quantities.
- 4th April: 1 order with 100 quantities.
- 5th April: 1 order with 4 quantities.
For this scenario, there are no problem for 1st, 2nd, 3rd, 5th.
But at 4th April obviously there are lack of resources.
Then "Delay" was occurred for the order 4th April.
For resolving "Delay", we need to modify the Route before running MRP.
(Adding resources to the Resource group in Route and change Quantity on Resource load.)
In this way, we can resolve Delay but we need "Re-modify" the Route to the old setting.
It does not make sense as we always need to monitor the all of demand orders.
MRP should automatically solve the "Delay" using resources in Resource group.
Or we should edit the Route manually in planned order after created by MRP.
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.
The innovation in AX 2012 to add forecast consumption by "any transaction" was very important. It closed the gap for the Assembly to Order business scenarios.
These scenarios require forecasting on a level below a configured end product. The forecast is maintained on major subassemblies that represent product options.
The item allocation key is the other piece of the solution, It represents the product line and we can indicate , with percentages, our expected breakdown in the configuration options we are hoping to sell. This mechanism creates forecasts on the option level using a total forecast on a product line level. In summary:
- we can forecast on second level
- we can consume forecast on second level.
But one detail creates a problem in this scenario. These major assemblies that are being forecasted with a percentage (the base unit gets 100%) are often a phantom BOM. Companies do that to keep engineering revision control out of the configurator model as much as possible. If the configurations themselves do not change from the customer perspective, but engineering improvements take place leading to BOM changes and routing changes, we can handle that below the phantom level. The configurator model calls up the phantom item, which is not changing. This is a common choice for ATO companies.
In AX the part numbers in the item allocation key with their percentages would be phantoms. All works fine as long as my planned production order for my configured end product is still planned. The dependent demand created by this planned prod order consumes the forecast on these major assemblies , represented by phantom part numbers. The forecast is consumed as expected. But as soon as I firm my planned prod order for my configured end item, the phantom part numbers disappear from the resulting Prod-BOM and my forecast consumption is instantly reversed.
We need to find a way to have this forecast consumption NOT be reversed but stay in place. We want the logic to be a little different. In order to determine the forecast consumption quantity, the code should always look up one level in the BOM structure and determine how many sales orders were booked for the parent of the phantom item. It should not count on always getting dependent demand for itself because it will have that only temporarily, being a phantom.
This is our suggestion to accommodate a common scenario for Assembly to Order companies.