TM1 Forum

Hello,

New here and new to TM1.
My company has TM1 11.0 (PA 2.0) and I would like to find an easier way than we have today to be able to compare and validate several versions in the same cube.
For example we have a revenue cube and I have a working forecast that I archive as JUNE 2017 Scenario.
I built a worksheet that compare both versions per quarter, month, years and validate the aggregate number but what about the text and each line item. how can I make sure that all the text, all the transactions, are properly copied into the archive? and not just the aggregate number?
Is that feasible using a TI that would scan both versions and validate that all the lines, all the parameters are identical and the archive is successful?

thanks for the help.

Its relatively easy to have a process check whether it's source is equal to numeric or string values in the same cube reference with a different version; then it could output differences to a cube or just a txt log file of differences found.

The question that is always worth asking here though is whether using TM1 to check that TM1 is working as expected is the correct approach or whether an external tool/manual intervention is required to create confidence in the results.

scom57 wrote:Hello,

New here and new to TM1.
My company has TM1 11.0 (PA 2.0) and I would like to find an easier way than we have today to be able to compare and validate several versions in the same cube.
For example we have a revenue cube and I have a working forecast that I archive as JUNE 2017 Scenario.
I built a worksheet that compare both versions per quarter, month, years and validate the aggregate number but what about the text and each line item. how can I make sure that all the text, all the transactions, are properly copied into the archive? and not just the aggregate number?
Is that feasible using a TI that would scan both versions and validate that all the lines, all the parameters are identical and the archive is successful?

thanks for the help.

Let's start with some basics of how TM1 works. TM1 aggregates all sub-totals and totals on the fly. TM1 does not store aggregates, data is only stored in leaf cells; that is the lowest possible level of each dimension in a cube. Therefore you should be confident that if the totals match then all understudying granular data must match too.

I'm assuming there is a process to create the snapshot versions on the fly as opposed to all possible snapshots already existing in the version dimension? This process could also create a variance consolidation
JUNE 2017 Scenario Variance to Working
JUNE 2017 Scenario 1
Working Forecast -1

By doing this the database itself is doing the check for you and it is also a useful reference to determine which parts of the business have changes their forecast from one monthly scenario to the next.

Thanks Declanr and lotsaram for the help.
I use a worksheet with a variance cell that let me know if the $$ are equal are not. But what I notice is that from time to time... the description (text) that the user wrote in the original version (working forecast) did not copy. Sometimes it is there, sometimes not.
I will look at the process itself.
Thanks a lot.

scom57 wrote:Thanks Declanr and lotsaram for the help.
I use a worksheet with a variance cell that let me know if the $$ are equal are not. But what I notice is that from time to time... the description (text) that the user wrote in the original version (working forecast) did not copy. Sometimes it is there, sometimes not.
I will look at the process itself.

If your totals always match and you have seen strings copy at all I would say that your process works and that your strings are always there too. However, what is often forgotten is that strings don't consolidate. If you enter a string description against "Widget 001" in your Widgets dimension, you will NOT see that string when you are looking at the "Total Widgets" consolidation. This is also true if you are looking at a total in any other dimension. Unless you entered the string at that consolidation node, you won't be seeing a string that has been entered against a lower (or higher, come to that) level. This can lead to the incorrect impression that the strings are only sometimes there.