segunda-feira, 24 de fevereiro de 2020

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.
MRP1.PNG
  • 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:
MRP1_1.PNG
  • 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:
MRP_Area.png
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

1.PNG
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
2.PNG
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

3.PNG

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)

4.PNG

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.

5.PNG
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
6.PNG
MRP
7.PNG
Material Master
8.PNG
Stock Requirement list
9.PNG

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:
10.PNG
You will have additional views for MRP 1, MRP 2, Forecast & Consumption values. You need to fill required fields as per your need.
12.PNG
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.
13.PNG
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
14.PNG
Total stock MMBE
15.PNG
MD04 – MRP Area ZSY1
16.PNG
MD04 – MRP Area MA001
17.PNG
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
18.PNG
Stock requirement for MRP area MA001:
20.PNG
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
21.PNG
MRP area MA001 is untouched:
22.PNG
After running MRP for MA001 system creates planned order for 200 quantities
23.PNG
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

domingo, 23 de fevereiro de 2020

Part 1: SAP S/4HANA migration cockpit – Migrating data using staging tables and methods for populating the staging tables

One frequently asked question (FAQ) regarding the SAP S/4HANA migration cockpit’s migration approach “Transfer Data Using Staging Tables” is: how to load data into the staging tables?
This blog series will provide a few options for populating these staging tables with data.
This first blog post will give an overview of the SAP S/4HANA migration cockpit, focusing on the migration approach “Transfer Data Using Staging Tables”. The next blog posts will provide step-by-step examples on how to load data into the staging tables using SAP Data Services and SAP HANA smart data integration (SDI).
First, let’s have a short introduction and overview of the functionality, features, and key benefits of the S/4HANA migration cockpit.
The SAP S/4HANA migration cockpit is a tool designed for customers who have just installed SAP S/4HANA (new implementation scenarios) and want to transfer their business data from SAP or non-SAP software systems. The SAP S/4HANA migration cockpit has become an essential tool for SAP S/4HANA data migration, supporting customers during the transition to SAP S/4HANA. It is part of both SAP S/4HANA and SAP S/4HANA Cloud and can be launched using the “Migrate Your Data” app in the Fiori Launchpad (Manage Your Solution Launchpad) or using transaction LTMC. With the migration cockpit, you can migrate your master data and transactional data to SAP S/4HANA. It uses migration objects to identify and transfer the relevant data and, facilitates the migration process by providing predefined migration content and mapping. The SAP S/4HANA migration cockpit is SAP’s recommended approach for the migration of business data to SAP S/4HANA (on-premise) and SAP S/4HANA Cloud.
The most important functions and features of the migration cockpit are outlined below, as well as its key benefits.

Functions and Features:

  • Preconfigured data migration. No developer skills required.
  • Step-by-step guidance through the migration process.
  • Preconfigured migration objects and rules.
  • Automated cross-object value mapping.
  • Migration programs are automatically generated.
  • Migration object modeler can be used for custom requirements.

Key Benefits:

  • Preconfigured content and mapping for each migration object, for example Bank, Customer, Cost center, Material.
  • Predefined file templates and staging tables for each migration object.
  • Automated mapping between template and target structure.
  • Migration programs are automatically generated – no programming required by the customer.
  • Available for SAP S/4HANA and SAP S/4HANA Cloud, included in these licenses.
  • Available for Cloud and for On-Premise.

Migration Approaches:

Currently, the SAP S4/HANA migration cockpit uses the following migration approaches:
    a) Transfer data using files (xml templates)
    b) Transfer data using staging tables
    c) Transfer data directly from SAP System (new with SAP S/4HANA 1909)

For the migration approach “Transfer Data Using Staging Tables”, the SAP S/4HANA migration cockpit can automatically create staging tables for each migration object (for example bank) that is relevant for your migration project. Staging tables are database tables and therefore provide greater flexibility than files regarding managing data (for example sorting or searching data). Furthermore, such kind of tables are a more efficient way of transferring large volumes of data as they can handle a greater volume of data without the need of splitting large tables into several portions. If you need to transfer a lot of data to SAP S/4HANA in an automated way, then this approach is the recommended migration approach.
The following section provides information about the motivation, benefits, and technology for this approach:
Below are the motivations, benefits and technology regarding the staging tables approach:

Motivation

    • Amount of records and size of file is limited for XML files
    • Large tables need to be split by creating several spreadsheets
    • Filling of XML templates with multiple tabs can lead to inconsistencies

Technology

    • Secondary database connection must be available
    • Staging tables: created natively in the schema of HANA database
    • Separate staging table for each source structure of a migration object

