The function module should carry out the following steps:
- 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.
- When implementing an inbound function module for master data that can be "reduced" by customers, don’t check the message type; check the basic IDoc type instead (field Idoc_Contrl-Idoctp) Initialize/refresh any global variables and/or tables.
- Initialize/refresh any global variables and/or tables. The inbound function module can be called a number of times by the same process, so the global variables will not be empty the second time around.
- Convert the character data in table Idoc_Data to 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 when the field in the IDoc is empty (i.e. blank): In ABAP, moving a blank character field into a date field leaves the date field blank, rather than initial (all zeros) i.e. the date field ends up containing an invalid value. Errors will occur in subsequent processing whenever 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.

Remember: the function module should not do a Commit Work.
If you have the choice, don’t update the database using Call Function "xxx" In Update Task - it is unnecessary for ALE inbound processing, and only increases database load.