Oracle EPM Data Integration Reporting

Jul 7, 2026

Turning Oracle EPM Data Integration Reporting into a User-Friendly Self-Service Process

Turning Oracle EPM Data Integration Reporting
into a User-Friendly Self-Service Process

Predefined Data Management reports, custom Non-Consolidation Reports, Groovy and Pipelines

A practical architecture for making source-to-target reporting available to non-administrator users.

Core idea: Oracle already provides the reporting components. The missing piece is a secure orchestration layer that exposes them to users without granting unnecessary System Administrator access.

Bertold Bicsak | Oracle EPM Cloud & Financial Systems

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:

Data Integration → Actions → Other → Report Execution

Figure 1. The standard Data Management Report Execution menu in Data Integration.

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.

Figure 2. A named connection can be used by the Groovy business rule to call the reporting service.

Figure 3. Oracle provides several predefined Data Management reports that can be invoked by the automation.

· 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.

Important limitation: Predefined reports are efficient and reliable, but their layout is fixed. Columns, labels, order and formatting cannot be redesigned to match a company-specific reconciliation or audit requirement.

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.

Figure 4. A custom report query can be created in the reporting setup area.

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')

Figure 5. Example of a parameterized report query using TDATASEG and related Data Management tables.

Design note: The exact columns selected from TDATASEG should be limited to the fields users actually need. This improves readability and avoids publishing technical columns that do not add value to the reconciliation process.

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.

Figure 6. The report definition connects the query, RTF template, output format and runtime parameters.

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.

Figure 7. The custom report becomes available from the Reports interface for authorized users.

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

Recommended pattern: Use the predefined reports when the standard layout is sufficient. Use a custom Non-Consolidation Report when the organization needs a specific set of source and target columns, a branded RTF layout or a reconciliation-focused output.

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.