02-08-2023 05:02 AM - last edited on 05-02-2023 10:23 AM by JackLacava
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.
Solved! Go to Solution.
02-08-2023 07:52 AM
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.
02-08-2023 07:52 AM
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.
02-08-2023 09:01 AM
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.