In standard material requirements planning (MRP) transactions, data is selected sequentially from each database table. That means the system selects each planning element from the table and the record selected is processed by ABAP code. If this record is considered as a valid MRP element, it is included in the internal table MDPSX. At the end of the process of data selection from the database, this table stores all the MRP-relevant planning elements, and this information is considered for further processing during the MRP run.

This approach has been part of the standard MRP for several years and it works very well with traditional SQL databases. However, SAP HANA is a very disruptive technology, which offers much more power and features that are not present in the old databases. For example, instead of selecting data sequentially, the parallelization available on SAP HANA allows several tables to be read at the same time, improving the overall performance of the data selection.

To take advantage of all the new features of SAP HANA, as of SAP enhancement package 6 for SAP ERP Central Component (ECC) 6.0 (version for SAP HANA), the classic MRP transactions are optimized to run on an SAP HANA database. The data selection process in the old MRP transactions was completely redesigned and, instead of selecting data sequentially and processing each record after the selection, all the data selection is triggered at the same time on the SAP HANA database, where the tables can be selected in parallel.

After selection, an ABAP code carries out the post-processing, and the planning elements are available on the internal MDPSX table. Therefore, there is no visible change to the users from the classic MRP transactions, despite the performance improvement.
 

How to Activate the MRP Performance Optimizations

Even on a system upgraded to the latest releases, the MRP performance optimization is not active by default. Therefore, you can still run the old MRP without any kind of enhancement.

To activate the performance optimizations for MRP, SAP HANA must be the primary database. Having SAP HANA as a secondary database (side car) does not suffice.

If SAP HANA is your primary database and you want to activate this functionality, the first step is to open Business Add-In (BAdI) PPH_MDPSX_DBSYS_OPT. To open this BAdI, execute transaction code SE18, and in the screen that appears (Figure 1), ensure that the following steps are carried out:

• Enhancement Spot PPH_DBSYS_OPT is active.
• There is an active implementation of BAdI PPH_MDPSX_PREPARE_READ.

Figure 1

BAdI PPH_MDPSX_DBSYS_OPT

In Figure 1, double-click Implementations (on the left), and the screen shown in Figure 2 displays. If you select the option Filter Val. (filter values), you see that the value HDB was set to filter DBSYS_TYPE. This value corresponds to the SAP HANA database. It is the default value for this implementation delivered by SAP on the standard system.

Figure 2

Enhancement Implementation PREPARE_READ_MDPSX

After you complete the above steps, the performance optimizations for MRP on SAP HANA are active on your system. Note that the optimization is only available for MRP, not for Long Term Planning (LTP).

When to Use the Classic MRP Transactions and When to Use MRP Live 

In the classic MRP transactions, only the selection of the planning elements from the database have been optimized, whereas on MRP Live, everything is executed on SAP HANA. Therefore, there are design differences between the classic MRP transactions and MRP Live.

Because MRP Live is fully executed on SAP HANA, there are some functionalities from the classic MRP transactions that are not feasible in the new MRP Live mode. For example, if you use transaction code MD01N to execute MRP Live, an MRP list cannot be generated and you must evaluate the MRP results using transaction code MD04 only.

Another restriction is that the existing BAdIs are not called by MRP Live, as it is not possible to call an ABAP code during MRP Live execution in SAP HANA. This is also a restriction for the optimization on the MRP classic transactions. However, because only the database reading was optimized, the restriction is only valid for the BAdIs that are called when data is being read from the database (such as BAdI MD_CHANGE_MRP_DATA). You can use BAdI MD_ADD_ELEMENTS to replace them.

If you need to call a custom code in a BAdI or you need to generate MRP lists, it is also possible to define that a specific material be planned according to the classic MRP logic on transaction code MD01. In order to do that, you must run transaction code MD_MRP_FORCE_CLASSIC and select the materials that always will be planned with classic MRP.

