目前，我们不能在列表上有版本。客户每天都会遇到这是一个限制。下面是Red Hat，Inc的一个例子，证明了该限制会产生的挑战以及在列表上拥有版本的挑战可能是一个巨大的好处！帐户层次结构：L1 GEO L2组L3区L4子区域L5托管区域L6区域L7全球客户名称L8帐户主要挑战是，通过在列表上没有版本，您无法捕获L6到L6到L8领土管理机芯版本，因为它只能坐在层次结构中的一个地方。示例：在V1 GCN中，ABC被分配到领土123，然后滚动到托管区域1。ABC坐在层次结构中。如果他们正在做类似GCN级别计划或领域级别计划之类的事情，则目标将不会概括版本之间的层次结构。这也意味着他们必须从数据中心中断导入的层次结构。当前的解决方法：在数据集线器中，他们创建了一个名为“版本”的列表，该列表匹配其顶线计划模型中使用的真实版本的相同名称。 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.
。。。View more
