Introduction

Right after I published the previous installment of S/4HANA MRP – to Live or not to Live mini series S/4HANA MRP – to Live or not to Live: Planning scope I realized that the way MRP Live handles MRP areas has even more profound consequence.

MRP Live blurs the boundaries of responsibility areas. It makes it impossible for a MRP controller to take control of their materials if MRP areas are used.

First, let’s look at two terms.

SAP Glossary defines MRP controller as:

The person responsible for a group of materials in MRP in a plant or company.
Material that takes part in material requirements planning must be assigned to an MRP controller.

Notice, that a MRP controller is a flesh and blood person, who assumes responsibility of MRP planning. It should never be just a group of products.

MRP controller configuration features fields as “telephone” or “recipient name” that confirm the above.

MRP controller configuration settings

SAP Glossary defines MRP area as:

An MRP area represents an organizational unit for which you can perform material requirements planning separately.
An MRP area can include one or several storage locations of a plant or a subcontractor. You can define MRP areas in a plant.
By defining MRP areas, you can perform MRP for each area. This means the right quantity of materials can be provided on time for each area, such as a production line, a storage location for spare parts, or subcontractor stock.

Here the key statement is that MRP areas are planned separately. Also MRP relevant material master data is maintained for each MRP area independently, here including MRP controller assignment.

MRP areas are to be planned separately. Materials can be managed by different MRP controllers in different MRP areas.

MRP areas in MRP Live

MRP areas are prominent in S/4HANA. They are obligatory. They have superseded storage location MRP. Subcontractor’s stock planning relies heavily on them. In my opinion these are the changes in the right direction as MRP areas are powerful tool in MRP planning, often underutilized.

However the way MRP Live handle MRP areas is peculiar at least. Note 2640393 – Differences between t-code MD01N and classic MRP t-codes MD01/MD02/MD03 reads:

Lack of selection by MRP areas in MD01N transaction confirms the above statement.

Selection screen of MD01N MRP Live transaction

Selection of material for MRP run is performed by method GET_PLANNING_FILE_ENTRIES of class CL_PPS4_MRP_DISPATCHER, by queries similar to this one, around line 30:

    SELECT dbvm~matnr,
           dbvm~berid,
           marc~werks,
           dbvm~gsaen,
           CASE WHEN mara~disst = ' ' THEN '999'
             ELSE mara~disst
           END AS disst,
           CASE WHEN dbvm~berid <> dbvm~werks THEN mdma~sobsl
             ELSE marc~sobsl
           END AS sobsl,
           marc~dispo,
           marc~beskz,
           t438a~disvf,
           CASE mara~kzkfg  " fill groupid so that all variants belong to same group as KMAT
                         " logic for PP/DS RPM, here only plant specific SATID is taken into account
             WHEN 'X' THEN marc~scm_matlocid_guid16
             WHEN ' ' THEN marc_kmat~scm_matlocid_guid16
           END AS group_id,
           dbvm~num_mdps,
           dbvm~num_rto_header,
           dbvm~num_rto_item,
           CASE marc~ppskz
             WHEN 'X' THEN
               CASE t438a~cbppt
                 WHEN '6' THEN ' ' " Plan in ABAP but read components from PPDS -> do not send to PPDS
                 ELSE 'E'          " send to PP/DS
               END
             ELSE ' ' " in future here we can already determine whether ABAP or Hana is to be started
           END AS mrp_kind
      INTO CORRESPONDING FIELDS OF TABLE @lt_pfe
      FROM pph_dbvm AS dbvm
      INNER JOIN mdlv  ON dbvm~berid = mdlv~berid
      INNER JOIN mara  ON mara~matnr = dbvm~matnr
      INNER JOIN marc  ON marc~matnr = dbvm~matnr    "table names and alias must be in sync with CON_TABNAME_MARC and CON_MARC_ALIAS in method AUTH_TO_SQL
                      AND marc~werks = mdlv~werzg
      INNER JOIN t438a ON marc~dismm = t438a~dismm     "#EC CI_BUFFJOIN
      LEFT OUTER JOIN marc AS marc_kmat ON marc_kmat~matnr = mara~satnr " find KMAT for material variant, only MARC-level
                                       AND marc_kmat~werks = marc~werks
      LEFT OUTER JOIN mdma ON mdma~matnr = dbvm~matnr
                          AND mdma~berid = dbvm~berid

      WHERE dbvm~plscn = '000'
        AND dbvm~matnr IN @it_so_matnr
        AND mara~picnum EQ ' '                          "only non SUS materials
        AND mara~imatn  EQ ' '                          "only non MPN-MRP set materials
        AND marc~werks IN @it_so_werks
        AND ( marc~dispo IN @it_so_dispo OR mdma~dispo IN @it_so_dispo )
        AND ( dbvm~gsaen IN @lr_gsaen
             OR dbvm~rhytd <= @iv_dispd AND dbvm~rhytd <> '00000000'      " rhytmic dispo shall take place if material fits
            )
        AND marc~lvorm <> 'X'      "not marked as deleted
        AND disvf IN @lr_disvf
        AND dbvm~sc_empty = ''
        AND dbvm~nodisp = ''       " exclude materials with "No MRP"
        AND (iv_sql_fragment)
        .

Notice the line:

AND ( marc~dispo IN @it_so_dispo OR mdma~dispo IN @it_so_dispo )

The selection is performed by MRP controller (DISPO field) both on plant level (MARC table) and MRP area level (MDMA table) with OR operator.

Also notice that there is no provision for selection by MRP areas in the SELECT statement.

As result MRP controller is not able to select material assigned to them on MRP area level. MRP Live run is very likely to inadvertently plan materials assigned to other MRP controller.

Let’s analyze the following simple case:

A single material is assigned to MRP controller A on plant MRP area level and to MRP controller B on storage location MRP area level. It means that the material is to be planned separately in both MRP areas and two different people are responsible for the planning there.

Now, if I run MD01N for the material as MRP controller A, it’ll also run on storage location MRP area i.e. within the responsibility scope of MRP controller B.

The same is true the other way around. If MD01N is run for MRP controller B with an intention to cover only their MRP area and their responsibility scope, MRP situation of the material will change for both MRP controllers.

MRP Live makes both MRP controllers to step on each other’s turf! Those guys will not be happy!

Solution proposal

To give MRP planners control back over their areas of responsibility, I’d suggest the following solution.

1. The selection screen of MD01N transaction should be enhanced with MRP area criterion.
2. Optionally another selection criterion of MRP controller on MRP area level could be added. That might be necessary depending on the final materials selection logic implemented.
3. Materials selection logic of MD01N should be enhanced to handle selection by MRP area and MRP controller on MRP area level.
4. Additional authority check should be implemented to prevent MRP Live run on MRP area to which a user don’t have privileges. Similar checks are already implemented AUTH_TO_SQL method of CL_PPS4_MRP_DISPATCHER class.

In my opinion those are relatively simple enhancement that would improve usability of MRP Live tremendously.

Vote to support MRP planner control over MRP areas: https://influence.sap.com/sap/ino/#/idea/249785

Disclaimer: Opinions and views expressed herein are solely my own.