This content has been marked as final. Show 6 replies
Have you tried to put the 3 accounts in a smartview form with the suppress zeros and no value options?
To make sure there is no value in Account 1 and Account 2.
I do not know exactly why this is happening but it almost certainly related to HFM storing values as floats. I think have had problems with HFM returning zero when I know there was a very small value in a cell but I cannot remember the details.
If you want to the result of your calculation to be no data in HFM you could use HS.IsZero and clear or not write to the cell as appropriate. I do this is rules:
If Not HS.IsZero(x) Then
HS.SetDataWithPOV POV, x, False
i tried this and the relevant rows where supressed.
Don´t know why the cell information in the data grid shows
displayed data = 0,00
full resolution data = -0,0000000000145519152283669
stored data = -0,0000000000145519152283669
while the adhoc analysis shows 0,00.
Another information: the curious value will only be viewed at the parent entity, not at the base.
We only have calculation rules, no consolidation or translation rule.
This won't be of much value (<----- PUN Intended), but as long as I can remember there have been weird rounding issues like this when it comes to really small numbers appearing where you would expect a zero.
Since it's E-11, it's going to round out to zero just about every time in reality anyway so it's never been an issue for us at least...
All the big numbers seem to work ok. :-)
Edited by: beyerch2 on Aug 23, 2012 10:26 AM
I've seen something similar to this, unrelated to HFM, though the root cause was an interesting case that could apply to this case as well: There was a bug on the floatingpoint unit of the processor on that machine!!! Because the number is very insignificant, it can escape attention very easily.
Generally the HFM calculations are carried out with 15 significant decimal digits; this includes the digits to the left and right of the the decimal point. The round-off error noted is considered normal for floating point calculations. In fact, the relative error is 1.29 x 10^-15.
That is 15 significant decimal digits is the maximum accuracy can expect with the product.
HS.Round() functions can be used to narrow down numbers especially in dynamic account rules.
You can verify the same in the below oracle knowledge base document.
Accuracy of HFM in Floating Point Calculations (Doc ID 1437033.1)
Hope this helps.