The reporting challenge
A common Oracle EPM Cloud challenge is not the availability of data, but making it accessible in the right format to the right users. Finance teams often need to review the records loaded through Data Integration or Data Management (FDMEE), including the original source values, mapped target members, load rule, location, period and category.
The standard Data Management reports already provide much of this information and are available from:
The limitation is access. The Report Execution option is normally available only to System Administrators. As a result, controllers and local finance users may depend on an administrator even when they only need to generate a report for a data load they are already authorized to run.
Option 1: expose the predefined reports through Groovy
The fastest solution is to keep the predefined report and place a Groovy business rule in front of it. The rule collects the required parameters and calls the reporting service through a named EPM connection.
- Users run a business rule instead of opening the administrator-only Report Execution page.
- Runtime prompts can capture Location, Data Load Rule, Period and Category.
- The rule can generate the report, save the output and make the file available for download or email delivery.
- The same rule can be attached to a Pipeline so that reporting becomes part of the end-to-end data-load process.
Option 2: build a custom Non-Consolidation Report
When the output must be redesigned, the Non-Consolidation Reports framework provides a more flexible alternative. Although the configuration is located within the Task Manager reporting area, the report query can access the Data Management staging tables, including TDATASEG. This makes it possible to build a user-facing report that contains both source and target information.
A practical custom solution has three building blocks:
- A parameterized report query that retrieves the required rows and enriches them with Location, Category and Data Load Rule information.
- An RTF template that controls the report design, column order, headings, branding and pagination.
- A report definition that maps the query parameters and publishes the output under Reports, where authorized users can execute it.
Querying TDATASEG with business context
TDATASEG contains the staged Data Management records. Joining it to the relevant reference tables adds readable business context such as the Location name, Category and Data Load Rule. A simplified parameterized pattern is shown below:
SELECT d.*, p.PARTNAME AS LOCATION_NAME, c.CATNAME AS CATEGORY_NAME, r.RULE_NAME AS DATA_LOAD_RULE_NAME FROM TDATASEG d INNER JOIN TPOVPARTITION p ON d.PARTITIONKEY = p.PARTITIONKEY INNER JOIN TPOVCATEGORY c ON d.CATKEY = c.CATKEY INNER JOIN AIF_BALANCE_RULES r ON d.RULE_ID = r.RULE_ID WHERE p.PARTNAME = '~POVLOC~' AND c.CATNAME = '~POVCAT~' AND r.RULE_NAME = '~POVRULE~' AND d.PERIODKEY = TO_DATE('~POVPERIOD~', 'YYYY-MM-DD')
Designing and publishing the report
After validating the query, generate a sample XML file and use it as the data model for the RTF template. The RTF file becomes the presentation layer: it can contain company-specific headings, source and target columns, mapping results, totals, page breaks and branding.
Once published, the custom report appears in the Reports area. Users can execute it directly based on their assigned access, without opening Data Integration administration screens.
Pipeline and email automation
User access through Reports solves the self-service requirement, but the same custom report can also be invoked by Groovy. This allows the report to become a controlled step in an EPM Pipeline and supports automated file delivery.
- Run the data load and validation steps.
- Pass the Pipeline parameters to the Groovy rule.
- Generate the predefined or custom report.
- Save the output using a meaningful file name containing the Location, Rule and Period.
- Send the file to the Pipeline initiator or another approved email address.
Which approach should you use?
| Requirement | Predefined Data Management report | Custom Non-Consolidation Report |
|---|---|---|
| Speed of implementation | Best choice | More configuration required |
| Custom columns and layout | Very limited | Full control through query and RTF |
| Direct business-user access | Use Groovy as the front end | Available under Reports |
| Pipeline integration | Yes, through Groovy | Yes, through Groovy |
| Email delivery | Yes | Yes |
| Best use case | Standard load-detail and audit reports | Company-specific reconciliation or source-to-target extracts |
Why this matters
This is more than a reporting workaround. It creates a controlled self-service process around Data Integration and reduces unnecessary administrator dependency.
- Finance users can validate data loads faster.
- Source-to-target mapping becomes more transparent.
- Audit and reconciliation evidence can be generated consistently.
- Pipelines can deliver the right report automatically after processing.
- System Administrator access remains restricted to the users who genuinely need it.
Oracle EPM already contains the main components: Data Management reporting, TDATASEG, report queries, RTF templates, Groovy, connections and Pipelines. Combining them turns an administrator-centric function into a secure, repeatable and user-friendly reporting service.