The consolidated data export, one honest slice
Everything this reference teaches about the dimensions becomes one practical question at export time: which exact slice of the cube leaves the building? Cut it right and the warehouse ties forever. Cut it wrong and it double counts by design.
First of the two export pages in the FCCS reference. The general routes out of EPM live on the extraction pattern, the automation on the EPM Automate page, and the whole reference is mapped on the FCCS index.
◆ The slice, dimension by dimension— every choice the dictionary pages already explained, applied at the door.
| Dimension | What to export, and why |
|---|---|
| View | FCCS_Periodic, always. The to-date readings contain the periods they accumulate, so exporting them alongside periodic is the double count. Derive quarter and year to date in the warehouse, where accumulation is one line of SQL. The trap has its own page, the View dimension. |
| Currency | One currency per file: entity currency in one export, each reporting currency in its own. They are separate translations of the same facts, and a file that mixes them is a file that sums them eventually. The Currency page explains why each stands alone. |
| Consolidation | Pick the member that matches the question. Entity Input for the local books as loaded, Contribution for what each child hands its parent. Exporting the whole belt and summing it recounts the same money at every step. |
| Data Source | The parents here, total input and adjusted, total eliminations, total data source, are dynamic calculations per Oracle's own dimension reference, and dynamic members export nothing. Take the level-zero children, loads, journals, and the elimination members, each in its own rows, and the audit split survives the trip. |
| Movement and Intercompany | Level zero again: your movement detail plus the system's opening, FX, and closing members as separate rows, and base partners with the no-intercompany member. The rollforward and the matching query both depend on this grain arriving intact. |
◆ The job, and the traps at the door— how the export actually runs, and the three ways it silently lies.
| Topic | What to know |
|---|---|
| The mechanics | An Export Data job saved in the application, run on schedule by EPM Automate, downloaded, dated, and shipped to your cloud storage. The script kit on the commands page is exactly this, six lines to fill in. |
| Trap one, the empty export | A job pointed at a dynamic parent returns nothing, no error, just an empty file, and the pipeline happily loads zero rows. Point jobs at stored, level-zero members, and alert on row counts, not just job success. |
| Trap two, the stale export | Data exported while entities sit Impacted is last run's truth wearing today's date. The publish gate is the status check: every entity OK for the period, or the export waits. |
| Trap three, the moved member | Renames and moves in the dimensions change what the job's member selections mean. After metadata work, re-verify the job definitions; a documented release-note history of elimination members not clearing correctly in unusual tree shapes is one more reason the tie-out below exists. |
The proof the slice was cut right: the exported rows, summed per entity, tie to the consolidated trial balance the application shows, entity by entity, period by period. That tie-out runs as a gate in the owned warehouse, the star schema we recommend building beside FCCS on your own cloud, mapped here, before anything publishes. Member storage behavior and export mechanics verified against Oracle's dimension reference and documentation, July 2026.
- the slice
- One member per overlapping family, level zero, periodic, one currency.
- dynamic parent
- Computed at retrieve, stored nowhere, exports as nothing.
- row-count alert
- The check that catches an empty export before the warehouse does.
- the tie-out gate
- Exported rows equal the application's trial balance, or nothing publishes.