The situation is as follows. The customer has created a reporting requirement that defies the many to many rule of multidimensional database. They want to call something a name depending on the condition in another dimension.
The answer can be implemented in one of four places.
A. In the source system, reclass the transactions by creating a new member, the doppelganger member.
B. In the source interface to Essbase, make an sql fix that does a union query on the exceptional member and hardcodes the new doppelganger member in the select of the second query.
C. In Essbase itself, write a calc that re-allocates based upon the rule and send zeros to the original number based on the @isdesc of the driving dimension.
D. Report logic.
The higher upstream this is done, the less maintenance it will take in Essbase. However, the C method makes it easiest to handle history.
Comments