Data Migration Methodology

LSMW

This is a facility provided by SAP that enables migrated data to be first cleansed in spreadsheets (or access depending on the data volumes), and subsequently loaded into SAP via predetermined field mapping.  The facility also caters for ‘data transformation’ where field values can be created from simple predefined logic.  It is the preferred tool for all data migration into SAP.  The main benefits are:  

A highly flexible tool provided and supported by SAP.

Independence from SAP releases, platforms and the kind of data to be migrated. 

Independence from SAP releases, platforms and the kind of data to be migrated.

A step by step guide through the data migration process.

Generates ABAP code once data transfer has been configured.

It allows additional ABAP coding for complex data loads.

It allows reusability of data mapping and conversion rules.

LSMW Process Flow:

The LSMW process flow is made up of the following steps:

Read data (legacy data in spreadsheet tables and/or sequential files) from a file on a local PC or file server. 

Convert data (from the source into the target format).   

Import data (to the database used by the SAP application). 

2013-05-21_110834

Data Migration Strategy (Customer First)

Data Migration_Methodology_for_SAP_V01a

Creating OM and PA data through LSMW

There are many ways to upload your PA and OM master data to SAP HR, but the one method that I have learned to have more control over and have minimal data errors is by using LSMW. There should be a Data Migration strategy indicated on your Business Blueprint documenting the sequence of OM and PA infotypes to be loaded.  The DM strategy would contain also the scope of data to be loaded, the freeze date of the snapshot of the data, the key dates to be used, the list of LSMW programs to be created and of course some volumetrics of the data to be loaded. That way you have a complete plan in your hands that you can follow. Now let’s get started.

Typically, you would need an initial upload in PA just to get things started. You should load these infotypes first:

  • Actions Infotype (IT0000) – This record captures the EE’s hire date into the organization as well as their personnel number and some Enterprise structure details
  • Organization Assignment Infotype (IT0001) – This record captures the some more information about the EE’s Enterprise Structure Details except for Position, Job and Org Unit. You can use the default position 99999999.
  • Personal Data infotype (IT0002) – This record captures initial basic personal information like the First Name, Middle Name and Last Name. Personally Identifiable Information (PII) is not loaded, only when authorizations in SAP HR are active. And PII is normally loaded only in the Production system.

There are many alternatives to uploading these infotypes with an LSMW, and the most efficient way I have used so far is recording the Conversion Hire Action into the LSMW. The Conversion Hire Action is configured only for the three initial infotypes mentioned above.  You can remove the conversion action from PA40 once you are live. As for other PA infotype uploads, I recommend that you simply use PA30 when recording the PA infotype creation for the LSMW. You will have more control and flexibility in the long run.

Once you have this initial PA upload ready you can at this point prepare your OM data.  Don’t worry, the current org assignment of the EE will be loaded in another LSMW upload as soon as the OM data is loaded and verified.

In your current SAP Installation, SAP has some standard delivered OM objects for your org structure that you may not need. To delete these objects you may have to use report RHRHDL00. This program will delete all infotype objects associated with an object. Cleaning up the SAP system will reduce data errors in your uploads.  If you skip this step you may end up having a German named Org Unit, Position or Job in your Org plan, so it is better to safe now than sorry later.

OM data must be loaded in a correct sequence depending on your requirements; one must plan the creation of your organization structure with ESS/MSS in mind. That way your approval hierarchy will be in place and you will avoid a lot rework when you are implementing ESS/MSS. I have written down a sample sequence just to give you an idea how OM infotypes should be loaded.  There are several ways for you to use an LSMW you could either have multiple LSMW’s for each object to be loaded or you can have just one for the objects and another for the relationship objects.  I don’t recommend using the OM actions as it is just too much data to verify in one go.  You can use PO03, PO10, PO13 or PP01 as part of your LSMW recordings.

If you have multiple companies I suggest that you load the smallest organization first so that you can confirm that your LSMW’s work and your data sheets are organized correctly. If you need to load in piecemeal then do so, that way you have more control and it will be easier for you to verify what you have loaded. But that’s really all up to your overall strategy. Let’s take a look below.

  1. Org Unit Objects (IT1000)
  2. Job Objects (IT1000)
  3. Position Objects (IT1000)
  4. Org to Org relationship objects (IT1001)
  5. Position to Job Relationship Objects (IT1001)
  6. Position to Org Unit Relationship Objects (IT1001)
  7. Chief Position Object (IT1001)

I recommend that you load all the objects first and then the relationships, you can upload the rest of the related infotypes later once you have at least uploaded these objects and their relationship infotype records.

