+1 to @Joel Acha - here is effectively what you want in SQL ... SELECT * FROM ( --BEG rows SELECT B.PSTL_CDE, A.ITM_ID, B.TRNS_TYP, MAX(B.QTY) KEEP (DENSE_RANK LAST ORDER BY B.TRNS_DTE DESC) OVER (PARTITION BY B.PSTL_CDE, A.ITM_ID, B.TRNS_TYP) FIRST_QTY, MAX(B.AMOUNT) KEEP (DENSE_RANK LAST ORDER BY B.TRNS_DTE ASC) OVER…

Agreed a count is ineffective ... and a filter on the database reduces the table to only serving up the combinations where a customer has purchases from all three locations ... really what you want? Maybe think about the setup of a materialized view that is refreshed everyday with the customers that have a positive value…

+@Gianni Ceresa "VM of a VM" is not going to be a good approach

What's your end-game? If it is to have a 'quick install' for a server - this isn't the way to go; that VM is standalone and software configured for it's own environment. If you just need the content (samples) set up the VM and then export - RPD, Webcat and Data ... but that just begs the whole thing of why even do that ...…

No Threshold Analyzer in OBIEE or in OBIA that I have ever heard of ... 10+ yrs in

Difference in dates is a measure Date itself is an attribute - get it into a dimension where it belongs.

good catch!

EVALUATE('SUM (%1) OVER (PARTITION BY %2,%3)' , "Fact - SCM AP Spend Summary"."Converted Amount","GL Period"."Period Year", "SCM Vendor Mapping"."Revised Vendor Name" ) --- This does not work -- not the --- Error being State: HY000. Code: 42015. [nQSError: 42015] Cannot function ship the following expression: EVALUATE.…

Build once - use many ... this is what makes sense! Why build many? Any logical measure to use the LBM will be correct ... any dimensional attribute to filter the LBM will work according to the logical hierarchies and the business model. ^-- this is KEY; it all depends on your model

Agreed ... this is a level-based measure

Sounds like your model isn't ... you need related data and specified logical relationships. Sounds like your RPD is configured to run like a query tool and not a business logic layer. Model correctly and the Master-Detail functionality of OBIEE solves your issue.

Once your full solution is built .. what makes you think your users will undergo a second change? From a leadership perspective this is a risky move ... furthermore - you will have to spend double effort to build the 'rules' ... do the same work twice? Sounds like a management risk. What is your plan when you have…

something to check: https://troubleshooot.wordpress.com/2011/10/13/obiee-11g-bi-publisher-login-does-not-work/

"I am not asking about the prompt filtering here. The requirement is something like that. User is responsible to look at Departments with selected regions only." Again your answer is very unclear. User is responsible to look at departments with selected regions ... that to most everybody indicated a pre-defined filter on…

"One particular user should have access to two departments with different regions(one department with all regions and one department with only one region)." you can only get that if you apply it to distinct logical fact stars... if you only have one fact than the 'can have it all' filter supersedes the other one. in fact.,…

what does your time dimension look like? if you have fiscal info on the date row then: SELECT TIME_DIMENSION.FISCAL_YEAR FROM table TIME_DIMENSION WHERE TIME_DIMENSION.DATE = CURRENT_DATE * CURRENT_DATE being the builtin variable value That would get you the fiscal year for the current date always .... depends on how well…

the online sample app wasn't up earlier... this blog post is built on the same RPD... http://obieehelper.blogspot.com/2012/04/aggregate-at.html Learn Oracle and OBIEE: Aggregate at essentially: Total Measure = AGGREGATE (Measure AT a dimensional hierarchy level) % of Total = Measure / Total Measure IE: Assume hierarchy…

Are you the business user? if so, then the system has no value without your input! it's a best/leading practice I'm giving you here ... have it built once so it can be reused. built by a developer who should understand the technical implementation of the level-based measure. else, study up on using the AGGREGATE(x AT y)…

if you have one fact table and you have a rule that says person A sees all regions because of being in IT department, then they will see only one region if they are put in the sales department in addition to the IT department. what is happening is: SELECT ... FROM fact WHERE (regionkey = 'NORTH') <-- sales department; IT…

Ya. ... I remember having to ask someone at Oracle for it (the plugin) ... it's got sample EBS data in it ... not sure what version of OBIEE or what SampleApp it plugged into