Required Dimensions for Single and Multi Currency Applications in Hyperion Planning

Dimensions are the basic foundation of  a oracle hyperion planning application and dimensions are together are referred to as an outline. Every planning application has a set of standard dimensions. Single Currency Planning Application having six dimensions and Multi Currency Planning Application having eight dimensions.

Required Dimensions for Single Currency Application

• Period
• Year
• Scenario
• Version
• Entity
• Account

Other Dimensions

• Smart Lists

Multicurrency Applications Require Two Additional Dimensions

• Period
• Year
• Scenario
• Version
• Entity
• Account
• Currency
• HSP Rates

Planning application stores the data in an Essbase.

Account Dimension

This is standard dimension in hyperion planning application. In this dimension all the measures such as profit, loss, expenses, IT expense, rent expense, HR expense and so on form the Account dimension members.

The Account dimension specifies the data to be collected from budget planners. Can establish accounts for all budgeted items to the necessary level of detail.

 Period and Year Dimensions

These two are also standard dimensions and these both represent time. Specify a time period and year for each value. Base time periods, such as months, are automatically rolled up to summary time periods, such as quarters and total year and has information of different calendar distribution of weeks like a 445, 454, 454, or even.

As administrators, specify base time periods and distribution of weeks in the Period dimension when creates application views. Use the year dimension to add years to the calendar. Year dimension members can not be renamed once they are created.

Scenario Dimension

Scenario dimension represent the broadest categories of data planning  application and it's  describes the type of data that a plan includes, such as budget, actual, or forecast, as well as the time span that the plan covers.

Should define the time span  for every Scenario Dimension Member and time span includes starting year, ending year, starting period and ending period.

• Actual
• Budget
• Forecast

Version Dimension

Two types of members can be created in the Version Dimension, they are as follows,

• Standard bottom up
• Standard target

Bottom up facilitates bottom up budgeting/forecasting and target version facilitates top down budgeting. Version allows for flexibility and iterative planning cycles. For example, your application could have two versions, Working and Final, for each scenario.

Also can use versions to model possible outcomes based on different assumptions about interest rates, growth rates, and so on. For iterative planning, version dimension is the key.

Entity Dimension

This is key dimension that defines business organization hierarchy, workflow, and Entity responsibilities in an organization.

Entity dimension shows the flow of Planning information through organization. Can establish an entity for each group or responsibility centre that submits a budget plan. This dimension typically includes geographic regions, departments, or divisions, depending on your requirements.

HSP_Rates Dimension

This is a Multi Currency Planning Application. This dimension contains a member to store exchange rate values for each currency. It also contains a member for input values and currency overrides. This dimension can be divided into two types as follows,

• Input members
• Currency rate members

If an application has three currencies, would have three corresponding members as follows,

• HSP_Rate_USD
• HSP_Rate_EUR
• HSP_Rate_INR

Alias and Smart Lists

In addition to the required Planning dimensions, you must set up an Alias dimension if you want to assign aliases to dimensions such as Account or Entity. If you want to use Smart Lists in your application, you must set up a Smart List dimension.

Currency Dimension

Plan in one or more currencies. The Currency dimension identifies the currency in which values are displayed. In the Currency dimension, you set up the following categories:

• Which currencies are used by applications and reporting
• How currencies are displayed in reports and data forms
• How currencies are translated into other currencies
• When currency conversion occurs

Storage-Properties-in-Hyperion-Essbase

Essbase - Consolidation Storage Properties:

In oracle essbase data storage properties will be defined where and when consolidations are stored. For example members are tagged as store data then Essbase sums the values of store data members and stores the result at parent level.

 

Total we have six storage properties in Essbase:

1) Store data

Store data property is a default storage property, when we load the data in to essbase will store values in the cell. Store the data values with member.

2) Dynamic Calc

When we tag any member as a dynamic calculation the values are never stored in the cell, but values are dynamically retrive in the reports. The data associated with the member is not calculated until requested by a user. The calculated data is not stored. 

                   Dynamic calculation options allow outline members to be calculated when requested by users rather than during the batch calculation process.

Advantages:

Memory saved.

Calculatin would be fast.

Backup would be fast.

Retriveng would be fast.

Disadvantages:

Reprt performance would be slow.

3) Dynamic Calc and Store

When we tag any member as dynamic calc and store, the value is does not store the first time. However the value is dynamically retrived and stored in the block. Would not calculate the data value until a user

requests it, and then store the data value.

Advantages:

Memory saved.

Calculatin would be fast.

Backup would be fast.

Retriveng would be fast.

Disadvantages:

Reprt performance would be slow.

4) Shared member

The shared member storage property provides a way to reuse data that essbase has indexed or calculated. Shared members, instead of storing data in multiplies places, create a pointer to a stored member. The data value associated with shared member comes from different member having the same name. Shared member is also called alternative hierarchy.

Conditions of shared member:

Shared members should not have children below it.

The original member and shared member should be in the same dimension and original member should be created first only then we can create shared member.

We do not have any formulas, attributes and UDA's to the shared members.

5) Never share

The data associated with the member is duplicated with the parent and its child if an implied shared relationship exists.

6) Label only

Label only used for all grouping pupose or navigating purpose and we would not tag a 'level 0' as lable only. Although a label only member has no data associated with it, it can display a value. 

The label only tag groups members and eases navigation and reporting. Typically, label only members are not calculated.