Use multiple recordings in a single LSMW Object

Some objects call for two or more recordings because the screen flow is different based on the source data. In many cases a single recording will do when used with the coffee cup method because SAP raises a warning over a missing screen field instead of stopping the transaction, but the transaction can still be run.

Some objects must be run with multiple recordings and, because it is simpler to have just one LSMW object rather than two, we build a single LSMW object with two recordings. In this example the client wanted the component allocation in the Routing to be on the second task to ensure that "backflush materials are consumed". Due to some customization, neither the standard transaction nor the BAPI load methods worked and, after a lot of research, two recordings were written to load the routings.

The first step was to create two recordings. The first recording created the routing with a single material. The task list group was left blank and created internally by the system. The second recording added the second task with the same material. No linking to the routing group in the first recording was was required because SAP automatically assigns the material to the same task list group and then adjusts the component allocation to the second task.

The two recordings where named CA01 and CA01U. Adding them to the LSMW is very easy in the Change Object Attributes screen. Click the button to the right of the recording name and add the second (or third or forth) recording here.

After the structure for the source file is created and the field names are added, the source file must be related to the structure of both recordings. Later we make the determination on which recording to use based on the source data.

In the Maintain Field Mapping and Conversion Rules section the hierarchical layout now reflects the fields from both recordings and LSMW will create a transaction for each of them without instructions on which to use. Since the CA01 recording is only for activity 0010 a filter is added to ensure that any other activities are not processed in this recording. The same is done for the CA01U recording with the activity 0020. A small snippet of code corrects the activity number where it was handled with Excel.

With these two lines of code we ensure that only the transaction intended for the source data is created. It is easy to see how, with a little effort, two transactions can be created for the same source code. In this case the same transaction code, CA01, was used for both recordings, but it needn't be. A good example of where two different transactions might be called back-to-back is creation of inventory and then packing it in a handling unit. Another idea is to create a bank master record and then assign it to a vendor master.