Benefits

    • Safer, faster, and easier
    • Staging tables will be created natively in the schema of the SAP HANA database depending on the selected database connection
    • For each source structure of a migration object (for example Customer), a separate staging table will be generated.
    • Staging tables must be filled by customer using extraction tools (ETL) from SAP or from a third party.

System Setup for On-Premise

System Setup for Cloud


General Procedure for Transferring Data to SAP S/4HANA Using Staging Tables


Prerequisites, Required Roles, Installation/Setup Activities


Before starting with the creation of a migration project, we recommend you review the following documentation which contains information about required roles, SAP Best Practices Explorer, installation activities (On-Premise only) and, set-up instructions (Cloud only):
On-Premise:
Cloud:

General Process for migrating data


The general process for migrating data to SAP S/4HANA using staging tables is as follows:

1. Create a migration project to transfer data using staging tables. You can do this using transaction LTMC for the SAP S/4HANA migration cockpit for On-Premise Edition or using “Migrate your Data” App for Cloud Editions / Fiori Launchpad.


2. When you create a migration project, you specify a database connection to the source system database.
  • On-Premise: Only those connections are displayed here that are whitelisted. These connections must be maintained in table DMC_C_WL_DBCO_OP.
  • Cloud: For cloud deployments, this database connection is automatically done through the so-called communication scenario. For more information about the communication scenario, and how to set-up this connection, refer to the following document: Setting Up Data Migration to SAP S/4HANA from Staging (2Q2)

3. Open the migration objects (for example, Bank, Customer, Cost Center and so on) that are relevant for your project.
You can do this by double-clicking the name of the migration object that you want to add to your project.

When you open a migration object, staging tables are automatically created for the migration object. For each source structure of a migration object, a separate staging table will be generated natively in the SAP HANA database schema (for example in the migration project sample below for the migration object G/L account, four different staging tables are created which correspond to the four structures for G/L account: S_GENERAL, S_COMPANY, S_SKA1_TEXT, S_KEYWORDS, that are currently available for this migration object).
 Figure: “Migration Object Details” Screen for migration object G/L account

You can view the table definition in the SAP HANA Studio. On the Systems tab, expand the folder Catalog and locate the relevant schema. Expand the schema and expand the folder Tables. Select the staging table and choose “Open Definition” from the context menu.
Fields that are marked as NOT NULL or with an * (Asterix) in the data definition must contain a value. This means they need to be populated with data taking into consideration the leading zeros, default values, and correctness of the values of some data types (for example, DATE, DECIMAL, TIME and so on).

You can find more information about default values and leading zeros in SAP KBA 2733253 and the SAP Help Portal: SAP Help Portal: SAP HANA SQL and System Views Reference for SAP HANA Platform → SQL Reference → Data Types.
If the available migration objects do not meet your requirements, you can enhance or modify migration objects using the Migration Object Modeler. The SAP S/4HANA migration object modeler is part of the SAP S/4HANA migration cockpit, and it is designed to integrate custom objects and enhancements. Note that the Migration Object Modeler is only available for the on-premise and single tenant editions of SAP S/4HANA. You can access the SAP S/4HANA migration object modeler by using transaction LTMOM.

For more information about the SAP S/4HANA migration object modeler, refer to the following resources:

4. Add the data that is relevant for the migration object to the staging tables

You can fill the staging tables with data either using the SAP HANA Studio and SQL Insert statement or the option Import – Data from File. Also, you can fill these tables using SAP tools such as SAP Data Services, SAP HANA smart data integration or other third-party tools.
The next blog posts of these blog series will show you step by step three methods for populating the staging tables using SDISAP Data Services, and SAP HANA Studio.


5. Once you have added all the relevant data to the staging tables for the migration object, you can transfer the data for that migration object to SAP S/4HANA or SAP S/4HANA Cloud.

Note: You can improve the performance of the data transfer by increasing the number of data transfer jobs. The field Max. Data Transfer Jobs can be found on the Migration Object Details screen.This function is available as of 1809 release and it is advisable to set this parameter at object definition. For more information see the documentation for the SAP S/4HANA migration cockpit on help.sap.com 
You can start the data transfer by clicking “Start Transfer” button available on the “Migration Object Details” screen.

Important Notes:
Once you have started the data transfer, the staging tables of the migration objects you selected get locked. The is done using freeze triggers, which prevent changes from being made to the data in the staging tables during the data transfer.

In the SAP HANA database, you can see three triggers for each staging table:
If freeze triggers are set, you will see the message following message on the Migration Object screen in the Migration Cockpit:
“Staging tables of the migration object locked; cannot change data records”

