Characteristic Relationships 

Use

It is often the case that characteristics used within a planning task do not coexist in isolation. A relationship often exists between the different characteristics in terms of content, although this may not be immediately obvious from the technical modeling of the characteristics.   Characteristic compounding indicates that a particular (higher-level) characteristic always has to be lead to a compound characteristic (see Tab Page: Compounding). However, characteristic compounding does not make clear whether the particular values of one characteristic correspond to the particular values of the other.     The content of, for example, the characteristics Article and Article Group correspond in this way.

Characteristic relationships are used to relate those characteristics that correspond to each other in terms of content. Using characteristic relationships you can set up procedures to check valid combinations of characteristic values and in addition, check that the system enters valid combinations of this sort within manual planning in the lead column or in the header area of a planning layout (default values). Furthermore, you can define rules according to which the system can derive values for further characteristics from the characteristics that you use for a planning task. These values are not contained in the planning level but should nevertheless be updated.

Data entry in manual planning has the following advantages:

·        In a planning layout for which the “all possible characteristic combinations” option has been selected, those combinations are generated that have been defined as useful in the characteristic relationship. For example, in a lead column that contains the characteristics cost centre and currency, only the currency valid for this purpose is provided for data entry. 

·        By deriving characteristic values, the system is able to determine values of different characteristics from the entry of a single characteristic value. For example, the system can determine the corresponding value of the characteristic article group from a value of the characteristic article.

·        With characteristics between which there is a dependency, the system can check whether a combination of characteristic values that has been entered is valid. This prevents transaction data from being entered for invalid characteristic value combinations.

Integration

Characteristic relationships can be defined with reference to attributes and hierarchies on characteristics, among other things. Here, those attributes and hierarchies are used that were created in the BW system for a characteristic (see Tab Page: Attributes, Tab Page: Hierarchy and Hierarchy).  

Characteristic relationships affect all function types that change data. Therefore, planning functions cannot update transaction data for value combinations that are not the result of a defined derivation or that are recognized as invalid during a check for valid combinations. Forming combination proposals only affects manual planning layouts for which the “All Possible Characteristic Combinations” option has been selected.

Prerequisites

The following prerequisites must be fulfilled in order to define characteristic relationships:

·        The planning area must be a basic planning area

The characteristic relationships defined in a basic planning area are also effective in multi-planning areas in which a basic planning area of this type is contained

·        In characteristic relationships of the type attribute, the target characteristic must be defined as an attribute of the basic characteristic and must itself be contained in the planning area 

·        In characteristic relationships of the type hierarchy, the target characteristic must be contained in a hierarchy on the basic characteristic.

Features

For every characteristic relationship that you define it is possible to perform a combination check and to generate combination proposals in relation to the values of the characteristics involved. In addition, you can specify that the system should also derive the values of the target characteristic from the values of the basic characteristic.

A characteristic relationship that supports the derivation of values of the target characteristic can only achieve the defined derivation when the basis characteristic is, but the target characteristic is not, contained in the planning level. Otherwise the effect the characteristic relationship has on the combination check and proposal is limited.

You can create up to 99 characteristic relationships in a planning area. It is possible to establish implicit “relationships between relationships” by using the target characteristic of a relationship A as the source characteristic of another relationship B. In this case, the only characteristic values from the source characteristic that enter relationship B are those that result from relationship A.

The following types of characteristic relationships exist:

·        Attribute: The target characteristic is defined as the attribute of the basic characteristic (for example, the characteristic currency is an attribute of the characteristic controlling area).

·        Exit: The values of the characteristics involved result from the implementation of the specified user exit.

·        Reference data: Valid combinations are transferred from reference data that you determine using a suitable selection.

·        Hierarchy: The characteristics involved are part of a BW characteristic hierarchy on the basic characteristic.

For each of these relationship types you decide, when defining a relationship, whether only combination checks and proposals should be generated or whether a derivation of the target characteristic from the basic characteristic should also be performed.  In the case of derivation, the basic characteristic takes on the role of a source characteristic.

All relationship types offer the possibility to define relationships between a basic characteristic and several target characteristics. With the relationship types exit and reference data you can specify several basic characteristics.

Since characteristic relationships are defined in the context of a planning area they affect how all transaction data within the planning area is processed.

Adjusting Transaction Data after Changes to Characteristic Relationships

Transaction data stored for characteristics that are linked to another characteristic by a derivation relationship can also contain values for the derived characteristic.  For example, a transaction data record for the characteristic material normally also contains the corresponding value of the attribute characteristic material group.   If master data is revised and former assignments between characteristic and attribute are changed (for example, by arranging a material in a different material group), then inconsistent transaction data records occur.

You can also use characteristic relationships to consistently match the key values of existing transaction data records to the current valid attribute assignments defined in the master data. This allows you to transfer from the old to the new structure. To do this, create a characteristic relationship as a derivation and assign the characteristics affected. Create a planning function of the type repost (characteristic relationships) and assign the derived characteristic to it as the characteristic to be changed. You also require a parameter group for the function, in which no further settings are necessary. When you execute the function with the parameter group the transaction data is reassigned according to the current assignments between the values of the source characteristic and the derived characteristic.

The Delete function (invalid combination) deletes all plan data in which errors were found during the combination check.

The Repost (characteristic relationships) and Delete (invalid combination) functions can only be used in planning levels that contain all characteristics. This is the only way in which incorrect records can be cleaned up.

See also:

Reposting (Characteristic Relationships)

Deleting (Invalid Combination)