TM1 Forum

Hi there,

There is a requirement to import data from a SQL table into a TM1 cube with user input data. The import should not wipe out existing user input in the cube.

How can this be implemented in a TI process?

Thanks.

Just have different measures for the user inputs as compared to the data load, then when the TI runs you just zero out the part it will load to and leave the rest of the cube alone.

tm1green wrote: ↑Fri May 25, 2018 12:24 am There is a requirement to import data from a SQL table into a TM1 cube with user input data. The import should not wipe out existing user input in the cube.

How can this be implemented in a TI process?

As Declan said, just make sure there is a separate measure for user input data versus date imported from the database.

If there aren't separate measures and you are expecting TM1 to know the input lineage of a cell and automatically skip overwriting user input cells when importing from a database. Well then you are in a bind and need to re-think things.

Leading on from what Declan and Lotsaram have said. I normally create an attribute on my measures dimension to indicate that the measure will be used for input. This is generally referenced in the security model but leveraged in TI.

In my load process I use MDX to create an All N subset with a filter on my Input items. This subset is then used in the zero out.

Or, just to add different options to the mix: input data (like adjustments) could come from a different cube - dimensioned differently. Then in that case, a rule could be written to transfer the data to the main cube. In that case, zeroing out all measures will not hurt you.
Though I agree that selecting the measures (be it hard-coded or with an attribute or name convention) would be beneficial.