
Situation Handling
Situation Handling is a framework in SAP S/4HANA Cloud that automatically informs the right users about issues requiring their attention. Situation Handling identifies the users by using integrated Responsibility Management. The blog post series Responsibility Management: What Is It and Why Do You Need It? (1/5) describes in detail how Responsibility Management works. This blog post series illustrates how Situation Handling and Responsibility Management work hand in hand. The second blog post shows how to inform the right persons about situations using responsibility rules. The examples are based on the extended framework for Situation Handling.
In the previous blog post I discussed the use case of expiring purchase contracts based on the fictional procurement unit of a reseller. Let’s use the same scenario. But this time we want to inform the creator a purchase contract creator when it’s about to expire.
The link between Situation Handling and Responsibility Management is the responsibility context. You choose the context when configuring a situation scenario. The responsibility context includes one or more responsibility rules that you can choose from when creating a situation template.
As an extensibility specialist you create your situation scenario with the Manage Situation Scenarios app. The scenario defines a business scope for an object that is affected by a situation and comes with multiple elements, such as situation triggers and actions for users. The situation scenario is assigned to a responsibility context that includes corresponding rules for the business scope. The responsibility context type SITO (Situation Object) is assigned automatically.
For our sample case we’ve extended the situation scenario PROC_PURCHASECONTRACT with custom rules.
Assign a responsibility context to a situation scenario
As a business process configuration expert you configure your Situation Handling use cases with the Manage Situation Types – Extended app. This includes conditions for when situations are triggered, informative texts for the business users, and situation recipients.
In the Recipients section of the situation template, you can select a rule from the list that contains all rules defined for the responsibility context. In our example, it’s Creator of purchase contract.
In the template you can add multiple rules and a team category to support optimal flexibility for deferred situation types.
Select a rule to determine the recipients of a situation
Here’s a simplified overview of rules within a responsibility context.
Simplified view of Responsibility Management
Condition filters are used to detect situations. Once again, let’s take the situation template Expiration of Purchase Contracts (PROC_ABOUT_TO_EXPIRE_CTR). You specify when to trigger a situation for an expiring contract by defining a condition for the anchor object that is the purchase contract.
Condition filter Validity Period End = NEXT 30 DAYS.
If this is the only condition filter, then all purchase contracts that will expire within the next 30 days are taken into account.
Define condition filters
The recipient configuration is used to identify the persons who need to be informed about situations. In the situation type you can keep the recipient configuration that comes with the underlying template. That’s the case in our example. If the template configuration offers multiple rules and a team category you can also remove the ones that you don’t need.
Now let’s look at a sample configuration.
You can use the condition filters to fine tune the detection of situations. The available filters are the fields from the trigger CDS view and the anchor CDS view (which are not flagged as hidden fields in the situation scenario). You can choose as many filters as you like. By the way, when you start testing, I recommend using filters to get a decent number of situations.
We defined the same two situation conditions that we defined in the previous blog post. This means, there is no difference in detecting situations.
Situation Type 1 recognizes situations for expiring contracts with the suppliers Apple and Lenovo. The situation is triggered 30 days before a contract’s expiration date. This requires two conditions:
Condition filters for situation type 1
Situation Type 2 recognizes situations for expiring contracts with the suppliers Canon, Epson, HP, and Samsung. The situation is triggered 14 days before a contract’s expiration date. This requires two conditions:
Condition filters for situation type 2
Responsibility rules are based on a BAdI implementation that can be as simple or as complex as required. You can use predefined rules that come with the situation scenario and you can define custom rules. In our example, we’re using a custom rule that identifies the creator of a purchase contract that is described in the blog post Responsibility Management: Create Your Rules.
Let’s illustrate the effects of our configuration with some sample contracts.
The following persons are informed about the situation:
The creator of the Apple contract no. 5987 is informed 30 days before it expires:
The creator of the Lenovo contract no. 3958 is informed 30 days before it expires:
The creator of the Canon contract no. 4092 is informed 14 days before it expires:
Inform the right persons about situations using rules
Now you know everything about how Responsibility Management and Situation Handling go hand in hand.
For more information, you can also refer to
SAP Help Portal
SAP Community for Intelligent Situation Handling
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
8 | |
7 | |
6 | |
6 | |
5 | |
5 | |
5 | |
4 | |
3 | |
2 |