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.
