Business Units steps configuration.

Transaction /EDGE/FC_SPRO → Configuration Folders "Business Units" → "Business Units steps".

Through this configuration, you can specify the different steps of the process you want to deploy. It is recommended to have previously designed the process, as mentioned in the chapter "Business process design". Additionally, it is required to have designed the states as indicated in the chapter "Design of the states through which the process can pass".

It should be clear that the execution of the steps operates based on the following

Every time the b+ dgtal eInvoice is executed, it checks the process instances that are still in a state marked for automatic processing.
It takes each instance that meets the criteria above and begins to verify each step, starting from the first one according to the sequence.
During the verification process, it validates that the process is in a state that the step can accept.
If the condition in point 3 is met, then the step is executed. At the end of the step, two things may result:
1. The step completes successfully, and the state is changed to the one configured or as indicated by the step's implementation.
2. The step encounters an error. If this happens, the execution of this instance is terminated.
The next step in the sequence is continued, and the logic from point 3 is applied again.

Below are the columns that must be filled out to create a step:

Step
Sequential number of the step, indicating the execution sequence of all steps. It is recommended to use increments of 10 to allow for the possibility of adding new steps after the initial ones have been configured.
Step name
Description or name of the step being configured.
ABAP Class
Refers to the ABAP implementation of the step being configured. This ABAP class should implement the interface /EDGE/IF_FC_INTERPRE_STEP. However, for developers' convenience, an abstract class that includes much of the commonly used step logic has been implemented. This class is /EDGE/CL_FC_GENERAL_STEP, and it implements the interface /EDGE/IF_FC_INTERPRE_STEP. Therefore, it is recommended that when creating a step, it should inherit from the class /EDGE/CL_FC_GENERAL_STEP.
For more information on the standard steps included in the product, please refer to the chapter "Reuse of Standard Steps in any Process". To understand how steps should be developed, please consult the chapter "ABAP Development of Configured Steps".
Final Stat
Represents the successful completion state that the step can reach. If the step can only have one successful completion state, it should be entered here. Otherwise, if it can have multiple states, this field should be left empty, and it should be the step's responsibility to determine the final state programmatically (by reimplementing or redefining the GET_FINAL_STATUS method). If, on the other hand, the step does not modify the current state of the process, this field should also be left empty, and the determination of the final state should not be implemented in the step. The generic step /EDGE/CL_FC_GENERAL_STEP takes this into account; if no final state is entered and the GET_FINAL_STATUS method is not reimplemented or redefined, the state will not change.
State err
Represents the error completion state that the step can reach. If the step can only have one error completion state, it should be entered here. Otherwise, if it can have multiple states, this field should be left empty, and it should be the step's responsibility to determine the error state programmatically (by reimplementing or redefining the GET_FINAL_STATUS method). If, on the other hand, the step is not susceptible to throwing exceptions because its execution is straightforward, this field should also be left empty, and the determination of the error state should not be implemented in the step. The generic step /EDGE/CL_FC_GENERAL_STEP takes this into account; if no error state is entered and the GET_FINAL_STATUS method is not reimplemented or redefined, the state will not change.

Example of the configuration: