Dynamic Calc with Two PassFebruary 20 2013 at 11:19 AM
No score for this post
from IP address 126.96.36.199
When I try to pull the value for an account that is dynamic calc with two pass, I get the correct value that I need but as soon as I use attribute dimension in data pull it gives me no data.
Re: Dynamic Calc with Two PassNo score for this post
|February 20 2013, 5:54 PM |
Not clearNo score for this post
|February 20 2013, 6:20 PM |
The attribute dimension - is it associated with the Account dimension or any other dimension? If the Attribute Dimension is associated to a different dimension other than Account, drill down that particular dimension first and then drill-down the attribute dimension to get the values.
It's in the DBAGNo score for this post
|February 21 2013, 8:06 AM |
You need to read this over:
What's happening is that the attribute calc (which is a dynamic roll up of the sparse dimensions)happens last, overwriting whatever two-pass value you calculate.
Per the DBAG:
If your data retrieval uses attribute members, the last step in the calculation order is the summation of the attributes. However, the use of attribute members in your query causes Essbase to disregard the value of the Time Balance member in the dynamic calculations. During retrievals that do not use attributes, the value of the Time Balance member is applied to the calculations. The difference in calculation procedure between the use and non-use of attribute members generates different results for any upper level time members that are dynamically calculated.
They're talking about Time Balance but the concept is the same.
The DBAG goes on to say:
During retrievals that do not use attributes, these dynamically calculated members are calculated in the last step and, therefore, apply the time balance functionality properly. However, during retrievals that do use attributes, the summation of the attribute is the last step applied. The difference in calculation order produces two different, predictable results for upper level time members that are dynamically calculated.
See, it's not a bug, it's a feature. :)
If you can't rewrite the logic, I am afraid you are going to have to fix this in the report layer.