LSMW is a standard SAP tool to do any kind of mass data changes. It has a number of ways how to update the data in the system:
- Batch Recording
- Direct Input
BAPI is the fastest way, but there is a limited number of BAPIs available to the customer.
In 99% cases, we use Batch Recording which works like macros in MS Excel/Word. The system follows user’s steps, recording screen by screen. Once done we map data file to these screens and data fields. Than system repeats the same steps like the user would be doing manually.
In LSMW transaction we have projects, subprojects, and objects.
Ideally, there should be one global project for routine updates, one for data migration.
The subproject is something meaningful, like OM, PA, PT, and PY for different HR areas. Or it could be one subproject for all infotypes, no matter.
An object usually represents what’s being changed: infotype, table or something else.
To start we need to create all three entities: project, subproject, object or choose them if they are already created.
Here is the main LSMW window. Steps “Define Object Attributes” to “Assign Files” are settings, other for execution for the end-user.
All steps should proceed one by one in the same order like on the screen.
Here we set the way how we want to load the data into the system. Again, for 99% it is ‘Batch Input Recording’. Usually, we create a new recording for each new mass changes. To create a new recording click on ‘Recordings: Overview’ button to the right.
Before we start recording we need to make sure we have all the data for all fields handy. When we record user activities system records all steps. If we click on the list to choose a value for some field it will also be recorded. We don’t want the system to record these screens with help values.
Click Create. It’s a good practice to give prefix for recordings like here R stands for Recording.
For OM module (infotypes 1000 – 1999) we PP02 transaction.
Pay attention we enter all data without using any help values or lists.
Click Save. Then exit transaction.
The system brings us back to the recording. Click ‘Default All’ button to fill field names automatically. We will use these names in mapping rules.
Save and go back to the main screen with ‘Change Object Attributes’. Select our recording from the list.
Save and go back to the main menu.
Source structure reflects data from a file. If we have a hierarchy in a file or have several files to load at once, we create on structure per each data entity or file. It’s a good practice to use a prefix in naming, like here ZS – Z stands for customer object, S – structure.
Save and go back.
Source fields created for each structure. It’s a good practice to
- Keep the real file fields order the same in the source structure
- Use SAP dictionary names in structure
Choose structure and click on table icon. It’s more convenient to enter all fields on one screen.
Enter all fields you want to load from file. If you have fields with constant values they can be omitted and defined on later steps as constants.
Save and return to the main menu.
Here we need to define relations between our recordings and structures. If it’s one recording and structure system proposes relation. All we need is to save and return.
This is the most complicated step. Here we define how our data from a file (source structure) maps to recording fields. On the screen, we see all recorded fields from the first step. For each field, we need to assign some value. There are some options:
|Button in toolbar||Meaning|
|Source field||Takes data from the file (source structure)|
|Rule||Converts data with some predefined conversion rules or custom ABAP code|
|Initial||Leave value as is from the infotype logic|
|Move||Copy a field or part of it|
|Fixed value||Fixed value from some predefined list|
|Translation||Conversion through mapping “if this value, choose that value”|
Here we can define fixed values, translations or ABAP procedures which are used in the previous step. For simple tasks in 99%, this is not needed.
Here we create a file reference.
Click on Legacy Data on the PC and click Create. It means the file will be downloaded from your PC, not SAP server.
File – full path to file.
Name – technical name. Use prefix, like ZF.
Depending on file choose correct delimiter.
It’s a good practice to have field names in the very first row in the file and follow the order from the source structure. So, tick both check boxes under ‘File Structure’ frame.
The file would look like this.
Save and exit.
Here we assign file reference to the source structure. Usually, it’s one file to one structure.
Save and exit.
Here the system reads the file and converts to internal format on the server.
If the file is large and we want to test our LSMW project, delimit a number of records to read and process.
Here we can double check ourselves if the file was organized correct and data placed into right fields.
If you click on the data record, it shows record content parsed into source structure.
The system converts data from the source structure to the recording structure including all kind of mapping we’ve done on ‘Define Field Mapping and Conversion Rules’ step.
The same as display read data step but shows already converted data. This data will be entered during simulation (batch input).
If you want to keep all recordings for your records, tick ‘Keep batch input folders’. Otherwise, the system deletes all successful recordings. Only failed will remain in the system until they are processed.
SAP opens a SM35 transaction with Batch Input sessions.
Select the recording and click ‘Process’.
For 1 record to test it’s recommended to use ‘Process/foreground’ as the system shows every step on the screen with the data filled in.
Display error only is to run the process in the foreground and stop only on errors, so that user could react somehow.
In case of a large volume, it’s better to run in the background. It’s the fastest way.
If the record was not processed it would show errors in the log.
If we double-click on the recording there is a tab with a log. Once errors fixed (most common the employee or OM object is locked by another user) you can restart recording process. It will run ONLY for incorrect records.
Once all errors are fixed and recording is processed it will disappear from the list.
It means no more error occurred and we can verify the data.
There are some scenario specific recommendations.
It’s the same like was explained above. To upload these infotypes use PA30 transaction.
These infotypes have tables, so the loading is a little different. Before loading we need to ensure we know max number of rows in the uploading data. If, let’s say, there are max 3 rows (one per wage type or cost center), than in our recording we need to fill three rows, so the system would provide three fields for wage types, rates, etc. If we fill only the first row, we’ll have just one field, and records with 2-3 rows will be skipped.
You need to make sure there is no actions in PA40 transaction which need you to scroll the screen. If so you need to change user group parameter in SU3 to UGR = 10 to show only US actions. If this is completely impossible, actions could be loaded in PA30 in infotype 0000.
When saving data in these system tables it asks for a transport request. Moreover it asks only the first time. So the transport request screen will appear during LSMW recording and not again. LSMW will try to find data for that screen and won’t find it throwing an error. To avoid this create couple entries manually, save them in the transport request. Then don’t exit the session, open LSMW, make a recording and data upload within one session. Systems stores transport request in the session memory and doesn’t ask for it until you exit. So all LSMW activities will be performed without requiring transport request as it was entered during first manual data entries.
Proceed as described above.
Proceed as described in Table PA infotype section.