TM1 Forum

simple example:

Cube 'cActual' with Dimensions Year, Month, Keys
Cube 'cPlan' with Dimensions Year, Keys
Cube 'cDistribution' with Dimensions Year, Month, Type

Rule in Actual: but how to feeder?

At first, it's obvious to feed in the plan-cube, but how to match the missing dimension month?

Do I need to set 12 feeder, so that every single month is fed(, due to arrays with { } are not available in feeder-target)?
or is there another way to aggregate this feeder?

proggi wrote:simple example:

Cube 'cActual' with Dimensions Year, Month, Keys
Cube 'cPlan' with Dimensions Year, Keys
Cube 'cDistribution' with Dimensions Year, Month, Type

Rule in Actual:

Code: Select all

['plan']=DB('cPlan', !Year, !Keys)*DB('cDistribution', !Year, !Month, 'typeLinear');

but how to feeder?

At first, it's obvious to feed in the plan-cube, but how to match the missing dimension month?

Do I need to set 12 feeder, so that every single month is fed(, due to arrays with { } are not available in feeder-target)?

Code: Select all

['Plan']=>DB('cActual', !Year, 'Jan', 'Actual');
['Plan']=>DB('cActual', !Year, 'Feb', 'Actual');
...

or is there another way to aggregate this feeder?

If you just want to feed all months, you can feed all child elements of a consolidation by feeding the consolidated element. Eg assuming "Jan", "Feb", "Mar" etc are all children of "All Months", you can do something like this:
Alternatively you can write the LHS of the feeder once and only the RHS twelve times with something like this:
Of course both will overfeed if the value for the month in "cDistribution" is zero.

edit: typo

Thanks!!

Too bad, as I have several Dimensions providung no consolidation by purpose. Seems to be senseful to implement consolidations for technical use only...

May I know why you can't create consolidation in such dimensions?

In our planning model we actually make quite a lot of use of consolidations that serve no calculation or reporting purpose but are there purely to send or receive feeders to the N elements they roll up. I think this is entirely valid use of consolidations from a design and model efficiency POV. Such "technical consolidations" can always be hidden from end users with element security.

Intelligent use of such consolidations can make rule maintenance a lot easier as all that is required to "update the rule" is not to update the rule but to do a simple structure change in the relevant dimension with the technical consolidation. (note a reprocess feeders might be required if going from a less to more feeders situation.)

to kempzhong: for example in Month are data by timestamp like 'actual stock', so you can't sum them up to a full year sum (...and if user see a consolidation they'll use it...)

to lotsaram: to use consolidation for technical purpose and hiding them for endusers sounds good to me and appears to be a useful approach. (Gives me a good feeling to do so... )

Thank you very much

Just check that you don't have this situation here - Re: TI load data with delayed rule and feed recalculation.

If you are feeding from many source cells to each consolidated cell, and that consolidated cell is propagating down to many target cells your feeder load times could increase dramatically, which could also affect dimension save and rule save times.

Indeed Duncan P. Feeding to consolidations (hence feeding all lowest-level children) might not be a good approach in many cases.
Certainly not feeding consolidations in 2 or more dimensions in any cube that is not trivial.

Writing feeders can sometimes be an art, you know. It requires one to think outside the box.
For example, feeding in a completely different way and starting from other elements.
Or feeding conditionally.

Or even using a (hidden) "Feeder" measure (filled with the value 1 through TI) that fires off feeders...
This is not as "easy" as the usual feeders logic (i.e. just reverse the rule logic) but your application will benefit heavily.