How OneStream Uses Extensible Dimensionality
What is OneStream’s dimensional extensibility feature? Extensible dimensionality provides the ability to create various dimensional hierarchies within an application based on the level of detail that a company requires for reporting. This capability in the Account dimension allows for the various reports, rules, security, etc. to integrate the lower-level detail accounts required in consolidation and statutory reporting to be compared in reports to a higher-level budgeting/forecasting management reporting. Extensibility in the Entity dimension provides the finance department with the level of detail required to run a full P&L by location, as compared to the consolidation requirements of reporting on a legal entity basis for tax and audit reports. Use of an extensible dimension can also be beneficial in the Flow and UD dimensions.
OneStream defines Extensible Dimensionality as:
“Business Units can inherit dimensions from a standard set that corporate may maintain but Extensible Dimensionality allows them to extend those dimensions to suit their own process and reporting needs. This allows the units to have operational significance for their business units yet grants control of the overall process to corporate. “
Account Dimension Extensibility Example
The consolidations team is required to report their chart of accounts at a detailed level, which includes the lowest level or base accounts that make up the P&L and Balance Sheet, as compared to the planning team, who need a higher level or summary accounts for their management reporting.
In this example, we will look at how account 60999 (Net Sales) is input and reported by the planning team, as compared to the more detailed input required by the consolidation team.
The Account dimension for this example contains the higher (less detailed) accounts in the BudgetCorpAccounts hierarchy, and includes the ActualCorpAccounts (more detailed) hierarchy.
The planning department has the ability to input their data for Net Sales directly into account 60999 – Net Sales. This is because, in this hierarchy, the account is at the lowest or base level.
For the reporting of Actuals data, the consolidations team requires that account 60999 – Net Sales be broken down further into four base-level accounts that roll up into Net Sales. The four base-level accounts in this example include 60000 – Operating Sales; 60100 – IC Sales; 60200 – Returns & Allowances; 60250 – Other Outside Sales.
As seen in the below screenshot, the four base-level accounts are in black, meaning they are base level, while the Net Sales account is greyed out, indicating it is a summary level in this hierarchy.
This is another view of how it would look when comparing Actual vs. Planning Scenarios
User-Defined Dimension Extensibility Example
An application can contain several extensible dimensions, all based on the company’s reporting requirements. In the following example, we can see extensibility in the UD3 dimension, which in this instance, contains DataType information. Below you can see where those individuals in the planning/forecasting teams who are working in a Planning scenario do not require a datatype. However, those teams using an Actual scenario do require a specific datatype breakout.
Other design notes:
- An extensible dimension can inherit dimensions and then extend them.
- When designing an extended dimension, the extended members are added below the inherited members.
- Different dimensions can be assigned to different cubes, and those dimensional assignments can be different for each scenario type.
- Note of caution: ‘Using this approach to extend accounts used within the Intercompany Matching process is not a recommended process.
Design Benefits for Flexible Dimensions
Extensible Dimensionality works best when the application design starts with the reporting grain required by each business process. Actuals may need detailed accounts, flows, entities, or user-defined members, while planning can use a more summarized hierarchy. Shared inherited members keep corporate reporting consistent, and extended members add detail only where it creates value.
Designers should document cube and Scenario Type assignments, extension points, ownership, security, intercompany requirements, and expected Data Unit size. Too little extensibility can limit flexibility or performance; too much can increase maintenance. The goal is a deliberate balance among local relevance, corporate governance, usability, and future growth.
Extensible Dimensionality and OneStream Resources
For more guidance, explore what OneStream is, OneStream XF, OneStream implementation, OneStream financial reporting, managed services for OneStream. Also review the official OneStream Extensible Dimensionality guide.
