Setting to ignore elements when imported into a time dimension.

AntonMineev

Hello everyone! I constantly face the problem that I described in this topic.

 

The problem is that if, when loading data, you have time in the columns, and the rows have several non-embedded columns (reference for the user, outgoing measurement (and the mapping is done according to an additional LI: code), then at the start of import there will always be a warning "*column name  not found in the time dimension".

 

With other dimensions, I can set" Ignore "for these items and then my import will be error free.

 

Why is it important? I always try to follow the best practices, including making imports without warnings or errors. But in this case, I have to either sacrifice convenience (wrap the time into lines), or use other workarounds, or measure the warning.

 

How to solve the problem? When mapping the time dimension, it is also required to display the elements found in the source and give the opportunity to indicate "ignore this". At the same time, other elements of time should continue to be mapped dynamically.

 

m.angeles11

This is definitely needed as I always have clients needing a template downloaded from Anaplan for them to use as a data input template which is subsequently used for loading into Anaplan after they enter/update data in it.

 

They always request to have description and other fields/columns included in the template which are not needed for the data import process.  It is these non-required columns that then make the data import not able to happen without errors unless the non-required columns are deleted by users prior to being used in the import process.

 

Deletion of the non-required columns is a relatively easy workaround but is still something that users tend to frown about when asked to have them follow the instructions and delete the unnecessary columns.

 

So please have this feature added so we can have happier users (and model builders).

 

Iain_Briggs

I am also encountering this exact issue, the solution proposed by @AntonMineev would be a very positive step and provide much greater flexibility.