The technical flow for the functionality of the subsequent processes is shown graphically in the flow chart below.

A subsequent process can be triggered by the user in different ways. It is possible to go via the QPPD or for the user to trigger the subsequent process directly.

If the user enters via the QPPD, the subsequent process is triggered by saving via the bus or the GUI. In both cases, the model is called via the controller. The model in turn calls the data service.

Depending on which subsequent process was set by the user in Customizing, the corresponding method is called using the data service. The three options of the data service are starting all subsequent processes, calling the info process control, and writing change documents.

Starting all subsequent processes leads to the distribution of subsequent processes and the customer processes using the method PROCESS_FUPP.

The IDOC outbound processing and the copying of data using RFC are processed using the distribution of the subsequent processes. To do this, the IDOC service is called by both the method for IDOC outbound processing and the method for copying data using RFC. In addition, the RFC service is called by the method for copying data using RFC. If the data is not to be saved using RFC, the RFC service calls the data service again and further subsequent processes can be processed.

The subsequent processes created by the customer can also be processed by the data service and using the method PROCESS_FUP.

If the info process control is to be called by the user setting, this is also done using the PROCESS_FUP method.  First, the info data records are selected and the info service is called. The info service uses the PROCESS_FUP method to control the info data record processing, which then also calls the info service.

Finally, the data service can trigger the writing of change documents. The method PROCESS_FUP is used to call the writing of change documents after objects have been saved. This method calls the change document service, which again triggers the processing of change pointers using the method PROCESS_FUP. The method for processing change pointers calls the change document service last.

The user can also address certain subsequent processes directly. These are the info process control, the follow-on process distribution, the customer processes, and the IDoc inbox. These subsequent processes are triggered by directly addressing the method PROCESS_FUP, except for IDOC inbound processing.  Here, the user triggers method PROCESS_FUP using method ALE_IN. The flow of the subsequent processes via the direct control of the user is equivalent to the flow by addressing via the data service. The IDOC inbound processing is an exception since it cannot be called using the data service. In this case, IDOC inbound processing is called, which calls the IDOC service. The data service is called via the IDOC service and processing of further subsequent processes is possible.

A detailed overview of the methods used to execute the subsequent processes can be found in the detailed view of the flowchart.