Social Icons

Tuesday, October 22, 2013

Where is @ISIDESC (Boolean Function) in ASO for MDX Formulas?

It has come out of surprise that ASO doesn't have a Boolean function similar to @ISIDESC function in BSO for writing MDX formulas. But, how can I achieve it? There are two different ways of doing it.
  1. Using ISANCESTOR Function
  2. Using CONTAINS function with a combination of Descendants function

[1] Using ISANCESTOR Function [ IsAncestor (Member1, Member2) ]

As the name says, this function will check if Member1 is ancestor of Member2. Let's take a simple example

IsAncestor ([Market].CurrentMember, [Florida])  This will check if the CurrentMember in the retrieve is Ancestor for [Florida].

Now, If we switch the member1, member2 we will be able to achieve the @ISDESC functionality.

IsAncestor ([Florida], [Market].CurrentMember) - This will check if [Florida] is ancestor of your CurrentMember and this condition will satisfy for all the members that fall under [Florida].

Using CONTAINS function with a combination of Descendants Function [ CONTAINS (Member_or_Tuple, Set) ]

Contains function will check if the Member_or_Tuple is present in Set.Below example will compute or check for Descendants

CONTAINS ([Market].CurrentMember, {Descendants([Florida])})

Hope this will help when you want to check for the Descendants in Boolean functions like CASE and IIF

Happy Learning!!!

Sunday, October 6, 2013


TWOPASS... Why do i need TWO PASSES for a calculation to get it right?

One of my colleague who was new to Essbase asked me.. What is TWOPASS? 

As usual, I took the standard example of % Calculation and said that 

"When you are performing % calculation using a member formula, you have to calculate again at Total level than to aggregate the percentages from child to parent. In such case, you have to re-calculate again at total level and in order for the essbase to do this, we tag the member as TWOPASS so that it will calculate again in the End. Below is the example i gave

Calculation Without TWOPASS

                 Jan        Feb      Mar      Q1
Sales        1000      1200    800      3000     
Profit          20          50      20        90

Profit %      50          24     40       114

Profit % has to be re-calculated again at Q1 to provide the correct results

Calculation With TWOPASS

                  Jan        Feb      Mar      Q1
Sales         1000      1200     800      3000     
Profit            20          50       20        90

Profit %        50          24     40       33.33
When we tag the member Profit % as TWOPASS, it calculates correctly. But, the next question he asked made me think as it's been a while that I was made to think :)

His question was not just one but two

  1. When we tag a member as dynamic calc and write a formula, it has to calculate correctly. Why do we have to tag as TWOPASS to tell essbase to calculate it again?
  2. Do we use TWOPASS only for percentage calculations or is there any other scenario where we use TWOPASS?
 There are two ways how you can perform Calculations in Essbase
  1. Build a calculation script to perform the calculation that you wanted (Batch Calculation)
  2. Use Member Formula
    • You can make the member as Dynamic Calc and essbase would calculate that member on the fly only when you retrieve (Dynamic Calculation)
    • Make it stored and calculate that member in Calculation Script (Batch Calculation because the member is stored and is explicitly calculated using a calculation script)
Essbase follows a specific order when performing a Batch Calculation or Dynamic Calculation. Understanding the order of calculation is very important which will give a clear picture to choose which option is better to perform a calculation.

So, You use TWOPASS on a member with Dynamic Calc to override the default calculation order.
Note: You can always control the order of calculation if you are using a calculation script to calculate that member

Below is the section of content from Essbase Database Administration Guide

For dynamically calculated values, on retrieval, Essbase calculates the values by calculating the database in the following order:

  1. Sparse dimensions
    • If the dimension tagged as time is sparse and the database outline uses time series data, Essbase bases the sparse calculation on the time dimension.
    • Otherwise, Essbase bases the calculation on the dimension that it normally uses for a batch calculation.
  2. Dense dimensions
    1. Dimension tagged as accounts, if dense
    2. Dimension tagged as time, if dense
    3. Time series calculations
    4. Remaining dense dimensions
    5. Two-pass calculations
    6. Attributes
 So, let's say that if your retrieve has multiple members which are dynamic calc (Across multiple dimensions) and you will tag that member as TWOPASS that needs to be calculated at last.

You can Achieve the same functionality in ASO using Solve Order Property. Using Solve Order, you can define the order of calculation similar to BSO Application.

Bottomline: Always evaluate if you really need TWOPASS as it has to calculate twice and it may take lot of time if you have complex calculations / multiple dynamic calc members.

Hope this information helps you when to use TWOPASS and when not to

Happy Learning!!!

Friday, October 4, 2013

Variance Reporting - How to do it - Part III

In the Last series of Posts Here (Part I) and Here (Part II), we have talked about the basics of Variance Reporting (Part I) and Variance Reporting Across Time Periods (Part II). 

In this post, we will talk about variance reporting Across Scenarios (Actual, Plan, Forecast).

Most of the Organizations who have been using Oracle EPM set of tools as part of their financial process would have the below process setup
  1. Fetch the Actuals (transaction level data) from different source systems for their reporting & analysis. Most of the actual data comes from oracle GL, Oracle EBS, PeopleSoft or any type of an OLTP system or it could even come from flatfiles or excel or could be any readable format
  2. Have a Planning application where users can input their PLAN data. Most of the organizations have long-term goals and target and plan to achieve it. What are the steps that are involved to achieve their goals and targets is part of their planning. I am not going to talk in details of about different types of Planning.
  3. organizations do make some assumptions based on their current & Historical Actuals. This is called Forecasting and is mostly considered as a short-term process. You can also employ a Rolling Forecasting process based on your running actuals. 
    • You Forecast for Jan based on the last year actuals. When you move to Feb, You forecast again for Feb based on Jan Actuals. This is really advantageous as it will help you to consider any uncertainty that arise during the course of your current business operations.
  4. organizations do have What-If modelling that will help them to understand the consequences that might arise and take precautionary measure to prevent them. 
    • For Example, Let's say that you expect that due to increase in fuel prices you predict an increase in "Transportation Expenses". 
    • Reduction in Raw Material Cost will reduce your Production Cost. But, that does not mean that you have to reduce your product cost. You might treat this as part of your Assumption and Forecast & Plan accordingly.
  5. organizations do have a Budget process on how to allocate money across various departments. Based on the amount of Budget that has been allocated, companies plan in order to reduce the cost of their operations.
Based on the above points, we can categorize scenarios as Actual, Plan* , Forecast

*Most of the organizations have multiple plans. Based on the number of planning sessions, you can create one scenario for each plan session

Taking all the points above in to consideration, below would be the variance scenarios that you can build in your applications
  • AvP (Act Vs. Plan) , AvP% (Act Vs. Plan %)
  • AvF (Act Vs. Forecast), AvF% (Act Vs. Forecast %)
As you plan and forecast, you always want to maintain multiple versions (Working v1, Working v2, Revised Working, Final) before finalizing your plan. These can be maintained in versions dimension (Standard Dimension when you create a Hyperion Planning Application).

As per point [4] , you can build Variance Scenarios considering What-If Scenarios

Hope this information will help you in building Variance Scenarios that will help your organization in taking better decision, better analysis and do better planning

Happy Learning!!!