This content has been marked as final. Show 8 replies
Hope the section "About Row and Column Templates" in the FR user guide " http://docs.oracle.com/cd/E17236_01/epm.1112/fr_user.pdf " will be helpful.Check through page 97 onwards.
hmm I browsed 20 or so pages after p97, and did not see anything that would help. can you clarify?
This seems to be not possible unless if you go for some text options in the report.
Yeah I have tried different things, and could not find any solutions.
Another question, "Auto Calculation" seems to skip hidden rows (at least that is what they say), is there a way I can do calc based on "Auto Calculation"? I can do a count in "Auto Calculation" to get a value "1" for each row, all I need to do is summing them up...
Are you rows hard-coded or do you use functions like 'Children' and 'Descendants'? Also do you use expansion as that may affect any numbering you manage to set up?
I think I may have done something similar using the COUNT function and a formula column. I used it to show/hide a number of 'empty' columns (columns designed to return no data) so that a graph and grid had the same number of columns and could be aligned.
Might be worth having a look at that and see whether you can do anything with it
Hope this helps
Well, I have lots of reports, some are hard coded, some are Children etc. And we are also looking to use Expansion too --- so I need something that is quite versitile and less manual. Right now, I am using manual entry and trying to use hard coded rows only. I tried CountA, but it has its problems. In the end FR needs to have more functions.
Yes I completely agree, a few extra 'Excel' type functions could make a huge difference!
Thinking outside the box, one ugly workaround might be ranking??! Could you somehow use ranking on the report to return a row number?
I'm thinking on the Essbase side you might need to create a member in a dimension other than Accounts that you can store a static value against, incrementing it for each account in your hierarchy, e.g 10, 20, 30 etc. Then in your reports you have a hidden column to return that value and a formual column to rank it in ascending order.
Like I say not pretty but if you could do it in a dense dim e.g. Period then it shouldn't significantly add to block size / db size as it is only one member, store it against a static member in your other dimensions, e.g. No Year, No Entity assuming you have something similar. You would also need to be careful of your numbering if your row numbers needed to include subtotals so that those values were ranked correctly.
Its amazing what you can come up with when you have to find a way to do things.
Hope this helps
Good point Stuart. I would definitely try that if I were at my old job, but companies are different when it comes to out of box things like this. lol. I guess I will hard code numbers for now. Take care