Basics of MRP Area

 The purpose of this document is to explain the basics of MRP area, steps involved in activating MRP area and to use it in different possible ways.

As we know MRP runs at plant level (centralized), but as per business need we may have to plan MRP for individual & independent planning areas (decentralized). This can be achieved by activating MRP areas. These MRP areas are fully configurable organizational units within ECC where MRP can be run individually. So we can broadly classify running MRP in 2 major ways.

• MRP at plant level: The system adds together stocks from all of the individual storage locations to determine total plant stock. The requirements are combined in the planning run and procurement elements are created for these pegged requirements with unknown sources. Individual storage locations can be planned separately or be excluded from planning.

Illustration:

• MRP area level: Only the stocks from the storage locations or subcontractor assigned to the respective MRP area are taken into account. The requirements in this particular MRP area are combined and procurement elements are created for them. This enables us to plan material requirements specifically for certain areas (MRP areas).

Illustration:

You can define MRP areas within a plant and carry out MRP specifically for that particular area, for example in above illustration, for MRP area M0001 can be planned independently without running MRP for plant FP01.

In each MRP area you can control staging and procurement of parts that are produced in house or externally. All MRP procedures are supported by MRP areas and one can display the result of MRP run for each MRP area.

MRP Area (definition):

As per SAP, “MRP Area represents an organizational unit for which material requirements planning is carried out independently”

MRP Area is functionality for special planning process that enables you to carry out planning not only at plant level but also at different planning levels (eg, storage location & sub-contractors). There are 3 types of MRP areas in SAP

• Plant MRP Area
• MRP Areas for storage location
• MRP Areas for Subcontractors

Plant MRP area:

MRP area can be created at plant level. On doing so, system combines all its storage locations and stock with subcontractors under that MRP area. When you define MRP areas for storage locations and for subcontractors and assign material to newly created MRP areas with in plant then the plant MRP area gets reduced by exactly the numbers of subcontractors and storage locations. This is because they will now be planned separately in new MRP areas.

MRP area for storage location:

MRP area can also be defined for storage location or multiple storage locations. Material requirements for this storage location are then planned separately from the rest of the plant. Important point to note here is that you can assign 1 storage location to only 1 MRP area but you can have multiple storage locations under single MRP area. It’s a N to 1 relationship.

MRP Areas for Subcontractors:

You can also define an MRP area for each subcontractor. Important point to note here is that a subcontractor can be assigned to only one MRP area in a plant. An MRP area of the subcontractor type can only contain one subcontractor. It’s a 1 to 1 relationship.

How to setup MRP area in SAP

There are 2 aspects of setting up MRP area. First one is to activate it in customizing and second part it to set up master data (i.e. adding materials to that particular MRP area in material master).

MRP with MRP area is not operational until you assign MRP area to a particular material in material master or in order words create a MRP area segment. If you have not assigned a material to an MRP area, that is, you have not created an MRP area segment in the material master, the material will continue to be planned in the plant MRP area only.

Step 1 – Converting Planning file entries

Path: SPRO > Production > Material Requirement Planning > Master Data > MRP Areas > Convert Planning file entries for MRP areas – OM0F or SE38 program RMDBVM00

When we convert planning file entries for MRP area, system creates plant MRP area for each plant. Following entries from below tables are converted. Planning file entries are maintained in MRP file which are converted to MRP area file in below tables.

Planning file entries in MDVM are converted to DBVM

Planning file entries in MDVL are converted to DBVL

Planning file entries in KDVM are converted to KBVM

Planning file entries in KDVL are converted to KBVL

If you are running converting planning files for the first time then system will automatically create plant MRP areas. These new entries can be seen in OMIZ under plant MRP area with area type “01”.

IMP note: After the conversion, contents of MDVM/MDVL/ KDVM/KDVL are deleted and entries are created in DBVM/ DBVL/ KBVM/ KBVL.

Step 2 – Define MRP area in SPRO – OMIZ

Path: SPRO > Production > Material Requirement Planning > Master Data > MRP Areas > Define MRP areas

MRP area has 3 types (01, 02 & 03) and system will allow you to have MRP areas in below types only (Plant, Storage location or Sub Contractor)

Plant MRP area should have same name as plant so you can have only one entry for plant MRP area. For example plant 1000 will have plant MRP area as 1000.

In order to maintain consistency and uniformity, only MRP areas of the type ‘plant’ are allowed to have 1-4 digits key. Sloc MRP area should have minimum of 5 digits. Example M0001 etc…

