LSMW for Specification Management
Check this document useful for creation of Header data in specification management.
Steps to create a simple LSMW for EHS
The LSM Workbench is an R/3-based tool that supports you when transferring data from non-SAP systems (“Legacy Systems”) to R/3 once or periodically.
The tool supports conversion of data of the legacy system in a convenient way. The data can then be imported into the R/3 system via batch input, direct input, BAPIs or IDocs.
Furthermore, the LSM Workbench provides a recording function that allows to generate a “data migration object” in an entry or change transaction
To start working with the LSM Workbench, use transaction LSMW:
Click on the create button to create new project, subproject and the object. As shown below.
Project, Subproject and Object:
On the initial screen, you can create a new project, corresponding subprojects and objects via Edit -> Create new entry.
– Project: An ID with a maximum of 10 characters to name your data transfer project. If you want to transfer data from several legacy systems, you may create a project e.g. for every legacy system.
– Subproject: An ID with a maximum of 10 characters that is used as further structuring attribute.
– Object: An ID with a maximum of 10 characters to name the business object.
In the initial screen, All objects provides a list of all projects created already. My objects displays a list of all objects you created personally. All objects of the project displays all objects of the selected project as tree structure. Project documentation displays any documentation written for the individual popups and processing steps. you can print the project documentation out, send it and save it in various file formats.
Click on the execute button once the project, subproject and the object are created.
Click Back.Now record usingBatch Input RecordingData Migration – Step by Stepvia Batch Input Recording
Step 1: Maintain Object attributes
In this example, you will be updating the Specification master records with the help of recording a transaction (CG02). Choose radio buttonBatch Input Recordingand click on the recording overview icon to record the R/3 transaction. Enter theRecordingname asCG02_REC1, the description asCG02 Recording method, and the transaction code asCG02.
Click on create to record the transaction.
Click on Done to actually start recording the transaction.
Enter the fields required for recoding a transaction successfully.
Note that the fields are populated with default values. The values you entered when you recorded the transaction are set by default.
Click on default all
Click on SAVE to save the recording. The click on BACK icon to the main screen. Save the while going back to the main screen.
After completing the recording the system will automatically take you to the second step as shown below:
Step 2. Maintain Source Structures
Click on CREATE to create a source structure. Give a name and a description to the source structure as shown below:
Save the source structure and go to the main screen.
Step 3. Maintain Source Fields
In this step, you need to list what fields are present in the source structure. The easiest way is to click on ‘Table
Click on Object Overview
And Click on Table
Click CTRL + Y Copy to excel
Make Excel file ready like this
Maintenance’ icon to enter Field name, Type and Length for each field as shown:
Click on Hit list icon
Copy the Excel made items into this screen directly
Save while coming back to the main screen.
Step 4: Maintain Structure Relations
Execute a step to ‘Maintain Structure Relations’. Since, there is only one Source and Target Structure, the relationship is defaulted automatically.
Save while coming back to the main screen.
Step 5: Maintain field mapping and conversion rules
Keep cursor on field ‘SUBID’ and click on ‘Assign Source field’ icon to choose source field shown
For constant field like NAM LANGU click on constant give required language example EN
Similarly, assign ‘Source Field’ rules to the remaining fields.
Once all the fields are mapped, you should have an overview screen as shown
Save while coming back to the main screen.
Step 6: Maintain fixed values, translations, user-defined routines
You can also maintain re-usable translations and user-defined routines, which can be used across conversion tasks. In this case, that step is not required.
Step 7: Specify files
In this step, we define how the layout of the input file is. The input file is a [Tab] delimited with the first row as field names. It is present on my PC (local drive) as C:\TransOil.txt.
Double Click on the legacy data
Save while going to main screen.
Create an Excel with your data and save it as a Tab-delimited text file on your local drive (C and name it .txt.
****The Structure of the flat file should be proper otherwise data will not be uploaded.. All the mandatory fields should be present in the flat file for the required transaction
Step 8: Assign files
Execute step ‘Assign Files’ and the system automatically defaults the file name to the source structure.
Save while going to main screen.
Step 9: Read data
In this step, LSMW reads the data from the source file (from your PC’s local drive). You have the option to read only selected rows and convert data values to internal format.
Here 1 to 23 represents the number of rows to be read from the flat file. If you don’t specify any number the system will read all the rows from the flat file. We have 23 rows in the flat file hence from 1 to 23.
After we execute the data read from the flat file is as shown below.
Step 10: Display read data
This step is optional. If required, you can review the field contents for the rows of data read.
This is the step that actually converts the source data (in source format) to a target format. Based on the conversion rules defined, source fields are mapped to target fields.
Click BACK to come back to main screen.
Step 12: Display Converted data
Again this is an optional step to view how the source data is converted to internal SAP format.
Step 13: Create batch input session
Once the source data is converted in an internal format, you can create a batch session to process updates.
Click EXECUTE button to execute a batch inout session.
Step 14: Run Batch Input Session
You can execute the BDC session by Run Batch input session. Executing a batch input session is a standard SM35 transaction for managing BDC sessions. Once you have successfully executed the batch input session, the Specification master records are updated in the system. You can confirm this by viewing the Specification master records
Select the session and click on the PROCESS icon.
You can Process the session in foreground or background or can only display errors.
Select the Processing Mode and then click on the PROCESS tab to executive the session.
After the session is completely processed you can confirm this by viewing the Specification master records (CG02) or in the table.
first thanks for quite interesting document.
But according to SAP (what i know from history) etc. SAP does not ! support batch input for EHS (e.g. The SAP Fan Club Forums &bull; View topic - EHS BDC for T-code CBIHM2)
I can remember that for CG02 as well there is a corresoponding OSS not. So: does it work now? (please check discussion here: Error in Exporting the Pharases - OBJECTS_OBJRE... | SCN
Here the corresponding OSS note is referenced
PS: Corresponding OSS note 757907 is still valid. No change here. So batch Input is not supported for EHS transactions.
If I remember correctly you are right:
You can not load property data with LSMW into CG02 - because of the controls used.
In my opinion without property data you can only load 5% of the data....
as you may be know. LSMW has some "suboptions" One suboption is (for load purposes)
You can use IDOCs.And clearly you can use IDOCs for CG02 upload (SUBMAS etc.)
But I have never found somebody (or get in contact with somebody) in the EHS world who has used this approach.
Today: for upload purposes in CG02 my list of preferrred processes would be:
a.) use Standard import for generation of new spec id (or use may be SAP OCC)
b.) for update of data of any kind: use SAP OCC or SAP standard import; most consultants might use SAP OCC here.
I would assume that because of the very nice new feature in SAP OCC many consultants might use option "a.)"
As for a.) and b.) the prerequisites are the same (you need phrases, mapping of data etc.) option a.) seems to be a good one. The "only" but is, you need a little mor customzing etc and you need to set up SAP OCC (rfc connection etc. etc.)
For specification Header(include identifier) i successfully used LSMW without any error, LSMW it capture the fields where we have the enter the data.
I will work on IDOC how it will work.
For Specification Header data i did LSMW & for Property tree i done import & export.
surprising results as the OSS is quite clear. No suport of any EHS transaction for Batch input.. (even not specification header etc.)
In any case: Very interesting document. I hope that you will update soon to share informaiton about use of IDOC scenario with LSMW
check e.g. LSMW -BAPI - hazardous substances
LSMW - BUS1077 - Specifications for CG02
Master data Load for Substance Creation : Using BAPI in LSMW ?
LSMW for CG02
Please update how to migrate and create1000 substance specs in SAP EHS through legacy system
Create mass specifications and update value assignments
spec import_inheritance data
you will find some references of use of LSMW and ALE
kind of "warning" in your mapping. You have used char132 for identifiers. You need to pay attention regarding your text (source) file. You should make sure that the length of an identifier does not exceed 132 characters. If it exceeds: only the first 132 characters would be loaded
Still i have big doubts regarding the "MATLANGU" mapping. I do not understand it. FRM, SUM etc. is fine. But the handling of material texts is done different. And EHS is just using what MM is providing here.
For CG02 upload (specification header and identifiers) you don't need this
On top: it is "bettter" to be flexible in upload (and not just define that language is "EN" (=E) and therefore to enlarge the laod file structure.
The OCC approach good be of interest here.
Using your approach: you can not load "usage" and "regulatory lists" for identifiers. In most cases this is not that "interesting". But for usage: you should have set up a a "default" usage in SAP system. Starting with EHS 2.7 this is strongly recommended.
Thanks for the inputs.... actually we have to know exactly how much client is going to use.
In identifier normally allows up to 132 characters in the field if wont able to give more than that.
Actually here client need minimal requirement.
In case of USAGE i will take as constant Default.
I will try for I Doc also lets see which will work good.
Thanks for you valuable inputs CB.
if you use clever SAP OCC or SAP ehs standard import identifier can be longer than 132...
Identifier can be as long as needed (as with user defined text). Only because of the fact that "ESTRI" limit the length to 132 is only an indication. Using EHS standard import (and OCC) you can load clearly identifier longer than 132 characters. Same is true for "IDOC".
Pay attention for definition "In case of USAGE i will take as constant Default."
We have "two" default options (and you must/should take care here for upload purposes)
One default option is triggered via "customozing". Second one is triggered via "user profile". User Profile content has "higher priority" than customizing. Therefore.
For upload purposes it is always a very good idea to check the "user profile" used.
Clearly: the "IDOC" topic is more complex. And you need to have "very deep understanding" of EHS data model (but it depends as well on the data which you would like to load...)
In context of IDOC: I believe the story need to be distributed using:
BAPI_BUS1077_REPLICATE SAP ABAP Function Module - EHS: Request to Replicate Specification Data
BAPI_BUS1077_SAVREPMUL SAP ABAP Function Module - EHS: Saving Replicated Specifications
with highest focus on last one (this is the "inbound part; first is the "outbound" part)
(e.g. as well: SAP ABAP Function Module BAPI_BUS1077_SAVREPMUL (EHS: Saving Replicated Specifications) - SAP Datasheet - The Best Onlin…)
For full ALE scenario between two SAP systems you need to be an "expert" for ALE (because e.g. on source system there is the chance that there is a "document" assigned on user defined text level; and therefore you need to distribute documents as well)
Generally: the "import/upload" via IDOC part depends on your blueprint story.
One story could be:
1.) generate first the specification with some identifiers (as in your example)
2.) add e.g. materials to the specificitions (which is "simple" in comparison to 3.)
3.) add data as part of the "property tree" to the specification (this is the "most complex story"
Keep in mind: we have properties of type "A", "B"; "C"; etc. and mixed scenarios as well. You need a "good" load structure; and you need to use may be "LSMW" "heavily (e.g. you need to use ABAP code for mapping and other purposes)
PS: if you have the chance to check ALE scenario SAP <=> SAP for EHS data you can learn a lot how SAP is doing the job (and you can analyse the content of IDOCs and try to understand them)
Transactions as BD87 and WE30 are here helpful...
PS: I am very interested if you succeed to load via IDOC... never tried..
PPS:at least for outbound purposes you have a number of "exits" in ALE of EHS data; the same is true (i believe) for the inbound part Refer to the link as shown and this part:
If only specification data is to be deleted, it is deleted and the program is terminated. Otherwise it continues.
An identification must be run for all specifications, even for referenced specifications (ESTRR, ESTVP, TAB0F). If no user exit is specified, the specification key is used for identification. The result is two lists with new specifications and specifications to be changed. "
The interface data can be edited subsequently using a user exit.