Minimize the number of LSMW programs to load SAP projects

Introduction

Although SAP currently promotes “best practice data migration” using Business Objects Data Services, LSMW is still the tool of choice for many projects.

LSMW is free and simple to use and handles many things more or less automatically.

In this and other blogs I want to share some of my experiences from recent projects. I am not a programmer so any ABAP code that I show will not necessarily be the best that could be used. However, data migration is a one-off so it usually isn’t important if the code is beautiful and efficient (unless of course you have very large data volumes). I am assuming that you are already familiar with LSMW. If you are a beginner then there are plenty of other SCN posts that will help you.

How many LSMW programs to create a SAP project?

There is no standard SAP program, IDOC or BAPI available for the creation of a SAP project and its WBS elements, so recordings have to be used. The project builder transaction CJ20N is an “Enjoy Transaction” and is therefore not recordable.

The common approach is therefore to use CJ01 to create a project header and then to use CJ02 to add WBS elements. The question that then arises is how many recording and how many LSMW programs to use.

I adopted the classic approach of first creating the project header in LSMW and then separately adding the WBS elements.

The problem with adding WBS elements is the positioning of the cursor. The elements are added in a table and with an LSMW recording you can’t reposition the cursor with program code. Typically when adding records to a table, you need as a minimum to have a recording to add the first element and a recording to add subsequent elements. For WBS elements you only need these two recordings if you set them up correctly. These two recordings can be combined into a single LSMW program.

The reason that I am writing this blog is that I have seen examples with 3 or 4 separate recordings and LSMW programs being used and this seems unnecessarily complicated to me.

So, in order to add WBS elements to the projects created by a previous LSMW program, you need two recordings of CJ02:

• Recording to add the first WBS element to a project. This has to be separate because there is no parent WBS
• Recording to add subsequent WBS elements

Both recordings are included in a single LSMW program. In LSMW on the Maintain Object Attributes screen use the More Recordings button on the line where you add the recording. In the pop-up box you can then add extra recordings:

The “top” recording to add the first WBS element is straightforward. Here are some example screen shots:

The second CJ02 recording is what gives the most trouble. The way to set it up is as follows:

• On the first screen enter then project and the parent WBS of the WBS element that you want to insert and then press enter, for example:
  • Project = ZB.999999
  • Parent WBS = ZB.999999.001
• On the next screen which shows some WBS elements press the last page button followed by the next page button. This ensures that the second row of the table is always the place where you will enter the data for the new WBS. (When you do the recording with only your top WBS element present this seems a bit strange, but it’s the way to do it)
• On the (empty) second line of the table enter the level, the WBS element and the description. Then go to the WBS detail screen either via the menu Details – WBS Detail Screen or CTRL F9
• Now you can enter data on each of the tabs that you are using. Make sure that you analysed all of the tabs needed before you make the recording to avoid having to redo the recording in the future!
• When you have entered all the data press the save button

You now need to be a little bit careful with the assignment of field names to the recording. You can use the “default all” button but you must then change some of the field names afterwards. The reason is that POSID on the initial screen is the parent WBS but on subsequent screens it is the WBS that you are adding. You should also be aware that in the separate recording to add the top WBS element, POSID is consistently the WBS that you are adding.

The actual field names that you use don’t really matter as long as you are consistent. In my LSMW I also had some help fields as follows:

• h_pspid is the PROJECT identification
• h_posid is the parent WBS
• h_ident is the WBS to be added

and in the recordings I used the same convention.

Here are some example screen shots of the recording:

After defining the recordings you need to define the input file. The input file for the program should be sorted into the sequence of the WBS elements:

STUFE   C(003)   Level

PSPID    C(024)   Project Definition

POSID   C(024)   WBS Element

The remaining input fields will of course depend on the attributes being used.

Since multiple recordings are being used, we need some ABAP code in the BEGIN_OF_TRANSACTION block:

• Determine which recording to use. This is easy: If STUFE = 1 then it’s a top level WBS
• Determine the value for the parent WBS element. Obviously this depends on the template for the project type. For example in my case the level 3 element ZB.999999.001.01 would have a parent element of  ZB.999999.001
• It is easier to work with these codes without the “.” Symbols. There is a function module CONVERSION_EXIT_PROJN_INPUT which can be used

In my case all of the project types used had the same mask for the WBS structure, so it was fairly easy to code.

We also decided to determine in the LSMW program the values of the operative indicators using logical rules based on the project type.

The indicators were only set at the lowest level WBS element and in order to know if the current element was at the lowest level, I implemented “read ahead” logic. I explained how to do this in a previous blog. With read ahead logic it is easy to decide if we are at the lowest level: if the current level is higher than the previous level, then the previous record was at the lowest level. When read ahead logic is used we test this condition in the BEGIN_OF_TRANSACTION block and write the previous record there.

The LSMW was also designed to handle multiple project types where the attributes that need to be filled (and sometimes their values) differ per project type. In the BEGIN_OF_TRANSACTION block the project profile was retrieved from table PROJ. This can then be used in the coding per field of the recordings. The input file was included the full set of attributes that might be used. In the spreadsheet that users used to provide the input, it was indicated which columns where needed per project type.

Conclusion

When set up correctly you only need 3 recordings and two LSMW programs to create projects and WBS elements. This is easier to manage during data migration.