Forum Discussion

Montreux's avatar
Montreux
New Contributor III
2 years ago

C#aggregated and business rules

I have a business rule that requires referencing aggregated divisional (entity) data several times over the course of the rule.  Base level entities run their rules and at a point in the rule, the entity needs the aggregated divisional result and so a consolidation to division.

Can the data management jobs for consolidation have the consolidation filter set to C#Aggregated and the rule get the correct aggregated divisional numbers from the consolidation?  Or, is C#Aggregated only for data reporting?  Does the rule POV need to use C#aggregated when referencing divisional entity data or can this left out of the rule? 

I have run some tests and the answer seems to be yes, DM jobs with C#aggretated produce data that can be referenced in rules and no, the rule does not need C#aggregated in its divisional entity POV.  Can anyone comment on this more?  Thanks.

Finance
  • ChristianW's avatar
    ChristianW
    2 years ago

    I don't see any reason, why it shouldn't. C#Aggregated stores the data like any other condolidaion member. Attention, you need to run a consolidate or force consolidate on the Aggregated member to get any data.

    It isn't a dynamic aggregation.

    So in your case, you need to be sure, that before you run any condolidation on the c#local member of a parent entity, you need to run a consolidation on the aggeregated member.

    In most cases, a better solution might be to store the aggegated informaiton on a dummy account.

  • ChristianW's avatar
    ChristianW
    Valued Contributor
    2 years ago

    I don't see any reason, why it shouldn't. C#Aggregated stores the data like any other condolidaion member. Attention, you need to run a consolidate or force consolidate on the Aggregated member to get any data.

    It isn't a dynamic aggregation.

    So in your case, you need to be sure, that before you run any condolidation on the c#local member of a parent entity, you need to run a consolidation on the aggeregated member.

    In most cases, a better solution might be to store the aggegated informaiton on a dummy account.

  • Montreux's avatar
    Montreux
    New Contributor III
    2 years ago

    Thanks for the reply.  Yes, I realize C#Aggregated isn't a dynamic (automatic) aggregation.  It requires a consolidation with a data management job and setting the Consolidation filter from C#Local to C#Aggregated.

    I am not sure I would ever need to use the C#Local dimension for consolidations once I use the C#Aggregated.  I would one C# or the other.  All cubeview reports that could show a consolidated entity would need to have the Cons filter at C#Aggregate.  I leave the Cons filter at Local almost always now but always consolidate to C#Local.

    I don't know what benefit I get from a dummy account here.  Would this take the place of using the C#Aggregated?  I am using C#Aggregated to speed up my calculation/consolidation time.