Rule On consolidation which matches the natural consolidation

[MarenC]

Hi,

I have inherited a model which includes a rule that puzzles me and wondered if anyone may know of a use case for what I am seeing.

In a dimension there is a consolidation called "Parent" which comprises 3 children, "Element 1", "Element 2" and "Element 3", all with weight 1.

There is a cube which includes the above dimension, with the following rule:

Code: Select all

['Parent'] = ['Element 1'] + ['Element 2'] + ['Element 3'];

Is there a situation where it is necessary to have a rule which matches the consolidation?

Maren

[Wim Gielis]

Interesting question.
I take a guess: a cube with rules at level 0 for these elements and without skipcheck and feeders ?

[Wim Gielis]

Or, child weights in the parent are not all 1 for some reason (different cube maybe) and here you need the sum where weights equal 1.

[lotsaram]

Or, child weights in the parent are not all 1 for some reason (different cube maybe) and here you need the sum where weights equal 1.

But this you could resolve just with another rollup with different weights.

[MarenC]

Hi,

I don't think the weights are relevant as they are all 1, and lotsaram said, why would it be an issue?

Code: Select all

a cube with rules at level 0 for these elements and without skipcheck and feeders

Skipcheck and Feeder are included in the rule. There is an n level rule for the children, but they are complicated and there looks to be feeder statements in place for the children (but these are DB(If...) type feeders).

Maybe someone wasn't convinced by the feeders so put these rules in as a backstop? Does that even make sense?

Maren

[Wim Gielis]

Or, child weights in the parent are not all 1 for some reason (different cube maybe) and here you need the sum where weights equal 1.

But this you could resolve just with another rollup with different weights.

Correct but then elements are named differently, element security might need to be set up, reporting / dashboarding could change. Maybe a quick and (very) dirty way to “solve” it. As weights are 1 anyway it cannot be the reason though. Just wanted to add it as a potential reason.

[Elessar]

Hello,

I cannot see "N:" here. So I assume this rule is needed to override calculations on C: level

[MarenC]

Hi Elessar,

I cannot see "N:" here. So I assume this rule is needed to override calculations on C: level

That's a good thought, but if I comment out the rule, then the value just uses the consolidation and doesn't revert back to another rule.

I.e. trace cell just says consolidation and not any defined rule, and the value remains unchanged.

Maren

[ascheevel]

If I had to guess, 'Parent' used to be a leaf element and someone used that rule to make it the sum of the 3 other elements. Someone else came along later (or same person got a tiny bit wiser) and decided to make 'Parent' a real consolidation with the 3 as children and then forgot to remove the original rule.