If you are familiar with the simplifications implemented in MRP processes in SAP S/4HANA, you should be aware that the usage of MRP Areas is now mandatory for storage location planning and it is also recommended for subcontracting planning in MRP (if you are not aware of these simplifications, I suggest you to take a look into this blog).
However, not everyone knows that SAP provided many new features that helped companies to effectively use and manage MRP Areas in SAP S/4HANA. This blog provides a summary of all the improvements delivered for MRP Areas in SAP S/4HANA, across multiple releases.
Before the migration to SAP S/4HANA, planners could find an overview of the planning situation in different subcontractors and storage locations planned separately in a single screen of the Stock/Requirements List (transaction MD04). In the first SAP S/4HANA releases, however, this was no longer possible with MRP Areas, as the planned would have to access each MRP Area separately.
The new intra-plant view, delivered in SAP S/4HANA 1809 changed the system behavior and introduced a new tab in the Stock/Requirements List, bringing back the possibility to have an overview of the planning situation across multiple subcontractors and storage locations.
This blog explains in detail how to activate the Intra-Plant View in SAP S/4HANA 1809 or subsequent releases.
New transaction to create subcontracting MRP Areas
When creating a subcontracting MRP Area in customizing, we always need to add a reference to the subcontractor (supplier) number. As this number will usually not be the same in development, quality and production systems, it was necessary to open the customizing transaction OMIZ for changes in the productive system, so that the subcontractor number could be manually adjusted (a long time ago I wrote this blog explaining how to do that).
As of S/4HANA 1909, however, it is no longer necessary to open the customizing transaction OMIZ for changes in the productive system. SAP created transactions OMIZA and OMIZB, to segregate the creation of storage location and subcontracting MRP Areas.Transaction OMIZB can be now be used to create subcontracting MRP Areas and it is open for changes in the productive system without a request.
Assignment of subcontracting MRP Areas to the material master is not required
The subcontracting process was simplified in SAP S/4HANA and now MRP requires the usage of MRP areas to segregate the stock provided to the subcontractor and the subcontracting demand from the plant stock and demands.
In SAP S/4HANA, however, it is no longer necessary to explicitly assign a subcontracting MRP Area to a material that is involved in a subcontracting scenario. As explained in SAP Note 2227532, it is sufficient to maintain the subcontracting MRP area in the customizing to activate that logic for all materials with concerned subcontracting stocks and requirements. It is not necessary to assigned those material explicitly to the subcontracting MRP area in the material master data.
If subcontracting MRP Areas are not assigned to the material master, they are generally referred to as Generic Subcontracting MRP Areas, and in this case, system will try to mimic the same behavior of the old ECC subcontracting logic, with a deterministic MRP logic (similar to PD) and a lot-for-lot lot-size (similar to lot-size procedure ‘EX’).
- Existence of a MRP type for MRP or MPS planning (e.g. MRP type ‘PD’) – required to plan the MRP area during appropriate planning runs
- Existence of a lot-sizing procedure with a lot-for-lot lot-size indicator (e.g. lot-size procedure ‘EX’) – required lot-size procedure for the creation of stock transfer reservations between plant MRP area and subcontracting MRP area
- Existence of a special procurement key which allows a stock transfer within a single plant – required to create of stock transfer reservations between plant MRP area and subcontracting MRP area, the source and the target plant have to be identical in that special procurement key
Automatic assignment of Storage Location MRP Areas to material
When we wanted to plan a storage location separately or exclude it from MRP in ECC, we could simply define a value for the Storage Location MRP Indicator, in tab MRP4 of the material master. If a certain storage location would always be excluded from MRP or planned separately, we could simply define a default value for this field in the customizing transaction OMIR, and it would be used whenever extending tab MRP4 for a new material.
As of SAP S/4HANA 2020, a new feature emulates the sabe functionality, allowing the automatic assignment of Storage Location MRP Areas to the material master. Now we can create an MRP Area Profile in customizing, where we will define default settings for the MRP Area fields. This profile is assigned to the MRP Area in customizing and the MRP area can be automatically assigned to a material when we are extending it to the respective storage location, if we check the flag Assign Materials Automatically.
This blog provides more information about this new functionality.
Mass deletion of MRP Area assignments to material
When an MRP Area is assigned to a material, an entry is created in table MDMA and we can find this assignment when we access tab MRP 1 of the material master. If the MRP Area will no longer be used for this material, we can set the deletion flag for the material master assignment (as shown in the figure below), however, until SAP S/4HANA 2020, it was not possible in standard to completely delete this assignment and remove those entries from table MDMA.
Without the deletion of the material master assignment from the material master, it would not be possible, for example, to delete the MRP Area from customizing and SAP ever delivered report YMRPAREO in SAP Note 545444, to delete those assignments from table MDMA.
As of SAP S/4HANA 2021, Fiori App Schedule Unassigning of MRP Areas (F5447), allows a background job to delete the assignment of an MRP Area to a material that is flagged for deletion.
This app will not only delete the MRP assignment from the material master, but also dependent data from the following tables:
- Database Table MDMA – MRP Area for Material
- Database Table DBPR – MRP Area Material Index for Forecast
- Database Table PROP – Forecast Parameters
- Database Table PROW – Forecast Values
- Database Table PROH – Basic Forecast Values
- Database Table DBPROF – Forecast Error for MRP Areas
- Database Table DBPRON – Forecast Errors and Exception Messages
- Database Table DVER – Material Consumption for MRP Area
- Database Table MDKPDB – Header Data for MRP Documents
- Database Table MDFDDB – Firming Data of MRP
- Database Table PBID – Planned Independent Requirements Index (PBID)
- Database Table CDPOS – Document Items
- Database Table CDHDR – Change Document Header
Deletion of assigned Storage Locations
Until SAP S/4HANA 2020, a storage location could not be removed from an MRP Area in the quality system customizing if the respective entry already existed in the productive system.
As of S/4HANA 2021, the storage location can be removed from MRP Area customizing in the quality system if all the prerequisites are fulfilled in both productive and quality system. The prerequisites to delete a storage location from the MRP Areas include checks like the usage of storage location in material master data, material documents, etc…
Mass processing of MRP Areas
The last one is not a new feature of SAP S/4HANA, but it’s worth to mention, as it is a very useful functionality and it usually needed by customers implementing S/4HANA.
SAP ERP offers a transaction called MDDIBE, which allow the mass processing of MRP Areas, including features like creating, changing, and setting the deletion indicator of the assignment of a MRP Area to one or more materials.
With this transaction we can assign an MRP Area that has just been created to multiple materials at once, and we can also set the deletion flag of the assignment to one or more materials.
SAP also offers the report RMMDDIBE, which is the program behind transaction MDDIBE, and report RMMDDIBE02, which was developed for background processing.
Brought to you by the SAP S/4HANA RIG and Customer Care team.