This content has been marked as final. Show 13 replies
Try like this
<Some logic here, pulling some other member here and is working fine>
([Balancesheet],[Period].CurrentMember.PrevMember) /* this also is working fine*/
*[Balancesheet].value* /* ERROR*/ /* THIS IS WHERE IT IS FAILING AND MAKING THE VALUES '0' for and year other than FY10 */
Thanks but this also does not work.
Please suggest something else.
Is there any solution to this?
Thanks for replying!!
When you say "ONLY for FY10 and do nothing for any other year." What are you expecting to be in the cell when you query it for another year? I would assume December of that year since that should be the last period with a value in that year.
So something like
([Balancesheet], [Year].CurrentMember, [Period].[Dec])
Data already exists for FY08 and 09 for this member.
I want the calculation should happen as per my logic for FY10 and I dont want any change in the values for FY08 and FY09 i.e if for June FY09 the value existed before the member was 123, it should remain as is(123). but presently ASo is making it #Missing for june FY09. - I need essbase to workup the logic I am writing for FY10 and nothing for FY09 etc.
Was I clear enough?
Can you please reply to this?
Any help will be much appreciated.
What you're saying doesn't make sense. You state that a level zero member in ASO that has a member formula has stored data for prior periods. That is not possible.
It is like this. would you mind telling the technical reason why this can not exist this way?
Per the DBAG
Formula Calculation for Aggregate Storage Databases
Essbase calculates formulas in aggregate storage outlines only when data is retrieved. Calculation order may affect calculation results. Whenever you use MDX formulas on multiple dimensions in an aggregate storage outline, it is good practice to set the solve order for each member or dimension. See Calculation Order.
When designing an aggregate storage database calculation, consider that aggregate storage database members with MDX formulas are dynamically calculated. The dynamically calculated members have a value of #MISSING until they are queried.
Account dimension is by default dynamic and which inturn is the reason why MDX member formula can be applied on its members.
Having said this, (dynamic) account members may already have had data(until the MDX member formula was applied e.g. for FY09 and FY10).
Now, when in MDX, I am specifying some calulation to be done ONLY on FY10, why ASO makes FY09 as #Missing.
It may be possible that ASO gets confused in such a scenario, but practically, there could exist a need to cater to my case and it does exist.
thanks for the information...I have found an hack to achieve this....but its a hack so I did not want to use it, but it seems there is no solution to this.
thanks again :)
I'm still not clear on what you are saying, it sounds like you are saying in an ASO model you can take a level 0 member that has data in it, add a member formula to it and Essbase will retain the stored data that was there prior to the formula being added, but going forward it will use the result of the MDX formula.
If that is what you are saying, it is not accurate. If you are finding that it is, then it would appear to be a bug. In my testing it does not work that way, nor should it.
Think about the implications of not knowing whether it is stored data or calc'd data. What do you do if you have to reload data? You can't load data to a member with a member formula, so you would have to remove the formula prior to load, then load and then add the formula back?
There is something else going on here that is not being explained clearly.
The solution is to probably create another stored member for Historical data and then have the member with the formula reference that one for the periods you want and calculate for the other periods.
You are absolutly correct with ur proposed solution and this is what I have already implemented.
The reason I was asking this is that I have a requirement, where FY10 data has to be calculated based on FY09 data and when m applying MDX to this member for only FY10, it is removing(#Missing) FY09 data and resulting in doing a wrong calculation for FY10.
So now from your replies and my research, I guess using another stored member for my calculation is the only solution.
I am hoping that I have been able to explain correctly what I wanted achieve, if not, please let me know
It appears we are now on the same page. Good luck with the rest of your implementation.