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.

Change to EPM Software Release Cycle

 Oracle recently made an important announcement for all EPM environments that all administrators need to know.

First, some history, then what's happening, and then the consequences.

In the fall of 2025 the Essbase version in some products was upgraded to 21c. There were some product issues in the October 2025 and there was some communication from a group within Oracle advising customers to skip the updates. Probably more for the confusion as much as product issues, Oracle skipped the November and December 2025 releases and the January 2026 release (which usually doesn't have much anyway as it happens during year end close for the majority of customers).

Now, after further review and I'm guessing out of an abundance of caution, Oracle is skipping the February and March 2026 updates as well. The next scheduled release will be the April 2026 release. If following the normal cadence, the test environments will be updated on April 3 and the production environments on April 17.

So, consequences. The EPM Automate skipupdate command doesn't need to be used to skip these periods like was required for the October 2025 release. But, once April comes the environments will not have been updated in more than three months, so the skipupdate command won't work then either. To skip the April update (quarter end close for a majority of customers) an SR is required and Oracle will have to do it. 

Customers will need to make a choice regarding the test environments. Currently, the test environment is most likely either the same version as production or one version ahead, meaning that an artifact snapshot (application backup) can be moved back and forth. If both production and test are not updated in April, then that will continue but the new version won't be available for testing. If the normal update cadence described above is followed, then the test environment won't be able to import the production snapshot during the two week testing window (more than one version different).

Recommendations. If you want to test the new version in the test environment, do a fresh clone from production to test right before the update gets applied to test (like on April 2). Also consider creating an extra environment so the current test environment can skip the update (if needed to support production and/or migration policies) and the new test environment can get updated (best of both worlds).

Oracle really doesn't love acronyms

This post is a little off topic and definitely not technical. There is something that bugs (software pun intended) me about how many people refer to Oracle's products, including Oracle employees. And this issue isn't related to just Oracle; I see this everywhere, both in tech and non-tech.

Particularly with the Oracle Enterprise Performance Management products with which I work, there are a lot of abbreviations: EPM, ARCS, FCC, etc. And elsewhere in Oracle there are terms like AI, OCI, ERP, and many, many others. You're probably thinking "Yes, yes, we know all these acronyms and use them all the time. So what?"

Well, here's the issue: most of these are NOT acronyms. Really. They are actually initialisms. The difference between an acronym and an initialism is how one pronounces the grouping of letters. If the letters are spelled out individually, like EPM, AI, OCI, etc, then it's an initialism. If the letters are pronounced all together as a word, like ARCS (pronounced as "arcs") then it's an acronym.

If you don't believe me, look it up: here's one link.

https://www.grammarly.com/commonly-confused-words/acronym-vs-initialism

Epilogue: out of curiosity, I checked a free version of ChatGPT to see if their AI had any self-awareness. Looks like not yet.

Update: same happens with Google Gemini.

Oracle Cloud EPM - Renaming Stuff

Like most people I'm learning new things in Oracle Cloud EPM all the time. Many items (probably like this one) are most likely things that others have known for years and take for granted. Anyway, here is something I recently ran across that's a followup to my February 2025 post about migrating away from Financial Reporting.

Once all of the migration work is done for the reports, users should go to the Reports tab within the Reports card and not the Financial Reporting tab which unfortunately still shows.

The Financial Reports tab will be there until Oracle takes it away. Having it there may be a temptation for users to keep going there out of habit. We could delete the reports or change security to them all, but if they're needed during the first cutover close, either of those options would slow things down. So, here's an idea.

There's a menu item under the Tools cluster called Artifact Labels. This screen allows renaming practically anything. Well, at least within the web interface as the renaming occurs by browser language. The idea is for language translations or making something user friendly if the real label or name is cryptic.

So, go to Tools > Artifact Labels and click the Filter icon. From the extensive list (and you'll see you can rename just about everything), select Tab. Use the Add Language dropdown to select the desired browser language. Then scroll down to the Financial Reports line and enter the desired text and click Save.

When renaming a navigation flow item like this, closing the browser and logging back in may be necessary. But now, when a user goes into the Reports card, they see this.

The tab still works and the reports are all still there and work but hopefully the users get the hint.

For more extensive changes, create a line item like above and then export to CSV, make more changes, and then import as shown above with the Actions dropdown.

I'm thinking all of these renames could get out of hand but when used thoughtfully this is a great hidden gem of a feature.

FCC Consolidation Status - "Completed" does NOT mean Successful

UPDATE - September 2025 - this is looking to be fixed. A consolidation with this error now shows Error on the main jobs screen.

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.