Oracle Cloud EPM - Financial Reporting finally being terminated

After multiple years of notice, Oracle has announced the end of the Financial Reporting report module in the Oracle Cloud EPM products.

Dave Roberts (Oracle product manager) shared the announcement to remove Financial Reporting. All of the Financial Reporting references, user interfaces, and content will be removed in the 27.02 (February 2027) release. This will include the repository (where the reports are stored) and FR studio (the report editor/builder). So these Navigator links and the Financial Reports tab in the Reports screen will be gone.

The worthy successor to Financial Reporting, simply called Reports, has been in the Cloud EPM suite since 2021 and has built on and exceeded the capabilities of Financial Reporting in many ways. When I worked at Hyperion I saw beta versions of Financial Reporting starting a year before it was released and saw how it out-performed the previous report writer (Hyperion Enterprise Reporting). Now it's time for Financial Reporting to move on as well.

There were a few clarifications in the announcement where Financial Reporting is not quite disappearing yet. This sunsetting does not impact Fusion Cloud ERP, legacy Profitability and Cost Management, and the Hyperion on-premise solutions. There are no plans to move Reports to on-premise and my guess is that Fusion and PCMCS will eventually get Reports.

The Reports module has been in the suite since 2021 and is a great successor. If EPM customers haven't been using it and are still using Financial Reporting, this announcement should be enough of a reason to finally migrate. For details on how to do the migration, refer to my blog post from February 2025 - link provided here: https://ericerikson.blogspot.com/2025/02/financial-reporting-another-nail-in.html

And for Oracle documentation on the differences between Reports and Financial Reporting and the migration, go to this link: https://docs.oracle.com/en/cloud/saas/enterprise-performance-management-common/dmepr/appendix_b_migration_of_reports_from_financial_reporting.html

Oracle EPM Reporting - Trick for Period Reporting

A fellow consultant reached out for help on solving a problem with building a report with a specific requirement regarding periods in the columns. Like many things here on the blog, I'm adding the solution here for everyone (including me) to reference and find in the future.

The problem involves reporting a range of periods. The customer wanted to select a period in the point of view and then show the remaining periods in the quarter (not the year, which would be a simple RANGE function). So (assuming a calendar year setup) if the user selects January then show February and March and if the user selects February then only show March. With Essbase calculation scripting there are functions called LSIBLINGS and RSIBLINGS that can do this (show siblings before and after the current member). But in reporting, either within Narrative Reporting or within Reporting within the applications, there are no such functions.

My initial thought was to specify all the periods in the columns and then apply a bunch of conditional suppresses. It would work but I knew there was a better way, so I reached out to super star Opal Alapat for help. 

So, here's what to do: use the INTERSECT function. The function returns all members that meet all of a list of specified criteria. The issue is figuring out which criteria to use where the combination yields the desired result.

