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

Accepted answers

All comments

JaredDolich

@PavanKadambiMohan

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.

PavanKadambiMohan

@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

JaredDolich

@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.

wquan

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.

Vinay VaradarajM

@JaredDolich

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

rob_marshall

@Vinay VaradarajM ,

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

Vinay VaradarajM

@rob_marshall

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

rob_marshall

@Vinay VaradarajM ,

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

Vinay VaradarajM

@rob_marshall

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

rob_marshall

@Vinay VaradarajM ,

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

Vinay VaradarajM

@rob_marshall

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

rob_marshall

@Vinay VaradarajM ,

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

Quick Links

Can you help?

Unanswered questions

Workaround for Formula & Closing Balance summary methods together in Polaris
Hello folks, Does anyone know how to work around the Polaris limitation of using the Formula or Ratio summary method alongside the Closing Balance within the same line item? I have a Business Unit list where the total (All BUs) must display the Corporate (1 of 20 leaf items under All BUs total) number of Unique Customers.…
AnaplanXL Difficulties
Has anyone found success using Anaplan XL with Polaris models in a shared drive with or without concurrent users? My team has experienced a variety of errors, login failures, etc. sometimes it works, sometimes it doesn't. We've been recommended to save and edit files locally, which helps but certainly with its limitations…
Looking for Anaplan End-Users to take a short survey!
We are looking for Anaplan end-users to provide feedback on their experiences with the Excel add-in. Interested individuals will respond to this 5-minute survey to help us understand personal needs and behavior when using the add-in. The feedback provided by survey takers is essential to the roadmap of Anaplan's products.…