Configurable Dimension allows the HFM administrator to set the number of custom dimensions in the application. For each dimension it is possible to set the size of the dimension and give a short name and a long name (alias).
Configurable Dimensions provides HFM the flexibility lacking in the traditional tools with predefined fixed structures. HFM applications can be built with the exact number of custom dimensions needed. If 2 custom dimensions are necessary, then the application can be built with 2 dimensions. If it needs 4 or 6, the number of custom dimension can be set accordingly. Customer requirements drive the design and the structure of the application without constraints or compromises.
HFM is the preferred tool to create financial reporting applications. Management reporting and legal consolidation can be handled within the same application. Configurable dimension provides an expandable framework ideal to handle all the required details, whether it is operational or legal. For instance some dimensions can be used to analyze Product and Market information, while other dimensions for type of adjustments or eliminations. All the information in these configurable dimensions is automatically available in Web forms, Reports and in Excel using the SmartView module.
The size of a dimension determines the total number of elements in the dimension. Depending on the size of the dimension, the system allocates in the database a different number of bytes for the index .
The size of a dimension can be either:
Large: 2 billions members (4 bytes used internally)
Medium: 32,000 members (2 bytes used internally)
Small: 128 members (1 byte used internally)
The minimum is 2 custom dimensions. Technically the system requires these 2 dimensions to store the source and destination currencies for the exchange rates. The system will automatically create these 2 dimensions with a Large size.
The number of dimensions is limited by the total number of bytes used for all the index of these dimensions. This total must not exceed 40 bytes.
The system will always create the first two dimensions as Large, which will use 8 bytes. There will be 32 bytes remaining for additional customs.
Maximum number of elements
Number of bytes used internally per dimension
Possible number of dimensions in the application
None to 32
None to 16
2 to 10
Yes. It is possible to create some custom dimensions as Large and other dimensions as Medium or Small.
Although the officially published maximum number of elements is 128; 32,000; 2 billions for Small, Medium, and Large dimension, internally the system can accommodate twice this number of elements. Once the maximum number of elements is reached in a dimension, it is not possible to create additional elements. The solution is then to create a new application and set the dimension with a larger size.
No. The system does not reuse index number of deleted elements.
After the application has been created in a Development environment, it is recommended to create a brand new application for Production containing only the final version of metadata and using internally only the exact number of index
Configurable dimension does not have a direct impact on performance. In an application where Calculation rules are correctly written, performance is driven by the amount of data in the application, not by the number of dimensions or the number of elements in each dimension.
Adding dimensions to an existing application is likely to introduce more detailed reporting and therefore require additional data and additional calculation rules. These additional data and rules will have an impact on performance.
There is no technical optimum number independent from the business requirements. For a specific application, the optimal number of dimensions is the smallest number of dimensions necessary to handle the business requirements.
Usability is better with fewer dimensions. It will be easier for the users to view and set the Point of View with fewer dimensions. There will be less dimensions to use in Journals, Reports, Grids, Web forms, SmartView.
The existing applications can be converted using the migration utility, they can continue to be used as is.
It is not possible to remove a dimension from an existing application. A new application must be created.
If the business requirements are the same, then the existing application should remain the same. If the reporting needs are evolving, then it is possible add new dimensions to the existing application.
The number of custom dimensions depends on the level of details of the reporting. When the same detailed analysis exist for multiple accounts, this detail should be created in a custom dimension. For instance, if Sales, Cost of Good Sold and Gross Margin must all be detailed by products, then it is advised to create a Product hierarchy in a custom dimension. When an account must be analyzed by a combination of details, for instance Sales by Product and also simultaneously by Market, then these details should be be created in separate dimensions. The more analytical details are required, the more dimensions are necessary. For instance, if Sales, Cost of goods sold and Gross margin must be analyzed simultaneously by Product, Market, Channels, and Packages, then it is advised to use 4 custom dimensions.
Yes. A custom dimension can contain different type of details, as long as these details are used on different accounts. For instance if the P&L accounts are detailed by Products and the Balance Sheet accounts are detailed by Flows, then it is possible to use the same custom dimension for both details. Products and Flows will be created as separate hierarchies in the same dimension. When defining the accounts, P&L accounts will be associated with Product hierarchy and Balance Sheet accounts will be associated with Flow hiearchy.
We believe it is better to create fewer dimensions because it will be easier for the user to navigate in the product. When possible we think it is better to use the same dimension for different type of details, using the top member attributes in accounts to define the correct intersections.
Like in prior version, the valid custom dimension elements are associated with accounts using metadata attribute <Dimension Name>TopMember.
No. The application should be created with the exact number of dimensions required for the current business requirements. We will provide a separate utility to add custom dimensions to existing application. When a new dimension will be added to an existing application, all historical data will be preserved. The new dimension will contain a [None] element. The existing data will be set to [None] for the new dimension.
Several changes were made in the User Interface of the product to accommodate a variable number of custom dimensions. For instance, it is possible to control the dimensions displayed in the Point of View and also how the Point of View is displayed.
Yes. In order to adapt the Journal module to a possibly large number of custom dimensions, the system can automatically move common elements from the rows to the page so that the user does not have to repeat the same element on every row.
All existing functions continue to work. Some new generic functions have been created to handle applications with more than 4 custom dimensions.
Both custom dimension name and alias can be referenced in rules, web forms and system reports.
There is no direct impact of custom dimension on the infrastructure. The infrastructure must be sized based on the number of concurrent users, the amount of data processed during consolidation, the amount of data processed in reports or other data retrieval mechanisms, the intensity of the calculation required. For best performance, 64 bit system using fast processors and large enough amount of memory is recommended.