If you are using the SQL Insert Statement in SAP HANA Studio for filling the staging tables and you try to insert data while the freeze triggers are set, you will get an error message such as:
Could not execute ‘insert into “DBUSER”.”/1LT/DSXXX000312″ values(‘CUST14′,’BP02′,”)’ in 5 ms 828 µs .
SAP DBTech JDBC: [12000]: user-defined error: “DBUSER”.”/1LT/DSXXX000312FRI”: line 2 col 142 (at pos 279): [12000] (range 3) user-defined error exception: no table change allowed
There are two options for deleting the freeze triggers (that is, to unlock the staging tables): ​
  1. Finish the transfer: After the data transfer is finished, the freeze triggers will be dropped automatically. ​
  2. Choose the “Restart Transfer” button on the Migration Object Details screen.

change log is recorded in table DMC_CF_CHANGELOG to record action DELETE/RESET executed on the Staging Table Detail screen. This change log is not recorded on all single records which are in the staging table as this would be a very huge amount of information. If you need a change log for each single record, you can set up change recording on database level.
When a staging table contains data, you can view the data records on the Staging Table Details screen. However, you cannot edit or add data records here.


If you want to delete one or more data records, you can do that directly from the Staging Table Details screen by selecting the data records you would like to delete and then press the button “Delete Selected Records”.
You can also Delete All Records from that particular staging table by choosing the button “Delete All Records” (regardless of the status: Unprocessed, processed, etc.).
You have then to follow the guided procedure provided within the SAP S/4HANA migration cockpit. Starting with “Validate Data” then “Convert Values” and “Simulate Import” and finally “Execute Import”.

6. When the activity “Transfer Data” is complete, the data has been migrated to SAP S/4HANA.

7. You repeat this process for each migration object that is relevant for your project.

Note: It is not possible to combine staging tables and file approach in one project.
For more information about migrating data to SAP S/4HANA using staging tables, refer to the documentation on the SAP Help Portal:For more information on Transferring Data to SAP S/4HANA Using Staging Tables you can check the following SAP Help Portal Links:
  • For On-Premise
  • For Cloud


Coming back to the question stated at the beginning of this blog:

How do we fill the staging tables of the SAP S/4HANA migration cockpit?


The staging tables can be populated either manually using ABAP or with the SAP HANA Studio or by using ETL tools from a third party or from SAP (for example SAP Data Services, SAP HANA smart data integration (SDI)). In the image below, you can see some possible solutions to fill the staging tables.
Note: It is important also to consider the following major recent Innovation for the staging tables approach of the SAP S/4HANA migration cockpit, available from 1809 FPS0:
  • Mapping table for staging table names – From 1809 FPS0 there is now a mapping table ‘/1LT/DS_MAPPING‘, which is provided in the same schema where the staging tables are generated. This table stores mapping information about the migration object, the source structure and the staging table name. You can use this table to determine the staging table names after you copy a project from a quality system to a production system and then use these names in your scripts or applications that populate the staging tables with data.


In this blog series, we will focus only on the following ETL tools from SAP to load data into the staging tables of the SAP S/4HANA migration cockpit:
The third blog post will focus on SAP HANA Smart Data Integration (SDI)
The forth blog post will focus on SAP HANA Studio – Data from File option 




SAP S/4HANA Migration Cockpit (On-Premise & Cloud) References, Blog Posts and Useful Links


SAP help portal:


     – On-Premise:
     – Cloud:

SAP Communities:


Trainings & Videos:


Blog posts

Relevant SAP Notes/KBAs:

  • 2537549 – Collective SAP Note and FAQ for SAP S/4HANA Migration Cockpit (On-Premise)
  • 2538700 – Collective SAP Note and FAQ for SAP S/4HANA Migration Cockpit (Cloud)
  • 2733253 – FAQ for SAP S/4HANA migration cockpit – Transfer option: Transfer data from staging tables
  • 2608495 – SAP S/4HANA Migration Cockpit: Errors using staging functionality w/ pre-delivered data migration objects in on-premise release 1709 FPS1
  • 2596411 – SLT / NZDT / S4HANA Migration Cockpit (DMIS2011 SP11-SP15; DMIS2018; S/4HANA 1610, 1709 & 1809) – Note Analyzer
  • 2587257 – S/4HANA 1709 FPS01 – Migration – Corrections for Migration Cockpit – Staging Scenario
  • 2596400 – Migration objects available in the Migration Cockpit
 Central SAP Notes

Newsletters:

Other Useful Links: