Allow un-balanced hierarchies on composite hierarchies for child hierarchies

alexpavel

As a model builder, I would like to be able to add "parent" elements into the child hierarchies (Level 2, 3, etc.).
As for now, in a child hierarchy is allowed only to add leaves elements (elements without children) because as "parent" are allowed to be set only elements from the parent hierarchy.

As for now, the unbalance elements can be created only in the Top hierarchy (Level 1).

Imagine this scenario: You have a 4 level hierarchy built and the client asks you that some of the 4th level elements need to be grouped under a new parent.
In order to do this, in the Level 3 hierarchy, it is needed to be built the parent element that is needed but also another dummy parent to group the other elements.
For the client is not acceptable to be seen in reports this "dummy parent" for the other elements.

Of course, there are some workarounds to solve the hiding of the "dummy parent", but it would be simpler just to accept that in level 4 hierarchy to create the parent element and setup under this element all the desired Level 4 children.
The parent hierarchy would be respected, because, in the end, at some point in the hierarchy path, the elements from the child hierarchy will have as a parent an element from the "parent hierarchy".
Of course, it is needed to be respected the constraints that, when you need to choose a parent from the "parent hierarchy" it is needed to be a "leaf" (element without children).

This will give much more flexibility to the already very good way of organizing the lists.
There will be some things to figure it out like what will be returned by the function PARENT when a line-item is formatted as "Parent hierarchy". An idea is to return the first ancestor from the Parent hierarchy.

Is there any technical constraint that needs to be respected in order to accept this kind of flexibility?

Thanks
Alex

Miran

Status changed to: New

Noemi.andres

@alexpavel this is a great idea! It would be useful as this situation happens often and having an extra level of the composite hierarchy is not always the most efficient/best-looking solution.

 

As you say there are some current functionalities that would need to be revisited as basically this change would mean mixing properties from ragged hierarchies and composite hierarchies. The example you've put for retrieving the PARENT would clearly be a big debate. For me, the ideal situation would be to have the option of telling Anaplan which PARENT you are referring to, so by using an extension of the PARENT function to determine if it's the ancestor parent or the next levels' parent. The idea of making it fixed to one of them only does not seem dynamic enough. 

 

Another functionality which would need to change is the selecting the levels to show option. However, if Anaplan treats the extra children as the top level item (so as an extra "level" within the lowest level of the composite hierarchy) then this would work fine as it would allow you to choose which level to show from the lowest level of the hierarchy too.