List Inheritance

[Nicolas Cadier]

Where lists are in a hierarchy, it would be really helpful if Anaplan natively understood the concept of inheritance.

Here's an example. Consider two lists in a hierarchy:

• L1 Countries
• L2 Cities

L1 Countries is the parent to L2 Cities.

Within an attributes module, each L1 Countries list item is assigned a currency.

Let's say you want to assign a currency to each L2 Cities list item. The current method would be to use a LOOKUP formula against the L1 Countries list item of each L2 Cities list item.

I would like to see Anaplan natively understand that London's parent is UK, and thus return GBP without the LOOKUP.

[DavidSmith]

@Nicolas Cadier 

Just interested to ask, would you envisage the need to inherit that values for grand parents, or great grand parents, for lists with more than 2 levels?

If so, how would you want to inform the result which level to use?

David

[Nicolas Cadier]

@DavidSmith 

To avoid daisy chaining per level I think that grandparent (or greater) list items should be able to be inherited from.

If you had a hierarchy with many levels, the inheritance should reference the level that the formula references. Expanding on my example above:

Lists

• L1 Country
• L2 County
• L3 City

Modules

• Country Currencies
  • L1 Country with one line item, 'Currency'.
• City Details
  • L3 City with many line items, one of which being 'Currency'.

Formulae

• City Details.Currency
  • The formula is simply Country Currencies.Currency.
  • Anaplan recognises that L1 Country and L3 City are in the same hierarchy and derives the relationship as defined above, ignoring any data against L2 County.
  • The formula summary method could operate on the same basis, applying a LOOKUP between L2 County and L1 Country, returning the correct currency for each L2 County list item.

Hope that makes sense.

[DavidSmith]

@Nicolas Cadier 

A common occurrence is for the L2 member to have a different currency (often in financial consolidations). 

How would you expect to Anaplan to handle that situation?

David

[Jared Dolich]

@Nicolas Cadier 

I like where you're going with this and I guess it saves one step of creating system module which you could look up the parent/grandparent/etc.. value.

As a matter of habit though, every time I create a list, I almost always create a system module to go with it which makes looking up the parent values pretty straight-forward.

But there's something about the idea of inheritance that might prevent us from having to build a separate line item in each module, like the "currency" example you used. Where I might want to develop this idea is around the concept of overrides. Some overrides are simply to sort out the list items for classification purposes. If there's a way to avoid the Booleans and extra line items to handle overrides that might be something worth developing.

Not sure how that would work but intuitively the concept of inheritance makes sense.