Reports Design

Designing effective reports helps support useful insights and decision-making. Here are some best practices for report design and management.

Follow these general design guidelines:

• Before building reports, plan how to report on your financials for management and determine how many different report formats are required. Report formats specify the layout of the report, such as which elements are on the rows and columns. Report formats can be used to create many different reports, such as by cost center or division.

• To simplify building reports, specify a report format for each type of report you need. For example, build your income statement and other detailed reporting with the formatting that your management team is accustomed to reviewing.

• First set the report dimension layout and member selections. Next, get the report to capture the data. Finally, apply formatting.

Answer these questions to determine the most effective design:

• How many individual reports are required, where a single report (such as an Income Statement) can be run for multiple POVs?

• What is the maximum number of users that will be running reports frequently within the same time frame at peak times? What is the frequency of running different sets of reports?

• What types of cubes are going to be the data source for the reports? For example is an ASO reporting cube going to be utilized or BSO/BSO? If you are using BSO/BSO, consider the query performance impact of using dynamic calc storage on sparse dimension parent and formula members. Do any of the cubes contain a large amount of dimension members that need to be reported on?

• Try to avoid writing relational-type reports, where possible. A good indication of relational-type report is one with multiple row dimensions that are expanded using member selection functions such as Descendants or Bottom Level which return a large number of cells. A report is considered big when the number of cells starts getting into the tens of thousands and above. Consider using Suppress Missing Blocks with this type of use case.

• How many books and bursting definitions are required?

  Are larger books required, which contain many reports or reports run for a large number of members? Consider the book governor limitations and potentially longer book processing times when creating large books.

  What is the number of members bursted across a dimension for larger bursting definitions?

  How many bursting definitions are planned to be run at peak times? Do you plan on running bursting definitions using EPM Automate or REST APIs? If so, consider the performance impact when doing this.

For additional information, refer to Designing Reports in Designing with Reports for Oracle Enterprise Performance Management Cloud.