In general, you should try to use function modules to update the database rather than resorting to a Call Transaction; a Call Transaction has a significant performance overhead. The advantage of using a Call Transaction is that, if an error occurs, the user can reprocess the IDoc by going through the transaction’s input screens.

Implementing a ‘one IDoc at a time’ function module as described above, but where the function module uses a Call Transaction to post the application data to the database, results in the application data being posted in a different logical unit of work from that in which the IDoc status data is posted - a Call Transaction does a ‘commit work’ when successfully executed. (See the above section on ‘Ensuring one logical unit of work’).

The solution to this problem is to modify the transaction so that it updates the IDoc status data when the application data is updated, i.e. when the IDoc is successfully processed. Note: this only applies to successfully processed IDocs; errors are handled in the same way as before.