Creating Alternate Entity Hierarchies

In the Entity dimension, you can create alternate hierarchies, where a single entity can have multiple parents and contribute differently to each parent. The parent members can be in different currencies and the translation that happens in the parent currency member will be different for these entities. To accomplish this, you use partially shared members, where only a part of input data is shared across all instances of the entities.

The following example shows a leaf-level entity that has more than one parent.


Example of Entity with multiple parents

In this example:

  • Entity E111 is a child of both P11 and P12.

  • Input data that is entered for E111 at either P11 or P12 is replicated to the other entity after Save. You can enter the data at any of P11.E111 and P12.E111 members.

  • After consolidation, the calculated values at P11.E111 and P12.E111 can be different. For example, suppose the application is a multi-currency application, where the currency of E111 is GBP. P11 currency is USD and P12 currency is EUR. When entering data to E111, data is always entered in the entity currency member of the Currency dimension. The parent currency member is calculated and the values for Parent currency for P11.E111 and P12.E111 will be different, as the exchange rates between GBP and USD, and GBP and EUR can be different.

You can also create an entity hierarchy where a parent level entity has more than one parent. However, a hierarchy where the parent level has multiple parents that have different children is not supported.

You build an alternate hierarchy by creating partial share Entity members, and selecting "Shared" as the Data Storage member property. See Creating Shared Members.

You can use shared hierarchies to meet your reporting needs, however, the number of shared hierarchies affects performance, as they increase the database size and consolidation times.

As a best practice:

  • The top member of alternate hierarchies must have the Consol operator set as Ignore, to avoid duplicate values.

  • Shared members must be added after non-shared members in the hierarchy.

  • Alternate hierarchies are allowed outside the Closing Balance, but they should roll up to Total Movements.

In the Member Selector, you can view the parent and child relationships. When you select an entity, the member selector displays it as Parent.Child, for example, North America.USA. You can then select the entity you want, or if an entity has multiple parents, you can select each occurrence of the entity under different parents.

When you enter transaction data to a Common data Consolidation dimension member, you only need to enter data once, either for the Primary or Shared member.

You can also enter data once in data forms. For example, suppose E111 is a partially shared entity that has two parents, E11 and E12. In a data form, if you enter the amount 100 in E11.E111 and save it, 100 is immediately shown in E12.E111. If you change the amount to 150 in E12.E111 and save it, the same amount is reflected in E11.E111. In data forms, you can select whether to display the members of the Entity dimension as Parent.Child, and whether to display their currencies. See Setting Form Dimension Properties.

When you export data, the same data is exported for partially shared entities and the data is exported in the Parent.Child format. If you import data to one of the partially shared entities in a data file, the data is imported to the other one also.

When a journal entry is posted to one of the partially shared entities, the values are posted to all instances of that entity.

Any change to Common data that is made to one partially shared entity that results in a change of calculation or process management status will be reflected in other instances of the entity. For example, if one instance is consolidated and its Calc status changes to OK, the status of the other instances changes to OK. The same rule applies for locking and unlocking of partially shared entities unless Enhanced Organization by Period has been enabled.

Security and valid intersection rules defined for an entity also apply for its partially shared instances.

When you enter transaction data to a Node data Consolidation dimension member, the data must be entered, or the journal posted, for each Parent / Entity combination in which the data is required.

If Enhanced Organization by Period has been enabled, then each instance of partially shared entities are locked and unlocked independently of each other.

Watch the following video to learn more about alternate hierarchies:

Video icon Configuring Alternate Hierarchies for Entities

Partial Shared Entities – Initial Behavior

When new level 0 entities, or new instances of level 0 partial shared entities are created in metadata and the application is updated through a Database Refresh, the system applies several default settings and data updates.

The first instance of a new level 0 entity is assigned an Ownership % of 100%. The range-based system default consolidation method of Subsidiary is applied (unless the range-based setting for 100% ownership has been changed by the user.

Any additional (non-primary) instance of a level 0 partial shared entity added to the application is assigned an Ownership % of 0%. The total ownership within each alternative hierarchy is limited to 100%. If partial shared entities reside in different alternative hierarchies, then the user can change the initial 0% settings to the required settings, as long as the total ownership % across all instances does not exceed 100% in each alternative hierarchy.

If Enhanced Organization by Period has not been enabled, the range-based system default consolidation method of Not Consolidated is applied (unless the range-based setting for 0% ownership has previously been changed by the user). When the new instance is added to the database by the Database Refresh process, the system copies any existing Entity Currency Common Data from the primary instance to the new shared instance. Although the Consolidation % for the Not Consolidated method is 0%, the parent of the new instance is impacted where data has been copied. This might require that Locked entities be unlocked and re-consolidated.

If Enhanced Organization by Period has been enabled, the range-based system default consolidation method of Inactive is applied. When the new instance is added to the database by the Database Refresh process, the system copies any existing Entity Currency Common Data from the primary instance to the new shared instance. The system than translates the copied Entity Currency Common Data to the Parent Currency of the new instance. The Parent Currency of the new instance might not be the same currency as the Parent Currency of the primary instance, so the translation process is executed along with any relevant system and user-created calculation rules. The Calc Status becomes OK in the new instance of the partial shared entity.

When Enhanced Organization by Period is enabled, and the Inactive method is assigned to an entity, a break-point is created between the Common Data and Node Data of the Inactive entity. The data copy, translation and rules execution applied to the Common Data does not impact the Node Data of the new Inactive instance, nor does it impact its ancestors. The Node Status of the new instance will be No Data because Node Data is specific to the parent / entity combination and no data has been populated in any of the Node Data consolidation dimension members. The new instance of the partial shared entity remains unlocked regardless of the locked / unlocked status of its parent.

If required, you can change the Ownership % and method assigned to the new instance of the partial shared entity. However, changing the method from Inactive to any other method will require that the parent of the entity be Unlocked. By changing the method of the new instance of the entity from Inactive to an active method, its ancestors will be impacted unless the new instance has a Calc Status of No Data.