Logging into a test EPM environment after the 25.02 release (February 2025), I saw this message.
Eric Erikson's Oracle EPM Blog
Monday, February 10, 2025
Financial Reporting - Another Nail in the Coffin
Monday, January 13, 2025
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.
Tuesday, August 13, 2024
Kscope24 Speakers' Awards
Wednesday, June 5, 2024
Happening Now: ODTUG Board of Directors Election
Friday, May 31, 2024
FCC - Showing Calc Status on a Report
Friday, May 24, 2024
When was the last data load?
I had a request recently for a simple way for users to know when the last data load occurred. They could go into process details or jobs, maybe, but was there a simple way to check from within a report, data grid, or even Smart View. There may be something better, but here's what I did.
I created an account called LL_DateTime. I originally was going to put the year in one account, month in another, etc. but I ended just using the one account.
Within data management (this part isn't in the new interface yet) I created a logic group to duplicate a record. I picked a retained earnings account for one of the primary legal entities so there would always be a data point to duplicate.
After assigning the logic group to the location, I used a SQL map to change the amount. The two SQL functions in use here are SUBSTR (get a subset of a string) and SYSTIMESTAMP (date and time on the server).
The SYSTIMESTAMP returns a format of 28-MAY-24 02.34.56.654321 PM -00:00 which isn't something we would be able to load as an amount. So SUBSTR is used to pull out pieces of this and to combine them into something useful. There are a few components that need mapping. The month of May needs to be converted to a number. The AM/PM indicator needs to be converted to a 24 hour clock (again, trying to load the date and time as one amount. There are a couple of different WHENs in use to direct the calc (if May, then 05; if PM, then add .12 [12 hours]). Admittedly there is probably a more elegant way of converting the month to a number without having to enumerate all of the options.
So, the format of the output looks like this: 20240528.1434. This is an easy number to load and report.
The last part of the output (00:00) indicates the timezone. In this case, it is UTC. This could be converted to a specific timezone but in the case of worldwide users, most people would have to convert anyway. It's better to just use UTC and let each user deal with summer time, etc.
The last part of the puzzle here was to create a simple data grid with all of the point of view members locked except for the year and period. This way users can check and see when the data was last loaded. They can also replicate the point of view and use Smart View, etc.
Friday, April 19, 2024
EPM Cloud Data Integration - Dealing with [Parent].[Child]
Another day, another solution to remember for later.
When moving data from one application to another, shared members can sometimes flow through the integration with [Parent].[Child] notation. If loading the child member to the target application and the target does not have the same hierarchy, then this won't work. Or, like I did today, when loading entity elimination data from FCC to Planning, then only the parent entity is needed.