SAP S/4HANA offers two different options to execute MRP: classic MRP and MRP Live. To understand when to use classic MRP versus MRP Live, we need to understand a little bit about MRP design and the differences between the options.
Because it needs to run a large data selection from the database and to execute complex algorithms to calculate shortages and create replenishment elements, MRP is usually a performance-intensive application.
In SAP ERP, the database was usually a performance bottleneck for the MRP execution because too many MRP elements had to be selected from the database and processed by ABAP code. Classic MRP was originally designed with logic by which, for each material to be planned, the planning elements were selected individually from the database; each planning element selected was postprocessed by ABAP source code, which would check if it was a valid element for MRP. For example, classic MRP would first select planned orders, and then each planned order would be validated by ABAP source code. Then MRP would select production orders, and each order would be validated. Then it would select purchase requisitions, and so on, until it finished reading and validating all the planning elements.
When SAP launched SAP HANA, a powerful in-memory and columnar database, it was clear that MRP performance could be improved by it. But though this traditional MRP logic worked fine for many years in SAP ERP, it did not take advantage of SAP HANA’s internal parallelism, meaning that running MRP on an SAP HANA database would not result in major performance gains. To extract the best of the SAP HANA resources and tune the MRP performance, the underlying logic of MRP had to be completely redesigned.
The first performance improvement delivered by SAP was to redesign the data selection from the database during the MRP run. Instead of selecting the MRP records one by one, MRP optimized for an SAP HANA database would trigger the whole data selection at once and allow the SAP HANA internal parallelism to work its magic. In a second step, ABAP code would post-process and validate all the planning elements selected from the database, and the rest of the MRP logic would remain the same.
This change improved the MRP performance, but it was restricted to the data selection. There was still room for improving the overall MRP performance through the power of the SAP HANA database. Therefore, MRP Live was created, pushing the MRP logic into the SAP HANA database and allowing an in-memory planning run, which was much faster than classic MRP.
The figure below shows a comparison between MRP in SAP ERP, classic MRP in SAP S/4HANA, and MRP Live. This figure highlights which pieces of code were moved into the SAP HANA layer, and you can see that most of MRP Live runs on SAP HANA.
Note: In SAP ERP on SAP HANA, the performance optimizations for classic MRP and the new MRP Live should be activated by a business function. In SAP S/4HANA, however, the performance optimizations for MRP are active by default.
The new MRP Live is executed in a different transaction, which means that we can choose whether we want use classic MRP or MRP Live for planning. It also brings some simplifications and changes when compared with classic MRP, so if we need to choose which one to use, it is important to understand those differences.
One of the simplifications with the most impact is related to MRP lists. When MRP was created many years ago, it used the concept of the MRP list: a static report that provides a screenshot of the MRP results for each material. The MRP results were saved into a single table, which could be easily and quickly accessed by the user after the MRP run.
SAP S/4HANA offers the new MRP Live and the SAP Fiori applications of the MRP Cockpit, which means faster MRP and a new user interface to evaluate the MRP results. In addition, the performance was improved in the classic MRP transactions, such as the Stock/Requirements List, which means that the user can work always with live data, instead of analyzing a screenshot of the past MRP run. With all those new features, the MRP List became obsolete, so when we run MRP Live in the new transaction, Transaction MD01N, the MRP List will no longer be generated during the planning run.
MRP Lists were traditionally saved into table MDKP, MDTB, or MDTC, and those tables were commonly used for the creation of custom reports based on the MRP results. Those reports will not work when using MRP Live because they will no longer be updated.
Tip: SAP recommends that function module MD_MDPSX_READ_API be used in custom reports to read the information previously read from the MRP list tables. Another option is to use the MRP extractor (report RMDMRPEXTRACT01) to save the MRP results into a custom table.
Another simplification that affects MRP Live is related to creation indicators, which allow us to choose whether it should create planned orders, purchase requisitions, or delivery schedules for materials procured externally. MRP Live will not use creation indicators, nor does it offer the option to create purchase requisitions only within the opening period defined in the scheduling margin key.
MRP Live will always create purchase requisitions for materials procured externally, or it can create schedule lines when a valid scheduling agreement is selected as a source of supply. If the creation of planned orders for materials procured externally is still required during the MRP Live planning run, we can use the ABAP-managed database procedures (AMDP) BAdI PPH_MRP_SOURCING_BADI => SOS_DET_ADJUST to change the MRP element to be generated during the planning run. Another alternative is to use the handover purchase requisitions feature, which was introduced in SAP S/4HANA 2020. It will create purchase requisitions that will not be immediately relevant to purchasing until they are handed over by the MRP controller.
The last major difference between MRP Live and classic MRP is related to the BAdIs available to implement any custom code. While classic MRP is almost entirely written in ABAP, the new MRP Live logic was pushed down into the SAP HANA layer, meaning that it is almost entirely executed with SAP HANA stored procedures. This change allowed for a performance improvement, but classic MRP BAdIs that were previously executed in ABAP will no longer be called in MRP Live. This means that any custom logic written in ABAP-based BAdIs will have to be translated into the new AMDP BAdIs provided by SAP in MRP Live.
Tip: If it is not possible to translate a BAdI into its respective AMDP BAdI, we can use Transaction MD_MRP_FORCE_CLASSIC to force a material to still be planned in ABAP, even when using the new MRP Live transaction, Transaction MD01N. If we force too many materials to be planned in ABAP, however, we may not see any performance improvement when using MRP Live, so it is always advisable to use the new AMDP BAdIs.
One additional feature of MRP Live is the possibility to plan PP/DS advanced planning materials when PP/DS is used in SAP S/4HANA system. We can combine PP/DS and the MRP planning run in a single job, reducing the effort of synchronizing different jobs for materials planning. This feature is not available in classic MRP; it is a major improvement delivered for MRP Live.
Finally, MRP performance is also a major difference between MRP Live and classic MRP. MRP Live was developed to improve MRP overall performance because the planning run can take hours to be executed. However, note that though MRP Live is much faster than classic MRP when planning large sets and very complex materials (e.g., materials with complex BOMs), classic MRP can still be faster when planning a few simple materials.
These critical differences are key when deciding whether to use the new MRP Live or classic MRP, but they are also important for defining a migration strategy to SAP S/4HANA. For example, companies that currently rely heavily on MRP lists or on custom reports based on MRP Lists will have to carefully plan steps to migrate to MRP Live by adapting the custom code.
Warning: MRP lists are part of the SAP S/4HANA compatibility pack and won’t be supported by SAP after 2025, even in classic MRP.
5
Another thing to consider is that it is possible to adopt MRP Live gradually, rather than abandoning classic MRP and exclusively using MRP Live all at once. For example, we can adopt a hybrid approach: use MRP Live for planning large sets of materials and taking advantage of the performance improvement, but keep using classic MRP for single-item planning, in which we can see the results before saving and for which classic MRP performance might still be better.
However, a note of caution here: before defining any migration strategy or choosing between MRP Live and classic MRP, always keep in mind that MRP Live has been defined by SAP as the target architecture, which means that new features and improvements will mostly focus on MRP Live, rather than classic MRP.
11
Editor’s note: This post has been adapted from a section of the book Material Requirements Planning with SAP S/4HANA by Caetano Almeida.
Comments