When it comes to number ranges for these objects the best way would be use external number ranging and assign the object IDs yourself.  When I had used internal numbering for the objects, I had to spend some time creating the object relationships sheet manually before I do the upload into the different SAP systems as the internal numbers  assigned during the LSMW upload differ from DEV,QAS and PRD. So your data sheets are off already once you switch from DEV to QAS and then again from QAS to PRD.  If you use external  number ranges that would make the LSMW uploads into the different SAP systems easier as you will have the same object id throughout the conversion activity, therefore negate the need to redo your data sheets.

With all these OM objects loaded, a consistency check must be executed.  OM-PA Integration reports RHINTE10 and RHINTE20 must be executed so that all OM objects that are uploaded are also present in the PA side.  When you have performed these two reports, it will be time to upload your next PA LSMW upload which is the Organization Reassignment data. This data represents the EE’s current position in the organization as of the freeze date that has been agreed upon with the client. If there are recent changes to an EE’s position after the freeze, you have to discuss with your client how you want to update your MD.

Assuming that your Org Assignment LSMW update went well,  you need  to execute RHINTECHECK. This program will basically report which PA or OM data is inconsistent  and is able to provide an explanation

To investigate the inconsistency, go to PA30 and look at  the Organization Assignment infotype (IT0001) of each employee in the report. Once you are in infotype 0001 click  on the Org Structure button and compare the values in the pop-up box and IT0001.This will show you whether the Position or Org Unit or Job are the ones that have inconsistency and which EE has the inconsistency

If you click on the Org Structure button in infotype 0001 and you get an error message that there is no Org Structure for this object then there is no holder for that position in OM. You have to execute RHINTE00 with the create holder relationships only.  Be careful that you only create the holder relationships only, otherwise you will have the program create extra OM objects that you will not need. Now if you look  the Org structure button in IT0001 and you do get some data but it is not the same as the one in IT0001. Let’s say after confirming with your client that the data in OM is correct, then you need to execute RHINTE30. This report creates a batch input session for specified personnel numbers. The session updates IT0001 for the persons concerned. I recommend that you start this report in test mode initially.  With these tips you will be able to upload your PA and OM master data in all your SAP systems consistently.

As I said in the beginning of this blog that there are many ways to upload your data, I only discussed one method of uploading it.  I have used this method many times and this is a method I would recommend to most clients because you have more control and it is much faster than the other methods I have used in my career with SAP.  The trick here is to organize your data, make sure that all the objects you need are present and stay in constant communication with your client as they own Organization Plan you are loading and therefore are the best persons to verify your Org Plan.

Upload transaction data into SAP system

A) Pre – Go Live activities:
1. Master data Load into Production system
Ensure all the master data is loaded into the production system.
We will broadly cover the master data which needs to be loaded and the module
responsible.

  • Material Master – Basic responsibility MM: All the respective views of the
  • material masters the other modules responsible . Ensure that all the required views are uploaded
  • GL codes – FI
  • Customer Master – FI (accounting view) and SD (sales view)
  • Vendor Master – FI (accounting view) and MM (purchasing view)
  • Cost elements – CO
  • Secondary cost elements – CO
  • Profit centers – CO
  • Cost center – CO
  • Activity type – CO
  • Bill of Material – PP
  • Work Center/ Resource – PP
  • Routing / Master Recipe – PP
  • Purchasing Info Record – MM
  • Service Master – MM
  • Bank Master – FI
  • Quality Info Record – QM
  • Quality Inspection plan

2. Upload Cost center plan
Cost center plan must be updated through transaction code KP06 or using excel upload.

3. Execute the allocation cycles within cost center accounting
The plan allocation cycles (distribution, assessment) must be executed within the cost center accounting module. This will allocate the costs from the service cost center to the receiver cost center.
4. Update planned activity
After executing of the plan allocation cycles, the production cost centers are now ready with the planned costs. You can now calculate the activity prices through the system or manually update the planned prices by calculating it outside.  The planned activity must be updated through transaction code KP26.
5. Calculate Activity prices

Calculate the activity prices using transaction code KSPI.

6. Execute product costing run
The product costing run will be executed for all semi-finished and finished materials in the system using transaction code CK40N. This should be run after all the BOM and Master recipe are uploaded.
The product cost finalization takes a long time and should begin well in advance before the go live date. Normally the product costing run has to be executed again and again (3 – 4 times) since data needs to be corrected and costs have to be compared with the existing legacy cost.
The possible errors in the product costing run are:-

  •  Moving average prices or planned prices are not correctly maintained in the material masters
  • Incorrect quantities in the Bill of Materials, incorrect base unit quantity in the Bill of Material
  • Incorrect quantities (hours, KWH etc) for activities in the Routing or Master recipe.
  • Incorrect alternate unit of Measure

