Comparative analysis of financial data over multiple periods and years with more flexibility just got a lot easier with FCC’s new feature called SingleTime dimension. This is a system replacement dimension that combines the period and year dimension. For example, Jan (period) and Year (FY23) becomes Jan2023 (think of the way the Cloud ERP period dimension is displayed in smart view). This allows the use of the relative function for any range of period or year combinations.

Below are the steps required to enable this functionality and an example of how this can be used in a data form.

Enabling the Application Feature

For new applications, this can be enabled during the application creation process. For existing applications, you can enable from the Enable feature page under application configuration. Check the “Combine Year and Period as a single dimension” feature to enable.

Application in a Data Form

• Create a new data form
• Check SingleTime under the properties tab
• When the feature is enabled and the SingleTime is checked on a data form, two new functions (Relative and Relative Rage) will be available under member selector.
• Under the Layout tab, Move the SingleTime dimension to the row/column.
• Add the first Time column and add additional columns, using the relative function (+ for future periods and – for previous periods) in relation to the first column.

Data Form – Data Review

• From the screenshot below, you can display the single periods and offsets using the relative function, where applicable on the form, which allows you to cross multiple years.

Limitation/Conditions

• Only available in Dense/Sparse (DSO) FCC applications.
• The SingleTime dimension is only available in data forms (including when opened via Smart View).
• When the SingleTime property is checked, the period and year dimension will not be selectable.

For more detailed information, see the Oracle FCC Admin Guide

Introduction

Some balance sheet accounts are translated at historical rates, meaning that the standard balance sheet translation methodology using the period end rate does not apply. This is one of the requirements unique to foreign entities in a multi-currency organization.

FCC provides 2 options to override the standard translation for these accounts.

1. Historical Rate Override
2. Historical Amounts Override.

For the override entry to correctly override the translation amount in FCC, the override rate/amount must be entered at the same intersection (all dimensions) where the functional currency activity exists. The overrides amount entered (for the reporting currency) only overrides the current period activities.

This blog focus on the required configuration in Data Management (DM) for loading override data.

 Account Property

• The Exchange Rate Type property for the account should be set to Historical Amount Override or Historical Rate Override

• Add the Currency dimension with the Expression set to “USD”

Create USD Override Location with the following settings

• The Currency dimension should be set to the required reporting currency. In this example, USD
• The Expression “NZP” in the Amount row allows you to load zero amount, if required

• Update the source and target mapping for all dimensions. It is easier to pre-map the dimensions in the data load file

• Upload the override file and save

• Execute the DLR for the specified POV

• Below is the USD Override data in workbench after successful data load
• Notice that the Currency columns is USD

• The screenshot below shows the pre-USD override input for entity 3000 (GBP). With a period-end rate of 1.350518. On translation, £20,000 = $27,003 in the common stock account
• When a USD override amount of $28,000 is loaded from DM, the new translated amount in USD reporting currency equals $28,000 (overriding the pre-override amount of $27,003)

Summary

In organizations with lots of periodic activities in the historical accounts, DM is the most efficient tool for loading the override data compared to data forms. This also offers a reference point as all loaded override amount can be viewed in Workbench.

Introduction

The exchange rate is essential for consolidation and translation in a multi-currency FCC application. The data can be submitted using the pre-built data forms or loaded directly from source systems (direct integration or via flat file) using Data Management. We will be covering exchange rate data load configuration and process for a flat file using data management

Exchange rates data is loaded to the Rates cube in FCC. This cube does not use all the dimensions in the Consol cube. Below are the relevant dimensions in the rate cube

Example of TCI journal entry in FCC

Exchange Rate Import Format

• Create an import format based on the exchange rate source file
• Add the View dimension and set the expression to “FCCS_Periodic”

• Create Exchange Location with the following settings
• Note: The functional currency should be set to the application currency. In this example, USD

• Map the average rate and end of month rate accounts in the source file to the equivalent accounts in FCC

• Map the ISO currency codes in the source file to the equivalents in FCC. Use the like mapping below.
• Note: The currencies in the source file must exist in the target FCC application. If this is not the case, they must either be added in FCC or set to IGNORE

• Map Entity to FCCS_Global Assumptions

• Ensure that the Target Cube is set to “Rates”
• Upload the exchange rate file and save
• Execute the DLR for the specified POV

• Below is the exchange rate data in workbench after successful data load

View Loaded Exchange Rate in FCC – Using Data Form

• Use any of the prebuilt data forms to verify the exchange rate data loaded from DM

Summary

The accuracy of the exchange rate data between source and consolidation system will impact the degree of variation in FX calculation and CTA. Factors like the number of decimal places are important considerations.

Automating the exchange rate load process, using DM will reduce the human error that may result from a manual input

Introduction

The consolidation process for the finance organizations could be as easy as a simple aggregation of data in a single currency organization to complex ownership structure in a multi-currency organization, multiple reporting standards, etc.

One of the functionalities available in most consolidation applications is the ability to make adjustment/reclass to close the books using a journal module (often referred to as “topsides”). The journal entry requirement could range from a simple reclass, unbalanced (one-sided entry) to entries in a currency different from the functional currency of an entity.

In legacy Oracle Hyperion Financial Management (HFM), one of the journal entry scenarios is the parent currency adjustment (PCA), which provides the ability to post an entry using the currency of the parent rather than an entity’s own functional/base currency.

While PCA allows you to skip the time-consuming effort required to figure out the why this type of entry is needed in the first place, the fact that a PCA entry inextricably tie the data intersection to parent and child entity makes reorganization difficult in the future.

And this is where Oracle FCC “Translated Currency Input” (TCI) journal entry functionality comes in. It provides the same functionality as PCA to post an entry in a different currency, while also removing the restrictions on “parent.child” entity requirement of HFM. The data intersection for the base entity is independent of the parent and re-organization of the entity structure in the future will not be impacted

FCC Configuration Requirements

The following steps are required to enable TCI in Oracle FCC

• Step 1 – Enable the consolidation member “Translated Currency Input” under Enable Features
• Step 2 – Create a new Data Source member with the same properties as the FCCS_Journal Input member with only the following unique changes
  • Assign a currency to the new journal member. In the example below, a USD journal input member was created

Note: You can create as many of these new journal sources by currency as you need. I would however recommend that this is limited to the reporting currencies in FCC

Example of TCI journal entry in FCC

The example below shows the result of a TCI journal entry in FCC. Note that there is no reference to the parent entity in this journal. The only requirement is to specify the consolidation member and data source; Translated Currency Input and Journal Input_USD respectively

In this example, we have 2 data sources

• Managed Data = Baseline trial balance data for entity Germany (EUR) 25,000
• TCI journal using the Journal Input_USD data source member $5,000

From the example above, FCC Translated Currency Input journal is a significant improvement from the limitation of the legacy HFM PCA which by default joins parent and child at the hip, makes reorganization difficult and the data intersection invalid when a re-org takes place.