Situation Handling: Advanced Configuration of Situation Types (5/5)

Now that you’ve learned the basics about Situation Handling and its configuration, it’s time to dive deeper into advanced possibilities to adapt the framework to your needs. The two major topics that we will discuss in the last blog post in this series are:

1. Fine-tuning condition filters, in particular: setting up complex filters and aligning filters with the responsibility management configuration
2. Multiple situation types based on one template, multiple conditions for a situation type, and when to choose what

For both topics we will provide insight into the how and why of the configuration, including a number of sample use cases in which they might be applied. Contrary to previous entries in this series, examples will vary per topic to best illustrate the respective ideas. Similarly, you can use the presented options as a toolbox, choosing what seems most valuable to you and your organization’s use cases.

Fine-tuning conditions

As discussed in the third post of this series (Situation Handling: How do I configure situation types? (3/5)), Situation Handling provides you with several options for refining the behavior of a situation type on top of the basic properties established by the template.

While in many cases, simple refinements, such as condition filters for a simple value, might be sufficient, others might require more advanced options. Two of these, for example, setting up complex filters and aligning conditions with responsibility determination attributes, will be discussed below in more detail.

Setting up complex attribute filters

Defining condition attribute filters can be as straightforward as entering a single value. However, more sophisticated configurations are also possible. As shown in the screenshot below, you can specify both include and exclude parameters for the filter (please note that the exclude section is collapsed by default). That is, you can specify a general pattern but exclude one or more specific values.

It is also possible to adjust the operators used in the filter (see the screenshot below). So, you might want to specify that situations should be raised once the attribute (like Deficit Quantity) is greater than a particular value. But you might want to exclude a small range (operator: between) for which there is a known problem that you are already working on, but which takes longer to resolve.

If you have a condition attribute which is a date, instead of the options above, you will see a list of predefined options from which you can choose (see below). If you want to add your own options here, you have to define custom date functions using the Manage Date Functions app.

We recommend that you use complex conditions judiciously, and check especially for the following common types of misconfiguration:

• You might accidentally create conditions attribute filters that are too constrained. That means, if you try to cover all potential attribute values, you might miss a case, or your data might evolve later on and new values are introduced. In this case, your business users would not be alerted about potential situations.
• Especially when you use multiple situation types based on one template (as also discussed below), please check that you have not accidentally defined overlapping condition filters (e.g. quantity between 1 and 5 in one situation type and between 3 and 10 in another one). This might lead to situations which are perceived as duplicates by users (technically, they are different, as they are based on different types).
• Also, when you define complex filters for a condition attributes, you might sometimes create contradictory filters (e.g. quantity greater than 10, but also smaller than 5). This results in no result for the evaluation in the Situation Handling framework, and which means no situations displayed for your users.

Our general recommendation regarding filters is to start gradually (fewer filters, patterns that capture many cases), and refine step by step. Ideally, you will check whether the result matches your expectations after each change.

Aligning conditions with parameters for Responsibility Management

As mentioned in the first blog post in this series (Situation Handling: What is it and why do you need it? (1/5)), Situation Handling relies on Responsibility Management to determine the users that see a situation in the My Situations app or are notified about it. The teams you set up for Responsibility Management may also contain filters (e.g. one team is responsible only for a set of plants). So one thing you may also want to consider when setting up your condition attribute filters is how they align with the ones you defined for these teams.

In general, before you put a situation type into production, it is a good idea to

• First check which attributes are used in Responsibility Management to differentiate responsibilities in the team definitions (in the Manage Teams and Responsibilities app).
• Then verify (in the Manage Situation Types app) that you pass these attributes in the responsibility definition for your situation type (you may, of course, purposely omit some of them if you decide they should not be considered).

Once that is done, we recommend cross-checking the filters you use in your team definitions for responsibility management against the list of condition attribute filters you have defined. In particular, please make sure that you do not define contradictory filters for condition attributes in the situation type and responsibility attributes in the responsibility team definition. In this case, situations might be created, but no users would be assigned to them, so they wouldn’t surface for any of your business users.

Multiple situation types from one template vs. multiple conditions in a situation type

Situation templates provide you with ready-made recipes to address a specific business problem in one area. To use them in your system, you typically create a single copy of a template and refine the configuration according to your needs (for details, see Situation Handling: How do I configure situation types? (3/5)). Most of the time, one of these types contains a single condition (with multiple attributes to which you can apply filters).

However, there might be cases in which this is not sufficient to model the configuration you have in mind for your organization. If this is the case, there are two options for more advanced configuration:

1. Creating multiple types from one template
2. Defining multiple conditions in one situation type

Using two types will give you more flexibility, i.e. you may define different recipient groups, different texts and links, or different schedules (in case of batch templates), but you will have to make sure to align them (see, in particular, the discussion about overlapping conditions above), and to update them consistently as the needs in your organization evolve.

When you use multiple conditions within a situation type, the text and links, recipient configuration, and scheduling times will be the same. That is, you don’t need to maintain them more than once. However, you will still need to make sure that the filters you set for the individual conditions are aligned with each other. As conditions will be evaluated in the order they are specified in the type, you need to make sure that the filters for the first condition are set up in a way that does not include the filters for the second condition.

In the text below, we’ve provided a number of examples of cases in which you could use multiple types based on the same template or multiple conditions within one type.

Creating multiple situation types from one template