You can only have 1 sub-contractor vendor assigned to 1 MRP area. Multiple vendors cannot be grouped together in a single MRP area.

You can have multiple storage locations combined together in a single MRP area.

You can only one entry for plant in plant MRP area. Multiple plants cannot be grouped together in a single MRP area.

Once MRP area is defined, next step is to Activate MTP area

Step 3 – Activating MRP Areas – OM01

Path: SPRO > Production > Material Requirement Planning > Master Data > MRP Areas > Activate MRP for MRP areas

NOTE: MRP areas are activated at client level. Once you activate it, it will be available for all plants and MRP areas features would be available to use.

This sums up setting up MRP area configuration in SAP customizing.

You can find following changes due to activation of MRP area. These are just few for example

MD61 – PlR creation

MRP

Material Master

Stock Requirement list

Step 4: Master data for MRP area

The material will not be considered in MRP area planning until it’s extended to MRP area.  Following steps shows how to extend a material in MRP area. You can extend a material to multiple MRP areas based on the need.

Go to change material master under MRP 1 screen and assign MRP area as shown below:

You will have additional views for MRP 1, MRP 2, Forecast & Consumption values. You need to fill required fields as per your need.

When you assign a material to a new MRP area, a new record for this assignment gets added in the planning file. You have an option to define individual MRP and forecast parameters for each MRP area that you assign to a material. These parameters can differ from those defined in the material master at plant level. As an example, you can have different MRP controllers, lot size or MRP type for each individual MRP areas that is assigned to a material.

Users can set up different forecast model and consumption values in MAR area tabs. Once MRP with MRP area is activated, ATP check is also activated at MRP area level.

Scope of planning with MRP area

You can create scope of planning run if you want to carry out total planning for limited MRP areas. In case you do not give any MRP area in total planning run, system will consider all MRP areas under a plant and plan for them in total planning.

For single item planning system, in MD02 & MD03 system plans a material only in the specified MRP area.

Sample Scenario:

Let’s consider a material Assembly maintained in plant ZSY1 under 2 storage locations (ZSY3 & ZSY4)

Sloc ZSY3 maintained in MRP area MA001. Assembly is extended to MA001 with following stock situation

ZSY3 – 100 (under storage location MRP area MA001)

ZSY4 – 150 (under Plant MRP area ZSY1)

Lot size for same material is maintained as FX (fixed lot size) in MA001 MRP area and EX in plant MRP area ZSY1

Total stock MMBE

MD04 – MRP Area ZSY1

MD04 – MRP Area MA001

Let’s have requirement from a Sales order for plant ZSY1, it will come under plant MRP area ZSY1

For testing, we can also have PIR created for specific MRP area MA001

Here is the stock situation of MD04 with sales order in Plant MRP area

Stock requirement for MRP area MA001:

If we run MD02 for plant ZSY1, system will only consider plant MRP area and will not plan for MRP area MA001 as it’s a separate planning area

MRP area MA001 is untouched:

After running MRP for MA001 system creates planned order for 200 quantities

Material Assembly was maintained as EX lot size in plant MRP area and with fixed lot size 200 in MA001 hence planned order of 200 Qty created in MA001. In this way separate planning parameters can be maintained to run requirement planning using MRP areas.

~~~~~~~~~~~~~~~

Thank you for reading this document. Please feel free to suggest any change and modification needed to improve the document.

*Scenarios related to MRP areas will be covered in a separate document. The link will be added below once completed

Source: https://blogs.sap.com/2015/07/01/basics-of-mrp-area/

S/4HANA Classical MRP vs MRP Live

 

Classical MRP:

The main function of material requirements planning is to guarantee material availability, that is, it is used to procure or produce the required quantities on time both for internal purposes and for sales and distribution. This process involves the monitoring of stocks and, in particular, the automatic creation of procurement proposals for purchasing and production.

In doing so, MRP tries to strike the best balance possible between

• optimizing the service level and
• minimizing costs and capital lockup.

The automatic planning run in MRP determines any shortages and creates the appropriate procurement elements. The system generates messages for critical parts and unusual situations so that you can rework the planning results in a specific area with problems.

MRP Live:

Using MRP Live, you can benefit from improved performance and execute the planning run in much shorter cycles. This means that you can execute several planning runs daily providing the MRP controller with the following benefits, for example:

• More up-to-date supply and demand information on which to base decisions.
• Faster reaction to demand changes reduces the risk of stock-outs and means that you can reduce safety stocks.
• Match demand and supply more efficiently than was previously possible.
• Identify and react to issues faster than was previously possible.

