Rules Consolidation - Avoiding ConsolidateChildren

[image2x]

Hi,

New TM1 (v9.4) user here... I've been pulling my hair out for the last day on the following seemingly simple issue:

If I use a rule to assign a value only to "N:" level elements, consolidations of the impacted N-level elements should work without having to utilize a ConsoildateChildren function, right?

So, for instance, in a two-dimension cube with Sales and Month (Month defined as typical time hierarchy, i.e. FY->Q1/Q2/Q3/Q4, Q1->J/F/A etc.), if I insert:

['Sales'] = N:150;

It assigns 150 to each month. And, as long as I don't have "SKIPCHECK", the Quarter and FY consolidations are accurate.

BUT, as soon as I use SKIPCHECK, the consolidated parent cells have no value. As consolidated elements are supposed to sum the leafs by default, I don't understand why this is going on.

Any insights are greatly appreciated.

Thanks, -- John

[Alan Kirk]

Hi,

New TM1 (v9.4) user here... I've been pulling my hair out for the last day on the following seemingly simple issue:

If I use a rule to assign a value only to "N:" level elements, consolidations of the impacted N-level elements should work without having to utilize a ConsoildateChildren function, right?

So, for instance, in a two-dimension cube with Sales and Month (Month defined as typical time hierarchy, i.e. FY->Q1/Q2/Q3/Q4, Q1->J/F/A etc.), if I insert:

['Sales'] = N:150;

It assigns 150 to each month. And, as long as I don't have "SKIPCHECK", the Quarter and FY consolidations are accurate.

BUT, as soon as I use SKIPCHECK, the consolidated parent cells have no value. As consolidated elements are supposed to sum the leafs by default, I don't understand why this is going on.

Because if you use Skipcheck, you also have to use feeders. Take a look at the Rules manual which explains what they are (essentially, they send a "flag" to the cell telling TM1 "you need to calculate this"), and how they're implemented.

Non-appearing consolidations are the usual symptom of unfed calculations.

If you need any specific advice relating to them, feel free to post again.

[image2x]

Thanks... I read somewhere to get your rules working first and then worry about your feeders but it sounds like they are mandatory to ensure consolidations happen correctly.

So is there a catch-all feeder assignment in the case of an element that doesn't have any dependency on another element?

[Alan Kirk]

So is there a catch-all feeder assignment in the case of an element that doesn't have any dependency on another element?

Short answer "No", longer answer "I'd suggest considering whether you should be using a rule at all in that case, or whether you should just be populating the cell(s) with values".

[image2x]

Roger that... Thanks.

[lotsaram]

Thanks... I read somewhere to get your rules working first and then worry about your feeders

Well errm yes in principle, but NO in practice. Writing rules without SKIPCHECK in effect makes the cube dense, which means TM1 needs to look in each and every cell to perform aggregations. In other words it turns a Ferrari F1 into a Model T.

In a small cube you can get away without feeders but once you have cubes with greater dimensionality or one or two large dimensions then not having SkipCheck (or overfeeding for that matter) is a real performance killer. It is not uncommon to see calculation performance gains of several hundred times between rules with no SkipCheck vs. properly fed calculations.