Best Practices for Hyperion Financial Reporting (FR) Report Design (Doc ID

1196695.1)




Abstract

History
Authors:
Create Date:

Details
All Data Sources
Estimating Report Size
Essbase or Planning Data Sources
HFM Data Sources
Template Reports
Safeguarding Reports

Summary
Purpose
Scope

APPLIES TO:
Hyperion BI+ - Version 9.0.0.0.00 and later
Information in this document applies to any platform.
ABSTRACT
The purpose of this document is to provide Best Practices for Financial Reporting Report design. It assumes
that you are a report designer for Hyperion Financial Reporting, and are acquainted with Financial
Reporting Studio and general Financial Reporting terminology.
HISTORY
Authors:
Sharon Morris
Kathleen Hardin
Create Date:
September 1, 2010
DETAILS
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 requirements. There is a
great deal of flexibility with Essbase cube design. There is somewhat less with HFM databases and
Planning databases and cubes, since both of those 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 POV.
To set a value in the Grid POV that users cannot change, take the following steps:
1. Click on the Grid Corner to highlight the grid.
2. In the Grid Properties pane, check "Grid Point of View".
3. In the Point of View display in the grid, make the desired selections. For the dimensions to
be available to users, leave the value as "User Point of View".
4. 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.
Callouts
o Instead of expansions, use Related Content.
If you want to see detail from a high level in a report, you can use Related Content reports,
which are related detail reports containing detail information for the member in the calling
report. The related report will pull the point of view 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 section, you
include Asset Purchases, which are an alternate rollup of Fixed Assets . 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 Hierarchy for
Account". The "Current Point of View for Account" is Asset Purchases, from the calling
report.
o Minimize the number of row selections using "Descendants of".
If you have more than two dimensions in the rows that are calling Descendants, you can
quickly produce an excessively large data set that Financial reporting cannot manage, and
your report will not run. You also run the risk of slowing performance at the data source if
the data source needs to provide a very large number 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 selection 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 large one.
o A report should not require more than 30 or 40 data rows to facilitate maintenance.
Similarly, columns should be kept to a manageable number. There is a limit of 256 columns
in a report. There is no fixed limit to the number of rows.
o Most calculations should be done at the data source.
o Basic suppression at the data source reduces the number of data intersections pulled into
the report. Always do Basic Suppression separately from Advanced Suppression.
Estimating Report Size
You can estimate the number of data intersections in a report using the following formula:

(# of members in dimension1) * (# of members in dimension2) * (# of members in dimension3) ... *
(number of data rows) * (number of data columns)
o Each dimension in the grid acts as multiplier, including dimensions in the rows, columns and
pages.
o You determine the number of members in a dimension by expanding the dimension until
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.

o Dimensions in the POV do not act as multipliers. The members are pulled into the report
only once.
o 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
Children of
Measures
Descendants of
Market
Level 0 of
Product
Children of
Year
nnn nnn

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 be 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 or Planning Smart Lists
in your report.
When you use a Planning Details Data Source, Financial Reporting goes to Planning 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 execution time.
Use Substitution Variables to make your reports dynamic.
If your rows or columns contain multiple dimensions, put the dense dimensions first. Doing so will
minimize the number of data intersections pulled into the report.
HFM Data Sources
Be very cautious about using more than one row dimension pulling "Bottom of hierarchy".
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 group 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 create a base report with a group of rows, columns, and calculations you
use repeatedly in reports, but which will vary by report to some extent, and which will retain formatting
and format heritability.
1. Create one or more template reports.
2. Export the report designs from Workspace and save them to a secure location that is backed up
regularly.
3. When you wish to create a new report using the template, import the desired design file, and make
the necessary changes.
We recommend the preceding steps, because we have seen situations in which a number of reports had
been created from a single report. There was an issue with the repository, and all of the copied reports
were lost. If you import the design every time, the resulting report is not related to any other report, and
is independent 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 repository restore is all or nothing.

You can safeguard your most important reports and your reports under development as follows:
1. Export the reports from Workspace.
2. 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.
SUMMARY
Purpose
This paper provides basic information for creating efficient, maintainable Financial Reporting reports.
Scope
This paper is a basic guide for efficient design, with tips on safeguarding your reports.