Here is the new system modules I'm building for the AU Hierarchy: FQA SYS07 Exp Mgmt L3-AU.
I would also like to use the new System module created above to build out the AU hierarchy. I'm trying to now bring in the Parent (AU L2) of that AU Number Flat from the original System Module (FQA SYS01) but running into the following error:
Thanks for that reminder. I was using our current Flat List and we didn't have properties setup in our current flat list so I had forgotten about that. I went back and created the Properties for the attributes and am now able to bring that into the System module.
I have the following two questions that are related as well.
1) We are in the process of updating the Codes for our lists. If the list is going to be part of a hierarchy list, should the code include the Parent Code in front of it with a hyphen or can we leave it just as a single code? If including the Parent code, could you help me understand why? We may add new L3 in the future and are trying to figure out a best way to maintain the process of creating a code so would prefer having a single code vs. including the parent in the code as well. Our preference is Option B but want to do Option A if that is the best practice and we understand why.
Please see example below:
2) List Properties: I understand Flat list should not have properties and it should only have a Parent code so that it can be used to generate a hierarchy list. What is the best way to bring in a property line item from the Data System Module into the List System Module to capture the property?
Ok, let's hit these in order (by the way, good questions):
Should you append or prefix the code with the parent. In a flat list (call it Cost Centers), no for the very reason you stated. Now, in the composite hierarchy, the answer would be a yes especially if you are using a numbered list so you know where you are in the list. In the 305 video, I believe I have a flat list of cost centers and then I have a SYS module where I am importing the parent.
Now, when I build my composite list, I can use the code of the parent with a delimiter concatenated with the code of the member.
Really, you shouldn't be using properties in a list period, except if they fall into one of these exceptions (Planual Rule 1.05-03) and Display Name for a numbered list. There is one other exception that @jasonblinn found, but since that is on the Old UX, I will refrain. So, this should be your order of operations:
Load the list (in this case Cost Center Flat)
Load the properties or metadata to a. SYS module
Create a module, using the Cost Center Flat list), to derive your composite hierarchy (this is where the 305 video comes in).
This is mandatory if you update the lists via an import action.
Strange enough: If you update manually a list, Anaplan accepts the same Code or Name in the Details list identical to the Parent....but not via automation through an import action.
If both parent and details codes are numeric values, there is a chance that the parent code would be present also in the details codes and you will receive an error when you update the lists.
From your example, it seems that Parent codes are alphanumeric (letters) and Details codes are numeric (only numbers)... In this particular case I do not see the reason why you should concatenate in the Details Codes also the Parent Code.
The same reasoning is applying also for the Name (Descriptions): the same Description can be present under different parents ( for example descriptions like "Unknown" or "Other" can be present under different Product Families/Accounts). Usually, the way to make the Names(Descriptions) unique is to concatenate to the Description the Code.
Re: Error when updating hierarchies with list items
@svbhagat Just came into my mind: The hierarchy can change in time... one element of details can change its parent at some point.
Usually, the expected behavior is just to change the parent of the detailed element and all the historical data will be automatically restated based on the current new hierarchy.
If the Parent Code would be present as concatenation in the Details code, the default behavior in these cases would be that a new element will be created in the hierarchy and the same Details code will appear twice: once under the Old parent concatenated with Old Parent code and secondly under the New Parent concatenated with New Parent code.
If the Details Code has only concatenated the Level to make it unique then automatically with an import action, the Details Code will be updated with the New Parent and the element moved from the hierarchy of the Old Parent.
However, if the desired outcome is to maintain the historical data under the Old Parent and only all new data to be updated under the New Parent then concatenating the Parent code to Details code is the solution to achieve this.