In May 2004, I showed you how to use the Legacy System Migration Workbench (LSMW) for your day- to-day logistics data conversion activities.1 Numerous requests for more information about using LSMW have inspired me to follow up that article with an advanced trick for using LSMW to meet your more complex mass change business requirements in an SAP R/3 system.

For those of you who have not read the earlier article, LSMW is a free, fully supported tool from SAP that can help you to, for example, quickly update customer master records from an Excel sheet or change pricing dates for specific sales orders. It is standard starting with Web Application Server 6.2. For earlier releases, you can download it from SAP Service Marketplace (https://service.sap.com/LSMW). Table 1 compares LSMW with other means of performing mass changes within R/3.

The prerequisite for using LSMW is that the data should be already available in input file. However, preparing this input file is often time consuming and requires a lot of data massaging. This is overkill, especially if the data is already available in SAP system. You can use tricks demonstrated in this article to access data available in SAP system directly in LSMW, rather than extracting system data and preparing the input data file.

Typical Business Requirement

Let me take a common scenario from the SD module. To expedite the deliveries to your customers, say you want to ship the orders from an alternative plant. In SAP terms, you want to update the shipping plant for all order items for specific sales orders. You know the specific sales order numbers, but each order can have multiple line items and you don't know, in advance, how many items are in each sales order.

Each of the four sales orders shown in Table 2 on the next page, 10001, 10013, 10024, and 10025, can have a different number of line items, as Table 3 on the next page shows. For all these sales order item numbers, you want to change the shipping plant to 1000.

LSMW Process and Its Trouble Spot

LSMW uses standard R/3 programs and transactions to convert data, therefore guaranteeing data consistency. The typical way in which you perform the conversion process with LSMW is to first create a project using transaction recording with transaction VA02 (change sales order). It updates the Plant field for the given sales order and positions it on the item data screen using the item number. LSMW requires an input file with sales order number and item number, similar to Table 3.

To prepare a data file with item numbers, use transaction SE16 on table VBAP (sales order item data) for the four sales orders from Table 1. The data file may look like Table 3. The LSMW step required to maintain field mapping and conversion rules may look like Figure 1. Figure 2 shows an overview of tasks involved in this scenario.

Figure 1

Typical field mapping to update shipping plant using order and item number

Figure 2

Typical tasks involved in LSMW conversion process

The biggest difficulty with the LSMW conversion process is preparing the file with the order number and item numbers (task 2 in Figure 2), especially when the data is already available in the SAP system. To demonstrate the situation, I have shown only four sales orders in Figure 2, and this makes task 2, preparing a file with sales order and item number, look simple. In real-world scenario, however, you could have thousands of sales orders; using SE16 on table VBAP for thousands of sales orders can be challenging, to say the least.

Solution: LSMW with Logic Processing

As mentioned earlier, the biggest difficulty is getting the item numbers, since each sales order can have variable number of items. Instead of using an input file with sales order and item numbers, it would be easier if you could use a data file with just sales order numbers. LSMW allows you to insert the following short ABAP program for logical processing. It loops through VBAP for the given sales order and gets the item numbers.

SELECT POSNR
FROM VBAP
WHERE VBELN = 'Order from Input File'.
ENDSELECT.

Next, you must change the LSMW step Maintain field mapping and conversion rules that appears on the main LSMW screen as follows:

• Remove the mapping of item number, as the input file will no longer have a column for Item Number.
  
  
• Click on the Initial button to use the initialization rule to remove the mapping for POSNR.
  
  
• Click on Extras>Display variant and choose the Processing points check box as shown in Figure 3.

Figure 3

Display processing points in variant display

• Observe the __END_OF_RECORD__ section. By default, the TRANSFER_RECORD rule is applied. Technically, TRANSFER_RECORD means that the data row is forwarded for further processing.
  
  
• Double-click on the ABAP code in the __END_OF_RECORD__ section and insert the code as shown in Figure 4. When you are finished, the Maintain field mapping and conversion rules step looks like Figure 5.
  
  
• Save your code and follow the usual steps of reading data and converting data.

* First convert the Sales Order Number in an Internal Format 
*
call function 'CONVERSION_EXIT_ALPHA_INPUT'
     exporting 
          input   = va02s-order
     importing
          output  = va02s-order. 
*
* Loop thru number of items for the Sales Order
* Get the Item Number and assign to Target Field (VA02_REC-POSNR)
* Call TRANSFER_RECORD within the Loop.
* What we achieved is multiple item records are written for one Order  
*
select posnr                             "Loop thru VBAP, get Item No  
  into va02_rec-posnr                    "Assign to Target field
  from vbap
 where vbeln = va02s-order.              "For Sales Order in SourceStr 

   transfer_record.                      "This was the original line
endselect.                               "Loop complete

Figure 5

ABAP code for updating the sales order item numbers

Use a file with just sales order numbers as shown in Table 2; you don't need to prepare a file with item numbers. When you execute the step read data, it reads four records from the input file. When you execute the step convert data, the code is executed, which in turn creates item number data. The data records with item numbers are then used to update the plant details for each of these sales order items.

With this method, you have used an input data file with just sales order number (similar to Table 2). The code written near __END_OF_RECORD__ gets the item numbers and creates data records. It repeats as many times as there are items in the order. This code first converts the sales order number provided in the data file to SAP's internal format. SAP generally stores order numbers with leading zeros — e.g., sales order 10001 is internally stored as 0000010001. The function module CONVERSION_EXIT_ALPHA_INPUT converts the order number 10001 to the internal format. If you don't convert the order numbers in internal format, SAP won't access VBAP, even though sales order 10001 exists.

The code loops through VBAP for this sales order, gets the item number, assigns the item numbers to the target recording field VA02_REC-POSNR, and transfers this record for further processing. Looping through VBAP creates as many records as there are items. In effect, this code creates the data records shown in Table 3.

Another Business Requirement

Let me add complexity to my example. Assume that the business requirement is to update the shipping plant only if that item is not shipped completely. What is the use of changing the plant if the order is already shipped? Incidentally, R/3 won't allow you to change the plant if the item has been delivered.

Delivery status is stored in table VBUP (sales document: item status), field LFSTA (delivery status). Table 4 shows a list of items their delivery status (LFSTA) from VBUP. From this list, you want to retrieve all items except those with delivery status C (Table 5).

As described earlier, preparing the input data file for Table 5 is cumbersome, especially now you have to join three tables. To avoid preparing the data file for specific criteria, you could use the data file with all data and let LSMW ignore the data records that do not meet specific criteria. The trick lies in using LSMW's SKIP_RECORD or TRANSFER_RECORD features for if ... then ... else conditional processing. In simple terms, TRANSFER_RECORD forwards the input data record from further processing, whereas SKIP_RECORD ignores the input record for further processing.

You can slightly tweak the code inserted in Figure 5 to achieve this conditional logic. The conditional logic is this: If the delivery status is not completed (LFSTA <> 'C'), then you need to forward the data record for further processing.

Mitresh Kundalia

Mitresh Kundalia heads the SAP practice at Quality Systems & Software (www.QSandS.com), a consulting firm specializing in SAP S/4HANA, SAP General Ledger, and complex System Landscape Optimization (SLO)-type reorganizations. Mitresh is widely acknowledged as a leading SAP expert, with multiple publications and an SAP-PRESS book to his credit. He has published more than 50 peer-reviewed articles and white papers, and he has given presentations at various SAP conferences and events. Mitresh is the chief solutions architect of General Ledger Migration Optimizer (GLMO), a leading product to accelerate and jump-start the SAP S/4HANA and SAP General Ledger initiatives; SAP Data Reorganization Optimizer (SDRO), an SLO-type product for managing complex system landscape reorganizations; and Group Currency Activation and Conversion (GCAC), a product suite to manage introduction of parallel currencies and conversion of data in a live SAP system.

You may contact the author at Mitresh@QSandS.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.