Oracle EPM Cloud · FCCS · Guidance
The view storage tradeoff, who pays
Quarter and year to date get computed exactly once per change, or freshly at every retrieve. Someone pays either way. This page is the decision, in one table.
What the views are belongs to the View dimension; the slow-grid symptom to Retrieval Performance. This page only decides. The whole reference is mapped on the FCCS index.
◆ The decision— three settings, and when each one is right.
| Setting | When it is right, and who pays |
|---|---|
| Store the views | Many to-date reports, many readers, heavy close-week retrieves. Consolidation runs longer and the application grows, and the bill lands on the administrator's schedule, once per run, instead of on every reader, every time. |
| Compute at retrieve | Few entities, few to-date reports, a lean application worth protecting. The bill lands on the person opening the grid, and stays small only while the reader count does. |
| Recalculate changed entities only | The middle path, and the practical setting once the entity count grows: a late journal to one country reprices that branch, not the whole application. Most groups end here. |
How to change your mind safely: the monthly test window exists for exactly this, one close timed both ways before production feels anything. And in the owned warehouse, the star schema we recommend building beside FCCS on your own cloud, mapped here, periodic lands and to-date derives in the query, so the cube's storage decision stays about the cube.
Nobody remembers who decided this?
We time your close both ways, size the tradeoff for your reader count, and write the decision down where the next admin finds it.
Terms on this page
- stored
- Computed once per change. The administrator pays.
- computed
- Computed at every retrieve. The reader pays.
- the middle path
- Recalculate only what changed. Most groups end here.