Hello Nitishkrish16 ,
I am interested to hear what others have to say on this. If this is something they use multiple times, would it be better to just create an alternate hierarchy for the aggregation of those specific accounts? That way the client can also adjust it in the future easily.
Just a thought,
Ben
This is really the right answer. As soon as one has to manually define 100 rows in a CV, one is in "we're doing it wrong" territory. It's better to create an alternate hierarchy; as well as being easier to reference and maintain, it will likely be faster to display in Cube Views.
Agreed, although I am not sure if the 100 row count in a Cube View was just an example or a real-life case, as that would be quite an extreme amount of rows for one definition. One issue with the use of an alternate (account) hierarchy is when the underlying children are set up as DynamicCalc. In that case, I believe you will need to have a DynamicCalc on the top parent of the hierarchy to sum of the retrieved amounts of its children (might be different ways of dealing with this, but the point is towards DynamicCalc as part of a roll-up).
For most use cases, using an alternate hierarchy is the way to go.
Hi BenThompson ,
This is such an amazing idea!! But, few accounts used here are dynamic. So it would create complexities if the alternate hierarchy is created. Thanks a lot for your input 🙂
