Integration issues in S/4HANA – Evaluation of MRP planning results
The S/4HANA MRP – to Live or not to Live: MRP lists blog article has shown the importance of MRP lists to efficient MRP usage and how S/4HANA MRP Live is crippled without them.
To summarize the main points of the blog:
MRP exceptions of the group 5 and 8 are not available in stock/requirements list collective display i.e. MD07 transaction. Therefore MRP Live lacks a tool to conveniently deal with MRP run errors.
MRP exceptions of the group 4 are not available in stock/requirements list collective display i.e. MD07 transaction. Therefore MRP Live lacks a tool to conveniently fine tune MRP related master data.
MRP Live lacks a tool to focus MRP controller attention on materials that really need their attention and a tool to shield MRP controller from irrelevant MRP exceptions that have already been dealt with.
Despite substantial positive feedback and support the improvement proposal to bring MRP lists back in MRP Live has been rejected: https://influence.sap.com/sap/ino/#/idea/249067
MRP list in compatibility scope
The problem is exacerbated by the fact MRP lists as such, not only in MRP Live context, are part of S/4HANA compatibility scope – as per note 2268085 – S4TWL – MRP Live on SAP HANA – MD01N:
Classic MRP is still available in SAP S/4HANA. MRP lists are part of the SAP S/4HANA compatibility scope, which comes with limited usage rights.
It means that past 2025/2030 S/4HANA customers will not be able to use MRP lists no matter what MRP they run – MRP Live or classic MRP. See the note 2269324 – Compatibility Scope Matrix for SAP S/4HANA and the blog Compatibility Scope: What Happens after 2025/2030.
With that, S/4HANA loses capabilities to evaluate MRP planning results. Yes, that is correct – without MRP lists it is not possible to evaluate MRP planning results; it is not possible to tell if MRP correctly responded to demands and created procurement proposals as expected.
In order to correctly evaluate MRP planning results, they need to be compared with the demand at the time of planning, not with the current demand at the time of evaluation! That is a huge, fundamental difference, especially in fast changing business environments, for each MRP Live is advocated.
MRP lists are the only tool to do that. Stock/requirements list or S/4HANA Fiori apps like Manage Material Coverage present current demand/supply situation, not the situation at the time of an MRP run.
Fortunately the problem is quite easy to rectify in two steps.
First, SAP should take MRP lists off S/4HANA compatibility scope and let the customers choose if they prefer classic MRP with the lists or MRP Live. This way if a customer opts for classic MRP, they would still be able to enjoy its full functionality.
Second, once MRP lists usage is allowed past 2025/2030, they can be brought to MRP Live with a custom report of the following logic:
- Get all the materials for which MRP Live has run. The same data access as in Display MRP Master Data Issues can be used here.
- Split materials into two groups: one for the materials planned correctly, another for the materials with planning errors.
- For all material with planning errors, convert the errors into corresponding MRP exceptions of group 5 and 8.
- For all correctly planned materials:
- Read stock/requirements lists with either the BAPI_MATERIAL_STOCK_REQ_LIST or with the RMDMRPEXTRACT01 and the MD_SR_LIST_EXTRACT BAdI
- Convert the stock/requirements lists into MRP list format. That should not be complex as stock/requirements list and MRP list are almost of the same structure.
- Save data from point 3 and 4 as MRP lists in SAP standard tables. This way the results can be analyzed with standard MD05 and MD06 transactions.
The report will need to be run right after MRP Live planning. They could even be put in the same background job.
Of course, the custom report proposal is just a workaround, not a perfect one as demand/supply situation may still change between MRP Live run and the report execution. Nevertheless, it is unlikely and the workaround is better than nothing.
I would try building such a report and make it publicly available, if SAP removes MRP lists from S/4HANA compatibility scope.
Good blog post, thank you Dominik!
Here is the improvement proposal https://influence.sap.com/sap/ino/#/idea/298863
It needs at least 6 company votes to be considered by SAP.
👍 Vote now ! 👍
Great article, Dominik! SAP should have a former MRP controller/planner as part of their team. Then they wouldn’t make such incorrect decisions.
Thank you Ann!
The improvement proposal https://influence.sap.com/sap/ino/#/idea/298863 to keep the MRP lists as they are has already gained 9 votes, which is above the required 6. Therefore it will be considered by SAP. The big question is what they are going to say...
Thank you for pushing this, don't give up. I have read your other blogs and agree 100%. Sorry I missed the voting on this. We have been on S4 Hana for over a year and our business users will not accept MRP Live due to MRP lists not being supported. They absolutely require the ability to refer back to the snapshot MRP results, and we even save a history of the MRP results because they often have to go back further to settle disputes. Without MRP Lists we will have to customize heavily and I can't see any good reason SAP would take this functionality away, and not even provide an option. Maybe MRP Live would run a bit slower but that should be up to the customer to decide. Why take away a valuable tool?
Hi Dominik Tylczynski,
Pretty interesting reading. Thank you for it!
I would like to hear opinion from the "other side" (SAP) how absence of MRP list should be tackled in day to day operations.
BTW. You have my vote on 298863!
Hi Stepan Kadera
The official position is that new Fiori apps have been provided to monitor supply chain. However they all are based on the current demand/supply situation. Simply, the MRP lists cannot be replaced with those apps. I have explained the use cases of the MRP lists. They have not been questioned by SAP, but that has not changed to decision. It is pretty strange to me.