You are on page 1of 4

Best Practices for Hyperion Financial Reporting (FR) Report Design

Best Practices for Hyperion Financial Reporting (FR) Report Design [ID 1196695.1
Modified 10-JAN-2011
In this Document
Document History
Create Date:
Best Practices for Hyperion Financial Reporting (FR) Report Design
All Data Sources
Essbase or Planning Data Sources
HFM Data Sources
Template Reports
Safeguarding Reports
Applies to:
Hyperion BI+ - Version: and later [Release: 9.0 and later ]
Information in this document applies to any platform.
The purpose of this document is to provide Best Practices for Financial Reportin
g Report design. It assumes that you are a report designer for Hyperion Financia
l Reporting, and are acquainted with Financial Reporting Studio and general Fina
ncial Reporting terminology.
Document History
Sharon Morris
Kathleen Hardin
Create Date:
September 1, 2010
Best Practices for Hyperion Financial Reporting (FR) Report Design
All Data Sources
Choose the data source best-designed to meet your specific reporting need.
Data sources should be designed to meet the organizational reporting requirement
s. There is a great deal of flexibility with Essbase cube design. There is some
what less with HFM databases and Planning databases and cubes, since both of tho
se data sources have fixed numbers and types of dimensions.
Minimize the number of dimensions in the grid.
Single-member dimensions should be in the Grid Point of View (POV) or the Report
To set a value in the Grid POV that users cannot change, take the following step
Click on the Grid Corner to highlight the grid.
In the Grid Properties pane, check "Grid Point of View".
In the Point of View display in the grid, make the desired selections. For the d
imensions to be available to users, leave the value as "User Point of View".
Uncheck "Grid Point of View" in the Grid Properties pane.
The dimensions for which you selected members will not be visible to users. You
can use Text Functions to display the members in the hidden dimensions.

Instead of expansions, use Related Content.
If you want to see detail from a high level in a report, you can use Related Con
tent reports, which are related detail reports containing detail information for
the member in the calling report. The related report will pull the point of vie
w for the callout from the calling report. You can set up Related Content links
in the Grid Properties pane, or in the Cell Properties pane.
For example: Your primary report is a Cash Flow Statement. In the Uses of Cash s
ection, you include Asset Purchases, which are an alternate rollup of Fixed Asse
ts . You wish to drill down to individual asset purchases.
In your associated detail report, POV dimensions will include Account. The row
dimension selection will be "Current Point of View for Account and Bottom of Hie
rarchy for Account". The "Current Point of View for Account" is Asset Purchases
, from the calling report.
Minimize the number of row selections using "Descendants of".
If you have more than two dimensions in the rows that are calling Descendants, y
ou can quickly produce an excessively large data set that Financial reporting ca
nnot manage, and your report will not run. You also run the risk of slowing perf
ormance at the data source if the data source needs to provide a very large numb
er of intersections.
Instead of calling descendants for multiple dimensions into the grid, put one of
the dimensions into the POV. You can put the report into a book, and make the s
election in the Report POV in the book. The book will generate a separate report
for each selection, pulling in many smaller data sets rather than one very larg
e one.
A report should not require more than 30 or 40 data rows to facilitate maintenan
ce. Similarly, columns should be kept to a manageable number. There is a limit o
f 256 columns in a report. There is no fixed limit to the number of rows.
Most calculations should be done at the data source.
Basic suppression at the data source reduces the number of data intersections pu
lled into the report. Always do Basic Suppression separately from Advanced Supp
Estimating Report Size
You can estimate the number of data intersections in a report using the followin
g formula:
(# of members in dimension1) * (# of members in dimension2) * (# of members in d
imension3) ... * (number of data rows) * (number of data columns)
Each dimension in the grid acts as multiplier, including dimensions in the rows,
columns and pages.
You determine the number of members in a dimension by expanding the dimension un
til you see the desired member. In a large dimension, you may access hundreds or
thousands of members to pull one or a handful of members into the report.
Dimensions in the POV do not act as multipliers. The members are pulled into the
report only once.
The potential size of a report, before basic suppression, measured by the number
of data intersections is as follows:
Small Report: <1,000 intersections
Medium Report: 20,000 intersections
Large Report: 100,000 or more intersections
Here is an example using the Essbase Sample: Basic application.

Children of Scenario
Descendants of Market

Children of Measures
Level 0 of Product

Children of Year


Descendants of Market = 24
Level 0 of Product = 13
Children of Year = 4
Children of Scenario = 4
Children of Measures = 3
Estimated number of cells before suppression = 24 * 13 * 4 * 4 *3 = 14,976
This example is a medium-sized report. Basic suppression could make the report
substantially smaller.
Formulas, including AutoCalculation and conditional formatting and suppression,
make a report more costly to execute.
Basic Suppression makes a report less costly. Basic Suppression should always b
e done separately from Advanced Suppression.
Essbase or Planning Data Sources
Always use an Essbase data source for numeric data.
Only use a Planning Details Data Source if you will display Planning Cell Text o
r Planning Smart Lists in your report.
When you use a Planning Details Data Source, Financial Reporting goes to Plannin
g as its first stop. If the data are numeric only, Planning redirects the query
to Essbase, so it takes two hops to get the data instead of one.
For optimal Financial Reporting performance, you may need alternate roll-ups in
your structures.
Outlines should be designed so callouts allow report designs with relatively few
data rows and columns.
Use Attribute Dimensions and Dynamic Calcs sparingly. They are very costly at ex
ecution time.
Use Substitution Variables to make your reports dynamic.
If your rows or columns contain multiple dimensions, put the dense dimensions fi
rst. Doing so will minimize the number of data intersections pulled into the re
HFM Data Sources
Be very cautious about using more than one row dimension pulling "Bottom of hier
Since HFM builds the data store on the HFM server, you can severely degrade HFM
performance, or cause "out of memory" failures on the HFM server.
Template Reports
To minimize repetitive design, there is a Row and Column Template functionality,
which is discussed at some length in the documentation. There are limitations
to Row and Column Templates, such as limited formatting options and limitations
on use. The particular advantage of such templates is that you can maintain all
of the related reports at once.
There is a user-based option that does not give the advantage of maintaining a g
roup of reports at one time, but does have the advantage of limiting repetitive
entry and formatting. That option is creating template reports, in which you cr
eate a base report with a group of rows, columns, and calculations you use repea
tedly in reports, but which will vary by report to some extent, and which will r
etain formatting and format heritability.
Create one or more template reports.
Export the report designs from Workspace and save them to a secure location that
is backed up regularly.
When you wish to create a new report using the template, import the desired desi

gn file, and make the necessary changes.

We recommend the preceding steps, because we have seen situations in which a num
ber of reports had been created from a single report. There was an issue with t
he repository, and all of the copied reports were lost. If you import the desig
n every time, the resulting report is not related to any other report, and is in
dependent of any issues with another report.
Safeguarding Reports
Even though your environment has regular backups, there is not a way to restore
a single report that was mistakenly deleted, or had another mishap. A repositor
y restore is all or nothing.
You can safeguard your most important reports and your reports under development
as follows:
Export the reports from Workspace.
Save the resulting XML files to a safe location.
Should there be a mishap with an important report or a report under development,
you can import your backup copy to Workspace
Posted by Stuff at 1:10 AM
S PandaMay 9, 2013 at 6:05 AM
when we run any FR with HFM applications (HFM being using RDBMS) .. is there a w
ay to trace the query running in the rdbms .. any thoughts
David WilliamsOctober 31, 2014 at 5:54 AM
Thanks for Information Our Online-Training-Informatica proven expert in all Hype
rion Modules like Hyperion Financial Management, Hyperion Financial Data Quality
, Hyperion Financial Reporting, Hyperion Essbase, Hyperion Planning, Smart view
and Data Relationship management.Hyperion Essbase Online Training