Dynamic Calc with Two Pass

Dynamic Calc with Two Pass

Anonymous
Anonymous

February 20th, 2013, 4:19 pm #1

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.

Any clue?
Quote
Share

Anonymous
Anonymous

February 20th, 2013, 10:54 pm #2

Any help?
Quote
Share

Anonymous
Anonymous

February 20th, 2013, 11:20 pm #3

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.
Quote
Share

Joined: November 26th, 2001, 10:15 pm

February 21st, 2013, 1:06 pm #4

You need to read this over:
http://docs.oracle.com/cd/E10530_01/doc ... dynca15843

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.

Regards,

Cameron Lackpour
Quote
Like
Share


Confirmation of reply: