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.