Forum Discussion
Thanks Paul, I think the UD8 calculation will not work because we have multiple hierarchies with different aggregation weights. Account type is also influencing the analysis. Right now I have found the difference, fortunately it was in the end 1 account where I could recognize the account value. We thought of a drilldown formula, but seems to have the same issue. Probably Jack's solution works best, but needs a lot of cube view rows.
- phollander2 years agoNew Contributor III
Hi Ben,
Makes sense to follow the path that Jack suggested, in case the account are available through multiple hierarchies and with different aggregation weights.
To avoid the setup of manual cube view rows, you could consider writing an XFBR function that you can use in your cube view. Conceptually you could:
- Pass through a top account in the XFBR function from where you want to build up the cube view;
- In the XFBR function, identify the children of the top account. At this stage, you know the parent of each child;
- Build a recursive function to get the children of the children, until you have reached base level. If the query calls itself, you will have to make sure you pass on the child as a parent, which allows you to work with the unique parent-child relationships;
- In the recursive function you can create a member filter where you would add the GetDataCell suggestion from Jack for each account and you can pass on the parent account as a parameter;
- End result would be a list of all accounts under a certain top account with the aggregation weights, relative to that structure.
With this approach you can avoid static rows in the cube view, but will not have any indentation (not sure if that would matter).
Regards,
Paul- BenvanBergen2 years agoContributor
Thanks Paul! That's a really good idea. I was think of trying a |MFAccount| filter to identify the parent automatically, but need to work on it. I didn't find the time to focus on it yet.
Related Content
- 8 months ago
- 6 months ago
- 8 months ago