FCC Consolidation Status - "Completed" does NOT mean Successful

FCC has a similarity to Microsoft Excel on manual calc. Change data, then press F9 for the calculations/formulas to run. In FCC, the similar process is consolidation, just like it was in its predecessors MicroControl, Hyperion/Enterprise, and HFM. This process is central to how all four products work. Unlike those great products of the past, however, FCC consolidations have one big deficiency: the status reporting. Did the consolidation work or not? Without going to multiple screens, you don't always know.

Look at these two consolidation results from the Jobs listing. One of them failed and one succeeded. Can you tell which is which?

Looking at the details of one of the consolidations, can you tell now? No, you can't.

Actually, this consolidation failed. Clicking the word "Completed" shows that the consolidation didn't even run.

It could be that "Completed," internally, means someone started the process, the process started running the software code that Oracle told it to do, and the code reached the end of the process. Whether the process actually encountered an issue during that; well, that's up to you the user/admin to figure out. In my mind, this is like saying whether I have eaten. I start the process of eating: something goes in mouth, I chew, I swallow. Ok, I ate something. Did I like it, did I hate it, did I get sick, did I eat something poisonous and die, am I still hungry: who knows.

I posted an enhancement idea on Oracle Cloud Customer Connect on this over four years ago. Maybe everyone is okay with this level (I want to use other words here but am trying really hard not to) of status reporting. I'm thinking that Oracle can do better. If you want to upvote the idea - please do -  here's the link:

https://community.oracle.com/customerconnect/discussion/558521/consolidation-jobs-should-indicate-error-not-just-complete

Since FCC has been reporting consolidation status this way for so long, you'd think everyone would know about it. That's not true - I just had this conversation with a client today. The issue appeared in downstream processes: reporting was weird, data wasn't correct, etc. So if your consolidations run but you don't get the results you expect, unfortunately a little digging is required.

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 - Loading data as admin not working (issue, workaround, and fix)

Some FCC applications have an issue where data loads done with an admin ID are not calculating correctly after the data load. What is happening is that the data status isn't correctly being set to impacted and so the subsequent calculation/consolidation doesn't bring forward opening balances, calculate movement, etc.

The workaround for this is simply to do the data loads with a non-admin ID. Or do something that impacts all status, like a database refresh.

Sources tell me that Oracle is planning (safe harbor statement applies) to do an off-cycle update to the test environments this week, probably on Jan 14. Once that happens, admins can test the fix in the test environment and then file an SR to request that their production environment gets an early update. Both the test and production updates would happen during the daily maintenance cycle, which can either be run on the normal schedule or on-demand using EPM Automate. Or, if the early update is not desired, then continue with either workaround until the regularly scheduled production update.

Update: Jan 14: The test pods were updated to 25.01.31 overnight from 25.01.30. Early testing is showing the fix to be in place.