Characteristic relationships in SAP BW IP and BPC made simple

In planning, you can use characteristic relationships to determine which combinations you want to allow within your planning application. Correct values can also be derived automatically. In this article, you will learn how to work with characteristic relationships.

Functions of characteristic Relationships

You can use characteristic relationships to link corresponding characteristics with each other, thus ensuring data consistency. You achieve this by defining rules to check permitted combinations of characteristic values for the plan InfoProviders.

You can also define rules according to which values for other characteristics can be derived automatically from characteristic values. For example, you can use the city to determine the region. This is useful, if the derived characteristics are not relevant in the current planning context, but should be available for further evaluations.

Basically, you can differentiate between three functions:

2. The SAP system also knows the valid combinations for each characteristic and can propose (generate) them automatically. The following table shows an example.

3. Furthermore, the value of a characteristic can be derived from the value of another characteristic. For example, the corresponding product category can be filled automatically in the background from a planned product group, as shown in the table below.

In general, multiple characteristic relationships are possible for each InfoProvider. In this case, all characteristic relationships are executed step-by-step in the specified order. This allows you to form causal chains when defining characteristic relationships. For example, you can first derive the product group from a product and then derive the product category from the product group in the second step. You can also deactivate individual steps of the characteristic relationships for test purposes.

You can differentiate between characteristic relationships with derivation and without derivation. In the following sections, I will explain the main differences using an example.

Characteristic Relationships without Derivation

Let's take a look at the following master data: the product group Smartphone S is assigned to the product category Smartphones. The product group Tablet I belongs to the product category Tablets.

At the InfoProvider level, we define a characteristic relationship without derivation. You can either use transaction RSPLAN or, in higher versions, the BW Modeling Tools.

Both Characteristics are in the Aggregation Level

If both characteristics are in the aggregation level, the valid combinations are checked and can also be generated automatically.

For example, the combination of Smartphone S and Tablets is recognized as invalid.

Note, however, that the following combinations are considered valid:

You can view a list of all valid combinations if you select the option Characteristic Relationships for the characteristic Product Group in the query settings under Extended → Access Type for Result Values.

The following combinations are generated automatically.

As you can see, this is a cartesian product of all permitted combinations. The initial characteristic value # (Not assigned) plays a special role here. This means that combinations with the initial value # are valid by default. This is because characteristics that do not occur in an aggregation level are always updated with the initial value. Therefore, there is no validity check for the initial values.

Prohibit automatically valid Combinations

If this behavior is not desired, you can prohibit automatically valid combinations by selecting the Exclude # option in the characteristic relationship.

In this case, the following combinations are no longer considered valid:

If you set the setting Access Type to Characteristic Relationships, only three valid combinations are generated.

Product Group in the Aggregation Level

If only the Product Group characteristic is in the aggregation level, the defined characteristic relationship has no functionality.

If you plan at the product group level, the product category is saved as Not assigned #.

To derive the product category automatically, you must define a characteristic relationship with derivation. The next section explains how this works.

Characteristic Relationships with Derivation

To explain the characteristic relationships with derivation, I use the same combination of product group and product category as an example.

To define a characteristic relationship with derivation, activate the With Derivation setting and define the source and target characteristic.

Both Characteristics are in the Aggregation Level

In the case of a characteristic relationship with derivation, valid combinations are still checked, if both characteristics are in the aggregation level.

For example, the combination of Smartphone S and Tablets is still recognized as invalid. However, unlike the characteristic relationship without derivation, the product category is automatically derived when you enter a product group.

Therefore it is not possible to enter the following combination:

However, please note that an undefined product group with a product category is still allowed.

To display the list of all valid combinations, you can select the option Characteristic Relationships for the characteristic Product Group in the query settings under Extended → Access Type for Result Values.

Unlike combinations that are generated with characteristic relationships without derivation, no Cartesian product is generated. Only valid combinations of product group and product category are generated. However, as you can see, combinations with an empty product group are considered valid.  If it is not desired, you can prohibit automatically valid combinations.

Prohibit automatically valid Combinations

As with characteristic relationships without derivation, select the Exclude # setting.

If you reset the query, the result looks the same as for characteristic relationships without derivation.

Product Group in the Aggregation Level

However, the most important difference becomes visible if only the characteristic Product Group is in the aggregation level.

In this case, the corresponding product category is automatically derived and stored in the InfoProvider when you plan a product group.

Recommended Setting

In general, you should always use the characteristic relationship with derivation. This ensures that each data record is provided with valid values, even if a characteristic is accidentally missing in the aggregation level. Even if you select the property with derivation, a combination check is still performed (or a proposal is created) if respective characteristics are contained in the aggregation level.

Planning Tools compared - SAP BW IP vs. BPC vs. SAC

Sources of Characteristic Relationships

The values of the characteristic combinations can be determined in four different ways. The source for characteristic relationships can be master data attributes of a characteristic (type attribute), a hierarchy (type hierarchy), a DataStore object (type DSO), or an exit class (type exit).

If Attribute is selected as type, the combinations of characteristic and attribute values contained in the master data of the characteristic are transferred as allowed values. If you select Hierarchy as Type, you can use a hierarchy to determine the source and target characteristics of the characteristic relationships. However, you can also store the valid combinations in a DSO and use this as the source for characteristic relationships. In addition, you have the option of designing permitted combinations of characteristics flexibly and individually by programming them. In this case, use the type Exit.

It is recommended that you implement individual exit functionality for characteristic relationships directly in the SAP HANA database using SQLScript. The SAP-HANA-specific interface IF_RSPLS_CR_EXIT_HDB must be implemented. However, if you do not want to deal with SQLScript, you can still use the ABAP implementation as a fallback. You can use the example class CL_RSPLS_CR_EXIT_BASE. The interface IF_RSPLS_CR_EXIT used here must also be available if you are using SQLScript. In certain situations, the system triggers the ABAP implementation to avoid data being transferred record by record between the SAPBW∕4HANA system and the SAP-HANA database.

However, please note that in this case you will not fully exploit the possibilities of performance optimization. Performance can suffer, especially if disaggregation or planning functions are carried out with large data quantities. For more information about the exit and fallback scenario, you can use SAP Note 1956085 (BW-IP (PAK): ABAP as fallback for exit characteristic relationships and data slices in SAP HANA).