Currency, and the column that is not optional

Two multicurrency builds, one downstream rule: every number must carry its currency, or nothing downstream can trust it. The build decides where conversion happens, and the export decides whether the answer survives.

Note: In Planning, Oracle's budgeting and forecasting module, multicurrency comes in two builds, simplified and standard, and the choice decides how rates are stored and what an export carries. This page is that choice and its consequences.

The whole module is mapped on the Planning index.

RuleEvery exported number carries its currency; conversion for analysis happens once, in the warehouse, on the shared rate table.

Neverexport converted values without the currency column and the rate source. An unexplainable USD number is worse than a local one.

◆ The two builds, downstream, simplified, standard, and the shared rule.

Build	What it means downstream
Simplified multicurrency	One Currency dimension, rates in the cube, conversion at retrieval for reporting currencies. Lighter to run; the export carries entity currency and lets the warehouse convert, which is where conversion belongs anyway.
Standard multicurrency	Currency plus a separate rates cube and stored converted values. Heavier, older, still common in migrated apps. Exports must say which currency a number is in, or the warehouse merges apples into oranges.

The operating rule is the same either way: every exported number carries its currency as a column, and conversion for analysis happens once, in the warehouse, with the same rate table the close catalog pages use. The sixty-entity world plans in local currency and reads in USD; the Chilean subsidiary 1010-CL plans in pesos, which is exactly why the column is not optional.

THE USE CASE, SIMPLIFIED

The problem: Two reports convert the same plan differently and both look right.

What we build: Numbers export in local currency with their currency column, and one rate table, shared with the close data, converts them in the warehouse.

What you get: Every report converts identically, because conversion happens once, in one place.

Plan in five currencies, reports arguing about rates?

We land local-currency plan data with one conforming rate table, and every report converts the same way because there is only one way.

Talk to us

Terms on this page

simplified: One dimension, retrieval-time conversion. The lighter build.
standard: Rates cube, stored conversions. Common in migrated apps.
the column: Currency on every exported row. Non-negotiable.
one rate table: Shared with the close catalog. One truth for rates.