On my recent project among others, I was assigned a task of connecting a Workflow to the event of Sales Document status change. As you may know any Sales Document can have different statuses, and those statuses can be freely customized via so called Status Profiles. Actually, Status Profiles and Statuses can be used with other business documents and entities throughout the SAP system.
Generally, Status Profile consists of several individual statuses, which can be changed in specific order, each status can be linked to a particular authorization group, and also it can influence corresponding business transaction, e.g. restrict change access to the document if it is in specific Status. All in all, Status Profile is a universal tool, and in particular it can be used for designing quite sophisticated approval process, making a strong temptation to employ Business Workflow functionality.
And when workflow technology involved, you always have a task of connecting specific workflow template to some Business Object event. Some application events of standard business objects are fired by the system, and some are not. Often, you can link a particular event to a specific Change object – this is done in a transaction SWEC. Though, linking events to change documents is not always reliable as they can be switched off due to database volume affect or other Basis team consideration.
In case of Statuses the problem is that they are stored in a separated table JEST, so you cannot link Status change via Business document change object. However SAP has special customizing tables containing linkage between Status change and Business Object event. This is done in the transaction BSVW. Let us call the moment when one status becomes inactive and another becomes active a Status change.Actually there is more than one customizing table sets in the system which affects the Status change and BO Event linkage, and the system takes into account all of them.
- Tables BSVWCOUP1 and BSVWCOUP2 store system settings which are not supposed to be altered by the Customer; this table set is always taken into account
- Tables BSVWCOU3 and BSVWCOUP4 store old customer settings, and are taken into account unless the Customer configured the new settings tables
- Tables BSVWCOU5 and BSVWCOUP6 store new customer settings.
Old and new customizing tables differs in primary key declaration, and as a consequence, using new customizing you can assign different Status changes to the same BO event.
The precise usage of all these tables you can see in the source code of the function module SWE_EVENTS_FOR_STATUS_GET which is called whenever status of any object in the system changes. Also the source code helps us to understand the configuration principles of Status Change – BO event linkage; to get the key of it, imagine the process: when some status is assigned to a business document (or any other entity) for the first time, the system is aware of only one status – the new one; in case of status change, there are always two statuses involved – the new one (which becomes active) and the old one (which becomes inactive).
When calling SWE_EVENTS_FOR_STATUS_GET the system passes to the FM an internal table with a status change signature – both old and new statuses, and to find a link to a BO event the FM analyses configuration tables searching for the exact match – a pair of entries, one of them denoting the old status (with inactive state) and the other – the new status. In other words, the system takes into account not only a particular status which was assigned to a document, but also the order in which statuses were changed.
In the following example we see the linkage between the Status profile (of Schema) and Business Object Event. Starting from SAP 4.7 you can use ABAP classes instead of old flavor business objects in Workflow. However, it is obvious that this customizing does not accept ABAP classes. The very first key field of this table is Status Object Type (or Object Category), it defines a kind of business entity to which you can assign a Status profile. The VBK object category represents Sales Order Header.
For such an entry, you also have to define Status restrictions (see the folder icon in the tree to the left of table view). Status restrictions define a particular status change which will invoke the specified BO event. See the screen shot below:
This pair of entries represents a moment when Status of object changes from ACCP to RJCT. Note that “Inact.” checkbox column corresponds to inactivity state.More than one Status change (belonging to the same or different Status Profile) can be assigned to a single particular Business Object event. To help you differentiate the Workflow behavior depending on the Status change order the system supplies additional parameters to the event container:
- STATUS_ON – for statuses which become active
- STATUS_OFF – for statuses become inactive
Both parameters are multiline and contains only 5-character internal status representation, such as E0002 (user status) or I0002 (system status), though I could not model a situation when the function passes with the event more than one status in the container parameter. Do not forget to specify these parameters, when defining Business object events for Status change.
Interesting enough that according to the source code of the function module SWE_EVENTS_FOR_STATUS_GET you can use function modules for evaluating Business Object Type and its event names to be fired, however the fields in which you can set those function module names are not displayed in the maintenance dialog. Maybe this feature is planned for future releases.