One of the main new features delivered for production planning in SAP S/4HANA is the new MRP Live, which uses the power of the HANA in-memory database to improve the MRP performance. There are several differences between Classic MRP and MRP Live, and the most impactful simplification is the fact that MRP Live no longer generates MRP Lists.
The MRP list is basically a snapshot of the planning situation taken when MRP plans a material, and many planners were used to evaluate the MRP results using the MRP Lists, using transactions likeMD05 or MD06. Several companies are also using the MRP Lists tables to read the MRP results in custom programs or integrations with external systems and it is unclear how to proceed in SAP S/4HANA, now that MRP Live does not generate MRP Lists.
This blog tries to explain what can be done in SAP S/4HANA, now that the MRP Lists are gone with MRP Live. Let’s start understanding what is the MRP List, and it is gone.
What is the MRP List?
MRP was introduced in the SAP ERP a long time, when computers were not so powerful and there wasn’t so much memory and processing power available. It means that a transaction like the Stock/Requirement List (MD04), which is used evaluate the MRP results and selects a lot of data from many different tables, could take a lot of time to load.
Whenever a material is accessed in the Stock/Requirements List, system needs to read the stocks, sales orders, purchase orders, purchase requisitions, production orders and all the planning elements from the database, which means that it needs to perform dozens of selects in different database tables and process a lot of data. When running the collective access of the Stock/Requirement List (transaction MD07), all this data needs to be selected for dozens or hundreds of materials, and in the past, this was a huge concern from a performance point of view.
Therefore, SAP created the concept of the MRP List, which was basically a snapshot of the stock/requirements list taken after a material was planned by MRP and saved into a single table to be quickly accessed. With the MRP data saved into a single table, it was easy to extract it to other systems, or to read by custom reports.
While the MRP List brought a major benefit in terms of performance, there was also a major drawback, that is the fact that the MRP List can get very quickly outdated. As it is a snapshot of the planning situation taken during the MRP run, if a new sales order is created five minutes after a material is planned, it won’t appear in the MRP List. If a planner makes changes into the dates or quantities of a planned order, it will also not appear in the MRP List, until the next planning run. It basically means that using the MRP Lists is to rely in outdated information!
If the MRP Lists are relying in information that can become very quickly outdated, why they are still being used by several companies?
From a production planner perspective, the main advantage that you get by accessing the MRP List is to be able to use the Processing Indicator to mark materials that you have already reviewed after the MRP run. The processing indicator is automatically marked whenever we open a material, and it is reset whenever this material is planned again by MRP. The processing indicator is an easy way for the planner to identify which materials were already evaluated after the MRP and it is not present in other MRP transactions, like the Stock/Requirements List.
Very often companies also need to extract the MRP results to be used as an input for custom programs or external systems that integrate with the ERP. Since the MRP List saves data into a table, it can be easily read by custom programs or by any external system.
In both cases, however, we will be using data that is potentially outdated, because the planner will not see in the MRP List any changes that happened after the MRP run, and those changes will also not be present in the MRP List tables.
Why the MRP Lists are gone with MRP Live?
As explained earlier, the MRP List was introduced mainly as measure to avoid performance issues in older releases of the ERP and the information from the MRP List will very quickly become obsolete.
SAP S/4HANA runs on top of the HANA database, which is an in-memory database with built-in parallelism, and the Stock/Requirements List was improved to take advantage of the database. It means that, when we call the Stock/Requirements List, system is capable of reading several tables in parallel, so the stock/requirements list can be read much faster than in previous releases of the SAP ERP.
The new MRP Live was designed with a focus in performance improvement, so it wouldn’t make any sense to include an additional logic in MRP Live to aggregate the MRP results into a table, considering that this information would be quickly outdated and also because the actual information can be quickly read from the Stock/Requirements List.
Therefore, when we plan a material with MRP Live in SAP S/4HANA, it will not generate an MRP List. Only materials planned with the Classic MRP transaction (such as MD01) will still generate MRP lists. As explained in SAP note 2268085, however, the MRP List is part of the SAP S/4HANA compatibility scope, which comes with limited usage rights (see sap note 2269324 for details about the compatibility scope).
What should I do if want to use MRP Live in SAP S/4HANA but I need MRP Lists?
For planners who are used to evaluate the MRP results in ECC using the MRP Lists, SAP delivered a new set of MRP Fiori Apps, also known as MRP Cockpit. Those apps take advantage of Fiori to provide a modernized user interface and they can be opened directly in the browser, either in a computer or a mobile device.
While these apps do not provide a feature equivalent to the MRP List processing indicator, in the blog Why should I use the MRP Fiori Apps? I explained the main advantages of using the MRP Fiori apps. SAP has been delivering new features for those apps in each of the lastest S/4HANA releases and it is focusing in improve the design and the usability, therefore, planners should get use to these apps, as Fiori is the main user interface in SAP S/4HANA.
Alternatively, the Stock/Requirements List (transaction MD04) can also be called directly in the Fiori Launchpad, for old school planners who are used with the old SAP GUI transactions.
Companies that are still using the MRP List tables to extract data, should consider using an API to read live data, instead of reading outdated information that was aggregated into a table after the MRP run. SAP Note 2268085 suggests that function module MD_MDPSX_READ_API can be used to read the stock/requirements information in custom programs or even in interfaces with external systems.
If using an API is not a possibility and you really need to read data from a table, SAP offers report RMDMRPEXTRACT01, which extracts the planning data and saves it into a custom table. This report can be scheduled to be executed shortly after the MRP run, in order to save the results into the table.
In order to use this report, we need to create an implementation of BAdI MD_SR_LIST_EXTRACT, where we will define the table where data will be saved and which fields will be saved. SAP delivers an example implementation, where we can extract Days‘ Supply Evaluation without Planning, Purchase Orders due/delayed or the Stock Information.
Be aware that, just like the MRP List, information in the custom table will become quickly obsolete, so it is a good idea to execute this report more often, so that the planning information in the custom table doesn’t get too outdated.
Conclusion
- Companies that keep using Classic MRP to be able to use MRP Lists, are not getting all the benefits of the new MRP Live.
- As MRP Lists are part of the S/4HANA compatibility scope, they will no longer be supported in the future, so we need to avoid relying in the MRP Lists on a new SAP S/4HANA implementation.
- Fiori is the main User Interface in SAP S/4HANA and SAP keeps improving the MRP Fiori apps.
Nenhum comentário:
Postar um comentário