Creating Hierarchy Authorizations

This lesson covers the implementation of authorization settings for managers in your company who are responsible for specific cost centers assigned to particular board areas in SAP BW/4HANA. Managers should be authorized to access solely the designated portion of the cost center hierarchy aligned with their responsibilities.

Hierarchies are a helpful way to organize and group characteristic values based on specific evaluation criteria. For instance, products can be grouped by product groups and sub-groups. You can easily create hierarchies in SAP ERP, SAP S/4HANA, or other source systems and then load them into SAP BW/4HANA, or create them directly in SAP BW/4HANA. The figure, Product Hierarchy Example, shows a hierarchy for products. This kind of hierarchy is also called External Hierarchy.

There are many terms that are used when discussing hierarchies.

• External hierarchy: Parent-child data stored in SAP BW/4HANA-related Master Data tables for a specific characteristic. They are referred to as external because they are outside of the transaction data tables. External hierarchies provide flexible, easily changed rollup groupings for reporting. To use these external hierarchies, you must create them manually in SAP BW/4HANA, or load them.
• Root Node: A node with no superordinate node is called a Root node. The nodes below the Root node are categorized as nodes and leaves, with leaves representing the characteristic values.
• Not Assigned node: This is an artificial node that does not belong to the hierarchy. However, it can be included in reports and contains all characteristic values not found in the current hierarchy.
• Hierarchy Levels: In a hierarchy, a node's level indicates its distance from the root. The root is at the first level, its children at the second level, and so on.
• Intervals: Intervals contain several leaves that belong together, described by their upper and lower limits. You can create them for a node that has more than one leaf. By defining intervals, new characteristic values that are added to the master data are assigned automatically to the interval, if the characteristic value is included in the interval range.
• Hierarchy Version: Hierarchies can be used in different versions. This option should be selected when hierarchy versions are to be addressed in reporting. For example, you can create a company structure by area for different hierarchy versions for the InfoObject Main Area in order to execute a plan-actual comparison in a query.
• Time-Dependency: In a non-time-dependent hierarchy, the characteristic values remain consistent. If you want to create time-specific statuses of a hierarchy, make the entire hierarchy time-dependent or define the hierarchy structure as time-dependent.

Hierarchies are an important aspect of your SAP BW/4HANA implementation, and the need for security should be determined in collaboration with the business team. It's the responsibility of the SAP BW/4HANA developers to create and maintain hierarchies, and security can be enabled for hierarchies from a security perspective.

In setting up hierarchy security, there are various options to consider. This includes enabling users to view the entire hierarchy, only specific nodes, or the subtree below those nodes.

Before setting up hierarchy security, it's essential that the characteristic on which the hierarchy is based is authorization-relevant. For example, if the hierarchy is based on products, characteristic 0D_NW_PRID must be marked as authorization-relevant.

To maintain hierarchy authorizations within an Analysis Authorization, select the relevant characteristic (1), choose Details (2).

Then, choose the Hierarchy Authorizations (3) tab, and choose Create (4) for a new hierarchy authorization or Details (5) to open an existing one.

A Hierarchy Authorization is made up by the following settings:

1. Hierarchy
2. Nodes (not when Type of Authorization is 3)
3. Type of Authorization
4. Hierarchy Level (only when the Type of Authorization is 2 or 4)
5. Validity Period

This table provides an overview of the values available for the Type of authorization field.

Note that when the authorization type is set to 2, the hierarchy level is considered an absolute value and refers to the entire hierarchy. The highest visible node of a hierarchy stands at level 1. For example, if you have entered the value 3 for the hierarchy level then the user can expand the hierarchy up to level 3.

Type 4 makes sense if an employee may only expand the hierarchy to a certain depth below a certain node. The node may be moved to a different level when the hierarchy is restructured, then the authorization remains the same.

Specify the exact criteria for aligning a hierarchy authorization with the chosen display hierarchy within the Validity Period field. This ensure other hierarchies are included in the authorization check.

The following options are available:

• 0 or blank: Name, version, and key date identical
• 1: Name and version identical
• 2: Name identical
• 3: None of the three properties have to match (least strict check)

You can use the validity period field to extend authorization to additional hierarchies based on the same characteristic.

Use 1 to set another hierarchy with the same technical name but a different validity period.

Use 2 to set another hierarchy with the same technical name but a different version number.

Or even to another hierarchy with a different technical name.

If you restrict the selection to hierarchy nodes, the hierarchy nodes in the other hierarchy must have the same technical name (see the following example).

Another aspect of hierarchy authorizations involves:

Using the special characteristic 0TCAIPROV (InfoProvider) to limit authorization to the data of individual InfoProviders.

In the BW Repository, InfoProviders are arranged in InfoAreas and hierarchically structured by the generated INFOAREAHIER hierarchy. This hierarchy is based on the technical characteristic 0INFOPROV, with the InfoAreas serving as the hierarchy nodes. Using this hierarchy can provide authorization for the InfoProviders within one or more InfoAreas. You can create a hierarchy authorization for the special characteristic 0TCAIPROV using nodes of the INFOAREAHIER hierarchy in transaction RSECADMIN, as shown in the following figure.

This hierarchy can now be used to grant authorization for the InfoProviders of one or more InfoAreas.

For that, in transaction RSECADMIN, create a hierarchy authorization for the special characteristic 0TCAIPROV using nodes of the hierarchy INFOAREAHIER.

This type of authorization assignment can have a negative impact on performance.