The Legacy System Migration Workbench (LSMW) is a SAP tool that enables efficient data transmission into SAP systems. Especially when creating more complex datasets that cannot be imported via the MASS transaction, "LSMWs" play an important role. Additionally, no programming knowledge is required for its application. This makes the tool interesting for a broader spectrum of users.

The following article discusses LSMWs in general and examines the Business Object Method in more detail using a short example in the RE-FX module.

An advantage of the LSMW transaction lies in its division into numerous easy-to-understand steps. This is illustrated in the following figure.

In this article, we will focus primarily on steps 1-6, as these steps include the configuration of the LSMW. Steps 7-16 involve uploading and processing the input data. These steps must always be repeated if further data is to be fed into the system. They can be implemented without difficulty if the configuration of steps 1-6 and the input file are compatible.

Step 1 is the most important step when creating an LSMW. The explanation of this step will shed light on LSMWs in general. The remaining steps are best illustrated using an example. Step 6 is not shown in this article as it is not required in many cases and is relatively complex.

Selection of the LSMW method (step 1)

At the start of each LSMW, it must be specified which fields are to be filled. There are four different options for this, standard batch/direct input, batch input recording, business object method and IDoc. The selection screen is shown in the figure below.

Batch input recording

The simplest method for users is batch input recording. The user can use a suitable transaction to fill in the required fields. The fields are saved in the background during the use of the transaction. The disadvantage of this method is that it can only be used to a limited extent and is prone to errors. For example, pop-ups or switching between tabs within a transaction can be insurmountable obstacles to using this method. It is also possible for fields to be filled unintentionally, as the evaluation of the adressed fields is a greater technical challenge in relation to the recording. However, if the transaction used has a simple structure, this approach offers an easy solution.

Standard-Batch/Direct-Input Methode

With the standard batch/direct input method, the fields of an object are filled via an existing program. The disadvantage of this method is that it is only available as standard for a limited number of use cases. It therefore depends heavily on the problem as to whether this method is easy to use. If, for example, financial documents are to be recorded, then this can be easily implemented as ready-to-use programs are available. On the other hand this method is less suitable for modules such as RE-FX, as many aspects of the module are not covered by the available programs.

Business Object & Intermediate Document(IDOC) method

In the case of RE-FX, there are many BAPIs that can be used for the Business Object method and for the Intermediate Document (IDOC) method. BAPIs (Business Application Programming Interfaces) are standardized interfaces provided by SAP to enable access to business processes and data. For the user, this means that a structure is available that enables certain fields to be filled. Depending on the respective BAPI, more complex data objects can also be accessed and filled. The disadvantage of these two methods is that they are relatively complex. This means that a considerable hurdle must first be overcome before they can be used. Once this hurdle has been overcome, the knowledge can also be transferred to other use cases, as the use of different BAPIs works in the same way.

The major difference between the Business Object and the Intermediate Document (IDOC) method is that the IDOC method uses a standardized file format (intermediate document). The intermediate document file format is similar in structure to the XML format. A port must be set up so that the SAP system can process this format. This is also necessary if the upload data originates from an Excel file. These requirements mean that the IDOC method tends to be even more complicated and errors are more difficult to rectify than in the case of the Business Object method.  

After defining the fields to be filled with one of the methods mentioned above, the data from the upload file must be mapped to those SAP fields. This is done using several sub-steps, which are illustrated in the next section.

Application Example

In our specific use case, we would like to create settlement units using the BAPI "BUS1506_CREATE". The following figure shows the selection of the BAPI.

Settlement units are an important part of service charge settlement in the RE-FX module. They are used as containers to redistribute costs either to other settlement units or to rental properties.

The data of the settlement units in the RE-FX module is divided into different registers (see transaction: RESCSU). The BAPI "BUS1506_CREATE" enables each of these registers to be addressed individually. Each register itself contains certain fields which can be viewed using the "Object overview" function from the LSMW guide. The button is highlighted in the image below.                              

The next figure below shows the object overview.  The "Struktur" column contains an entry for each of these settlement unit tabs, the fields that can be filled in are listed in the "Zielfeldname" column.

Users who are familiar with creating a settlement unit will immediately recognize this structure. Depending on how exactly the settlement units are to be created, certain of these fields must be selected and mapped to the input data.

Maintain source structures (step 2)

In this step, you must define how the source structures are constructed. The source structures correspond to the tabs from the "Struktur" column in the object overview. In our case, a hierarchy must be set up here, as nesting can occur when creating settlement units. We define a header that contains the basic data (company code, business entity, service charge key and Settlement Unit number). In addition, further subordinate files containing data for each specific settlement unit. In this case, apart from the header, we want to fill the base data (E1BP_RE_SETTL_UNIT_DAT), participation group (E1BP_RE_PARTICIP_REL_DAT) and allocation rule (E1BP_RE_APPORT_RULE_DAT) registers. Which registers are to be filled depends on the use case. However, some registers must always be filled and there are dependencies between some of them. The source structures of our example can be seen in the following image.

Maintain source fields (step 3)

In this step, the fields of the individual files (source structures) are defined. These are all fields that are entered into the system from an external source. In step 5, there are further options for filling fields that do not originate from an external source, for example via constants. The desired fields can be taken from the "Zielfeldname" column in the object overview. In order to link the various registers/source structures correctly, it is necessary to define a mapping variable. This mapping variable ensures that the hierarchy described in step 2 can be guaranteed. For example, the mapping variable links the correct allocation rule with the correct header. On the Participation group tab, this mapping variable makes it possible to link several participation groups to one settlement unit (1:N relationship). All selected fields can be seen in the figure below.                              

Maintain structural relations (step 4)

In this step, the input files (source structures) from step 2 must be mapped to the SAP registers from the object overview.

Maintain field mapping and conversion rules (step 5)  

This step involves a considerable amount of effort. Here you define which SAP fields are to be filled by the fields from the input files (source fields) that were defined in step 3. If a field is not to be filled with data from the input file, this can also be done using a constant. This is useful if a field constantly contains the same value.

Specify files (step 7)

In this step, the external data to be imported into the SAP system is determined. In our example, this is done by uploading 4 .txt files. The following images illustrate what the content could look like.

In this example, we create the two settlement units 1000 (mapping variable=1) and 1001 (mapping variable=2). Both settlement units would be assigned the allocation rule ZZ01. Settlement unit 1000 is linked to participation groups 1 and 2. Settlement unit 1001 is linked to participation groups 3, 4 and 5.

Allocate files (step 8-16)  

In step 8, the input files must now be linked to the source structures previously defined in step 2. The assignment for our example can be seen in the image below.

We will not explain steps 9-16 in detail here, as they mainly involve processing data. These steps are helpful for recognizing errors and determining the causes of errors. It is recommended to check the data carefully during this process. After carrying out these last steps, the settlement units are successfully created in the system.

Conclusion

LSMWs are not easy to use, but they enable users to cope with enormous amounts of data.

By using the BAPI "BUS1506_CREATE" shown in the example, the creation of a basic object of the RE-FX module can be automated without any programming knowledge.

‍