Version on List

romain_brabantvila

Currently, we cannot have versions on a list. It is a limitation that customers run into every day. Below is an example from Red Hat, Inc that demonstrates the challenge that this limitation creates and how having versions on a list could be a tremendous benefit!

 

Account Hierarchy:

L1 Geo

L2 Group

L3 Region

L4 Sub-region

L5 Managed Region

L6 Territory

L7 Global Customer Name

L8 Account

 

The main challenge is that by not having versions on a list, you cannot capture the L6 to L8 Territory Management movements that happened between versions because it can only sit in one place in the hierarchy.

 

Example:

In V1 GCN ABC is assigned to Territory 123 and rolls up to Managed Region 1. Then in V2 GCN ABC moves to Territory 456 and rolls up to Managed Region 2. Without versions on a list, you have to pick a spot for GCN ABC to sit in the hierarchy. If they are doing anything like GCN Level Planning or Territory Level Planning, targets will not sum up the hierarchy between version to version. It also means that they have to break the hierarchy for the imports from the data hub.

 

Current workaround:

In the Data Hub, they have created a list called "versions" that matches the same names of the real versions used in their Top Line Planning model. L1 to L5 System modules have no "versions" to them. They have two sets of system modules for L6 to L8, one that has the fake version list applied to it and one that does not have a version to it. When they load the data, they load the data into the "versioned" system module. Then, they have a drop-down on an admin module to select the current version. When they select a version from the drop-down, the Non Versioned system module will do a lookup to the versioned system module based on the list value they have selected. They are then importing whatever is considered the live version into Top Line.

 

The challenge:

They have two core datasets for Revenue that utilize this hierarchy that is versioned. In the Data Hub, they are loading the account level data then doing LOOKUP off of the versioned system modules. When they import into Top Line, they have to break the hierarchy. Instead of using native "parent" functionality, they have essentially hardcoded the import for each level of the hierarchy. If they did not do this, they would lose the total values in the previous version at the different levels of the hierarchy. The problem with this is that if you are not on the current version and sum the $ values from L6. You will get a different value at L5 and up through the native sum functionality in the hierarchy as if you were summing the L5 column. 

 

They are forced to break the connection because versions do not exist on a list.

 

ShekharGite

100% agree. Definitely needed.

Axel_H

Hi,

I believe many of us will face the complexity of having nested dimensions that are not constant over time, and would therefore be different on a version to version basis.

Although the idea seems to cover that, I'm not sure about the technical feasability of it, so keen to share my work around:

When I have dimensions where roll-ups are not constant over time, I do not build the parent/child relationship in the list settings. Instead, I use version and child list dimensionned module with the target parent as a parent-formatted line item.

Doing this means you're not able to use the native aggregations anymore between child and parent levels, but you have full flexibility over the child/parent relationship on a version basis.

You then need to work with SUM aggregations in order to sum up your numbers from 1 level to the next.

david.savarin

It's a common challenge of the main EPM Tool on how you manage dimensions changes and if / how you can manage "dimensions history".

wwood

Another vote for this functionality.

nikolay_denisov

I would add that it will be essential for reporting and especially in comparison reporting like variations analysis