Build the row's corresponding last year surrogate key at ETL/ELT time ... then you can build using a canonical date approach. Leaving this to the logic layer of OBIEE might prove difficult and non-performing.

@Gianni Ceresa has given what I would point out next ...

The second one shows 3 dimensional attributes and 1 measure ... that's by design. The intersection of the measure at the attribute values is essential for analytics - OBIEE is an on-screen analytics tool. You want to remove the context of the measure ... why?

to use timeseries (ago, todate, etc) ... hierarchy must be marked as a TIME type ...

"I can tell you that IT controls our ETL and I am in an Analytics Function." You control the WHAT of ETL ... they only control the HOW. You are here because WHAT isn't getting it done! "I was not part of the conversation and can only work with the information available to me." Foisted requirements ... fails every time. Sad…

+1 "A solution was already provided to you but I have a different question. Why do this in OBIEE and not make this calculation in your ETL process? It seems you have an employee dimension so this would be just another attribute that should just require a minor change instead of forcing OBIEE to send queries to the server…

OBIEE is an on-screen analytics tool ... from an information stand point the axis labels having all three elements is valid, valuable and by design.

I had begun to write this up the other day ... then realized I was attempting to remodel the whole thing in a forum post ... unfortunately @skull, it's what you are going to have to do ... boil the physical transaction snowflake into ONE OR MORE logical fact stars (preferably with conformed dimensions).

You have same totals ... but your detail rows don't fit the bin (as you've presented them) ... or are you saying that the 4th row: 10,651 is an aggregation of multiple deals all withing 1000-10000? if so, that's very confusing to someone who is struggling with an issue. Show them the end result - EACH detail row that…

Looks like some of your amounts are greater than the bin 1000-10000 ...

+1 ... needs to have a 'key' to work right ...

Physically join on your keys ... Logically you must reduce this to a star - you need to map out what your dimensions (attributes) and facts (measures) are. Be prepared (especially with that Negotiation Detail table) to create additional physical structures to make this work (perform) -- if indeed it is highly snowflaked…

Just to be clear: you have 3 internationally known OBIEE / BI Architects providing you input ... none of us have 'explained it' to your customer -- I'm not convinced you've found the key explanation point that will move your customer into the realm of accepting/embracing/adopting a proper solution to the issue -- find that…

1. same error in the database - so acknowledge that you get the same error directly in the database then... 2. I know what the error means I'm looking for a solution using direct query in OBIEE - you want to circumvent the limits of your database with a direct query? via OBIEE? ^ not going to happen OBIEE is not a data…

OBIEE stores NO data ... (other than cache files)

BI Publisher has it's own scheduler ...

Add the manipulations to your query ... SELECT SALES, (SALES/1000) SALES_K, (SALES/1000000) SALES_M FROM TABLE ... then do your format masking

BI Publisher can burst your report ... Bursting = specific content to specific recipients.. I think you are missing the design and intent of OBIEE ... BIPublisher is another tool that complements OBIEE

The user would put in the parameters and then export the report (csv, excel, pdf, html, etc ...) you would just build it so you have the master and detail rows showing.

No setting .. but if your users use a bookmarked linked like: http://server:port/analytics/saw.dll?catalog#%7B%22location%22%3A%22%2Fshared%2F ^ easy to get your specifics from the browser address bar