Data change in tm1

[ravi]

Hi All,

Need some advise,

Actual data (P&L reported data, only for Mar 13 month) for previous month has changed in tm1 cube,

We are trying find the root cause for the same by comparing the data with source (DB) and other sources. still no luck.

Can you please advsie what other area or checks can be done.
Regards,
Ravi

[Alan Kirk]

Actual data (P&L reported data, only for Mar 13 month) for previous month has changed in tm1 cube,

We are trying find the root cause for the same by comparing the data with source (DB) and other sources. still no luck.

Can you please advsie what other area or checks can be done.

I would hope that you had checked the transaction log files as a first step.

Of course it's possible that the transactions weren't logged, so that's not a guarantee. However it also depends on how certain you are that the numbers in TM1 have changed, and that you aren't looking at a change in your source system due to, for example, a prior period posting in your ledger. (You haven't said how you know that the numbers have changed; whether you're comparing to a snapshot of the prior data, or the source system.)

It would also be worth checking your TIs to see whether any of them are capable of making such an adjustment, intentionally or not.

[ravi]

Thanks Alan.
I have retrieved tm1 data at consolidated one on 04/05 and other on 06/11 for actuals. what I noticed is only expenses catogory values have changed and this effecting QTD and YTD. Revenue and other accounts are good for March month.
Regards,

[Martin Ryan]

You didn't mention whether you'd consulted the transaction logs?

I have retrieved tm1 data at consolidated one on 04/05 and other on 06/11 for actuals. what I noticed is only expenses catogory values have changed and this effecting QTD and YTD. Revenue and other accounts are good for March month.

Could you try re-phrasing that? I for one am still confused as to how you know the numbers have moved.

Another reason numbers can move is because consolidations have changed. From time to time I've found numbers change quite drastically and found I've accidentally created a consolidation that double counts numbers.

Unfortunately, tracing moving numbers can be very difficult in TM1. It's one of the reasons I take daily backups of TM1 because even if you know that the numbers have moved at a high level, it's very hard to find out why if all you've got is a few summary reports that have changed.

[ravi]

Hi Martin,
Unfortunately, transaction log file are not saved for previous months.
also backup tm1 data files.

I did not try re-phrasing.will check on this.
on consolidations - I have checked number look good- will revalidate it.
Thanks

[declanr]

Without a transaction log or noticing a blatant error in the development (such as a TI changing cell values where it shouldn't or an incorrect consolidation) it is very difficult to pinpoint the cause of this sort of issue.

However since it is actuals that you are dealing with, it shouldn't be hard to repopulate them anyway and then check them to your source system as you would any other time.
Then go through and make sure that absolutely NO ONE (with the exception of Admins of course) have access to adjust historic values. After this go through each of your TIs line by line and make sure that none of them can overwrites these values when they shouldn't.
This doesn't get to the the bottom of why you had the issue in the first place but as long as you check all bases and make sure that only Admins could make a change to the values in the future, you then mitigate against the risk for the future and if it does happen again you know exactly which bunch of users to blame!

[ravi]

thanks declanr.

Actually we do period lock for DB after the every monthend close.
And repopulating actual data for previous may cause concern for tm1 model stability and data accuracy in tm1 model(users).
I am currently reading TIs line by line.....
Regards,
Ravi

[tomok]

You don't save transaction logs OR have backups of your TM1 objects AND you know there would be problems restoring some of the older data??????? I hate to say this but you've just been bitten by your own laziness. There is a reason best practice for ANY system calls for regular backups. Perhaps you'll learn your lesson though I hate that it's going to be such a painful one.

[ravi]

Hi tomok,
I take your words.

The best practice of taking tm1 data folder backups are not followed.
We also did not check the previous backups availabilty in tm1 environment. We had takenup this responsiblity only from this monthend to support tm1 issues.
any other root/direction out of your experience, as to how to handle this issue further..........

Thanks

[vinnusea]

One more point to check is METADATA.

Moving of Metadata could cause this issue too... Means you have your numbers in place and nothing got changed at transaction level but what if your consolidation elements gets moved?

Example :
If your numbers at product hierarchy got changed at higher level when compared to march report... Metadata of Product dimension got changed..If Product consolidation of ABC product Family in march have 20 SKU's but now this month the product hierarchy changed and removed 10 SKU's from ABC hierarchy and placed in DFF hierarchy ...then your numbers associated to those 10 SKU's will also move..right... In this case also it seems your numbers got changed when compared to march report...

Let me know what you think....

[BariAbdul]

One more point to check is METADATA.

Moving of Metadata could cause this issue too... Means you have your numbers in place and nothing got changed at transaction level but what if your consolidation elements gets moved?

Example :
If your numbers at product hierarchy got changed at higher level when compared to march report... Metadata of Product dimension got changed..If Product consolidation of ABC product Family in march have 20 SKU's but now this month the product hierarchy changed and removed 10 SKU's from ABC hierarchy and placed in DFF hierarchy ...then your numbers associated to those 10 SKU's will also move..right... In this case also it seems your numbers got changed when compared to march report...

Let me know what you think..

If this is the case as Declan rightly pointed out the first place to go through is your TI code.Thanks

[Wim Gielis]

Or... maybe... the figures you are looking at, are (perhaps in part) the result of rules on 1 or more cubes. And someone changed a rule...
Or the feeder(s) were not appropriate.

Hence, you will need to check quite some things in the absence of a good backup procedure. Good luck !