Sorun Cevaplayalım

İşinizle ilgili öngörüler edinin, gerçek zamanlı bilgilere göre karar alın.

SAP Eğitim ve Sertifika Dönemleri

Uzmanlığınızı ve deneyiminizi SAP çözümleri kullanarak tasdik edin.

Çözüm Ekibi Başvurusu

Kullanıcılara hızlı ve pratik çözümler üreterek görev almak isteyenler.

SAP BLOG S/4HANA MRP – to Live or not to Live: MRP areas of reponsibility

SAP Blog

Kayıtlı Üye
22 Ara 2017
Tepki puanı

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:

FeatureClassic MRP (t-codes MD01/MD02/MD03)MRP live (t-code MD01N)Related Note/KBA
Scope of planningMRP 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.

  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:

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

Okumaya devam et...