IDoc Processing

The function module should carry out the following steps:

1. Check that the IDoc contains the correct message type (field Idoc_Contrl-Mestyp). If it does not, raise the exception Wrong_Function_Called with an appropriate message.

2. When implementing an inbound function module for master data that can be "reduced" by customers, do not check the message type; check the basic IDoc type instead (field Idoc_Contrl-Idoctp).

3. Initialize/update all global variables or tables. The inbound function module can be called up more than once by a process. The global variables are therefore filled with values the second time.

4. Convert the character data in table table Idoc_Data to an internal format in internal tables. See the example coding below to see how to do this. Special attention must be paid to fields containing:

   • Units of measure (ISO code in IDoc)

   • Currency codes (ISO code in IDoc)

   • Country codes (ISO code in IDoc)

   • Shipping instructions (ISO code in IDoc)

   • Monetary amounts (conversion factor needed)

   • Dates and times (see below)

   Fields containing dates and times can lead to errors during inbound processing if the field in the IDoc is empty that is, blank: In ABAP, if a blank character field is copied to a date field, the date field remains blank and is not initial (does not contain zeros). This means the date field contains an invalid value. Errors occur in subsequent processing as soon as the field is checked for an initial value, if DateField is initial.... To avoid this, clear the date field if the IDoc field is empty, as shown in the example code.

   Note

   The function module should not commit the data to the database (using a commit work).

   If possible, do not update the database using Call Function In Update Task - this is not required for ALE inbound processing, and only increases database load.