Did you ever wonder why Master planning takes so much time processing hundreds of thousands of items, while you only have demand for a fraction of these items?
We recognized this with several customers which had around a million items. The majority of the items were simply required in their system to allow looking up parts from older bills of materials, which were not sold actively anymore. Or the items were used for maintenance or replacements which were only needed ‘on demand’.
You can set an item to get planned manually on different levels. You can assign an item to a coverage group with coverage code Manual. Master planning settings on a warehouse can be set to exclude it from master plan. Coverage settings for the item and for specific product dimensions set or a specific warehouse can be set to Manual. Even though the items, or a specific variant in a specific warehouse, was marked as Manual, MRP would still check if the item needed to be included in the plan. That was a price to pay for a very flexible way of setting up coverage settings for your items. Imagine that MRP needs 10 ms for each item to figure out if it needs to be included. Do this times 1 million, and you still need almost 28 hours to process this. Using planning helpers might make a difference of course, by making sure this is handled in parallel threads, which make sure total run time is less. But this is still quite a lot of work when you know most of these items never need to be replenished.
Good news! An update is released for Microsoft Dynamics AX 2012 R3 which may be able to help you reduce Master planning run time considerably. You can find this hotfix on LCS using issue search, entering hotfix KB 3159477:
For Dynamics AX 2012 R2, the same update is available with KB 3181387:
This will show you more details about the hotfix also, but I would like to add some more details.
The changes in this hotfix are only triggered when running a Complete master plans!
First important part of this new logic is that it is built to improve run time of complete master plans. If you run master planning for a subset of items by using Select button in the master scheduling dialog form, the new logic will NOT be used, and Master plan will simply be processing all the items again which match the selection criteria you entered. Master plan is supposed to be run for all items anyway, so please make sure that, unless you want to update requirements for a few items, you clear the selection criteria.
Only works if you set Master planning parameters.
Please notice two new fields in the Master planning parameters form:
The Pre-processing: Automatically filter by items with direct demand parameter is making sure that, during the pre-processing phase in the master plan, AX will run several queries which probe for demand in the following places:
- On-hand inventory. It will look for records with Arrived, Ordered, Quotation receipt, On-order or Quotation issue, Reserved ordered and Reserved physical quantities. So basically all items with some kind of expected receipt or issue will be included.
- On-hand inventory warehouse management items. AX will look at these separately due to difference in how Reserved physical or reserved ordered quantities are being registered.
- Safety stock. It will look for items which have been setup with safety stock (Minimum on-hand inventory).
- Forecast demand. It will look for any forecast demand records (invent) with a date later than today.
- Forecast supply. It will look for any forecast supply records (invent) with a date later than today.
- Continuity plans. Include any continuity lines from Call center module yet to be created.
If an item does not meet any of the above criteria, it will not be included in the master plan.
Note: This also means that an item, which has physically available on-hand inventory, would previously be included, and would show a requirement transaction for the on-hand inventory. In the new situation, it would not show a requirement transaction anymore, since there is no demand for the item.
With the list of items updated, MRP will only run through these items during the next phases of the master plan after the pre-processing.
The Post-processing: Automatically filter by items with direct demand can be set also. Just before the coverage step can start, there is a pre-coverage step, in which items with coverage setting “BOM version requirement” set to true need to be reprocessed, in order to make sure that the items from the required BOM are planned. This may lead to situations where items, which in pre-processing were considered to have both on-hand and demand, could now have just on-hand and no demand, so they can be excluded from planning. If you do not use “BOM version requirement” in your coverage groups, you do not need to set this.
What difference does it make?
The actual impact on performance always depends on many different things of course. If you have direct demand for almost every item, the difference will not be that big. If Master plan needs to do a lot of planned order scheduling, and this is using up majority of the time, the difference will not be that big. The biggest differences you will see when you have, let’s say, a million items, but only demand for 50.000 of these items. The overhead for checking the 950.000 items before this update had a rather big impact on update phase and coverage phase of the master plan. By filtering out all these items, it could save up to several hours.
One example before applying this update:
After applying the update:
Some other differences you might notice is the number of items in your Master plan session logs. Where before, this would show all items that exist, it now only shows items with direct demand. The master plan is however treated as a complete plan, which makes sure plan version is renewed and InventSumLogTTS records are getting deleted.
Number of planned orders should be around the same as before. There can be slight difference when items exist with physical negative stock levels. When coverage settings for items show a minimum inventory level of 0, planned orders would be generated to correct this physical negative stock to 0. However, the queries that are looking for demand do not look at negative on-hand inventory when minimum inventory is 0. When you look at the design of this change, it however makes sense, as a physical negative stock level does not necessarily mean there is demand.
Again, be aware that this change does not make a difference if you specify a filter when scheduling an MRP run. If you specify selection criteria, AX will simply schedule all the selected items, and not check for demand.