Skip to Content
Author's profile photo Kayur Goyal

Hierarchies in CDS views

Why do we need Hierarchies?

The main purpose of a hierarchy in analytics is to aggregate facts and provide a high-level overview with the option to drill into the lower hierarchy branches and nodes. Facts are represented as CDS analytical views, which are identified by the analytical data category CUBE provided as CDS view annotation.

A hierarchy is usually not defined on the facts themselves but on some master data column that categorizes the facts. This master data entity, or any business entity that should be arranged in a hierarchy, is given by a CDS view of analytical data category DIMENSION.

In general, a separate hierarchy view is needed, identified by data category HIERARCHY. Its rows represent the nodes of the hierarchy. The hierarchical relation of these nodes can be specified in two ways:

By two sets of columns, one identifying a node as child, often the key columns of the node, and the other one identifying the related parent node

By a self-association of the view with cardinality [1 : 0..1] pointing to the parent node of the node

Root nodes are those nodes which have no parent.

Usually, a business entity instance is assigned to just one node in a hierarchy. Depending on the capabilities of the analytical engine, it could be assigned to multiple hierarchy nodes, and the engine would consider this multiple assignment when aggregating facts via the hierarchy. The analytical engine in ABAP, for example, can handle multiple assignments to leaf nodes.

Note that a hierarchy node relates to just one business entity instance. This is different than in current set hierarchies, where a node can relate to many business entity instances, but allows for a unified treatment of all nodes of a hierarchy.

Often there is not just one possible hierarchy for a business entity but several alternatives. These should be represented as instances in a hierarchy directory from which a user can select the hierarchy he wants to see. The hierarchy directory is represented by a CDS view of data category DIMENSION. An entry of the hierarchy directory is used as grouping of hierarchy nodes. At runtime, only the nodes of a single hierarchy directory entry are considered. This reduces the number of processed nodes and improves performance. The connection between the hierarchy node view and the hierarchy directory is modeled with an association between these two views, where the on-condition must include all key elements of the hierarchy view.

Assume that the user has chosen a master data dimension for (hierarchical) drill-down and some measures from the fact view. Then he has to select one hierarchy from the hierarchy directory view (or the hierarchy might be pre-selected by the analytical query). Then the engine reads hierarchy nodes and structure from the hierarchy node view for the selected hierarchy (or uses cached information). Afterwards, the measures are aggregated via the fact view to those master data instances that are assigned to hierarchy nodes. Measures for unassigned master data instances can also be aggregated and shown at a virtual hierarchy node for unassigned values.

The analytical engine recursively aggregates these values along the hierarchy structure to higher level nodes

The hierarchically aggregated measures are displayed at all visible nodes.

The following check-list helps to express your hierarchy in CDS.

All hierarchy nodes must be represented as the rows of a CDS view, the node view.

  1. Hierarchy nodes are all nodes belonging to a hierarchy, including root nodes, inner nodes, and leaf nodes. For those readers familiar with set hierarchies: also each set element, e.g. each cost center, is considered as a separate hierarchy node.
  2. For each node, a single parent node is specified in the node view. Nodes without a parent are considered root nodes. A node cannot have more than one parent. Therefore, all hierarchies are strict. Each chain of parents must be acyclic, and therefore end at a root node.
  3. The complete set of nodes can be divided into several individual hierarchies. The list of hierarchies is given by a CDS view, the hierarchy directory for this node view. Each node belongs to exactly one hierarchy, identified by one or multiple key fields of the node view. A hierarchy can have multiple root nodes. Within a single hierarchy, multiple sub-hierarchies are available, given by a node and its descendents.


Analytical View

The below is your analytical view, which has a costs center Hierarchy.

Hierarchy Node

Define a foreign key association to Hierarchy Directory and also Hierarchy Node Text View as below.

The Cost Center Master View should have the association to the Cost Center Hierarchy Node view. Also, Cost Center Field is annotated with @ObjectModel.Hierarchy.assocation indicating that a hierarchy is available for this master data entity.

Below is the Hierarchy Directory grouping all the available hierarchies.

Text view for Hierarchy Directory.

Text view for Hierarchy Node View.

Analysis for office


