"Rule 1.05-10": Article 1, Chapter 5, and Rule 10 – “Never delete list and reload the list as daily occurrence”. Using a unique key to update to values rather than delete and re-load. It goes against P & N elements of PLANS if you wish to do so.
Here is how it was done in Pre Planual Era: When we had to delete the transactional data & reload the data we used to delete/wipe out the entire list items of the lists
What is wrong with this method? There are a lot of disadvantages
Deleting the list items is model specific and not module specific when there was a need to add/update data to few modules of a model.
There are lot of changes that the system has to do – first delete the list items, create the change log and record it in history, update the lists, create the change log again and record it in history. When the certain threshold is surpassed model will require a save and thus taking more time. On top of that model has to recalculate and re-aggregate the data across the whole model. That is a lot of work for Hyperblock and it surely impacts the performance of the model
Deleting and reloading the lists calls for an additional maintenance by resetting the lists once it nears 999,999,999 items
Here is how it should be done in Planual Way: All the transactional data should flow into modules and NOT lists, which is a Thumb Rule. There is an article by @rob_marshall about Data Hub – must read for everyone which clearly illustrates this rule.
Now if your client operates in such a way that you have to delete the transactional data then you delete it from the modules without touching the list items. You can do it by creating a process which will wipe out the data first and then reload it back
Create line item formatted as “No Data”
Create a process with two imports
Import No Data formatted line item to Transactional data line item
Import data into the same line item
Now there can be many scenarios where you need to load data for all historical periods (i.e., restating the history) or load data for few periods (i.e., current month and previous month). These all can be tackled through filters and having one saved view for each scenario
Ideally what should happen is that only the updated/changed data should make its way to Anaplan Data Hub and not the entire data set which probably may remain unchanged. Two ways to achieve this (Excerpts from Data Hub Article)
From the source system, request IT to only send the updated information, not the full load every time. Additionally, request IT to create a column in the source file with a hardcoded value of “TRUE.” This will tell Anaplan which row is new or has been updated and can be used as a filter for an export. Just know, before the import of the source data gets loaded, make sure the first action within the process clears out the previous true records (set this up via a view using a filter where the view only shows members with a value of true).
Utilize the current period function to only export the current period data. In the SYS Time Filter module, create a line item named Current Period with the formula CURRENTPERIODSTART(). In the export views, filter the data on this line item.