MRP Live
MRP Live is a new version of MRP that was created to maximise performance when using a SAP HANA database. The entire MRP logic, including database selection, is performed directly on SAP HANA in MRP Live.
This means that SAP HANA handles all of the MRP steps, from net requirements calculation to replenishment proposal creation.
In this section, we will look at the main MRP Live functionalities, restrictions, and transactions.
Introducing Transaction MD01N and Report PPH_MRP_DISPATCHER
To run MRP Live, a new Transaction MD01N and report PPH MRP DISPATCHER were created. We had different transactions available in classic MRP to execute a total MRP run (MD01), a single-item, multi-level MRP (MD02), and a single-item, single-level MRP (MD03) (MD03).
Transaction MD01N replaces all of those classic MRP transactions by providing more flexible selection criteria, with more fields and selection options, as shown in Figure.
However, MRP Live cannot be used to replace multi-level, make-to-order planning (Transaction MD50) or individual project planning (Transaction MD51). As a workaround, classic MRP transactions should be used, or the header material should be planned within MRP Live with the flag BOM Components checked to ensure that all components are checked.
Transaction MD01N was also designed with the simplification concept in mind.
As a result, we will notice some differences when comparing it to traditional MRP transactions:
In Transaction MD01N, the creation indicator for purchase requisitions and schedule lines does not exist. This means that MRP Live generates purchase requisitions for materials obtained externally or on a schedule.
when a schedule agreement is mentioned on the materia source list For performance reasons, the creation indicator for MRP lists is also not available in MRP Live. This means that MRP Live does not generate MRP lists. If you must create MRP Lists, the material should be planned using traditional MRP transactions (such as MD01).
Otherwise, you can examine the MRP results using the stock/requirements list.
Because you can now select one or more plants in Transaction MD01N, the scope of planning is no longer required. MRP Live can also automatically determine the sequence of plants for planning, making the scope of planning obsolete. Transaction MD01N does not support the processing key NETPL (Net Change in the Planning Horizon). This processing key was created to limit the MRP run on the planning horizon in order to speed up the MRP run. Because MRP performance is much improved with MRP live, this processing key and the planning horizon concept are no longer relevant.
The flag for determining whether parallel processing should be used is not available in MRP Live; parallel processing is triggered automatically by the system. It is also not necessary to define the parallel processing destinations in Transaction OMIQ because they will be determined automatically based on the server group.
The fields user exit key and user exit parameter are not available. User exits SAPLM61C_001 and EXIT SAPMM61X_001 were used in classic MRP transactions to allow the user to select which materials would be planned by MRP, and the most common use was to plan all of the materials of a specific MRP controller. The MRP controller is already available as a selection criteria in Transaction MD01N. If a different selection criterion is required, the product group or material multiple selection can be used as a selection criterion.
Aside from transaction design changes, there are some MRP process changes to consider:
Old MRP BAdIs are no longer called on MRP Live
Because MRP Live is fully executed on SAP HANA, it is not possible to trigger an ABAP code during the MRP run, so none of the existing BAdIs are called.
MRP Live does not support total requirements.
Total dependent and sales requirements, like traditional MRP transactions, are not supported by MRP Live.
MRP Live only supports subcontracting with MRP areas.
On a subcontracting scenario, a separate planning segment is created for each vendor in a traditional MRP transaction. This functionality, however, is no longer available in MRP live. This implies that the subcontracting scenario must be linked to MRP areas. As a result, in customising, we must create an MRP area for each vendor and assign this MRP area to the materials that will use the subcontracting scenario.
Only for all releases is lead-time scheduling available.
Lead-time scheduling was added to MRP Live with EHP 8. In previous releases, planned orders for internally procured materials had basic dates calculated based on the in-house production time defined in the material master, and capacity requirements for those planes orders were not created.
The proposals for replenishment are reusable.
Unconfirmed planned orders and purchase requisitions were not necessarily changed during the MRP run in the case of a quantity or date change in classic MRP transactions. If the date or quantity of a replenishment proposal must be changed by MRP, the replenishment proposal is deleted and a new one is created in MRP Live. Essentially, this means that the number of existing planned orders and purchase requisitions in MRP Live may be changed more frequently.
Exceeding the maximum number of purchase proposals per day specified in customising does not result in MRP Live termination.
In MRP customising, a maximum number of purchase proposals per date can be defined, and if this value is exceeded during the MRP run in classic MRP transactions, the MRP run for this material is terminated. However, in MRP Live, the system generates as many purchase proposals as are specified in customising, and termination no longer occurs.
Because MRP Live is a new tool, some very specific settings have yet to be implemented; a complete list of those restrictions can be found in SAP Note 1914010.
This does not preclude materials using one of those settings from being planned with MRP Live. When MRP Live encounters a setting that is still not supported, it can switch back to the classic MRP logic. The material will be planned without issue using traditional MRP logic. However, this is not the best approach for achieving optimal MRP Live performance
By analysing the MRP Live results in Transaction MD01N, we can determine which materials had a restriction and which had a classic MRP executed. The system displays how many materials were planned directly in SAP HANA and how many were planned using traditional MRP logic on the MRP Live results screen.
By clicking the button Materials with messages on the results screen (see Figure), we can see which materials could not be planned with MRP Live and which had to be planned using traditional MRP logic.
Figure shows the materials with messages after the MRP Live execution.
By clicking the Solve Issue button, you will be redirected to the master data where this restriction is found (usually the material master), where you can change your settings and avoid this restriction to ensure that the material is planned with MRP Live.
The number of replenishment proposals generated by MRP Live may differ from the number of replenishment proposals generated by classic MRP in very specific scenarios. This occurs when we use a reorder point MRP type with external requirements (such as MRP type V1), or when we use a safety stock.
This occurs because, in classic MRP, the quantity of the safety stock (or reorder point) is added to the replenishment proposal created to cover the first requirement, whereas in MRP Live, a separate replenishment proposal is created to cover the safety stock. Despite the fact that MRP Live generates more replenishment proposals, the total number of replenishment proposals generated should be the same as the total quantity on classic MRP.
Check Master Data Using PPH_CHECK_MRP_
ON_HANA
SAP has also created a new report to check the master data to assist you in determining which materials are using a setting that is not supported by MRP Live. This report’s name is PPH_CHECK_MRP_ON_HANA. and is
SAP Note 2143063: Evaluating the material masters for MRP live is delivered on the standard system. This report can be used on older releases that have not yet been enhanced for SAP HANA.
With this report, you can evaluate all of your materials and determine which can be planned using MRP Live and which should be planned using traditional MRP transactions. The fact that this report is available for other releases is intriguing because it allows you to review all of your master data before upgrading.
When your system encounters a restriction or a setting that is not yet supported by MRP Live, it can switch to classic MRP logic and plan a material. However, in terms of performance, it is always preferable to plan with MRP Live.
The report interface is straightforward, with selection criteria including Plant, Material, MRP Controller, Low-level code, and Message.
We can find all of the restrictions considered by this report by checking the values of the Message field (see Figure) and filter the results for each of those messages.
These are the same messages that MRP Live generates, and they can be found by selecting Materials with messages.