Multiple LUW in single IDOC function module, is it OK?

Posted on Jan 27, 2012 at 03.37 PM - Kuala Lumpur, Malaysia

Well, there is NO definite answer for it. It depends on the scenario, sometimes it may be useful just to lump several LUW in one IDOC posting function module. As such the maintenance and monitoring part will be easier to do.

First of all, let’s see in which scenario we might need to have multiple LUW in one single IDOC function module. One case is when a plant has to be created first prior to certain material can be created. Another case would be when a sales order has to be created first prior to delivery order, etc.

By right, this issue is addressed by SAP through IDOC serialization. There are multiple techniques available, serialization by message type which is easier to implement, and object channel serialization which is more difficult to do. I will discuss both serializations in my next blog. However, implementing this serialization technique is easier said than done, and due to this reason it’s easier to handle the dependencies directly in the program or directly in one IDOC.

The problem with the program handling the dependencies of the IDOCs is started when the IDOCs get error out; the dependencies of the IDOCs are lost. So the dependencies must be maintained NOT at the program level alone but also at the IDOC level. The subsequent IDOC, except for first IDOC, must perform necessary check of the existence of the previous IDOC posting. Should it is NOT part of the standard IDOC validation, then this check will have to be done through IDOC enhancement or implicit enhancement. The same goes to storing unique identifier for necessary check of IDOC posting; this can be done by adding additional user segment and field to the IDOC.

As you can see that having multiple IDOCs with dependencies among themselves poses different issue by itself, as you need to know the proper sequence of the IDOC processing. And that’s when the idea of lumping all the LUW into 1 single IDOC making more senses.

Actually SAP also does this technique in some of the standard IDOC, like HRMD_A where it allows multiple info types for multiple persons to be created at once. The key over here is to make sure that when the IDOC error out, it should be able to be restarted on the correct LUW and bypassing the successfully processed LUW. The LUW has to be processed synchronously and NOT asynchronously as normal IDOC does!

Life is beautiful! Let's make it meaningful and colorful!