SAP ABAP Data Element UPC_Y_MTYPE (Type of Characteristic Relationship)
Hierarchy
SAP_BW (Software Component) SAP Business Warehouse
   BW-PLA-BPS (Application Component) Business Planning and Simulation
     UPC (Package) SEM-BPS: General Functions
Basic Data
Data Element UPC_Y_MTYPE
Short Description Type of Characteristic Relationship  
Data Type
Category of Dictionary Type D   Domain
Type of Object Referenced     No Information
Domain / Name of Reference Type UPC_MTYPE    
Data Type CHAR   Character String 
Length 1    
Decimal Places 0    
Output Length 1    
Value Table      
Further Characteristics
Search Help: Name    
Search Help: Parameters    
Parameter ID   
Default Component name    
Change document    
No Input History    
Basic direction is set to LTR    
No BIDI Filtering    
Field Label
  Length  Field Label  
Short 10 Type 
Medium 16 Type 
Long 30 Type of Char. Relationship 
Heading Ty. 
Documentation

Characteristic Relationships

Characteristic relationships can be determined in the following ways:

  1. A characteristic is an attribute of another characteristic. In this case the name of the attribute and the characteristic are the same in the planning area.
  2. Characteristics appear together in a hierarchy.
  3. The relationship is stipulated in an exit function module.
  4. Reference data describes this relationship.

Characteristic relationships describe:

  1. How characteristics are derived from other characteristics,
  2. How the combination of characteristics is checked,
  3. How characteristic combinations are proposed within manual planning.

A single characteristic is also often referred to as a step.

Characteristic Relationships in Multi-Planning Areas

In multi-planning areas, the characteristic relationships of the corresponding basic planning area are used. It is not possible to define individual characteristic relationships for multi-planning areas. This would also be superfluous as each transaction data record is assigned uniquely to exactly one basic planning area. If you are implementing an exit function module note that, for reasons of efficiency, function modules for checking and generating combinations are called up with the structure of the multi-planning area. In the examples, you see how you can program independently of the structure. You can find good programming tips in the documentation on the CREATE DATA command.

Combination Check

Characteristic relationships are only taken for the combination check if all of the characteristics involved are available in the planning level. If a characteristic is compounded to another characteristic, then all higher-level characteristics (the characteristics that are available in the key of the master data table) must also be contained in the planning level. Attributes are an exception to this. Not all attributes have to be available in the planning level. Those attributes that are available in the planning level are checked.

The algorithms run as follows:

  1. For compound characteristics, a combination check using attributes determines the values of all higher-level characteristics first. Then all attribute values are read in the master data table. The value of the attributes to be checked are compared with the corresponding characteristic values in the record. An error mesage is triggered if there is any disparity.
  2. In hierarchies with compound characteristics, the values of all higher-level characteristics are determined first. Then the system reads the nodes in the hierarchy. An error message is triggered if no node can be found. The system then tries to find a suitable higher-level node. If no higher-level node is found the system tries to find a lower-level node. Use hierarchies that include the basic characteristic (hierarchy- defining characteristic) for the combination check. Searching for lower-level nodes is costly in terms of performance. With intervals of compound characteristics, the system only takes into account the from-value of the interval of the higher-level characteristics. In other words, maintain hierarchies so that the higher-level values of compound characteristics are always the same.
  3. With the exit type check, the system calls the customer-defined function module. Info on the interface
  4. With the check using reference data, the system reads in the reference data whether or not a record is available with the corresponding characteristic combinations.

Generating Combinations

For generating characteristic combinations, characteristic relationships for manual planning are taken if the from possible characteristic combinations indicator is set in 'Additional Settings' in the planning layout for the characteristic combinations. This indicator replaces the 'Form-based Lead Column' indicator from earlier releases.

For planning level characteristics, all valid characteristic combinations are formed from the characteristic relationships and selection available in manual planning. For combinations that have been generated and still do not have transaction data, zero records are generated during the program runtime. These zero records are not saved persistently.

Combinations are generated as follows: Each step in characteristic relationships specifies a quantity of characteristics for which combinations are to be generated. If the characteristics are in the planning level, combinations are generated in accordance with the method for the step. However, if a characteristic for a step is not in the planning level, that particular step is not executed. Characteristics for this type of step are marked for a subsequent master data selection. Valid values are then determined with a master data selection, if no combinations have yet been formed for this characteristic in another step. Finally, the combinations are joined together from the steps and possibly determined master data to a final quantity of characteristic combinations (this corresponds to what is referred to as an 'inner join' in the terminology database.

The algorithms for the individual steps run as follows:

  1. If combinations of characteristic attributes are defined for a master date, the relevant master date is read from manual planning with the selection. In this case, these atributes also have to be planning level attributes. The selection for these characteristics is also considered.
  2. If combinations are stored in a BW hierarchy, the combinations are taken from the path of the root to the lower-level elements of the hierarchy. Each path corresponds to one combination at most. Intervals are also permitted in the BW hierarchy for the characteristic that defines the BW hierarchy. If the hierarchy-defining characteristic is a compound characteristic, the from-values for the higher-level characteristics always have to match the to-values when there is an interval involved. Each hierarchy node in a path that determines a characteristic combination has to be in the manual planning selection. If that is not the case, the entire subtree is rejected and is not included in the further search for combinations.
  3. If combinations are formed using an exit, the customer-defined function module is called up. Info on the interface
  4. Finally, combinations can be determined from reference data. The reference data for the characteristics of the step is read with the selection from manual planning. Restrictions can be defined for characteristics that are not used to form combinations in this step. These are still considered in the selection.

If there is no Customizing for the characteristic relationships and the 'from possible combinations' indicator is set, the master data for the current selection is read for all planning level characteristics, in accordance with the rules described above, in manual planning. The valid combinations result from the Cartesian product of these characteristic values. It is therefore clear that when used in connection with the 'from possible combinations' indicator, the selection for manual planning has to be sufficiently restrictive.

Derivation

Those characteristics that do not exist in the planning level are derived. However, source characteristics do have to exist in the planning level, or be derivable from a characteristic relationship. So that as many characteristics as possible can be derived, characteristic relationships are executed arranged so that subsequent characteristic relationships are able to use planning level characteristics and characteristics that have already been derived, as source characteristics.

The algorithms run as follows:

  1. In derivation using characteristic attributes, the value of the characteristic (inclusive of the values of higher-level compound characteristics) is determined first. The attribute values are then read from the master data table. The values are written into the characteristics to be derived, corresponding to the attributes.
  2. In derivation using a hierarchy, the node is determined first. The system then searches the hierarchy for a node that could be the higher- level node. This record is written in the record to be derived.
  3. In derivation with exit function modules, the appropriate function module is called up. The system then checks whether planning level characteristics have been changed. Info on theinterface
  4. In derivation using reference data, the system reads in the reference data whether the corresponding combination of source characteristic values exists. The target characteristic values for the derivation are determined from this record. So that derivation is always unique, each combination of source characteristic values can only occur once in the reference data. You can check the reference data for derivation by defining a level that contains both source and target characteristics as well as the characteristics and key figure, for which you have entered selection conditions when you maintained the characteristic relationships. Do not enter selection conditions for the source and target characteristics. The other characteristics are restricted to exactly the same characteristic values that you selected in the maintenance of characteristic relationships.

History
Last changed by/on SAP  20130604 
SAP Release Created in 3.0A