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:
| Feature | Classic MRP (t-codes MD01/MD02/MD03) | MRP live (t-code MD01N) | Related Note/KBA |
| Scope of planning | MRP parameter “Scope of planning” can be used to combine a group of plants or MRP areas. | Scope of planning is not supported. MRP Live can plan many materials in many plants. It always plans all MRP Areas. |
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.
- The selection screen of MD01N transaction should be enhanced with MRP area criterion.
- 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.
- Materials selection logic of MD01N should be enhanced to handle selection by MRP area and MRP controller on MRP area level.
- 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.
- SAP Managed Tags:
5 Comments
