Why should I use transaction MD05 to analyze the MRP results?
The stock/requirements list (transaction MD04) is the most requently used transaction to analyze the MRP results. It’s a very useful transaction because of it’s flexibility, which allows you to see the MRP elements, stocks and change the MRP elements according to your business needs.
However, there is another transaction called MRP list (MD05) which is very often forgot during the MRP results evaluation. MD05 is quite similar to MD04, and the main difference is that MD04 is dynamically updated, while MD05 shows the results of the last MRP run. Basically, MD05 is a screenshot of the last MRP run. That means, if you create or change or delete any MRP element after the MRP execution, this change will be reflected on MD04, but not on MD05.
If transaction MD05 is not dynamically updated, then why should I use it?
First of all, keep in mind that transaction MD05 does not replace MD04, however, there are some scenarios where MD05 is very useful.
Below there are some examples:
1 – Analyze the exception messages triggered during the MRP run: The MRP List (MD05) is builded during the MRP and it shows the exception messages that were triggered by MRP. The Stock/Requirements List (MD04) is builded when the MRP elements are readed from the database and the MRP logic cannot be completely reproduced here. Therefore, the exception messages from MD05 may be completely different than the exception messages from transaction MD04.
This is especially relevant when evaluating the rescheduling exception messages and the differences will generally arise when lot sizing procedures different that EX are used. The difference between both transactions arise because the lot sizing procedure is not considered when importing the planning elements from the database on transaction MD04. Notes notes 29703, 1794796 and Question 3 of the FAQ note 550441 provide more detailed explanation of such differences.
The differences between the exception messages may also apper on another scenarios, such as discontinutaion or when a quota arrangement is used.
2 – To know exactly when this material was last planned by MRP: Sometimes it looks like some materials were not planned by MRP at all. Using transaction MD05 it is possible to know exactly when a material was last planned by MRP and if all the requirements were covered (tip: if the material was not planned by the last MRP run, check the planning file on transaction MD21).
3 – See the planning results exactly how they were after the MRP run: In some cases, you may observe uncovered requirements, missing planning elements or unjustified replenishment proposals after the MRP execution. Using transaction MD05 and comparing the results with MD04 allows you to know clearly when a requirement or planning element was created, changed or deleted after the last MRP run and this is a very useful tool for troubleshooting.
4 – Check errors that happened during the MRP run: When an error happens during the MRP execution, the planning run for this material is terminated. If you check the results on transaction MD04, you will simply find uncovered requirements, however, the termination error message is logged and it can be found on the MRP list.
5- Performace: Transaction MD04 reads each planning element it’s respective database table on each call and. For a material with a huge number of planning elements, it means that long selections will be executed and it can take some time to finish loading. Transaction MD05 simply reads the MRP results stored encrypted on a table and this is generally faster than MD04. Therefore, MD05 can be used for a quick view of the planning elements, in case of performance issues on MD04.