Master Data and Hierarchies 

Purpose

You use master data and hierarchies to portray your corporate structure in the Consolidation System.

Integration

SAP Strategic Enterprise Management (SEM) is a distributed system. In SEM, the storage of the master data for a characteristic is distributed. The following options are available:

·        Master data is stored in the SAP Business Information Warehouse (BW)

When you change the data model in BW (for example, you change the length of a field), this change is not automatically reflected in the Consolidation System. Instead, you need to regenerate the objects in Consolidation that are affected by the change in BW. The data model synchronizer assists you in doing this.

·        Master data is stored in SEM

·        Master data is stored partially in BW and partially in SEM

You can maintain the master data and hierarchies for consolidation centrally in the SEM System. The SEM System writes the master data directly to the BW System.

See also:

Saving and Locking Concept for the Workbench

Features

Hierarchies

You can create hierarchies for almost all characteristics:

·        A prerequisite for creating a hierarchy for a characteristic in SEM-BCS is that the characteristic in BW must support hierarchies (that is, the hierarchy indicator in BW is selected for the characteristic).

·        No  hierarchies can be created for certain characteristics, such as methods and breakdown categories.

Assigning Nodes to Hierarchies

Node assignments are valid across different hierarchies: When one node is linked to other nodes and end nodes, this definition also applies to other hierarchies in which the one node is used.

A characteristic value can belong to one or more hierarchies (for example, under assets and/or liabilities), or it is listed under Nodes Not Allocated.

Item Hierarchy

Hierarchy Dependence on Time Periods and Versions

Definitions of consolidation unit hierarchies are version and time dependent.

Dependency on time or version is optional in other characteristic hierarchies – for example, hierarchies of financial statement items and subassignments.

The following rules apply when the definition is version and time dependent:

·        The existence of hierarchies is independent of versions and time periods.

·        Hierarchies are defined as version-dependent.

·        The assignments (between higher-level and lower-level nodes) are time-dependent within each version. There is an effective from year/period and an effective until year/period. These relationships can also be valid in several time frames.

When defining a hierarchy in BW for a characteristic, you can choose::

·        Whether hierarchies of this characteristic are version-dependent

·        Whether the entire hierarchy or the hierarchy structure is time-dependent

These settings in BW also affect the Consolidation System. An exception is made for hierarchies of consolidation units: You always define these time- and version-dependently – regardless of the settings in BW.

The node assignments in the Consolidation System are time-dependent (or, more precisely, the edges are time-dependent).

Say, in period 011/2000 you have a hierarchy of consolidation units, and the new consolidation unit CU Z is added in period 012/2000.

In period 012/2000, only the node CG 2 changes, not the entire hierarchy.