TM1 Forum

Hi, all
The following is the rule for a Enrol Ratio cube. It is getting base ratio from a Ratio cube by doing it at upper level of program. I am wondering if the feeder is right or not and over-feeding?

macsir wrote:Hi, all
The following is the rule for a Enrol Ratio cube. It is getting base ratio from a Ratio cube by doing it at upper level of program. I am wondering if the feeder is right or not and over-feeding?

Code: Select all

SKIPCHECK;
['Enrol Ratio'] = DB('Ratio',!Scenario,!Location,ELPAR('Program',!Program,1),!Course,'Base Ratio');
FEEDERS;
['Base Ratio'] => DB('Ratio',!Scenario,!Location,'All Programs',!Course,'Enrol Ratio');

You are very likely to overfeed if you are feeding a consolidation, remember all the children underneath will be feed .

EvgenyT wrote:

macsir wrote:Hi, all
The following is the rule for a Enrol Ratio cube. It is getting base ratio from a Ratio cube by doing it at upper level of program. I am wondering if the feeder is right or not and over-feeding?

Code: Select all

SKIPCHECK;
['Enrol Ratio'] = DB('Ratio',!Scenario,!Location,ELPAR('Program',!Program,1),!Course,'Base Ratio');
FEEDERS;
['Base Ratio'] => DB('Ratio',!Scenario,!Location,'All Programs',!Course,'Enrol Ratio');

You are very likely to overfeed if you are feeding a consolidation, remember all the children underneath will be feed .

Yes, I know but how to improve it? Any idea?

Im not sure if this approach would suit your model, but you could create Feeder Consolidations in Program dimension to get more precise feeding

EvgenyT wrote:Im not sure if this approach would suit your model, but you could create Feeder Consolidations in Program dimension to get more precise feeding

Thanks but what do you mean by Feeder Consolidations? Could you give me a general example?

Why do you feed this calculation? You have a rule at C level, which overrides the default aggregation algorithm in TM1.

Wim Gielis wrote:Why do you feed this calculation? You have a rule at C level, which overrides the default aggregation algorithm in TM1.

You are right Wim, sorry I overlooked the calculation statement.

Wim Gielis wrote:Why do you feed this calculation? You have a rule at C level, which overrides the default aggregation algorithm in TM1.

If no feeders, all the C level program of Enrol Ratio will be unfed?

Sorry for the confusion, I think the complete code is the following and the value in Assumption cube is not zero.

Ok, I think I have got it. The following code should be fine. The reason I am using the root element 'All Programs' is that in the rule, there are other ELPAR , such as ELPAR('Program',ELPAR('Program',!Program,1),1) etc. which across all the level of this program dimension. That's why I am using the root consolidation to feed all the programs.
But in order to get better performance, I would like to try attribute rather than ELPAR in the rule.

Is this rule writting the Ratio cube, or a different one?
If different, what is the dimensionality?

Since someone has mentioned feeding C level calculations I think I will just pop this reference in as a reminder of the complications

Supress Zero and FEEDERs.

Wim Gielis wrote:Is this rule writting the Ratio cube, or a different one?
If different, what is the dimensionality?

It is the ratio cube.

Duncan P wrote:Since someone has mentioned feeding C level calculations I think I will just pop this reference in as a reminder of the complications

Supress Zero and FEEDERs.

Thanks, duncan. I have checked that.

macsir wrote:Ok, I think I have got it. The following code should be fine. The reason I am using the root element 'All Programs' is that in the rule, there are other ELPAR , such as ELPAR('Program',ELPAR('Program',!Program,1),1) etc. which across all the level of this program dimension. That's why I am using the root consolidation to feed all the programs.
But in order to get better performance, I would like to try attribute rather than ELPAR in the rule.

Code: Select all

SKIPCHECK;
['Enrol Ratio'] = DB('Ratio',!Scenario,!Location,ELPAR('Program',!Program,1),!Course,'Base Ratio') * DB('Assumption','Medium Program Weight','value');
FEEDERS;
['Base Ratio'] => DB('Ratio',!Scenario,!Location,ELPAR('Program',!Program,1),!Course,'Enrol Ratio');

I have finished testing with attributes. And it does take less memory and better performance than ELPAR in the rule. Next time, if that is the case, I will use attributes directly.