Understanding Best Practices - Finance Hierarchies
  • 2 Minutes to read
  • Dark
    Light
  • PDF

Understanding Best Practices - Finance Hierarchies

  • Dark
    Light
  • PDF

Article summary

  • While you can use members from the main hierarchy for reporting purposes, in some cases, you might need to create an alternate hierarchy for optimal reporting performance. The Main hierarchy includes both leaf-level members and rollup members. Leaf-level members contain specific values and should be used directly in queries to enhance report performance. Rollup members aggregate values from their child members using a specified rollup operator. 
    • Leaf Level Members: These can be used directly in certain queries, such as Verify Data queries, where only leaf-level members are visible. However, it's important to note that querying at the leaf level does not necessarily guarantee optimal performance, as it depends on the specific use case. Additionally, leaf-level members do not inherently provide accurate data - accuracy depends on the correctness of the data loaded to them.
    • Rollup Members: These members aggregate values from their child members using rollup operators. It is recommended to use rollup operators primarily for dimensions like the Account dimension. For other dimensions, use the default rollup operator (‘+’). 
  • Use Alternate Hierarchies as needed, but be aware that large alternate hierarchies may affect performance. Alternate hierarchies are useful for specific circumstances, such as eliminations in consolidation. However, duplicating the entire Main hierarchy into an Alternate hierarchy can significantly impact performance. Click here to learn more about Alternate Hierarchies.
    Notes:
    • Performance Impact: Creating Alternate hierarchies results in duplicate members being generated. This duplication can lead to decreased report performance, especially if the alternate hierarchies are large or complex. 
    • Use Case: Alternate hierarchies should be employed judiciously and only for specific circumstances where they provide necessary functionality.
  • Avoid creating redundant hierarchies that mirror the Main hierarchy unless absolutely required. Avoid adding too many members under one parent (flat hierarchy). For example, rolling up hundreds of individual accounts directly under a single Total Accounts parent. Instead, create a more structured hierarchy with subcategories like Assets, Liabilities, and Equity to better organize the financial data.
  • Keep Segment Hierarchies simple. Simpler segment hierarchies improve performance, are easier to maintain, and enhance user experience. Complex hierarchies can slow down processing, make maintenance difficult, and confuse users. Stick to essential levels, avoid redundancy, and use additional optional Finance Hierarchies for specific needs to keep things efficient and manageable. 
  • Consider loading unused or discontinued members under a single member in the hierarchy to keep the structure clean and organized. This approach prevents cluttering the hierarchy with outdated members, making it easier to navigate and manage. It also improves performance by reducing the number of active members the system processes, while still retaining the historical data for reference if needed. 
  • Remember that a Member Code is required for every member in your segment hierarchies. While a Member Name may be optional in certain contexts, the Member Code is always mandatory as it serves as the unique identifier for each member. This ensures that the system can manage, update, or retrieve specific members, preventing potential errors or confusion in your financial data management.

Was this article helpful?