Hi,
I have encountered some rounding issue at consolidation level. Fyi, I have a cube, let say cube A, the amount value that store in this cube are two decimal places (#,##0.00).
In Cube B, the format of amount value is "#,##0". When I put the data from cube A to cube B, the amount value will be auto formatted. However, the consolidation level in Cube B is based on the before formatted value. And, this cause the consolidation value does not tally with the total of the amount in child value. Please refer to the sample below:-
For eg.
Cube A
Prod1 100.63
Prod2 100.52
Total 201.15
Cube B
Prod1 101
Prod2 101
Total 201 (the correct amount should be 202)
Do you have any solution for it?
Thanks in advance.
incorrect consolidation value due to rounding at leaf level
- Michel Zijlema
- Site Admin
- Posts: 712
- Joined: Wed May 14, 2008 5:22 am
- OLAP Product: TM1, PALO
- Version: both 2.5 and higher
- Excel Version: 2003-2007-2010
- Location: Netherlands
- Contact:
Re: incorrect consolidation value due to rounding at leaf le
Formatting is a display functionality, it is not actually changing your numbers. If you want to round the numbers when copying data from source to destination, you can ue the RoundP rules (and TI) function.sfnicole wrote:Hi,
I have encountered some rounding issue at consolidation level. Fyi, I have a cube, let say cube A, the amount value that store in this cube are two decimal places (#,##0.00).
In Cube B, the format of amount value is "#,##0". When I put the data from cube A to cube B, the amount value will be auto formatted. However, the consolidation level in Cube B is based on the before formatted value. And, this cause the consolidation value does not tally with the total of the amount in child value. Please refer to the sample below:-
For eg.
Cube A
Prod1 100.63
Prod2 100.52
Total 201.15
Cube B
Prod1 101
Prod2 101
Total 201 (the correct amount should be 202)
Do you have any solution for it?
Thanks in advance.
Michel
-
- Community Contributor
- Posts: 132
- Joined: Thu Oct 15, 2009 7:45 pm
- OLAP Product: TM1
- Version: 9.4.1 9.5 9.5.1
- Excel Version: 2003 2007
Re: incorrect consolidation value due to rounding at leaf le
Where are you performing the rounding? If you have only formatted your view to not show decimals, then that does not change the underlying data values and would cause the situation you presented.
Ankur Jain
- Alan Kirk
- Site Admin
- Posts: 6606
- Joined: Sun May 11, 2008 2:30 am
- OLAP Product: TM1
- Version: PA2.0.9.18 Classic NO PAW!
- Excel Version: 2013 and Office 365
- Location: Sydney, Australia
- Contact:
Re: incorrect consolidation value due to rounding at leaf le
This is not a bug. Again, it's requested that people read the How To Make A Bug Post thread before posting in that forum. The post has been moved accordingly.
You will not get rounded numbers by simply formatting them. To get 202 in cube B (which, IMHO, would be the wrong value anyway) you would instead need to apply the Round or RoundP rules functions when you are pulling the N level numbers from cube A to cube B. Because as things stand you may think that you have 101 twice in cube B, but you don't. You have 100.63 formatted as 101, and 100.52 formatted as 101 And those are still adding to 201.15.
{Edit: Clearly I shouldn't have typed so much since two people beat me to it. But the answer still stands...}
No, you haven't. That's because you haven't been rounding anything, you've only been formatting it.sfnicole wrote:I have encountered some rounding issue at consolidation level.
No, it doesn't. You've told it to display two decimal places. The values in the cube are stored as standard floating point values. The display precision that you specify only determines what the numbers look like, not what is stored.sfnicole wrote:Fyi, I have a cube, let say cube A, the amount value that store in this cube are two decimal places (#,##0.00).
As you yourself said... the total value is 201.15, And that rounds to 201, not 202.sfnicole wrote:In Cube B, the format of amount value is "#,##0". When I put the data from cube A to cube B, the amount value will be auto formatted. However, the consolidation level in Cube B is based on the before formatted value. And, this cause the consolidation value does not tally with the total of the amount in child value. Please refer to the sample below:-
For eg.
Cube A
Prod1 100.63
Prod2 100.52
Total 201.15
Cube B
Prod1 101
Prod2 101
Total 201 (the correct amount should be 202)
You will not get rounded numbers by simply formatting them. To get 202 in cube B (which, IMHO, would be the wrong value anyway) you would instead need to apply the Round or RoundP rules functions when you are pulling the N level numbers from cube A to cube B. Because as things stand you may think that you have 101 twice in cube B, but you don't. You have 100.63 formatted as 101, and 100.52 formatted as 101 And those are still adding to 201.15.
{Edit: Clearly I shouldn't have typed so much since two people beat me to it. But the answer still stands...}
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
-
- Posts: 20
- Joined: Wed Dec 02, 2009 2:27 am
- OLAP Product: TM1, Cognos
- Version: 9.5.1
- Excel Version: 2007
- Location: Singapore
Re: incorrect consolidation value due to rounding at leaf le
Hi,
I have used round and roundp. It may resolved this issue but it also cause another issue. If the value is in negative, for eg. -101.5, the system will give -101 instead of -102. So, for this issue, do you have any solution for it?
Thanks.
I have used round and roundp. It may resolved this issue but it also cause another issue. If the value is in negative, for eg. -101.5, the system will give -101 instead of -102. So, for this issue, do you have any solution for it?
Thanks.
-
- Site Admin
- Posts: 1454
- Joined: Wed May 28, 2008 9:09 am
Re: incorrect consolidation value due to rounding at leaf le
I believe (but could be challenged) that it is correct practice to round towards zero. if you don't like this, try something like
['Z'] = round(['Y']) + sign['Y'] -1;
(I'm sure someone will find a hole in the above logic, but hey...)
['Z'] = round(['Y']) + sign['Y'] -1;
(I'm sure someone will find a hole in the above logic, but hey...)