Technical Articles
S/4HANA MRP – to Live or not to Live: MRP areas of responsibility
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.
Wow !!! This is just called a perfect business analysis. I love how you take a closer look at the topic and break it down into prime factors using real examples.
I am surprised that nobody paid attention to the problems and dilemmas you mentioned. MRP planners should kiss your hands that you talk about such topics – I am surprised that the blog has no comments !! Great work, really – I can’t believe again how SAP could have skipped such issues during the development of S / 4 HANA.
Really these are very important comments … it looks like you have worked your whole life as an MRP planner
Do you know what I like the most about your blogs? that although my knowledge of SAP is seventy levels below yours and I don’t understand anything at first glance – you are giving examples that make a blog understandable for an average like me !! Awesome article !! Congratulations!!!!!
Dear Dominik,
we identified that in the S/4 MRP world (MRP classic and Live) PPH_DBVM entries are are a must, that means even if there is no automatical planning set (DISVF = N) , the systems creates PPH_DBVM records with NODISP = X.
We are a big retailer using classical MRP, that means we will create massive useless data in PPH_DBVM.
Have you came across this issue at any of your customers or is there any change to avoid the record creation ?
Thanks + regards
Stefan
Dear Stefan Gempp
I think there is really no issue here and you are not creating useless records.
PPH_DBVM table is S/4HANA implementation of MRP planning file. It replaces the following tables (planning file implementation in ECC) - see the note 2642499 - Planning File Entry Differences between S/4HANA and ERP
A planning file entry is created whenever a material MRP data is created with MRP type different than ND - see the note 1890440 - Materials are not planned by MRP. Planning file entry is marked with NODISP = X if a material MRP type is set to ND and it's no longer visible in the MD21 transaction.
S/4HANA uses planning file (table PPH_DBVM) both for classic and live MRP.
So whichever MRP type you use, you need the planning file, which is PPH_DBVM table in S/4HANA.
HTH
Best regards
Dominik Tylczynski
Thanks Dominik for your quick reply!
Perhaps it was a small misunderstanding. We are ok with the usage of new PPH_DBVM table, also for classic MRP. Our point are the planning file entries with NODISP = X if a material MRP type is set to ND. Our MARC is about 230 mio entries, but the majority ist ND, so there are a lot ND entries in PPH_DBVM which we don't need.
But anyway, we opened an OSS incident and see what the support ist telling us.
Thanks + regards
Stefan
Dear Stefan Gempp
Thanks for the clarification. I see your problem now. Indeed S/4HANA creates PPH_DBVM record with NODISP=X even on material master MRP view creation with ND MRP type. I think it'd better to just not create a planning file entry in this case or delete a record instead of setting NODISP=X. But possibly I'm missing something here.
I'd appreciate if you share the outcome of the OSS ticket.
Cheers
Dominik