Characteristic Relationships

Characteristic relationship is an option to derive or check characteristic values, which are written into a real-time info-provider in SAP BW.

There are generic characteristic relationships, which are predefined.

There are also customized characteristic relationships, which are maintained on info-cube level in transaction RSPLAN.

Example for generic characteristic relationship are the time characteristic relations. There are different time characteristics in BW (business warehouse) like fiscal period, fiscal year and fiscal year and period together(0fiscper). These characteristics are connected with such generic characteristic relationship.  If period and fiscal year are filled, the system fills also the characteristic fiscal year/period 0FISCPER automatically.

The following rows are about the custom characteristic relationships, which can be used to control the consistency of the transaction data.

 

Characteristic relationship types

Based on the function

This classification is based on the checkbox “with derivation” in RSPLAN transaction.

1. Type “Derivation”: With derivation of target characteristics: This type of relation works with source and target characteristics. From the selected source characteristics the target characteristics are filled in the moment of the creating of the records in the info-provider.

2. Type “check”without derivation of any characteristics, only check of the valid combinations. These relations are used to stop not valid combinations of characteristic values.

 

Based on the method

Both types Derivation and Check” can be realized with predefined settings using master data attributes and data store objects or with customer exit using programming code.

  1. Attributes – This type is using the attributes of the master data. For example we want to enter in the cube a record for a material, but we don’t know the material type. Material type can be derived automatically from the material master data attributes. The derivation happens for every entry in the cube. To set such characteristic relationship we need to choose the source characteristic material and the target characteristic material type.
  2. Hierarchy – this type uses existing hierarchies to read and fill the target characteristics.
  3. DSO (data store object) – this type uses data store object to define the characteristic combinations.
  4. Exit – this type uses classes, which are defining the logic of derivation or check. There is standard class provided by SAP (CL_RSPLS_CR_EXIT_BASE), which should be copied into new one and there the logic can be implemented. This class contains methods check, derive and create. The method check can be implemented when the characteristic relationship is from type check. The method derive is used for derivation of the target characteristics. The system only calls DERIVE if all source fields are filled.

When the characteristic relationship starts?

The characteristic relationships from type derivation are working by every entry or change of the data in the planning cube when the source characteristics are in the aggregation level and the target characteristics are not in the level. They start by execution of planning functions and also by manual entry in input ready queries.

The characteristic relationships from type check start when both source and target characteristics are in the aggregation level.

Tips and tricks

  • When creating a characteristic relationship you need to define an error message, which is understandable for the user. To be visible also in the design studio (Lumira) planning applications you can use RAISE EXCEPTION TYPE cx_rspls_failed.
  •  You can use characteristic relationships to lock or unlock specific combinations of data. For example you create relation from type check with DSO and enter there only the allowed combinations.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

two × 3 =