The report MRP Live (with the technical name PPH_MRP_DISPATCHER) is a copy of the report RMMRP000 and provides the following options for carrying out the planning run:

• MRP Live (transaction MD01N) calls MRP on HANA
• MRP Live (transaction MD01N) calls classic MRP

Planning selection MRP Live and Classical MRP

During the planning run, the system plans the materials according to the sequence determined by the low-level codes that are defined in the bill of materials. That is, for the first low-level code (0), the system determines which materials can be included in MRP Live on HANA and plans these first. In a second step, the system determines the materials with the same low-level code that could not be planned in MRP Live on HANA and then automatically plans these materials using classic MRP. Included in this second step are also the materials that were planned in MRP Live on HANA but for which an error occurred. Both the planning in MRP Live on HANA and classic MRP has to be completed for one low-level code before the system commences the planning of the next low-level code (1).

That is, during the planning process, the system divides the materials into groups:

• Materials that can be planned using MRP Live on HANA
• Materials that still have to be planned in classic MRP because:
  • They require a planning feature that is not yet supported by MRP Live.
  • You have set the Plan in Classic MRP indicator in transaction md_mrp_force_classic. In this report, the system displays all materials with active MRP views in the material master and you can define that the planning run is to be executed using classic MRP for individual materials. You should check which materials require the processing of a BAdI during the MRP run and always set this indicator for these materials.
• Materials that cannot be planned in either MRP Live on HANA or in classic MRP because of inconsistent master data, for example. The system creates exception MRP lists for such materials that cannot be planned.

Parameters Differences

Additional References:

https://launchpad.support.sap.com/#/notes/2268085

Best Regards,

Lingaiah

Source: https://blogs.sap.com/2019/03/25/s4hana-classical-mrp-vs-mrp-live/

Configuring Automatic packing in Outbound Delivery

 Configuration for Automatic packing in Outbound Delivery

Let me introduce you to the basics required to understand the Automatic packing concept in outbound delivery.

1. Packing Materials are material that can be used to pack or transport goods.
2. Items from an outbound delivery when packed into a packing material, the whole unit together is called the Handling Unit.
3. Packing process in SAP is the process of assigning delivery items to packing materials, which will produce Handling Units, which will then be packed into additional packing materials. Which in turn will create a new handling unit, this process of packing one handling unit into another packing material is called Multi-level packing.

The packing function is available in:

• Orders (as Packing Instructions)
• Inbound Deliveries
• Outbound Deliveries
• Shipment Document

Packing can be done manually as well as automatically in outbound delivery. Manual packing is done in outbound delivery by choosing PACK button manually while automatic packing uses the Condition Technique to automatically identify the material to be packed and create handling units.

As most of us would be aware of how manual packing is done, in this document I have explained how automatic packing is configured for outbound delivery.

I have noted down few steps that would be required to configure Automatic packing, these are listed below:

     a)      Activate Delivery Document type with Automatic Packing – OVLK

     b)      Define Packaging material type- VHAR

     c)      Define Material Group for Packaging – VEGR

     d)      Define Allowed Packing Material – VHZU

     e)      Define Material Master Data – MM01

     f)       Maintain Packing Transaction Profile for Outbound delivery – OVHU2

     g)      Set up Condition Technique for  Packing Instruction Determination

     h)      Create Packing Master Data – POP1

     i)       Maintain Packing Instruction Determination Master Data – POF1

Let us see how each of these steps are accomplished in SAP with screenshots

a)      Activate delivery type with Automatic  Packing

In this step you can activate the delivery type for automatic packing using the TCode OVLK as shown below.

Before moving further lets understand below mentioned SAP terminologies

Material – A product in outbound delivery that requires packing.

Material Group for packaging – This is a material master field used to group products requiring similar packing. For example say products A and B can be packed using similar pallets, in this case while creating product master data for A & B, we assign Material Group for Packaging, say 0001-pallets to indicate that both these material are packed using pallets.

Packing Material – The material used to pack the finished product in delivery.

Packaging Material Type – This is Material Master record field used to set up a Packing Material.(Applies to packing material master data) This field defines the family of packaging type to which this material belongs, for example Pallets, Truck, Container, Box, Crates, etc.

b)      Define Packaging material types

You can define Packaging Material Types using TCode VHAR. As discussed earlier this field plays an important role in setting up a packing material master record.

Let’s say we use already defined packing material type 0001- pallets in our case.(If you want to create new please copy an existing one that matches your requirement and create one) PFB the screenshot for the same.

