@Pavankadambi and @vinayvm Sorry it took so long to get back to you on this. Hopefully, this answer is still relevant to your use case. This is a very common challenge with the product hierarchy, especially ones with many levels and many SKUs. Anaplan can handle them fine but it's really important that the lists and system modules be set up correctly for maximum efficiency. Using an arbitrary rule like the first 3 characters and the last 3 characters is clever but is not the most efficient. And it can run into problems with the 60 character limit. In this example, I'll show you that we can build the entire hierarchy without ever going over the 60 character limit for the name or the code. I'm going to suggest two alternatives for you. I'm only going to use 3 levels though as an example. You can extend these to 9. 1. Using flat lists 2. Using structured lists Lastly, I'll give a suggestion on the SKU level that should be implemented regardless of which direction you go. FLAT LISTS If you go with flat lists, which is typical for a data hub in Anaplan, you'll always need to load the parent in the system module. Just the parent. All the levels above parent can be calculated using formulas. 1. Create your lists top to bottom. Start with Level 1 then level 2 then level 3 and so on 2. Create one system module for each list you created. In our case we'll create 3. 3. Load only the parent and any specific properties about that list in the system module. 4. Note: SKU. This is my best practice but you may have your own. I always create a "reporting SKU Code" rather than using the EAN, UPC, or GTIN. The reason is because sometimes a new EAN has to be created for the same item to the customer. Even if there is a change to the SKU it's the same to the customer - plus you may want to replenish around the the reporting SKU not the individual EANs. I'll need a way to roll up those EANs to a reporting SKU. Trust me on this one, you'll thank me later! Here's our data for the lists Create your flat lists. the structured list is something that would reside in your spoke application. The data hub should only have flat lists. I'll show you why at the end when we build the structured lists. Now build your system modules. One for each List. Here's our data for the system modules For each module, you will only load the parent and any relevant properties about that list. For example, in the SKU system module I load the EAN and the GTIN numbers. Note that in the SKU system module I have the entire hierarchy! Let's create the structured lists now! STRUCTURED LISTS The structured lists can be built using the system modules we created above. Always start with the highest level and work your way down. Since the data hub is used to build the lists you don't need a structured list in the data hub. Everything you need is in the system module. Start by creating saved views for each system module that contains the information you need to create the list. We start with the department list, then style color, and finally the SKU. Here's the SKU saved view and the steps to create the list. When you load the structured lists you should always get the green checkbox! There should be no errors or warnings. Start by creating your saved view Then import your saved view into the structured list Map your line items to the corresponding list values. Make sure you get no errors.
... View more
