TM1 Forum

Hi

I'm fairly new to rule writing in TM1 and have a question about some rules in a system I'm working on.

In some of the cubes there are rules written as follows :-

[{'010112','010114','010115'}] = N:DB('PandLCube',!Nominals,!Year,!Month,!Version) * 0.7

The idea is to populate the three nominal codes on the left with 70% of the values from the the same Nominal Codes in the PandLCube.

My question is would it be better to use a consolidation of the Nominal Codes in their dimension and rerwrite the rule as :-

[] = N:DB('PandLCube','My Consolidation',!Year,!Month,!Version)*0.7

There are some rules with many (up to 50) nominal codes on the left side of the rule. My reasoning is that it will be easier to maintain if I use a consolidation when new codes are added.

Is there some specific reason for listing the codes on the left or is using a consolidation on the right an accepatable method?

Thanks

The above rule will populate ALL N cells in this cube with the value pulled from corresponding C cells at the intersection with the 'My Consolidation' element. This is NOT what you want to achieve, is it?

It would be advisable to create an attribute (numeric or text) and use it in the rule together with an IF statement to pull the data for those nominal codes for which this attribute takes a certain value. The same thing can be achieved using your consolidation in the following way:
Replace the part between the hash signs with a condition that checks the attribute value to get the solution described above. I'll give you the chance to figure out the syntax yourself.

Hi

Thanks very much for the reply qml. Very useful.

I thought the elements of the consolidation would be used but as you say it picks up the consolidation itself.

I've tried using ELISPAR and it works fine.

I also had a go at using an attribute as follows :-

[] = N: IF(
ATTRS('Nominals',!Nominals, 'Account Type') @= 'Fees',
DB ('PandLCube', !Nominals, !Year, !Month, !Version) * 0.7,
STET);

Where 'Fees' is the attribute I want in the attribute 'Account Type'

This works fine as well. Now I just need to decide which method to use!

Thanks for your help.

David

No problem, that's what this Forum is for.

I just have one more thing to add.

If you want to get good performance you should look at using SKIPCHECK and FEEDERS, which can be a tricky task in itself. To start with, you will need to write the feeders in the source cube's rule file. And it can be a headache if the dimensions are not the same in both cubes. There are plenty of threads on this subject if you search the Forum.

Ok thanks.

I've had a little go at skipcheck and feeders but my knowledge is not too great.

I'll have a browse through the forum and learn some more!

David

You can start by reading the appropriate part of the documentation:

http://publib.boulder.ibm.com/infocente ... ers_N80007

In short, any rule attached to a cube will make this cube work slower by turning the default sparsity algorithm off. You can switch it back on using the SKIPCHECK keyword, but then you are also forced to create feeder statements in order to get correct results.

This is quite a unique concept that gives the developer incredible power over the inner workings of his application, but it's not always easy to get this part right. However, there's really no way around it if your application has any big & sparse cubes and more than just a few users.