There are also some features that are not yet supported for MRP Live, such as coverage profiles, discontinuation, and direct production. When one of these restrictions is found for a material, the system automatically changes to the classic MRP logic.

Every quarter, MRP Live is enhanced; therefore, a feature may not be supported yet, but it may be included on a future Support Package. A complete updated list of the MRP Live restrictions can be found on SAP Note 1914010.
 
From a performance point of view, MRP Live should be used when planning a large number of materials. When MRP Live is executed, the time spent planning each material is generally smaller than on the classic MRP transactions. However, the SAP HANA optimizer consumes a fixed amount of time to optimize the SAP HANA code (in other words, to translate the code into SAP HANA low-level code). This is a fixed time and it does not depend on the number of materials planned.

On the classic MRP transactions, data is selected on SAP HANA and post-processed on ABAP. This means that if you are planning a small number of materials, the classic MRP transactions can be faster than MRP Live, as the SAP HANA optimizer is not called. When you are planning a large number of materials, the time spent by the SAP HANA optimizer will not be relevant. Therefore, MRP Live is faster than the classic MRP. SAP estimates that for planning up to 100 materials, classic MRP is generally faster than MRP Live.

There are two very useful reports that can be used to compare the performance of classic MRP and the MRP Live:

• RMMDMONI: Classic MRP performance log
• PPH_MRP_PERF: MRP Live performance log

Optimizing the MRP Live Performance: Examples

In this section, I analyze some test cases to illustrate some points that were already discussed and to show how to get the optimal performance on MRP Live using SAP HANA.

For the first example, consider a material that was planned in less than one second on a classic MRP transaction (all the materials used in this example have the same settings as the same average number of planning elements).

Now I plan the same material with similar planning parameters on MRP Live. In order to do this, execute transaction code MD01N. As shown in Figure 3, in the Planning Scope section of the screen, populate the Plant and Material fields, and select the Regenerative Plng (regenerative planning) check box. In the Control Parameters section, enter a value in the Planning Mode field (e.g., 3) and click the execute icon to start the MRP run.

Figure 3

Populate fields for a single material before executing the MRP run

The next screen (Figure 4) displays with the MRP Live results. Note that the system took eight seconds to plan this material.

Figure 4

MRP Live results for a single material

In principle, it looks as if the system is taking more time to plan using MRP Live on SAP HANA versus classic MRP.

Considering the first MRP run in which a single material was planned in eight seconds, you might expect the system to take  aproximately 80 seconds to plan 10 materials. However, if you now execute transaction code MD01N again for the same material, plus nine additional materials (551 to 560, as shown in Figure 5), you have a different result.

Figure 5

Calling MD01N for 10 materials

Click the execute icon in Figure 5 to view these results in the next screen (Figure 6).

Figure 6

MRP Live results for 10 materials

In Figure 6, if you analyze the MRP run time, you see that the system took only 23 seconds to plan 10 materials, not the anticipated 80 seconds. Now execute transaction code MD01N again and this time increase the number of materials planned to 18. After you click the execute icon, the results of this MRP Live run appear in Figure 7. You can observe that the total planning time has increased to only 33 seconds. The conclusion is that the MRP Live run time does not grow proportionally to the number of materials planned.

Figure 7

MRP Live results for 18 materials

Why don’t you have a total MRP run time proportional to the number of materials planned on MRP Live? The answer is that the SAP HANA optimizer consumes a fixed amount of time on the beginning of the MRP Live execution, but planning each material is faster with MRP Live.

Consider another example: running MRP for an entire plant. In this example, you  run regenerative MRP and Planning Mode 3 to ensure that all the materials were planned and that all the planning elements were recreated (Figure 8).

Figure 8

Calling MRP Live for a plant

Click the execute icon to start the MRP Live run and the results of the MRP Live run are shown in Figure 9.

Figure 9

MRP Live results for a plant

A total of 89,927 materials were planned by MRP. From those 89,927 materials, 84,683 were planned on SAP HANA by MRP Live. However, for 5,126 materials, the system found a restriction and ran the classic MRP, and for 171 of those materials, MRP failed. Note that the value displayed in the Matls Plnd (materials planned) column considers a material and plant combination, whereas the values in the Mat. Failed (materials failed), Classic MRP, and MRP on HANA columns consider a material and MRP area combination. Therefore, the total number of materials planned will match the sum of materials failed, materials planned with classic MRP, and materials planned with MRP on HANA only if each material is planned in one MRP area. If there are materials planned in more than one MRP area, then the sum of these fields can be higher than the value in the Matls Plnd column.

In Figure 9, compare the SAP HANA MRP Live planning time with the classic MRP time. Note that 84,683 materials were planned in 188.5 seconds, but the classic MRP spent 140.0 seconds to plan 5,126 materials.

In this example it becomes very clear that MRP Live is much faster when you are planning a large number of materials. It also becomes clear that to optimize the MRP performance, you must reduce the number of materials planned with classic MRP to a minimum level.

If you click the Materials with messages button in the MRP Live results screen (Figure 9), you can see exactly which materials were planned by classic MRP and the restrictions that preventing the system from planning these materials on SAP HANA. These messages are shown on Figure 10.

Figure 10

Materials with messages

Why are there so many materials planned with classic MRP? The answer is that there are still some features that are not yet supported by MRP Live, and when a material is using one of these features, it is planned with the classic MRP logic.

•  Avoid the features that are not yet supported by MRP Live so that you can have as many materials as possible planned directly on SAP HANA instead of being planned with classic MRP in ABAP.
•  Avoid planning in small batches of materials so that the time spent on the SAP HANA optimizer can be reduced between more materials and become irrelevant when compared with the total MRP run time.

How to Review the Master Data to Get the Best Performance Improvement on MRP

You have seen that a key factor to achieving optimal performance is to increase the number of materials planned with MRP Live. Therefore, you must get rid of the scenarios that are not yet supported.

Checking for all the materials with messages after each MRP run would be very time-consuming. Therefore, SAP provides a report specifically to evaluate the production planning (PP) master data on your system and to identify which materials cannot currently be planned with MRP Live.

Report PPH_CHECK_MRP_ON_HANA is delivered by default on Support Package 5 of SAP Enhancement Package 7 for SAP ECC 6.0, and it can also be found in SAP Note 1975704. This report can be implemented on systems that are running on previous releases, even without SAP HANA, so that you can estimate the effort of the master data optimization. This is very useful if you are planning an upgrade of your system, so that you can estimate the necessary changes on your master data and customizing.

The interface of the report is displayed in Figure 11. The selection criteria are well known to anyone familiar with the MRP concept. These fields include Plant, Material, MRP controller, Low-Level Code, and Message.

Figure 11

Report PPH_CHECK_MRP_ON_HANA

To view a list of the messages and the number of materials that cannot be planned by MRP Live due to a restriction message, select the Compact Display radio button and click the execute icon (Figure 11). This results in the screen shown in Figure 12.

Figure 12

Report PPH_CHECK_MRP_ON_HANA compact display

In the highlighted line of Figure 12, note that 85 materials were planned with classic MRP because the Fix and Split indicator is set on the lot-sizing procedure defined on the material master. In this case, if you want to plan these materials with MRP Live, you must use a different lot-sizing procedure.

In Figure 11, if you select the Detailed Display radio button and click the execute icon, you can view a list of all the materials and their respective messages if they cannot be planned by MRP Live (Figure 13).

Figure 13

Report PPH_CHECK_MRP_ON_HANA detailed display

How Can MRP Live Give You a Competitive Advantage?

Caetano Almeida

Caetano Almeida is a computer engineer with an MBA in IT management. He has more than nine years of experience in production planning, with the last six years working at SAP Support, where he supports SAP customers and writes documentation and correction notes.

You may contact the author at caetano.almeida@outlook.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.