The product costing is calculated and made ready. The actual Mark and release will happen on after the stocks are uploaded into the system.

B) Pre – Go Live activities:

  •  Ensure all the customizing request are in the production system

Check that all the customizing request are gone in the system and no major requests are pending. Request relating to reports being developed can be transported as and when the reports are ready.

  • Ensure all the number ranges for all the modules have been maintained in the production system
  • Ensure that Operating concern has been generated
  • Ensure that all the Customer Master data is loaded
  • Ensure all material masters (all material types) have been loaded
  • Ensure that all the Vendor Master data is loaded

C. Upload transaction data into system:

1.Upload Open purchase orders

Open purchase orders can well be uploaded into the system in advance before the cut off date if no invoices are expected.

2. Stock upload

Stock upload happens in 2 steps:-

Finished goods: The standard prices are first uploaded through MR21 or through an ABAP program which also uses MR21. The stock quantities are uploaded using movement type 561 through an ABAP program which calls transaction MB1C.
Raw Material, packing Material, stores and spare parts: The quantities and values are uploaded at the same time using an ABAP program which calls transaction MB1C.
The stock upload will generate the following entry in the system:-
Finished goods stock a/c                   Debit
Semi-Finished goods stock a/c          Debit
Raw Material stock a/c                      Debit
Packing Material stock a/c                 Debit
Stores and spares a/c                        Debit
Data take over                                   Credit

3. Mark and Release the cost estimate

After the stock is uploaded into the system, the standard cost estimate will be marked and released into the material master using transaction code CK40N.

4. Upload Accounts Receivable and Accounts Payable open items
The Accounts Receivable and Accounts Payable open items are uploaded through LSMW which calls transaction code F-02 GL Account posting. The profit center is captured in the data take over account. Baseline date must be captured, which will determine aging based on number of days mentioned in the payment terms.
The accounting entry for Accounts Receivable open item upload is:-
Customer a/c (not GL)         Debit
Data takeover a/c                Credit
The accounting entry for Accounts Payable open item upload is:-

Data takeover a/c            Debit
Vendor a/c (not GL)         Credit

5. Asset Master and value upload

The upload of asset master and values through AS91
This upload of asset masters along with the values will not update the FI General Ledger. The FI – GL entry balance update will be passed through anothertransaction.
Transfer Asset balance into profit center
Once the asset master along with the values is uploaded, the opening balance for the asset needs to be transferred to profit center.The asset balances opening balances are transferred into profit center accounting through transaction code 1KEI.
Remove the GL codes for asset from 3KEH table
Remove the Asset reconciliation codes from the transaction code 3KEH. This is required because a manual FI entry will be passed in the next step, which will duplicate posting into PCA for the assets.
Update the FI entry for asset through transaction OASV.
We give an example of how a GL entry passed for Fixed asset upload:-
Let us take Plant and Machinery

Plant and Machinery a/c Dr 200,000
Accumulated depreciation a/c Cr 60,000
Data takeover a/c Cr 140,000

Reinstate the GL codes for asset in 3KEH
After passing the entry for asset upload update the asset reconciliation accounts in transaction code 3KEH.

6.Upload General Ledger account balances
Finally we upload the remaining General Ledger account balances other than Fixed Assets, Stock, Accounts Receivable and Accounts Payable. This is again uploaded through an LSMW program which calls transaction code F-02 GL Posting.
Let us take an example for the accounting entry passed:-
Data takeover a/c Debit 550,000 (Balancing figure)
Cash a/c Debit 10,000
Bank a/c Debit 50,000
Advances Debit 90,000
Share capital a/c Credit 100,000
Short term Loan a/c Credit 200,000
Long term loan a/c Credit 400,000
The Data takeover will become zero on upload of this entry.

Step-by-Step Guide for using LSMW to Update Customer Master Records

LSMW to Update Customer Master Records with Standard Object

As an alternative to using ‘Transaction Recording’, you could also use a standard SAP object to update Customer Master Records. Business Object ‘0050’ is already pre-defined in the system with standard Batch Input Interface Program ‘RFBIDE00’.

Step 1: Maintain Object attributes

Step 2. Maintain Source Structures

Step 3. Maintain Source Fields

Step 4: Maintain Structure Relations

Step 5: Maintain field mapping and conversion rules

Step 6: Maintain fixed values, translations, user-defined routines

Step 7: Specify files

Step 8: Assign files

Step 9: Read data

Step 10: Display read data

Step 11: Convert data

Step 12: Display Converted data

Step 13: Create batch input session

Step 14: Run Batch Input Session

Step-by-Step Guide for using LSMW to Update Customer Master Record