For packing material type you can set up

• How plant determination occurs for the packing material to which it is assigned.
• Packaging material category (whether packaging material, transport equipment, means of transport or Auxiliary packaging material)
• Assign a Number Range for the handling units that would be created in delivery.
• Define Output procedure and Output type.
• Handling Unit type

c) Define Material Group for Packaging Material

In this step you can define a Material Group for packaging material using TCode VEGR.

This is a field entered in the Material Master Sales: General/Plant data for materials that require packing. It is used to group together materials that require similar packaging materials.

In our case we defined material group 0001-Yard Mgmt using tcode VEGR.

d) Define allowed packaging material

This configuration plays an important role in packing for outbound delivery. In this step we define valid combinations of Packaging Material Type and Material Group for Packaging as shown below. We have defined a valid combination of “Material Group for Packaging”- 0001 Yard Mgmt and “Packaging Material type”- 0001 pallet for our scenario. It is maintained using TCode VHZU.

When packing an item in delivery, the system checks whether an entry for Material Group for Packaging for the delivery item and the Packaging Material Type for the packing material exists in Tcode VHZU.

By assigning Packaging Material Type to the Material Group for Packaging, you define which packaging materials are allowed for packing a delivery item.

For materials with no Material Group for Packaging Materials, no check is carried out on the eligibility of the packaging material. These materials can always be packed.

e) Define Material Master Data (Finished goods and Packing Material)

In this step create Material master record(MM01) for Finished goods and Packing Material based on the configuration done in the earlier steps.

Firstly define a FERT material code for Sales View having below data related to packaging.

As can be seen in above screen shots we have created a material TATA1 with Material Type FERT and Material Group for Packaging Material as 0001- Yard Mgmt.

Now, create another Material master record(MM01) with Material Type VERP (packing), so that this material could be used as a packing material in Deliveries.

Important information required for packing is shown in below:

• Item Category Group (Sales: Organisation 2 tab)
• Packing Material Data (Sales: General/Plant)

Packaging Material Type

Allowed Weight

Allowed Volume

As seen above we have created a packing material PACK1 with Item category group VERP, Packaging Material Type 0001-Pallet and allowed packing weight as 200kg.

f) Maintain Packing Transaction Profile

The configurations done from this step are specifically valid for Automatic packing in outbound delivery.

In this step, you can modify the Packing Transaction Profiles using TCode OVHU2.

For each application, in which the packing transaction can be used, there is a packing transaction profile. The profiles are set as standard in the system. You can change the descriptions and the settings for each profile. However, you cannot create new profiles, delete existing ones, or change the assignment of profile to application.

In our case we will use the transaction profile available for outbound delivery i.e. 0002- Outbound Delivery.

In each profile, the following parameters are set:

• display mode or change mode for HU proposals in the packing transaction
• the procedure used to automatically determine packing instructions
• whether the system expands packing instructions automatically when materials and quantities are entered or changed
• whether the system displays a selection dialog box in the automatic expansion process, so that the user can select a packing instruction from those proposed by the system (main packing instruction or alternative packing instruction)
• whether the system takes into account rounding and minimum quantities in the automatic expansion process
• whether the system also takes into account alternative packing instructions in automatic expansion, if the main packing instruction cannot pack the required quantity
• The expansion strategy. This controls whether

                   o Everything is to be packed automatically, that is, the system creates HU proposals for the complete quantity to be packed.

                   o Packages are to be created one at a time, that is, the system creates an HU proposal for exactly one main handling unit.

• the minimum packing status for packing instruction expansion
• the HU status of the handling units created
• The minimum packing status of HU proposals required to created HUs.

We have a Packing Instruction Determination Procedure ZSHIP1 assigned to the Packing Transaction Profile of Outbound delivery.  This procedure uses the condition technique to identify Packing Instructions maintained as master data which will be discussed going ahead.

Also we have activated Start packing automatically, Respect Rounding Quantities and Respect Alternate Packing Instructions. Pack Strategy is set to pack all delivery items.

g) Set up Condition Technique for  Packing Instruction Determination:

In this step you can set up condition technique for the packing instruction determination procedure i.e. ZSHIP1(assigned in the Outbound delivery Transaction Profile). You can set up Determination procedure, Determination type, Access Sequence & Condition table.

You can create each of the components of the condition technique using below Tcodes:

• Condition table – OFP8
• Access Sequence –OFP2
• Determination Type – OFP3
• Define Procedure – OFP4

I am not adding screenshots as this is done similar to any other condition technique setup.

h) Create packing master data – POP1

Once above SPRO configuration are done the only job remaining is to create packing master data.

Go to TCode POP1 and set up master data specifying what Material is to be packed and what is the material that will be used to for packing.

In our case the master record is maintained as shown below.

TATA1 is the material to be packed while PACK1 is the packing material. In the above master data set up I have specified that 1qty of PACK1 can be used to pack 4qtys of TATA1.

i) Maintain packing instruction determination  record – POF1

The second master data that you need to maintain is how the packing instruction that was created in the previous step would be determined.

This can be created using TCode POF1.

PFB the screenshot maintained in our case.

In the above screenshot you can see that I have maintained a record for Determination Type SHIP in Procedure ZHSIP1. The condition table has the combination of Material & Ship-to party while packing instruction number specified is 231 which we have created in the previous step.

This means that whenever Material TATA1 and Ship-to 4000401 combination occurs in delivery type LF the packing instruction 231 would be identified by using Transaction profile of outbound delivery & Packing instruction procedure ZHSIP1. This will in turn pack the delivery items using the material specified in packing instruction number 231.

Once you configure all of the above steps Automatic packing would be active in Delivery and Handling Units would be automatically created based on the master data you have maintained.

Source: https://blogs.sap.com/2014/08/30/configuring-automatic-packing-in-outbound-delivery/

MRP Live: Checking the MRP logs and forcing a material to be planned in ABAP with transaction MD_MRP_FORCE_CLASSIC

 SAP S/4HANA introduced the new MRP Live (transaction MD01N), which drastically improves the MRP performance. With MRP Live, the source code that was originally executed in ABAP was pushed down into the HANA layer, allowing MRP to take advantage of HANA in-memory capabilities and internal parallelization to improve the MRP performance. It basically means that MRP Live is executed in HANA stored procedures, rather than executed in ABAP.

However, there are still some settings which require MRP to be executed in ABAP, even if we are running MRP Live in transaction MD01N, and SAP note 1914010 provides a complete and updated list of those restrictions. When MRP Live finds one of these restrictions, it automatically switches to the classic logic and the material with the restriction is still planned in transaction MD01N.

There are very specific cases, however, where we need to force a material to be planned with the classic logic in ABAP. The most common reason for forcing a material to be planned with the classic logic is when we have an ABAP BAdI implemented, which must be executed for some specific materials. Since MRP Live is runs in the HANA layer, the ABAP BAdIs are not called, unless we force the material to be planned with the classic logic.

Transaction MD_MRP_FORCE_CLASSIC was developed specifically to allow you to choose which materials should be planned with the classic logic.

In the initial screen, the transaction allows you to choose for which materials you would like to see the details.

 

The results screen, shows when the material was planned by MRP Live and if any kind of restriction was found for this material, which lead this material to be planned with the classic logic, as we can see below. In addition to that, in recent S/4HANA releases, it will also show any issue that might have happened during each of the steps of the MRP run (BOM explosion, scheduling, etc…).

Besides the MRP Live logs, this transaction also shows any restriction that might prevent a material to be shown in the MRP Fiori apps in column App Issue.

Whenever system finds a restriction, you can try to remove it by clicking the button Solve Issue. Considering the example shown above, the first line shows that a material was planned with classic MRP because MRP type X0 was set in the material master, therefore, if we click the button Solve Issue, we will jump into material master tab MRP1, where we can change the MRP Type.

When we click the pencil button, fields “Classic MRP” and “MRP Apps” will be open for changes, as shown in the following figure.

By checking the flag Classic MRP you will force a material to be planned with the classic MRP logic and by changing the value of the field MRP Apps, you can choose whether a material will be displayed on the MRP Fiori Apps or not. Here, it is also possible to accept a specific issue, and there is a parameter in the selection screen that allows us to define whether accepted issues will be shown or not when the report is executed.

Forcing a material to be planned with the classic logic in MD01N will ensure that all the materials that can be planned in HANA and materials that must be planned in ABAP (due to a BAdI implementation or a specific restriction) can be planned together, in the same MRP job. However, you should always consider that, with many materials being planned by the classic logic (ABAP), the MRP Live performance will not be optimal.

Therefore, whenever it is possible, you should try to get rid of those restrictions and ensure that most materials are planned in HANA, in order to achieve an optimal performance.

Source: https://blogs.sap.com/2016/11/22/mrp-on-hana-forcing-a-material-to-be-planned-with-the-classic-logic-in-md01n/