Character limit of 60 on Anaplan code - Possible solution to address the issue required
Hi,
My Anaplan model contains an SKU hierarchy roles up to the top with 9 different levels... The codes for each of these levels are concatinated from the top level
| Levels | Level Codes |
| Level 1 - Organisation | Concatination of first and last 3 digits of Level 1 name |
| Level 2 | Level 1 + Concatination of first and last 3 digits of Level 1 name |
| Level 3 | Level 2 +…...so on |
| Level 4 | |
| Level 5 | |
| Level 6 | |
| Level 7 | |
| Level 8 | |
| Level 9 - SKU |
In the process of concatinating as mentioned above we are facing a challenge on the restriction on character limit of 60 on codes..Any suugestion on best possible way to address this issue would be of immense help
Answers
-
Really good question.
The relationship between your hierarchies should be maintained in system modules even if your lists are flat.
By doing that you won't need to concatenate the ID together.
So instead of 1000001-10000003-100000006
You would just have 1000000006.
Each level of the hierarchy will have it's own system module, a module that has one dimension.
Each system module would have the relationship mapped there.
Check out the DISCO methodology.
https://community.anaplan.com/t5/Best-Practices/Best-Practices-for-Module-Design/ta-p/35993
If you need an example illustrated in Anaplan, let me know. This is a very popular challenge.
3 -
@JaredDolich Thanks a lot for your response.
It would be more insightful if you can show us with an example please
@Vinay VaradarajM adding you to the thread
0 -
@PavanKadambiMohan and @Vinay VaradarajM
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.
6 -
Hi Jared,
Great overview. One thing I've noticed and had Anaplan come back to me on is the fact that if you're loading in a hierarchy, the codes of members between the hierarchy must still be unique or it'll throw an error.
An example is if an item in P2 and P3 have the same ID, on integration it'll have a fit when loading into P3 because it'll assume that you're trying to force the P2 members into the P3 hierarchy.
Raised with Anaplan about a half year ago and they said it was expected functionality and to concatenate... of which I don't agree with, but unsure whether that's still their stance now.
0 -
Thanks for a comprehensive explanation!
It is indeed a great approach to build hierarchies in the way you showed in the example. However, there is one more element of complexity in our hierarchies.
To describe better, I will continue with the same example of yours: Dept > Style color > SKU.
In our scenario, we have a same color coming under two different Depts. i.e., color "Anaplan Way Blue" comes under Depts "Anaplan Way" and "DISCO" (might sound a little weird, but that's the way data is organized in this use case)
1. Anaplan Way > Anaplan Way Blue
2. DISCO > Anaplan Way Blue
So, even though it is the same color, we are having to create two unique color codes in accordance with the Depts. Hence, we had to resort to concatenation of the parent and the level below it (eventually the codes spilling over 60 char).
Please let us know if you have experienced a similar issue, and the subsequent approach you took to overcome it..
Best Regards,
Vinay
1 -
In your case, then you would have to use a Numbered list with the concatenation of the codes, but that doesn't mean you have to use the concatenation on all levels. Your use case is not unique and in most cases, the bottom or last level is only repeated within the hierarchy. In this case, use concatenation of the codes at the bottom level. So, the first 3 levels would be a standard composite hierarchy and the last level would be a numbered list with the code being parent of the code_code of the member.
Hope this helps,
Rob
0 -
In my case, the repetition can happen at all of the 7 levels in the hierarchy (Color, Finish, Profile, Product Category etc..) apart from the top level and bottom level (which is SKU).
The Color, Dept. is just a mock-up example which I considered to explain the case.
So, in such cases, please let us know if there's a possible solution.
Best Regards,
Vinay
0 -
If that is the case, then concatenation is the only way to go. To get around the 60 character limit, have you thought about having an "Anaplan" code? This is how it would work...In your flat lists, you would have the real code from the source system. In the SYS Properties module for that list, you would have an "Anaplan" code to which you would use for the hierarchy code. For example, in your Product Category Flat list, say a members code is 1000000000009, but in Anaplan, the "Anaplan" code would be 10. The SKU flat list, a member from the source could be 20000009, but in Anaplan, the "Anaplan" code would be 20. So, in the Anaplan hierarchy, the code would be 10_20.
And if you needed to export the data out of Anaplan, then you could always refer back to the flat list to get the true source code.
Hope this helps,
Rob
1 -
The issue is, codes are not available for any level (apart from the SKU level). In my case, I just have the names of the entries. So, I am having to create codes.
Regards,
Vinay
0 -
If you don't have a SKU code, then how are you going to get the transactional data into Anaplan? Where is the SKU data coming from, the actual source system with the transactional data? If it is like 99.99% of all source systems, they have a code. This might not be available to you right now, but IT will certainly have it. Ask them to redo exports to include that.
Rob
0 -
Out of the nine levels of product hierarchy, I have codes only for SKU level. For rest of the levels, there are no codes, but only names. Sorry if I was not clear in my earlier message.
Regards,
Vinay
0 -
There has to be a structure that you are attempting to create/mimic from the source system. If not, then how would you know which SKU rolls up to which Product Category?
Rob
0
