Create Hierarchial list using import

Highlighted
Occasional Contributor

Create Hierarchial list using import

Hi,

I am trying to create a list as shown in the attached image. Here i have'nt created the seperate list for 5804 (which is like parent list). To avoid sparsity & size constrain, i am trying to create parent & child list in the same list. I know how to create in the tool for less items. Can someone tell me how to use Import data to create such list with bulk data.

 

Thanks,

Sangeetha

 

 

3 REPLIES 3
Highlighted
Certified Master Anaplanner

Re: Create Hierarchial list using import

Hi,

 

This response includes the following assumptions:

  • the parent list is Product and the Child list is Project.  This type of parent/child list relationship is called a composite hierarchy (see anapedia for more, search 'lists', then click on composite hierarchies.)  Note that having these items in two lists (as a composite hierarchy) offers some natural controls, and I recommend a composite hierarchy over a single list.
  • Project (child) list can include duplicates (i.e. a project may need to be under multiple Products)
  • (if the above two items are in reverse order (i.e. Projects is the parent list, and products is the child list, then just reverse the terms... the solution is the same).
  • Solution:
    • In this case, the nature of the Parent list (numbered or not numbered) is usually inconsequential (and can be whatever you need it to be... numbered or not numbered)
    • The child list, in order to contain duplicate projects, must be numbered
    • I recommend that the process that adds new projects include the writing of a CODE value, if possible, that is a concatenation of Parent & Child... such as 5804.0000
      • If the administrator (or a scheduled process) controls the adding of projects to parent products, then include a code... its a simple way to ensure the projects under each product are all unique.
      • If the process for adding children is controlled by end users, then writing a code to the list in production may not be practical/advisable.  In this case, the users would have a dashboard to add (project) records under Product Parents... and the related module would have line items to define the project.  the module where end users define the project can also be the source for the child list's Display By value... so, as parent/child relationships are defined, the hierarchy begins to display them wherever else the (composite hierarchy) is used.
        • When end-users are defined items in the child list, which is usually ok & controllable, there will, commonly, be the following:
          • Additional attributes of the project entered in the same place as the project is added to the list
          • at least one other module where monthly values are either calculated (based on project level data entered above), or manually entered.  
      • Anapedia has a lot of info on using numbered lists, won't bore you with that here.

Fun Stuff!  Note that the basic process outlined here is a common thread in many diverse use cases.  I'm an FP&A person, and we use regularly use this type of approach for Staffing Plans, Capex, ZBB/transaction level inputs, etc.

 

There are some nuances that you probably be challenged with, but they are relatively minor and tend to vary by client.

 

Regards,

 

Paul

Highlighted
Occasional Contributor

Re: Create Hierarchial list using import

Hi Paul,

 

Thanks for the detailed explanation. Its quite clear & i have created the list by creating code which is a combination of Parent & Child. Its working now. But only issue is my module size has been increased to 16 million cells after using this list for the module. i can't create subset here. Becuase products & projects are not static & fixed.

 

Thanks,

Sangeetha

 

Highlighted
Certified Master Anaplanner

Re: Create Hierarchial list using import

Hi,

 

16M cells, relatively speaking, isn't very big.  Notwithstanding, if you're only loading the combinations you need, then you should be ok.  If you loaded all possible combinations, then it defeats the purpose of using Composite Hierarchies.

 

Cheers!

 

Paul