ATTRS in Rules

[ashishkmr1]

Hi,
I am new to TM1. Can some one pls tell what am I doing wrong here?
I have an "Year" dimension with 2009, 2010, 2011... etc as elements. I also have another element "TY vs LY" in this dimension which should hold the This Year minus Last year value.
I have another dimension "DAYS" which has all the days in a year and has 2 attributes "Financial TY" and "Financial LY". Both are text attributes.

Now I have a cube that has the following dimensions - EXPENSE ITEM, YEAR, MONTH, STORE, MEASURE
In my cube I write this rule
['TY Vs LY']=N:[ATTRS('DAYS',TODAY(1),'Financial TY')]-[ATTRS('DAYS',TODAY(1),'Financial LY')'];

When I save the rule it gives the following error message

"Syntax error on or before ('DAYS',TODAY(1),'Fi
Dimension Name not found"

Immediate help will be greatly appreciated.

Thanks,
Ashish

[ashishkmr1]

Small correction in the problem statement. The cube has following dimensions - EXPENSE ITEM, YEAR, MONTH, STORE, SCENARIO (Actual, Plan etc)
My mind was somewhere else.

[Michel Zijlema]

Hi Ashish,

You can't use rules functions within the 'internal' (square brackets) rule area notation.
You need to use the 'external' notation - which means using DB() type of reference:

['TY Vs LY'] = N: DB(cubename, !EXPENSE ITEM, AttrS('DAYS',TODAY(1),'Financial TY'), !MONTH, !STORE, !SCENARIO) - DB(cubename, !EXPENSE ITEM, AttrS('DAYS',TODAY(1),'Financial LY'), !MONTH, !STORE, !SCENARIO);

But then, I'm still wondering why you're looking at days, while your cube contains data in months. I would think that setting the 'LY' attribute on your YEAR dimension and changing the rule to:

['TY Vs LY'] = N: DB(cubename, !EXPENSE ITEM, !YEAR, !MONTH, !STORE, !SCENARIO) - DB(cubename, !EXPENSE ITEM, AttrS('YEAR',!YEAR,'Financial LY'), !MONTH, !STORE, !SCENARIO);

would do the trick for you? This is a more generic rule comparing a chosen year with the previous year.


Michel

[ashishkmr1]

So as I understand, the limitation here is with ATTRS, not working with internal rule area notation.

Thanks for the response Michel. Let me try this out and see.

Thanks,
Ashish

[Michel Zijlema]

Hi,

There is an error in my last rule, as !YEAR in the first DB() function will always resolve to 'TY Vs LY'. So you need some way to indicate what this year is - that could be the function TIMST(NOW, '\Y') or a reference to a variable cube stating the current year. F.i.:

['TY Vs LY'] = N: DB(cubename, !EXPENSE ITEM, TIMST(NOW, '\Y'), !MONTH, !STORE, !SCENARIO) - DB(cubename, !EXPENSE ITEM, AttrS('YEAR',!YEAR,'Financial LY'), !MONTH, !STORE, !SCENARIO);

Michel

[ashishkmr1]

I had to use the DAYS dimension because of some limitations - one of them as you mentioned below is TY vs LY is an YEAR dimension element.
Any how, the break thru was I got to know the limitation, which when I removed as you suggested, everything worked fine. Thanks a lot for your help.

On a different note - where do I get information on such limitations? The help guides do not say such things.

Another question - For the same functionality the first thing that I had tried was a very specific rule for year 2010. So the rule that I had written was
['TY vs LY'] = ['2010']-['2009'];
2009 and 2010 are elements in YEAR dimension and they have their aliases as FY2009/10 and FY2010/11. When I try to compile the rule as above, it gives me an error that element name 2010 is ambiguous. But when I try the same rule with the aliases, it works fine. Can you pls help me understand why it does so?

Thanks,
Ashish

[kpk]

"['TY vs LY'] = ['2010']-['2009'];
2009 and 2010 are elements in YEAR dimension and they have their aliases as FY2009/10 and FY2010/11. When I try to compile the rule as above, it gives me an error that element name 2010 is ambiguous. But when I try the same rule with the aliases, it works fine. Can you pls help me understand why it does so?"

You probably have an '2010' and or '2009' element (or alias value for an element) in another dimension of that cube.

[Catherine]

Hi,

When an element name exists in 2 dimensions, you should prefix the element name with the dimension name. In your case:
['TY vs LY'] = ['YEAR':'2010']-['YEAR':'2009'];

Catherine

[kpk]

Hi,

When an element name exists in 2 dimensions, you should prefix the element name with the dimension name. In your case:
['TY vs LY'] = ['YEAR':'2010']-['YEAR':'2009'];

Catherine

You're right, although as far as I remember you don't need the apsotrophe around the dimension name.
['TY vs LY'] = [YEAR:'2010']-[YEAR:'2009'];

[Catherine]

Peter,
You're right. Sorry for the mistake!

[tomok]

You're right, although as far as I remember you don't need the apsotrophe around the dimension name.
['TY vs LY'] = [YEAR:'2010']-[YEAR:'2009'];

I think that's only true as long as your dimension name doesn't contain any blank spaces. If your dimension was named "FISCAL YEAR" instead of "YEAR" you would have to put the apostrophe there. I always use the apostrophe as just good practice. FWIW, I also NEVER use blank spaces in any of my TM1 object names either but a lot of people do.

[ashishkmr1]

@kpk
My first response was exactly what you have mentioned so I checked all the dimensions, elements and their attributes being used in the cube. But 2009 and 2010 are unique - they do not appear as alias or element in any dimension and so I was baffled. I could not overcome this error so in the end I just used one of the FY aliases for them. Any how, this is not critical for me at this point of time.

What I was more interested in now is where can I get some good stuff on such limitations as mentioned by Michel's first response?

I had another question but I am opening a separate thread for that.

Thanks,
Ashish

[Gregor Koch]

Hi
Just something for your consideration from a performance point of view:
With simple variances across years you are better off creating a consolidation (with negative weighting for one of the elements) in your Year dimension rather than writing a rule. Considering that your 'current year' most of the times doesn't change that often, once a year, the maintenance of this is also not that much work either.
Cheers