As discussed above, there might be cases in which creating multiple situation types out of a single template is necessary so you can address your organization’s requirements. (Since we already showed a detailed example of creating a situation type in Situation Handling: How do I configure situation types? (3/5), we won’t repeat it here). While not strictly required, our recommendation for this case is to use descriptive names that relate to the template, but also allow a distinction between types.

Sample use cases for multiple situation types created from one template include:

• Realizing similar use cases based on one template
• Adjusting situation handling based on business parameters
• Differentiating the handling of situations by organizational structure

A great example of how to realize similar use cases with multiple types based on one template can be found in Physical Inventory Monitoring. This template deals with inventory counting, a regular process in all companies, which often requires significant manual effort and care — especially when it comes to deviations. As discussed in the documentation for this template, multiple use cases can be realized on the basis of this template, for example:

• Tracking open physical inventory document items which are ready to be counted.
• Tracking open physical inventory document items to finalize the posting process.

And others would be also be possible, such as

• Tracking items in a physical inventory document with a value above a defined threshold.

Sometimes you might also want to segment the handling of situations by business parameters. For example, you might want to differentiate handling between different material groups. If you simply want to use different texts or allow a dedicated analysis based on these attributes in the Monitor Situations app, you just need to apply the correct filters for the respective condition attributes. If you also want different teams and/or users to handle the situations, please make sure to also include the respective attribute in the configuration for responsibility determination.

You might also want differentiate situation handling by organizational structure, e.g. by business region (such as Europe, Asia, Americas), purchasing groups or special handling for specific customers. In this case, the main question to consider is whether the different parts of the organization can be determined based on attributes or roles available for responsibility determination. If this is the case, you would simply include the respective attribute or role in the responsibility configuration. If not, you could, instead, create a situation type based on the same template in different clients in your system, which the different parts of your organization can then use.

As mentioned in the introduction for this section, defining different situation types allows you

• to define different texts used when displaying the situation (in the situation message or in notifications),
• to add different links to your process documentation,
• to select different roles for responsibility determination,
• or, if the template is batch-based, to use different scheduled times for the batch run.

Creating different situation types also allows you to analyze situations separately in the Monitor Situations app (for details, see Situation Handling: How to analyze situations using Monitor Situations (4/5)).

Multiple conditions in one situation type

As discussed before, conditions and condition attribute filters (see also Conditions in SAP Help) allow you to refine the behavior of a situation type on top of the basic properties established by the template. Setting up multiple conditions lets you combine different cases in one situation type.

To create the said conditions within a type, use the Create button at the top of the conditions’ list in the Conditions section. For each of the conditions, you can select the status (Invalid, Obsolete, Open, or Resolved) that the Situation Handling framework should assign to a situation when the filters match (in most cases, you will probably want to leave it Open, but if you already know that a situation will no longer be valid under certain conditions, you may also set it to Obsolete). You can choose whether you want to send a notification. The example below shows a configuration with two conditions:

Please remember that conditions are processed following a specified order, such as from top to bottom, and that processing will stop at the first condition which matches the data.

Cases in which you might consider the use of multiple conditions include:

• adjusting behavior according to levels of severity
• differentiating threshold based on units of measurement
• automatically resolving situations when certain criteria are met

For example, where handling is adjusted according to different levels of severity, let us consider the (Project) Budget Threshold Exceeded template. You might want to create a situation (setting the status to Open), but not send a notification for a first threshold, say 70%. The situation will then appear with an indication in the project budget application and in the My Situations app for the users configured as responsible. A second threshold, say 80%, might include a more urgent need for attention. You would set 80% as the limit for the second condition (target status also Open), but this time you’d also choose to send a notification. To achieve the right behavior, in this case the 80% condition should go first (Processing Order: 1), the 70% condition second (Processing Order: 2). Otherwise, the 80% condition would be never checked.

A nice example, in which multiple conditions are defined to allow handling of different units of measurement, is explained in the follow video on Managing Major Deviations in GR/IR Account Reconciliation:

In the example shown there, different thresholds and currencies are defined for each company code: 500 EUR for Company Code 1010 and 100,000 INR for Company Code 1810. The configuration with two conditions allows one central team to take care of both company codes/parts of the organization, even though they use different currencies.

Finally, if you want to not only create situations, but also automatically resolve them when certain criteria are met, the following example illustrates how this can be achieved with multiple conditions. For example, when you use the template Due Date Reached Soon, you may want to create a situation and notify users one week before the deadline is reached. However, if the deadline was over a month ago, you may no longer be interested in the situation and consider it obsolete. To clean up the list of situations, you would specify the condition attribute filter accordingly and set the target status to Obsolete. This would resolve the respective situations automatically.

Conclusion

In this blog entry, we covered two topics for the advanced configuration of Situation Handling: fine-tuning of conditions and the considerations around creating multiple types from one template or using multiple conditions in one situation type.

Hopefully, you found information, both in this blog entry and in the series as a whole, that will help you to adapt Situation Handling in conjunction with Responsibility Management to the needs of your organization.

This is the last post in a series of five to provide an overview of Situation Handling in SAP S/4HANA and SAP S/4HANA Cloud:

• Situation Handling: What is it and why do you need it? (1/5)
• Situation Handling: Selected use cases in different application areas (2/5)
• Situation Handling: How do I configure situation types? (3/5)
• Situation Handling: How to analyze situations using Monitor Situations (4/5)
• Situation Handling: Advanced configuration of situation types (5–5) [this post]

Thank you for reading! Please watch this space for further posts exploring more topics around Situation Handling.

The article originally appeared on SAP Community.