A Data Map in Oracle EPM Planning is a configured connection that defines how data flows between two EPM data stores — either between two cubes within the same Planning application (from a Workforce detailed cube to the Financials P&L cube), between two separate Oracle EPM Cloud applications (from Oracle PBCS to Oracle FCCS), or between different scenario or version contexts within a single cube. The Data Map specifies the source data location, the target data location, and the dimensional mapping between them — which source dimension members correspond to which target dimension members when the data is pushed or pulled. Data Maps are executed as business rules (they appear in Calculation Manager as rules of type “Data Map”) and can be triggered manually, via Task List steps, or as part of scheduled automation through EPM Automate.
Data Map Use Cases in EPBCS
| Data Map Type | Source | Target | When Executed |
|---|---|---|---|
| Module to Financials push | Workforce cube (position-level compensation detail) | Financials cube (P&L salary account summary) | After workforce planning approval; before Financials consolidation |
| Capital to Financials push | Capital cube (asset-level depreciation) | Financials cube (depreciation expense account) | After capital plan approval; before Financials consolidation |
| EPM to FCCS push | EPBCS Financials (budget/forecast data) | Oracle FCCS (Budget scenario for variance to actual) | After budget approval; budget loaded into FCCS for consolidation-level B vs A reporting |
| Scenario copy (intra-cube) | Working Budget scenario | Approved Budget scenario | After budget approval; locks approved version while working version remains editable |
| Version copy | Bottom-Up version (entity submissions) | Target version (management overlay) | After entity submissions; management applies top-down adjustments without changing entity versions |
Data Map Dimension Mapping
The dimensional mapping within a Data Map is the most consequential configuration — it defines which source dimension member values are translated to which target dimension member values as data moves between the source and target cubes. Where the source cube has a detailed Account dimension (individual product revenue lines) and the target Financials cube has a summary Account dimension (Total Product Revenue), the Data Map must include an aggregation mapping that sums the detailed product revenue lines into the single summary account member. Where a source dimension does not exist in the target cube (the Workforce cube has a “Position” dimension that the Financials cube does not), the Data Map must define which target dimensions the Position-level data is aggregated to — typically Entity and Cost Centre, which both source and target cubes share.
EPM to FCCS Data Maps for GCC Groups
In GCC enterprises where Oracle EPBCS is used for operational planning and Oracle FCCS is used for statutory consolidation, Data Maps between the two applications enable the FCCS consolidation to include budget and forecast scenario data alongside actual data — enabling budget-to-actual variance reporting at the consolidated group level within FCCS. The EPM-to-FCCS Data Map must account for the difference in dimensional models between the two applications: EPBCS typically uses a management entity hierarchy aligned to how the business is managed, while FCCS uses the legal entity structure required for statutory consolidation. The Data Map’s entity mapping translates between these two hierarchies — mapping management entities to their legal entity equivalents — a configuration that must be maintained whenever the group’s structure changes in either application.
What Goes Wrong in Practice
The most common Data Map failure in production EPM environments is a Data Map that pushes data to the wrong target scenario or version — overwriting approved budget data with working version data, or pushing a forecast to the Budget scenario rather than the Forecast scenario. Data Maps with hardcoded target scenario selections — where the target scenario is configured in the Data Map rather than supplied as a runtime parameter — are particularly vulnerable to this error when the application has multiple scenarios with similar names. Data Map target scenario selections should be validated every budget and forecast cycle before the Data Map is executed in production.
How Loop Wise Solutions Configures Data Maps
We configure and test every Data Map with source-to-target reconciliation — verifying that the total of the source data matches the total pushed to the target across every mapping dimension. Any unexplained difference in the post-Data Map reconciliation indicates a mapping gap or aggregation error that must be resolved before the pushed data is used for reporting or consolidation.
