There are many instances where it will be helpful to view data rolled up to different hierarchies. Data could be collected for items rolling up to the primary hierarchy, but users would like to report that data against an alternate hierarchy.
In the example below, an organization collected revenue data from sales representatives (“Sales Rep L2”), which rolls up to regions (“Regions L1”). With its primary hierarchy, it can report the sales representatives’ revenue by region. However, it would also like to report on revenue across the product lines of the representatives.
The primary hierarchy is set up as below:
Revenue data is collected in module “Revenue by Sales Rep-Region” with dimensions “Sales Rep L2” and “Year”.
An alternate hierarchy for sales representatives is set up as below to report by product lines.
A system module is set up to map the “Sales Rep L2” of the primary hierarchy to “ALT Sales Rep L2” of the alternate hierarchy using the unique name of each sales representative.
A module is set up to report revenue by the alternate sales representative hierarchy. In the report below, the organization can review revenue by the product lines of the representatives.
The example above demonstrates one method of building an alternate hierarchy from an existing hierarchy and data in the model. Based on an organization's data availability, organizational structure, and business requirements, alternate hierarchies can be utilized to drive valuable insights from existing information.
Hi Lisa, great article! Does it make sense to include import/process actions to fully build out the alternate hierarchy, instead of just using a reporting hierarchy via the module calculations? Thanks for sharing this best practice!