Transaction # /CODE(ITEM(# Transactions))/Text/(# Transactions is the numbered list I created with Properties of Account (Text Format), Cost Center (Text Format), Cost Pool (Text Format), Amount (Number Format), Version (Text Format), Period Text Format)
Cost Center/No Formula/Text/ (I have a hierarchy set up for this)
Account Code/No Formula/Text/ (I have a hierarchy set up for this)
Cost Pool/No Formula/Text/ (I have a hierarchy set up for this)
Year and Month/No Formula/Text/ (2 years by month)
Scenario/No Formula/Text/ (i.e. Budget/Actuals)
I have managed to import to a module via a numbered list by first importing the same data into a numbered list then using the numbered list as dimension and the other fields as line items. I am not sure this is the best approach as I will need to aggregate the data for calculations etc. Any advice on best practice? The data won't import using the other dimensions as there are multiple instances of cost center/accounts/in the data.
Creating a Unique key in Anaplan is not recommended (goes against best practices) because what that means is that you will have to create those many properties in the lists and then combining the properties to create unique keys.
Anaplan recommends having a unique Key in the source system.As per best practice you should have the unique key in such a way that you can extract the other parameters based on the Unique Key. For example Cost Centre, Account Code, Cost Pool & Scenario can be combined to get the unique key from the source system. Also never concatenate Time and Data to get the Unique Key. Here is the article which explains in detail about the best practices of data load.
The intention was to get this done as per best practices when the same thing can be done in multiple ways. Not sure if this is as per best practices because we are trying to minimize/optimize the imports and let Anaplan exploit the usage of its engine.
Article in the link above explains everything about best practices of data load.
Just gave him another solution wherein the module I have mentioned can be in the hub that would be updated via import from source and then this would flow into the spoke models as a hierarchy list starting at the top and going down.