Page 1 of 1
need your help
Posted: Thu Jun 28, 2012 10:00 am
by rooody
hello
i am new to tm1 and i am trying to make calcutions across more than one dimension i am using version 9.5
but it displays n/a in the view of the cube
Re: need your help
Posted: Thu Jun 28, 2012 10:07 am
by Alan Kirk
rooody wrote:hello
i am new to tm1 and i am trying to make calcutions across more than one dimension i am using version 9.5
but it displays n/a in the view of the cube
Welcome, but please read (and follow) the
Request For Assistance Guidelines. You should ask
specific questions, giving
full details of what you're doing, and what you've looked at to fix it.
Re: need your help
Posted: Thu Jun 28, 2012 1:14 pm
by rooody
i am trying to divide two elements from two differnt dimensions
rule:
skipcheck;
['YE Fcst. 11 vs. FY 10' ] = ['FY 10' ] \['YE Fcst.11' ];
feeder;
['FY 10' ]=> ['YE Fcst. 11 vs. FY 10' ]
it displays n\a on the view of the cube
so i want to know if tm1 9.5 support across dimensions aggregation
Re: need your help
Posted: Thu Jun 28, 2012 3:19 pm
by Steve Rowe
Without knowing a bit more its hard to know what the problem is.
I'd say Yes and No,
Yes you can write the rule like that and it will compile and in some locations in the cube you'll get the correct answer.
and
No, it doesn't make too much logical sense to do this as in some locations at least you are creating a circular reference. (hence the N/A)
Try going down to the N level of the cube and using the rule tracer to figure out what is going on. It's very hard to just look at the C level and figure it our, you need to work from the bottom up.
HTH
Re: need your help
Posted: Fri Jun 29, 2012 1:31 am
by rmackenzie
rooody wrote:i am trying to divide two elements from two differnt dimensions
rule:
skipcheck;
['YE Fcst. 11 vs. FY 10' ] = ['FY 10' ] \['YE Fcst.11' ];
feeder;
['FY 10' ]=> ['YE Fcst. 11 vs. FY 10' ]
it displays n\a on the view of the cube
so i want to know if tm1 9.5 support across dimensions aggregation
You could still have provided more information with your question... I have to guess that 'YE Fcst. 11' is part of a version/ scenario dimension and 'FY 10' is part of the year dimension, is that correct? If so, there are already fundamental design questions to think about - why have a version limited to a year, when you could just be using ['Forecast', 'FY 11'] ? Let's say you had 'Actual' and 'Forecast' versions and 'FY 10' and 'FY 11' years, then your rule could read:
Code: Select all
['YE Fcst. 11 vs. FY 10'] = ['Actual', 'FY 10'] \ ['Forecast', 'FY 11'];
But here the problem of not properly working with separate years and versions becomes clearer as you should really be giving a year for the LHS of the rule as you don't want to calculate that version for 'FY 05' and 'FY 06' etc. Perhaps:
Code: Select all
['YE Fcst. 11 vs. FY 10', 'FY 11'] = ['Actual', 'FY 10'] \ ['Forecast', 'FY 11'];
I think you need to go back to the drawing board and examine why you are referencing years in your versions and find out if it is really necessary.
Re: need your help
Posted: Tue Jul 03, 2012 10:19 am
by rooody
thank you for your help
i added n: to the rule and i still face the same problem
after i traced the calculation i get the following error
circular reference string over flow how can i over come the circular reference
Re: need your help
Posted: Tue Jul 03, 2012 3:35 pm
by tomok
rmackenzie wasn't trying to tell you that adding an n: to your rule was going to solve your problem, just that by using that you could use the Rule Trace function to help you find out why it's not working in certain cases. To me, it's quite obvious. You can't do what you want to do without running into circular references (i.e. dividing a number by itself). You have to write your rule(s) more granularly than you have to eliminate the possibility of a circular reference. And, please don't ask me to do that for you. You have been given enough information to know what the problem is and how to fix it.
Re: need your help
Posted: Tue Jul 03, 2012 5:27 pm
by Steve Rowe
A good start to try and solve this type of problem until you have a lot of practice is to build the model in Excel first with the full complexity of the formula required.
This means that you'll solve the logic problems in Excel a world you might be used to.
You are then left with translating the Excel logic into TM1 logic, a skill that you are going to use again and again while developing TM1 apps so worth getting. You'll also be able to post the excel model as way of explaing what you are trying to do in less than a million words....
Good luck and keep asking questions if you get stuck.
Cheers,