Zero Suppression - very small #'s

[ramjam]

Hi,

We're having an issue with TM1 converting 2 decimal values to very small numbers (15-20 decimal places). These are values that are written to the cells via a TI process, not rule driven or data spreads. I've tried ROUND and ROUNDP w/ 1-6 decimals in the TI, and also tried doing the rounding in the SQL we use as the data source - the ROUND and ROUNDP(val,0) both "solved" the problem, but this is GL data, so rounding to 0 is not a viable option. Just for fun, I also tried parsing out the value into a whole number and the decimal piece, then doing a CELLPUTN for the whole number piece and a CELLINCREMENTN for the decimal piece, and also creating two new elements and consolidation for the whole number, the decimal, and the total, respectively. None of that worked. This is a problem b/c it's causing zero suppression to fail when these elements roll up to a "zero" total (see attd) - the conversion "error" causes the consolidation to be a very small decimal # and not a zero.

I know I've seen this issue brought up before, but I can't seem to find it now, and AFAIK, the resolution was to use ROUNDP, but that is not doing anything. Other users have stated that it's a result of conversion to binary, and not a problem, but if that conversion causes the zero suppression to fail, I'd argue that it is a problem.

Anyway, just wondering if anyone else has the problem with consolidations, and how you fixed it?

Thanks for any help any of you guys can provide.

[tomok]

TM1 stores values in double precision, not decimal. This has been around since the tool was first developed and it can causes issues with zero suppression when you have a scenario like yours. The only way I know to fix it is to assign a ROUNDP rule to the consolidated elements. Doing a ROUNDP through a TI does not work because you can't change the way TM1 stores the data. Your TI code can tell TM1 to store 150.00 and it can still store it as 150.00000000122, or something like that.

[ramjam]

Ughhh - I was afraid that was what the answer was going to be. This didn't seem to be an issue until we went from 10.2.2 to 2.07 - any thoughts as to why that might be the case (just out of curiosity)?

[Steve Rowe]

If you have space in your cube then you can add a measure next to your loaded data and then write a rule to round the input values.

There is obviously an overhead to this on the rules and feeders required, you'll need the balance this versus the problems the zero suppression is causing.