Kontakt

Ansicht
Dokumentation

W_WB2B_WF_APPROVAL - BAdI: Workflow-Based Approval Process

W_WB2B_WF_APPROVAL - BAdI: Workflow-Based Approval Process

Vendor Master (General Section)   BAL_S_LOG - Application Log: Log header data  
This documentation is copyright by SAP AG.
SAP E-Book

This Business Add-In (BAdI) is used in the Global Trade Management (LO-GT-TC) component. It enables you to implement your own determination and check logic for the workflow-based approval process. An active BAdI implementation is an essential prerequisite for the workflow-based approval process. The BAdI is called by the system in two different situations:

  • When the BAdI expects a decision.
  • When the BAdI does not expect a decision.

The BAdI expects a decision

In this case, a non-empty table CTS_APPROVAL_DECISION is transferred to a method that can be modified by the BAdI.

If an approval process is required, the field WF_ID has to be filled with a valid workflow ID (for example, WSxxx, xxx = 8 digit number).

  • If the field has been filled, the systems checks whether the workflow ID has been declared in the associated Customizing table WB2_C_WF (see Customizing under Define Workflow IDs and use class CL_WB2_C_WF to get the current entries). If the workflow ID has not been declared, the system reacts with an error message, and the trading contract cannot be saved.
  • If the workflow ID is valid, the system changes the application status of the trading contract to the corresponding default status for the approval process (a status with the purpose To Be Approved). If the current status already has a suitable status purpose, the current status is taken instead of the default status. The workflow ID is stored in the event container and is later sent with the event "TOBEAPPROVED" of the (BOR) business object type BUS2124. In the event type linkage of this event, the function module WB2_WF_APPROVAL_EVENT_REC has to be assigned as the receiver type function module (transaction SWETYPV). This allows dynamic event receiver determination.

The system expects a decision by the BAdI if the trading contract is not yet part of the approval process, and the current application status

  • has the system status 2 (Release Carried Out)
  • has the status purpose 1 (To Be Approved (Open)
  • or the status purpose 2 (To Be Approved (After Release)

Only in these cases is it assumed that the trading contract can be approved by the workflow (note that it must be possible for the workflow to change the application status to an application status with system status 2 (Release Carried Out).

There are some Customizing-dependent checks that have to be fulfilled, for example, the incompleteness check. There is one exceptional case. If the trading contract has been approved by the workflow (import parameter IV_WF_CALL_ACTIVITY has the value A ; the new application status has the system status 2 (Release Carried Out)), it is possible to overrule the decision of the workflow. This could be necessary if, for example, unexpected changes to the trading contract data have been detected. In this case, the field "WF_RESUBMIT" can be used to reject the approval of the workflow. One consequence is that the changes to the trading contract data are not saved, and the trading contract remains in the workflow environment. If the parameter "IV_FOLLOW_DOCUMENTS" is set, the system tries to create or update the follow-on documents of the trading contract (normally there are only small or no changes in the data of the trading contract if the creation or update of the follow-on documents is requested by the system).

If no approval process is required, the field "WF_ID" has to remain blank. If the current application status has a system status with value 2 (Release Carried Out), the application status remains unchanged. If the current application status has the status purpose 1 (To Be Approved (Open)) or 2 (To Be Approved (After Release)), the fields "ACTION_NO_APPROVAL" and "OPTIONAL_STATUS_NO_APPROVAL" can be used to control the behavior. A specific application status is only taken into account if the status is valid.

The BAdI does not expect a decision

In this case, the empty table CTS_APPROVAL_DECISION is transferred to the method. The table CTS_APPROVAL_DECISION is not evaluated after the BAdI call. The BAdI is called to provide the option to detect changes to the data of the trading contract, or to take notice of the workflow response (import parameter IV_WF_CALL_ACTIVITY).

Note

It might be necessary to have a custom-based persistency. If the trading contract is changed after it was approved by the workflow, it may be difficult to determine whether a new approval process is required or not. In the standard system, there is no persistency that remembers that the trading contract was part of an approval process. Furthermore, there is no persistency in the standard that remembers which values of approval-relevant fields are approved by the workflow, nor that the approval was rejected by the workflow ( this information is available once only (see import parameter IV_WF_CALL_ACTIVITY )).

Note that only the actual values of the trading contract normally don’t allow the BAdI to decide whether an approval process is required or not. Therefore it may be necessary to remember or to make it ascertainable that a new approval process is required the next time, if the status of the trading contract allows a decision (the changes to data are visible in the trading contract only when the changes takes place). After the data is stored on the database, the data no longer shows that there were changes before (current state equals database state).

Example

An approval is required if more than 100 pieces of a material are ordered. The ordered quantity is 105 pieces, and the application status is changed to a status with system status 2 (Release carried out). The BAdI decides that an approval process is required, because the actual quantity is greater than 100 pieces. The quantity of 105 pieces is approved by the workflow. Now the data of the trading contract is changed in such a way that the system has to change the application status to one with system status 4 (Change after release). In addition, the quantity is changed to 103 pieces. The trading contract is saved and the BAdI does not expect a decision due to the current application status. Afterwards, the application status of the trading contract is changed to a status with system status 2 (Release carried out). Now the BAdI expects a decision on whether an approval process is required or not. The actual quantity is greater than 100 pieces, but a quantity of 105 pieces was approved by the workflow. If the trading contract is relevant for follow-on document creation, it may be necessary to compare the current trading contract (at the time when a decision is expected by the BAdI) with the corresponding data of the follow-on documents.

The Customizing of the status groups that should take part in a workflow-based approval process has to be set up correctly. This can be checked by using transaction WB2_CHECK_STATUS_GRP. The workflow-based approval process has been activated in Customizing under Activate Components.

There is no standard setup.






ROGBILLS - Synchronize billing plans   PERFORM Short Reference  
This documentation is copyright by SAP AG.

Length: 7580 Date: 20240523 Time: 170959     sap01-206 ( 190 ms )