MRP Live: Checking the MRP logs and forcing a material to be planned in ABAP with transaction MD_MRP_FORCE_CLASSIC

SAP S/4HANA introduced the new MRP Live (transaction MD01N), which drastically improves the MRP performance. With MRP Live, the source code that was originally executed in ABAP was pushed down into the HANA layer, allowing MRP to take advantage of HANA in-memory capabilities and internal parallelization to improve the MRP performance. It basically means that MRP Live is executed in HANA stored procedures, rather than executed in ABAP.

However, there are still some settings which require MRP to be executed in ABAP, even if we are running MRP Live in transaction MD01N, and SAP note 1914010 provides a complete and updated list of those restrictions. When MRP Live finds one of these restrictions, it automatically switches to the classic logic and the material with the restriction is still planned in transaction MD01N.

There are very specific cases, however, where we need to force a material to be planned with the classic logic in ABAP. The most common reason for forcing a material to be planned with the classic logic is when we have an ABAP BAdI implemented, which must be executed for some specific materials. Since MRP Live is runs in the HANA layer, the ABAP BAdIs are not called, unless we force the material to be planned with the classic logic.

Transaction MD_MRP_FORCE_CLASSIC was developed specifically to allow you to choose which materials should be planned with the classic logic.

In the initial screen, the transaction allows you to choose for which materials you would like to see the details.

The results screen, shows when the material was planned by MRP Live and if any kind of restriction was found for this material, which lead this material to be planned with the classic logic, as we can see below. In addition to that, in recent S/4HANA releases, it will also show any issue that might have happened during each of the steps of the MRP run (BOM explosion, scheduling, etc…).

Besides the MRP Live logs, this transaction also shows any restriction that might prevent a material to be shown in the MRP Fiori apps in column App Issue.

Whenever system finds a restriction, you can try to remove it by clicking the button Solve Issue. Considering the example shown above, the first line shows that a material was planned with classic MRP because MRP type X0 was set in the material master, therefore, if we click the button Solve Issue, we will jump into material master tab MRP1, where we can change the MRP Type.

When we click the pencil button, fields “Classic MRP” and “MRP Apps” will be open for changes, as shown in the following figure.

By checking the flag Classic MRP you will force a material to be planned with the classic MRP logic and by changing the value of the field MRP Apps, you can choose whether a material will be displayed on the MRP Fiori Apps or not. Here, it is also possible to accept a specific issue, and there is a parameter in the selection screen that allows us to define whether accepted issues will be shown or not when the report is executed.

Forcing a material to be planned with the classic logic in MD01N will ensure that all the materials that can be planned in HANA and materials that must be planned in ABAP (due to a BAdI implementation or a specific restriction) can be planned together, in the same MRP job. However, you should always consider that, with many materials being planned by the classic logic (ABAP), the MRP Live performance will not be optimal.

Therefore, whenever it is possible, you should try to get rid of those restrictions and ensure that most materials are planned in HANA, in order to achieve an optimal performance.