Exploring Hierarchy Processing

A hierarchy may contain entities of additional entity types as nodes. These entity types are specified under Entity Types for Hierarchies (in addition to the hierarchy name). By default, Use has the value No Special Use. You can also choose the value, Hierarchy Name.

In the example shown in the preceding figure, the entity type CCTR (Cost Center) has been specified as an allowed entity type within the Cost Center Group Hierarchy.

Another use case is to support text nodes.

• Switch on hierarchies for entity types of usage and storage type 1.
• Define hierarchies as edition-dependent.
• Define hierarchies as version-dependent.

  The hierarchy version is a fixed and predefined CHAR field of length 3. The hierarchy version cannot be modeled as an entity type. It is globally defined and valid across data models

• Hierarchies can be defined as hierarchy-name-dependent:
  • Hierarchies always have a name that is modeled as an additional entity type, regardless of whether the hierarchy is name-dependent or not.
  • The hierarchy name can have leading relations (additional key fields).
• Additional entity types can be used as nodes within hierarchies. These types can be of usage and storage type 1, 2, or 3.
  • Example: Text nodes can be modeled as an entity type and entered as an additional entity type.
  • Constraint: Exactly one entity type must be of usage Hierarchy Name.

    Entity types used as hierarchy names must have superordinate entity types.

• A hierarchy can have multiple key fields:

  Constraint: Key fields must also be key fields in the entity type for which the hierarchy is defined.

• Hierarchy relations can have additional attributes.

Hierarchy relationships can have additional attributes.

An attribute of the relationship can be specified by a data element or by a reference to an entity type. In this case, the data element is optional and taken from the entity type. You can specify an alternative data element if necessary.

The second example in the preceding figure shows that if you want to add attributes to the relationship of the entity type for which the hierarchy has been defined, you must specify it again under Entity types for Hierarchies.

Attributes of the hierarchy relationship can be initially maintained during the insertion of an entity into the hierarchy. Later, the attributes can be changed by calling Change Hierarchy Attributes or Change Range from the context menu depending on whether a discrete entity value is specified or a range.

In general, hierarchies are maintained in the hierarchy view of the Collective Processing generic application. The main features are the following:

• You can insert new or existing nodes. You can insert several nodes in one step.
• You can move nodes (including subnodes) with arrow buttons. Drag-and-drop functionality is also supported.
• You can find nodes in the hierarchy.
• You can expand ranges to see which entities are currently assigned.

At runtime:

• Like other master data hierarchies, they are maintained under the governance of change requests.
• The hierarchy can form nets (a node can have multiple higher-level nodes).
• Validations can be added in the rule service BAdI, for example, to enforce specific cardinalities like single higher-level nodes.
• A search for nodes in the hierarchy can be performed.
• Authorization can be granted on the level of arbitrary nodes of the hierarchy.
• Version-dependent hierarchies can be copied to new versions.
• Ranges can be expanded to see which entities are currently assigned.

The layout of the hierarchy view is derived automatically:

• Columns for descriptions are included according to the text settings of all entity types specified for the hierarchy.
• Columns for attributes of the leading entity type are included (unless disabled in the field property view by checking No Result List).

Maintenance UI:

• Hierarchies are maintained in the hierarchy view of the collective processing application, which is generic and works for all data models. The UI supports drag-and-drop functionality.
• Additional UI elements are available that can be added to the single item maintenance UI to maintain information on higher-level nodes and predecessors.

  Constraint: Currently these elements only support the entity type for which the hierarchy is defined.

The table shows the pre-delivered models.

A hierarchy can be added to model MM (Material Domain) by creating additional entity types (with the reuse area master data governance), one for the hierarchy and one for the name.

In the following example, a work package hierarchy is set up where materials can be assigned. These work packages belong to design studies and depend on the year of the development. Therefore, another entity type for the year is created and maintained as a key field.

Three entity types are created:

• One for the design study name (ZHRCHNAME)

• One for the work packages (ZWPHIER)

• One for the year (ZYEAR)

The hierarchy name ZHRCHNAME (which identifies the design study) and the entity type MATERIAL are then specified under Entity Types for Hierarchies.

Two relationships must be created to make the year a key field for the hierarchy.

Three entity types are created: one for the design study name (ZHRCHNAME), one for the work packages (ZWPHIER), and one for the year (ZYEAR).

The hierarchy name ZHRCHNAME (which identifies the design study) and the entity type MATERIAL are then specified under Entity Types for Hierarchies.

Two relationships have to be created to make the year a key field for the hierarchy.

In the hierarchy view of collective processing, you can maintain names for the design studies, create work package hierarchies below them, and assign materials to the work packages.

Two design studies have been defined (CAR WING and REAR VIEW MIRROR).

The first one contains three work packages and two materials at the leaf level.

The second one contains two work packages. No materials are assigned so far.

In the collective processing UI, you can maintain hierarchies in different versions and for different purchasing organizations.

In this example, hierarchy version001 has been created for purchasing organization0001.

In the figure, in the screenshot labeled as 1, the new entity type ZTEXT serves as text node in the upper example. In the screenshot labeled as 2, the collective processing UI, you can then insert text nodes.

An additional customer-specific entity type can be added to the list of entity types for the hierarchy that is delivered for the entity type BP_HEADER.

You can now assign Business Partners to hierarchies during Single-Object Processing (the Creation or Change processes).

The UI also offers a value help for the easy identification of the relevant parent node.

Previously, there were only the upload modes Delete All and Overwrite or Add. The latter can only add new edges but not manipulate edges (delete edges and create new ones).

Additional upload modes for hierarchy maintenance are available: Move Children, Replace Nodes, Remove Edges.