In the earlier releases of SAP ERP, MRP referred to one specific planning tool. In contrast, SAP has already delivered many new features and tools related to MRP since the first logistics-inclusive release of SAP S/4HANA was launched in 2015.
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.
SAP S/4HANA and the latest releases of SAP ERP introduced a new MRP functionality called MRP Live, which was basically the same concept and the same logic, but improved for better performance on an SAP HANA database. Since then, the previously existing MRP and its transactions have become known as classic MRP to help differentiate between the versions.
Classic MRP has a set of transactions that you can use to plan your materials, allowing you to plan an entire plant, a single material, or a material and its components. It was entirely developed in ABAP, the SAP programming language used originally to develop SAP ERP, and it was designed to be executed in SAP GUI, the software installed on an end user’s computer to access SAP S/4HANA.
All the classic MRP transactions are still available and supported in SAP S/4HANA, but it is no longer the target architecture for the future. Although classic MRP can still be used in SAP S/4HANA, it is not recommended as a long-term solution; all the innovation in MRP will center on MRP Live.
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.
MRP is traditionally executed as a background job overnight, planning all the changed materials within one or more plants. To calculate the shortages for each material, the system needs to read all the relevant planning elements, such as sales orders, purchase orders, and production orders. Basically, every document that may consume or receive a certain quantity of material into stock is relevant for MRP and should be read from the database. This means that MRP should select large chunks of data from the database, and because of that and the complex algorithms executed during the planning run, MRP may take a long time to complete.
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.
Innovations in SAP S/4HANA were focused not only on MRP performance, but also on usability and user interface improvements.
In SAP ERP, the traditional user interface was SAP GUI, a program installed on the end user computer and used to access SAP ERP. In SAP GUI, you could run MRP and evaluate the results using different transactions—but a common complaint from end users was that those transactions were cumbersome and not intuitive or user-friendly.
SAP S/4HANA was designed with a strong emphasis on leveraging cloud computing technologies to support the future IT landscapes of companies running SAP. Therefore, there is a new web-based user interface called SAP Fiori. In SAP Fiori, the transactions have been replaced with applications, and there is a strong focus on usability and improving the overall user experience (even though you can still call old transactions in SAP Fiori). You can still use the old SAP GUI UI in SAP S/4HANA, but you can also access it through the web browser using different devices, like a tablet or a smartphone, by logging into the SAP Fiori launchpad.
A new set of MRP applications collectively called MRP Cockpit was delivered in the latest versions of SAP ERP. With SAP S/4HANA, these applications were enhanced, and new applications were created as an alternate way to evaluate MRP results. For the SAP Fiori applications of MRP Cockpit, SAP has placed a strong focus on identifying and resolving shortages that may lead to supply chain disruptions. This figure shows the Monitor Material Coverage app.
The SAP Fiori applications in MRP Cockpit were created with a role-based approach: different applications were designed considering the different roles of users that execute a business process step or transaction within the organization. SAP delivers standard business roles. For example, there is a generic role for the production planner, which will allow access to all the MRP Cockpit applications, but there is also a role specifically created for the planner responsible only for external procurement, which will only include the applications relevant for materials procured externally.
These SAP Fiori applications were also developed while focusing on improving the user experience and productivity and thus offer additional features, such as charts and visual highlights of issues.
SAP also keeps improving the apps; there are new features and improvements delivered in each SAP S/4HANA release. If you compare the MRP Cockpit apps delivered in the first release of SAP S/4HANA with the apps available in SAP S/4HANA 2023, you can easily spot improvements like new columns, new filters, and new action buttons to aid usability.
It is highly recommended to take advantage of these UI improvements and to use the SAP Fiori launchpad in any SAP S/4HANA implementation.
Since MRP was introduced in SAP ERP, there have been incremental improvements, but no major change in the MRP logic. In the last decade, however, a new concept called demand-driven MRP (DDMRP) became popular in companies of different industries, and it was finally introduced in SAP S/4HANA 1709.
Traditional MRP is usually based on a forecast (or on an actual sales demand in MTO scenarios), and the lower-level products are planned according to those forecasted quantities. Any changes in the forecasted quantities for the finished products may lead to huge changes and exceptions for the lower-level products. If the forecasted quantities are incorrect, you may end up with excess stock or low service levels.
The new DDMRP tries to create stock buffers for strategic materials, allowing the demand to be fulfilled by the buffer. These stock buffers will protect the lower-level products from any changes to the finished products’ demand and help reduce the total replenishment lead time. Because the demand generally can be fulfilled by the buffer, DDMRP helps to increase service levels, keeping optimal stock levels for your products.
SAP S/4HANA offers a new set of SAP Fiori applications that will help classify and define which specific products should be buffered, automatically calculate the buffer quantities, and plan and execute the replenishment in order to maintain the buffer levels. Technically speaking, the new DDMRP is a new MRP type in which a maximum stock level, a reorder point, and a safety stock are automatically calculated by the system according to the average daily usage of each product.
Although MRP is basically an operational tool, you often need to carry out simulations to understand how a change to the demand plan will affect the MRP results. For example, you might need to understand if your suppliers will be able to provide enough raw material or if you will have enough capacity in your plant to manufacture the forecasted quantities.
In SAP ERP, a tool called long-term planning (LTP) was used for simulation purposes. It was basically a simulated MRP, with very similar transactions and results. Although LTP is still available in SAP S/4HANA, a new functionality called predictive material and resource planning (pMRP), released in SAP S/4HANA 1909, can also be used for simulation purposes.
pMRP provides an improved graphical interface and a strong focus on capacity simulations, and it can be used to validate a demand plan. It also can be used in conjunction with the new DDMRP, allowing a forecast to influence the DDMRP buffer calculation.
Companies looking for a quick migration to SAP S/4HANA with minimal impact in the conversion project may consider classic MRP as a temporary solution, but a migration to the new MRP Live should be considered part of the future roadmap.
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.
Depreciation of MRP Lists: 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.
Finally, another key advantage lies in what is to come. The new MRP Live has been defined by SAP as the future architecture, which means that all the innovation in this area will be focused on MRP Live, rather than classic MRP. Therefore, it is highly recommended that new SAP S/4HANA implementations use MRP Live as their default planning tool.
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
It’s time to master MRP! This course guides participants through the steps of the MRP run, from setting up integral master data to configuring its outputs for optimized analysis. Explore advanced functions and the what-if scenario planning capabilities of SAP S/4HANA! Click on the banner below to learn more and order your ticket.
Editor’s note: This post has been adapted from sections of the book Material Requirements Planning with SAP S/4HANA by Caetano Almeida. Caetano has been working with manufacturing solutions in SAP for more than 14 years. In 2009, he joined SAP Product Support in Brazil, and since 2016, he has worked as a business process principal consultant for the SAP Center of Expertise, helping SAP customers resolve complex business and technical challenges.
This post was originally published 5/2021 and updated 8/2025.