Legacy System Migration Workbench-SAP

Table of Contents

1 INTRODUCTION
1.1 PURPOSE OF THIS INTRODUCTION
1.2 LSM WORKBENCH: WHAT IS IT?
1.3 SUPPORTED R/3 RELEASES
1.4 COSTS
1.5 DELIVERY
1.6 LSM WORKBENCH VERSIONS
1.7 SUPPORT
1.8 SIGNIFICANCE OF DATA MIGRATION
1.9 BASIC PRINCIPLES OF THE LSM WORKBENCH

2 PRECONDITIONS

3 STARTUP AND PREPARATIONS
3.1 AUTHORIZATIONS
3.2 INITIAL TRANSACTION
3.3 PROJECT, SUBPROJECT AND OBJECT
3.4 USER GUIDANCE
3.5 FIELD MAPPING ON PAPER
3.6 CREATE OBJECT OVERVIEW
3.7 ADMINISTRATION
3.8 RECORDINGS
3.9 PREPARATIONS FOR USING IDOC INBOUND PROCESSING

4 GENERAL TIPS FOR THE PROCEDURE

5 DATA MIGRATION – STEP BY STEP
5.1 MAINTAIN OBJECT ATTRIBUTES
5.2 MAINTAIN SOURCE STRUCTURES
5.3 MAINTAIN SOURCE FIELDS
5.3.1 Create Individual Source Fields
5.3.2 Maintain Source Fields in Table Form
5.3.3 Copy Source Fields from Other Sources
5.4 MAINTAIN STRUCTURAL RELATIONSHIPS
5.5 MAINTAIN FIELD MAPPING AND CONVERSION RULES
5.5.1 For the Advanced User: Display Variant, Processing Times
5.5.2 For the Advanced User: Global Variables
5.5.3 For the Advanced User: Global Functions
5.5.4 For the Advanced User: Reusable Rules — Naming Conventions
5.6 MAINTAIN FIXED VALUES, TRANSLATIONS AND USER-WRITTEN ROUTINES
5.7 SPECIFY FILES
5.8 USE WILDCARDS IN FILE NAMES
5.9 ASSIGN FILES
5.10 READ DATA
5.10.1 Display Read Dat
5.11 CONVERT DATA
5.11.1 General Remarks
5.11.2 Additional Function for BAPI/IDoc
5.12 DISPLAY CONVERTED DATA
5.13 IMPORT DATA
5.13.2 Import Data with Direct Input
5.13.3 Import Data with BAPI or IDoc Technique

6 RECORDINGS
6.1 DETAILED DESCRIPTION OF THE PROCESS

7 TRANSPORT LSMW PROJECTS
7.1 GENERATE CHANGE REQUEST
7.2 EXPORT PROJECT
7.3 IMPORT PROJECT

8 PERIODIC DATA TRANSFER

9 LONG TEXTS
9.1 LONG TEXTS IN THE R/3 SYSTEM
9.2 DETERMINE TEXT KEY STRUCTURE
9.3 DEVELOP OBJECTS FOR LONG TEXTS VIA OBJECT 2000
9.4 DEVELOP OBJECTS FOR LONG TEXTS VIA OBJECT 2000
9.5 IMPORT TEXTS

10 TIPS AND TRICKS

10.1 DETERMINE THE TRANSACTION CODE AT RUNTIME
10.2 SKIP A RECORD
10.3 SKIP ALL RECORDS OF A TRANSACTION
10.4 DUPLICATE A RECORD
10.5 EXTRA HANDLING FOR “POS-IDOCS”

11 UPGRADE FROM LSMW 1.0 TO LSMW 1.7
11.1 DIFFERENCES BETWEEN VERSION 1.0 AND VERSION 1.7 OF THE LSM WORKBENCH

12 TRANSFER OF LSMW DATA FROM VERSION 1.0 TO VERSION 1.7

13 UPGRADE FROM LSMW 1.5 TO LSMW 1.7
13.1 NOTES ON THE UPGRADE TO LSMW 1.7
13.2 CORRECTIONS
13.3 DEVELOPMENTS

14 FINAL REMARKS

Click on below link to get the Document

LSMW_INTRODUCTION

Legacy System Migration Workbench-LSMW

  • Create a project, sub project and object
  • Create Recordings
  • Maintain object attributes
  • Maintain Source Structure
  • Maintain source fields
  • Maintain Structure relations
  • Maintain field mapping and conversion rules
  • Specify file for upload and create a file for upload
  • Assign files
  • Read data
  • Display Read data
  • Convert data
  • Display converted data
  • Create Batch input session
  • Run Batch input session

Legacy System Migration Workbench-LSMW