For this particular problem, there are two criteria to specify. First, use the SIBLINGS function to return all of the siblings of the current point of view period (which will be user specified). If a user selects January, this function will return February and March (which coincidentally meets the requirement). But if the user selects February, the function returns January and March (which doesn't work).

The second criteria filters out the prior periods. Use the RANGE function to show periods from the current point of view to December (or the last period if a non-calendar application). So if the user point of view is February, then this function will return all months February to December.

This is where the magic of the INTERSECT function comes in. The function looks at the two criteria and returns only the members that are in all the criteria sets. Here's what it looks like in the member selector and after returning to the grid.

And after clicking OK, the function shows this way in the report grid.

The solution works well: both easy to set up and understand. And avoids the hassle of creating a bunch of conditional suppresses.

Bonus: If there is a need to report months before the current point of view in the quarter, then change the RANGE to go from January (or the first period) to the current point of view.

Financial Reporting - Another Nail in the Coffin

 Logging into a test EPM environment after the 25.02 release (February 2025), I saw this message.

Oracle announced in the release notes that support for Financial Reporting in EPM is ending in June 2025 and this message is a confirmation. As noted above, this transition has been planned for some time now.

Fortunately, it's not a hard process to convert existing Financial Reporting reports to Reporting. But before trying to migrate reports, check first that they run and have no errors (if a report doesn't work now, it's not going to work later). Also check with the users about which reports need migrating.

Click the Navigator and go to Reports. On the Financial Reports tab where the FR reports are listed, there is an icon on the far right for each report for migration. Click the icon to begin the migration.

When prompted, click on the desired folder for the new report. If the folder isn't there, then cancel, create the folder on the Reports tab, and then run the migration.

After the process runs, a confirmation message is shown.

There is also a way to migrate all of the reports at once. Click the Migrate All button at the top right. Choose the top level destination folder and optionally select whether to recreate the existing folder structure.

The status of the process can be seen in the Jobs screen.

A common sense approach would be to migrate everything, deal with any issues (see below), and then migrate individual reports again if they require updating before the conversion is complete.

This process seems too easy, right? The documentation - link below - has two pages on (a) dealing with migration errors and (b) the differences between the two reporting tools. Depending on the report design and build, there may significant work still to do.

https://docs.oracle.com/en/cloud/saas/enterprise-performance-management-common/dmepr/epm_cloud_migrating_reports_from_financial_reporting.html

So the next step, even if no errors are reported, is to edit each report and check for validation errors (open the report in edit mode and see if the red bar shows at the top of the screen) and verify the output with three objectives: does the report run, is the content correct, and is the formatting correct. 

For example, open a report in edit mode and you may see something like this:

When I've done the migration, I've noticed that the report/folder security within Financial Reporting is not copied over. I can't say whether this is normal, but also plan to verify and apply security as needed.

Last, the Financial Reporting books do not migrate. These will need to be recreated.

Admins should start on this migration soon if they haven't already. When Oracle refers to the "June 2025 (25.06) update" above, remember that does not mean the end of June - it's the third Friday in June. 

FCC - Showing Calc Status on a Report

With HFM and Financial Reporting, there is a function that pulls the calculation status into a report. This is useful for those who want to ensure the data has been consolidated when looking at the results. I've seen conditional formatting used in conjunction with this to alert the users that the data is suspect if the consolidation hasn't been ran.

With FCC and Reporting/Narrative Reporting, there isn't such a function. But there's still the same need. I filed an idea lab submission to request the function. I thought I (and my clients) was out of luck, but then I thankfully ran across a simple solution, and it's built in!

When building the report, look at account FCCS_CSTATUS FILTER. This account just doesn't give you some number that you have to convert - you get the proper text status. Along with specifying the account, you have to set the point of view to FCCS_No Data Source (which isn't used often) and FCCS_No Movement. The rest of the point of view should be normal for other data retrieves, but the intercompany and custom dimensions should be set to FCCS_No Intercompany or No custom.

When the report runs, it looks like this. Note this report is also showing the out of balance amount. The column headers for the data source and the movement are hidden. Not shown, the rows for the report are level 0 entities.

And being an account, this means that the calculation status can be pulled into Smart View with either ad hoc or functions, which is a big bonus.

Reporting - Managing the POV - Grid/Global and Hide/Not Hide

Just spent five minutes figuring out how to manage the point of view in a Reporting (not Financial Reporting) report. One would think this would be simple. For the most part, it is, but not always.

When a grid is open, the point of view displays along the top. The word Default (as shown below for the Period dimension) means to prompt the user for the member selection at run-time. Choosing something else will lock the dimension to that member. Clicking the vertical ellipse icon on the right side of the dimension opens a menu. Reset to Default is straightforward - the member gets cleared and the below choices get reset. Hide Dimension suppresses or doesn't show the dimension and the selected member. In case you're wondering, if the dimension is set to Default AND the dimension is hidden, the first member in the dimension (likely the dimension name) gets used.

The last selection is whether the dimension is Global or not. If Global, then the dimension and the selected member will apply to all grids in the report. If Global is not selected, then the dimension setting is specific to that grid. If not global and not hid, then the dimension and the current selection will show at the top of the grid within the report when the report is run and users can change the member.

So far so good. The problem comes when you want to change things. The order of the selections should not matter - set the member, hide/unhide, or global/not global. But that is not the case. Here, the member is selected and the dimension is global, but the option to hide or not hide is greyed out. If you turn off Global, then Hide is still greyed out.

The solution for this is to reset to default and start over. After the reset, verify Global is selected, set the member, and then select Hide.

In the end, the initial build is easy enough, but if a change is needed, it isn't really a change: it's a start over.