Ugly but you could have a 'dummy' column that builds the narrative text using case statements and concatenation - then narrative only shows 1 row of the one column ...

Yes, you have the functionality in that version ... You might need to separate the functionality to different columns to achieve the total effect.

Make sure that whomever is gathering requirements knows the tool very well. No sense in agreeing on / setting expectation for the 'undeliverable'.

Looks like you are asking for the measure at the date and period levels AND the YTD 'version' of the measure at the bottom of the report ... you are dealing with two separate measures (logically speaking).

Master-Detail events ... looks like from your screen shots you might need to upgrade to get that functionality (11g has it)

It's OBIEE 10g; out of the box (with some mods) OBIA for Purchase and Spend and Financials. What does the same query do when you run against the no-mod original OBIA RPD for the same 2 queries .... in essence, what mods are done that causes this not to work? OR it never worked OOTB this way, and now you want to build…

I get the sense that your source uses that data in place of a null (column is not nullable) ... if so, then is this date joined to your Time/Date/Calendar dimension? If true, then just manipulate the Date Name (a text representation of the date) as NULL in your dimensional DW table ... do it once in ETL and never do it…

You need a properly formed Time (Date) dimension that has the Year and the Period on the individual date row in the database table ... it's the most efficient and easiest to implement. Use drives physical design.

+1 to Cesar ... Balances are inventory-style facts and need to be stored in the appropriate fact structure. Once you have it right, then you can show increase/decrease in balance over time AND also add value by having an aging balance fact built from the base balance fact.

Here's a very recent thread demonstrating why it's not always a good idea to build things in functions on reports ... WEEK_OF_YEAR in OBIEE11g always adds one additional week

This is precisely why these types of attributes should be built into your Time dimension ... since you have to go and modify/update your reports, you might as well get a fully formed Time dimension and do it once.

Following the instructions in the documentation, it takes about an hour...

This is where having a better formed time dimension pays off in spades ... to do this in a report is cumbersome. It's much easier to count the daily rows between two date rows where weekend_flg = Y ... and it's simple to put the flag in the day grained time table (day numbers 1 and 7) ... my solution is fix the time…

Not having your RPD and reports in front of me it is very hard to tell you what's going on ... PS: the sort with rows displayed as 10 is my preferred way ... user can swap the sort and have the bottom 10 or any set of ten between ... it's actually a much more useful thing. Call it Top/Bottom 10

What about getting your 40 rows ... then using Selection Steps to only keep the top ten.

OBIEE 11g Security Week : Row-Level Security - Rittman Mead Consulting

In addition to Christian's reply ... to keep the list manageable, SAs should be 'mapped' to business function and then security applied so that people only see what is pertinent to their business function.

You can set it with an RPD initblock (use a query to look it up via the UserID) ... it is a reserved system session variable DISPLAYNAME https://docs.oracle.com/cd/E28280_01/bi.1111/e10540/variables.htm#BIEMG3104

You can connect online in 12c... but then it's up to you to make no errors ...you are better off pulling a copy making changes, validating your changes and deploying via the prescribed methods in the docs (yes 12c is different) - better safe than sorry.

Did you try setting permissions on only the prompt (not it's folder) in catalog to be BI Administrator role only?