Hi,
We have a reporting Cube that has data for many different scenarios. We also need to implement "Variance" Scenarios. Our scenario dimension has the following Elements:
Actuals
Budget
Forecast
We want to implement also the following Elements:
Actuals vs. Budget (Which is Actuals minus Budget)
Actuals vs. Forecast (which is Actuals minus Forecast)
Budget vs. Forecast (which is Budget minus Forecast)
The cube also has the Accounts dimension, which includes statistical accounts and Metrics.
I know that there are 2 ways to achieve this.
One way is to create these "Variance" elements as independent elements and calculate their values in Rules as following:
['Actuals vs. Budget'] = ['Actuals'] - ['Budget']
And then Feed the variance with both elements
The other way (my preferred way) is to Create the "Variance" Element as consolitation of other 2 elements use the weight of -1 for Budget.
This works fine for normal Accounts but not for Statistical and Metric Accounts.
What I'm doing in this case is overwrite the C: Calculation for these accounts, which seems to be working.
Which method you think is more optimal ?
Thank you
Best Practice to implement "Variance" Calculations in TM1
- qml
- MVP
- Posts: 1096
- Joined: Mon Feb 01, 2010 1:01 pm
- OLAP Product: TM1 / Planning Analytics
- Version: 2.0.9 and all previous
- Excel Version: 2007 - 2016
- Location: London, UK, Europe
Re: Best Practice to implement "Variance" Calculations in TM
The second one, by far. Using natural consolidations gives you much better performance, smaller memory consumption and is instantly recognisable for what it is by users.
Of course, the simplicity and calculation performance are somewhat trumped when you have to apply C-level rules for the types of data that require different consolidation methods, but as a rule of thumb use consolidation by hierarchy whenever you get the chance.
Of course, the simplicity and calculation performance are somewhat trumped when you have to apply C-level rules for the types of data that require different consolidation methods, but as a rule of thumb use consolidation by hierarchy whenever you get the chance.
Kamil Arendt
-
- MVP
- Posts: 3698
- Joined: Fri Mar 13, 2009 11:14 am
- OLAP Product: TableManager1
- Version: PA 2.0.x
- Excel Version: Office 365
- Location: Switzerland
Re: Best Practice to implement "Variance" Calculations in TM
Always go for the natural consolidations. This also has the significant advantage that where you do need to overwrite the consolidation with a C level rule there is no need to feed the rule. I would even go so far as to make any variance % measures consolidations as well, then these also do not need to be fed should you want them to display in a zero suppressed view for example.
-
- Posts: 27
- Joined: Sun Aug 02, 2009 2:57 am
- OLAP Product: Cognos TM1/Cognos BI
- Version: from 9.4 to PA 2.0.9
- Excel Version: 2010
- Location: Toronto
Re: Best Practice to implement "Variance" Calculations in TM
Thank you for your quick answer.
lotsaram: Can you please explain how would you implement the Variance % as Consolidation? Do you mean only define the Varance % as a consolidation of Variance$ and then Use the C: Rules to calculate the value of Varance %? Or is there any way to have TM1 calculate the Variance % also:) That would be miracle
Thank you again
lotsaram: Can you please explain how would you implement the Variance % as Consolidation? Do you mean only define the Varance % as a consolidation of Variance$ and then Use the C: Rules to calculate the value of Varance %? Or is there any way to have TM1 calculate the Variance % also:) That would be miracle
Thank you again
Ardian Alikaj
-
- MVP
- Posts: 3698
- Joined: Fri Mar 13, 2009 11:14 am
- OLAP Product: TableManager1
- Version: PA 2.0.x
- Excel Version: Office 365
- Location: Switzerland
Re: Best Practice to implement "Variance" Calculations in TM
Essentially yes. "Normally" you would have variance % as a rule without an N: or C: qualifier. If you make ActBud variance % a consolidation with ActBud variance as the child (or actual and budget as children) then the only thing that is different about the rule is that it will be a C: rule and there is no requirement to feed such a rule since values in actual and budget will automatically "feed" the calculation.tm1expert wrote:Thank you for your quick answer.
lotsaram: Can you please explain how would you implement the Variance % as Consolidation? Do you mean only define the Varance % as a consolidation of Variance$ and then Use the C: Rules to calculate the value of Varance %? Or is there any way to have TM1 calculate the Variance % also:) That would be miracle
Thank you again
- stephen waters
- MVP
- Posts: 324
- Joined: Mon Jun 30, 2008 12:59 pm
- OLAP Product: TM1
- Version: 10_2_2
- Excel Version: Excel 2010
Re: Best Practice to implement "Variance" Calculations in TM
Leaving aside technical issues check that the variance calculation does not vary with account.tm1expert wrote:Hi,
We want to implement also the following Elements:
Actuals vs. Budget (Which is Actuals minus Budget)
Actuals vs. Forecast (which is Actuals minus Forecast)
Budget vs. Forecast (which is Budget minus Forecast)
What sign convention are you using for your figures in TM1?
- if you are using dr=negative\cr=positive (ie costs negative, income positive ) then this formula will work for all accounts
- if you are using dr=positive\cr=negative (ie costs postive, income negative, standard convention for many ledgers ) then this formula will need to be reversed but will work for all accounts.
- If you are using all figures positive (standard for budgeting and management reporting applications) you will need to multiple the variance by an indicator depending whether it is income or expense.
And for % variances I think you will need the denominator to be an absolute value.
-
- Posts: 27
- Joined: Sun Aug 02, 2009 2:57 am
- OLAP Product: Cognos TM1/Cognos BI
- Version: from 9.4 to PA 2.0.9
- Excel Version: 2010
- Location: Toronto
Re: Best Practice to implement "Variance" Calculations in TM
It makes perfect sense
Thank you all
Thank you all
Ardian Alikaj