For system setup, Analysis for office setup please refer to the below blog post.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Thanks a lot Kayur!

      I've been searching for this information for so long!


      Author's profile photo abilash n
      abilash n

      Nice blog Kayur...

      Author's profile photo Former Member
      Former Member

      Nice Blog Kayur....

      Would you pls comment on how the Hierarchy tables will be updated?

      Author's profile photo Kayur Goyal
      Kayur Goyal
      Blog Post Author

      You need to create services on top of your views and consume the same in an application to update the data in the tables

      Author's profile photo Rajesh Majeti
      Rajesh Majeti

      Hi Karul,

      Can you please shed some light on  "  You need to create services on top of your views and consume the same in an application to update the data in the tables".We moved to ECC on HANA and leveraging CDS views and got struck here and not sure how to proceed way forward.



      Author's profile photo Former Member
      Former Member

      Hi Kumail,

      In S4/HANA all set definitions are now stored in new HRRP* tables. The SAP VDM views assume the hierarchy data (GL Accounts, Cost Centers, Profit Centers, etc.) is stored in the new HRRP* tables.

      SAP provides a program to replicate the FI Financial Statement Version hierarchies and the FI-SL based sets (SETHEADER, SETLEAF, etc.) to the new HRRP* tables.

      There are two programs to do this:

      1. First you have to specify with hierarchies ("sets") you want to replicate to the HRRP tables. To do so, use tcode HRY_REPRELEV.
      2. Next, you have to to the actual replication of the set data. To do so, use tcode HRRP_REP.

      These tcodes are also included in IMG: Financial Accounting (New) -> Financial Accounting Global Settings (New) -> Tools -> Set Report Relevancy for Hierarchies (and Replicate Runtime Hierarchies).

      There is also a Fiori app/tile to perform the replication.

      Good luck!


      Author's profile photo Georg Koester
      Georg Koester

      Hi Kayur,

      thanks for the explanations. Is this feature limited to ABAP CDS or is it available on HANA CDS Views, too?



      Author's profile photo Kayur Goyal
      Kayur Goyal
      Blog Post Author

      Hi Georg,

      I am not sure, Semantically the two are different things and hence has different offerings but I think that creating hierarchies is a feature supported in HANA CDS as well.



      Author's profile photo Former Member
      Former Member


      thanks for the great post!  The hierarchy works quite well for me.

      I didn't manage however, to use a parameter to select a Hierarchy version dynamically.

      Do you have a hint for me to solve that issue?


      Author's profile photo Thorsten Wuelpern
      Thorsten Wuelpern

      Hello Kayur, hello everyone!

      Is it also possible to create my own hierarchy? I want to create a hierarchy which consists of Companycode > Banks > Bankaccounts.

      I saw two different blog-entries where someone created a custom hierarchy – but this was single field related hierarchy. In the first example there was a hierarchy for organization units ( one unit is the parent of another one) and the second example was for employees, where one employee could be the manager of another one. This information was also located in one database table.

      But my 3 components are different in there datatype, e.g. a bank is not a companycode or a bankaccount. I need something like as Masterdata Hierarchy.

      In the end I want to create a SAP Analytics Cloud Story, where I can see my profit per companycode and I want to drill down to the bank, to see the distribution of my profit. Or is using hierarchies for this function the wrong way to proceed?

      Does anyone knows how to create such a hierarchy/drilldown functionality with ABAP CDS Views? We are using a live data connection, therefore the hierarchy has to be defined in the underlying datamodel  - it is not possible to do this in the cloud.

      Thank you very much!

      Best regards, Thorsten

      Author's profile photo Virinchi Punyamanthula
      Virinchi Punyamanthula

      Hi Kayur,


      Thanks for the explanation- the concept of Hierarchy in CDS.

      I have observed few things while building a hierarchy for FI and Logistics.

      For FI related tables- Hierarchy table (HRRP_DIRECTORY), Hierarchy Node table (HRRP_NODE) have Validity start and Validity end date and their respective master table like for Cost Center (CSKS), GL (ska1) etc., also have validity start and end dates. Validity end/to is key and time dependency got simple.

      But for Logistics, Hierarchy, Hierarchy Node and master got different and only Hierarchy node got Validity Start and End dates.


      for Customer- Hierarchy table is THIT, Hierarchy Node is KNVH and Customer Master is KNVV. Only KNVH got Validity Start and End dates.

      for Vendor- Hierarchy table is TLHIT, Hierarchy Node is LFMH and Customer Master is LFM1. Only LFMH got Validity Start and End dates.

      For logistics, Time dependent is quite difficult. Logic implemented for Customer Hierarchy is not working for Vendor Hierarchy.

      i am succeeded to get Customer hierarchy with time dependency but vendor hierarchy case time dependency is not working.

      Could you please look into these tables and guide us how can time dependency work?