Journal or Subledger-Level Reporting Currencies

Overview of Reporting Currencies

Note: Unless otherwise specified in this chapter, the term Reporting Currency refers to subledger or journal-level reporting currency, rather than balance-level reporting currency.

Using reporting currencies, you can maintain and report accounting records in more than one currency. You do this by defining one or more reporting currencies for a ledger.

Each ledger is defined with a ledger currency that is the primary record keeping currency to record your business transactions and accounting data within General Ledger. If you also need to maintain and report accounting records in one or more other currencies, you do this by defining one or more reporting currencies for the ledger. Financial reporting can be performed using the ledger currency or any of the reporting currencies.

When you enter journals in General Ledger, they are converted into the ledger currency and each of the reporting functional currencies.

You can inquire and report on transactions and account balances in your reporting currency by logging onto a responsibility that has access to the reporting currency.

Related Topics

When to Use Reporting Currencies

Translation Versus Reporting Currencies

Reporting Currency Features

When to Use Reporting Currencies

Reporting currencies are intended for use by organizations that must regularly and routinely support statutory and legal reporting of both transactions/journals and General Ledger account balances in multiple currencies--other than the ledger currency. If you only need to report account balances in a currency other than your ledger currency, you can use General Ledger translation.

Note: Reporting currencies are not intended as a replacement for the General Ledger translation function.

Consider using reporting currencies when any of the following conditions exist:

Related Topics

Overview of Reporting Currencies

Translation versus Reporting Currencies

General Ledger's translation feature (balance level reporting currency) is used to translate amounts from your ledger currency to another currency at the account balance level. Reporting currencies convert amounts from your transaction currency to a reporting currency at the transaction or journal level.

Reporting currencies are specifically intended for use by organizations that must regularly and routinely report their financial results in multiple currencies. Reporting currencies are not intended as a replacement for General Ledger's Translation feature. For example, an organization with a once-a-year need to translate their financial statements to their parent company's currency for consolidation purposes, but no other foreign currency reporting needs, should use General Ledger's standard translation feature instead of reporting currencies.

Another benefit of reporting currencies over General Ledger's Translation feature is that with reporting currencies, you can inquire and report on transaction amounts directly from your subledgers. Translation only applies to General Ledger - it cannot be used to translate transaction amounts in your subledgers.

If you use reporting currencies and have properly initialized your reporting currency's balances, you can report directly from your reporting currency without running Translation. This is because the actual transaction amounts in your reporting currencies have already been converted. As a result, the account balances of your reporting currency are automatically maintained.

For example, to consolidate a subsidiary that maintains a reporting currency using your parent company's ledger currency, you might simply consolidate the reporting currency to your parent ledger, rather than translating, then consolidating the subsidiary's ledger.

Usually, when you compare the results of using amounts from your reporting currency rather than translated amounts, there will be rounding differences in your accounts. Many of these differences arise because:

Before you use your currency's amounts in lieu of translating your ledger's amounts, you need to understand and carefully consider:

Note About Budget Balances

If you use reporting currencies and need to report budget amounts in your reporting currency, you will need to translate the budget amounts in your ledger to your reporting currency.

For example, after translating budget amounts to your reporting currency, you can use FSG to create a budget variance report with three columns:

Related Topics

Translating Balances, Oracle General Ledger User's Guide

Type of Installation

Defining Reporting Currencies for Fresh Install and Upgrade Scenario One

Defining Reporting Currencies for Upgrade Scenario Two

Reporting Currency Features

Reporting Currencies

In General Ledger, you record routine daily transactions in your organization's ledger currency, either directly in General Ledger or from your subledgers.

To use reporting currencies, you must define reporting currencies for a ledger. From the primary ledger, you can report on your account balances in your ledger currency or any of your reporting currencies.

the picture is described in the document text

For example, a U.S. multinational company with a Canadian subsidiary may elect to set up two primary ledgers; one for the U.S. Parent, one for the Canadian Subsidiary. One reporting currency is set up for the Canadian Subsidiary to report in US dollars.

the picture is described in the document text

Routine parent transactions are recorded in the parent's ledger currency, in U.S. Dollars, and routine subsidiary transactions are recorded in the subsidiary's ledger currency, in Canadian Dollars. The associated accounting entries are converted to the subsidiary's reporting currency, in U.S. Dollars. The subsidiary can thus report its transactions and General Ledger balances in both Canadian Dollars and U.S. Dollars.

Note: Many General Ledger functionalities available to a ledger are also available to a reporting currency. You can post journals, convert balances, query account balances, submit standard General Ledger reports, define custom financial reports, and perform consolidations.

General Ledger Journals

Journal entries that originate in General Ledger, such as manual journals, recurring journals, and MassAllocations, as well as journals that you import from sources other than Oracle Applications subledgers, can be converted to your reporting currencies when you post the journals to your ledger. When you post a journal in a ledger that has one or more reporting currencies defined, the posting process creates new journals converted to each of your reporting currencies and includes them in the same batch as the original journal with a status of Posted.

Inquiry and Reporting in Reporting Currencies

Each General Ledger report or inquiry that normally displays information in the ledger currency can also be displayed in any of the associated reporting currencies. To inquire or report on the account balances of a reporting currency, you log into the associated General Ledger reporting responsibility that has access to the reporting currency.

When you inquire on account balances and journals in a reporting currency, you can drill down to the subledger details (in your reporting currency), using General Ledger's integrated drilldown features to provide complete and consistent views of underlying subledger transactions.

See: Drilling Down to Journal Detail

See: Drilling Down to Subledger Detail

For reconciliation purposes, you can use the Financial Statement Generator (FSG) to create a custom comparison report that lists balances from your ledger and reporting currencies in separate columns. Use this report as the basis for reconciling your ledger and reporting currencies.

See: Overview of the Financial Statement Generator

Setting Up Reporting Currencies

Note: Unless otherwise specified in this chapter, the term Reporting Currency refers to subledger or journal-level reporting currency, rather than balance-level reporting currency.

The following table provides a summary of the steps you must follow to set up reporting currencies in your applications. These steps are described in more detail in the next section.

Step Description Window Name (Responsibility)
Step 1 - Define ledger Accounting Setup Manager
Step 2 - Enable and/or define currencies Currencies (General Ledger)
Step 3 - Define reporting currencies Accounting Setup Manager
Step 4 - Define responsibilities Responsibilities (System Administrator)
Step 5 - Assign data access sets to responsibilities System Profile Values (System Administrator)

Note: Daily rates are used to convert your ledger's transactions to the appropriate reporting currencies. If you do not currently maintain daily rates, you must do so when you use reporting currencies.

See: Entering Daily Rates

See: Reporting Currency Conversion Rules

Reporting Currency Setup Steps

Step 1 - Enable or Define Ledgers

You must define your ledger.

Note: Your ledger is where you record your day-to-day business transactions in Oracle Applications. The ledger uses a specific chart of accounts, accounting calendar, and ledger currency.

Note: See: Defining the ledger in Accounting Setup Manager.

Step 2 - Enable and/or Define Currencies

To use reporting currencies, you may need to enable and/or define additional currencies if the currency you want to use for a reporting currency is not already enabled or does not appear in the list of predefined currencies.

Definitions

Throughout this chapter, we refer to currencies in one of three contexts - currency of the ledger (ledger currency), currency of the reporting currency, and transaction currency. Each is explained below:

Currency of the Ledger (Ledger Currency): the currency you use to record transactions and maintain your accounting data within Oracle Applications. The ledger currency is generally the currency in which you transact most of your business and the one you use for legal reporting.

Currency of the Reporting Currency: a currency other than your ledger currency for which you need to report accounting data. For example, as of January 1, 1999, the new pan-European currency, the euro, became effective. If you need to report in the euro currency, you will need a ledger with the euro as the ledger currency. Therefore, you need to enable the EUR currency.

Transaction Currency: the currency in which a transaction originates. For example, if you are a Canadian organization and you trade with organizations located in Japan, you must enable the Japanese Yen if you will be issuing purchase orders, generating invoices, paying bills, and receiving payments in Yen.

Step 3 - Define Reporting Currencies

To use reporting currencies, you must define reporting currencies for your ledger in Accounting Setup Manager.

Note: A reporting currency is a financial reporting entity that is associated with a ledger. The reporting currency has the same chart of accounts and accounting calendar as the ledger, but usually has a different currency.

For example, assume that your company headquarters is located in Australia and that its ledger currency is Australian Dollars (AUD). Assume also that you have one subsidiary each in Canada and Germany, both of which maintain a primary ledger in its local currency - Canadian Dollars (CAD) for the Canadian subsidiary and euro (EUR) for the German subsidiary. Each subsidiary should maintain a reporting currency in AUD, so it can analyze and report transactions using the parent's currency.

Note: See: Accounting Setup Manager.

Tracking Rounding Imbalances

When a standard foreign currency journal is created in General Ledger, the conversion to ledger currency or reporting currency may result in rounding differences (the difference between the debit and credit amounts). There are two methods in which rounding differences are handled in General Ledger when a standard foreign currency journal is created:

Using the Same Currency for Ledger Currency and Reporting Currency

In some circumstances, you may want to use the same currency for a reporting currency and the source ledger. For example, assume you want to create financial forecasts and budgets based on the results of operations recorded in your ledger currency, after removing the effects of any exchange rate fluctuations on your foreign currency transactions.

You can make a lot of manual calculations and adjustments to your forecast and budget amounts to achieve this, or you can use reporting currencies. You can define a reporting currency that uses the same currency as your source ledger. You then define conversion options to control how transactions and journals are converted. For example, instead of converting foreign currency transactions using fluctuating daily rates, you can set up reporting currencies to convert transactions using a more stable corporate rate that you define internally.

This approach has several benefits:

Multi-company and Consolidation Considerations

If you have multiple companies that are accounted for in multiple ledgers, and you want a consolidated view of all of them in a single currency, you can set up reporting currencies in the following way:

For each primary ledger, define a reporting currency that uses the currency you are trying to report on. If the ledgers that represent the multiple companies have different charts of accounts or calendars, then you will need to define secondary ledgers instead of reporting currencies. After defining your reporting currencies and/or secondary ledgers, create a ledger set that includes all of them to enable you to report across all the companies in the same currency.

Step 4 - Define Responsibilities

You or your system administrator must define your organization's responsibilities before anyone can use the reporting currencies. The purpose of these responsibilities is to provide the appropriate level of access your users need to 1) perform inquiry and reporting activities in your reporting currencies and 2) perform specific processes, such as run depreciation, post/transfer/interface to General Ledger, and run revaluation.

A responsibility is a level of authority in Oracle Applications that lets users access only those Oracle Applications functions and data appropriate to their role in an organization. Each responsibility allows access to a specific application or applications, a ledger, a restricted list of windows, a restricted list of functions, and reports in a specific application.

Notes:

You may use your standard General Ledger responsibilities, or you may set up new responsibilities to report and inquire on account balances in your reporting currencies, or enter or import journals directly in a reporting currency. For example, to comply with the accounting practices of the country in which you operate, you may need to enter adjusting journals in a reporting currency, but not in the source ledger.

Responsibilities Window

Use the Responsibilities window to define your responsibilities.

Note: See: Responsibilities Window, Oracle Applications User's Guide

Step 5 - Assign Data Access Sets to Responsibilities

You or your system administrator must assign a data access set to each of the responsibilities defined in the previous step. This ensures that anyone using the responsibility has access to the correct reporting currency account balances and journals. Each data access set includes the ledgers, reporting currencies, and balancing segment values to which you have access. See Data Access Sets, Oracle General Ledger Implementation Guide.

Note: This step is generally performed by a system administrator.

To create the association between a responsibility and a data access set, set the GL: Data Access Set profile option to the data access set name at the responsibility level for each of your responsibilities:

Note: See: Overview of User Profiles, Oracle Applications User's Guide

Reporting Currency Conversion Rules

Reporting currency conversion rules differ depending on whether the exchange rate relationship between a transaction and reporting currency is variable or fixed. When there is a variable relationship, the exchange rate between the two currencies fluctuates. When there is a fixed relationship, the exchange rate between the two currencies remains constant, having been fixed at a specific point in time.

the picture is described in the document text

Note: As of January 1, 1999, the national currencies of countries who are members of the EMU became another denomination of the euro, the pan-European currency. Fixed exchange rates are used between the euro and each EMU currency.

Variable Exchange Rate Relationships

Conversion business rules for variable exchange rate relationships are described below.

Transaction Currency Same as Ledger Currency

The following diagram illustrates the conversion business rules that apply when the transaction currency is the same as the primary currency and a variable rate relationship exists between the transaction and reporting currencies:

the picture is described in the document text

When the transaction and ledger currencies are the same, no conversion is needed to your ledger currency. When a transaction is converted to your reporting currency, it uses the appropriate reporting conversion type you specified for the journal source and journal category that originated the journal.

Transaction Currency Differs from Ledger and Reporting Currency

The following example illustrates the conversion business rules that apply when the transaction currency differs from both the primary and reporting currency, and a variable rate relationship exists between the transaction and reporting currencies:

Transactions are converted to your reporting currency using the appropriate reporting conversion type you specified for the journal source and journal category that originated the journal.

Note: The only exception to the case above is when you specify your own transaction-to-primary currency conversion rate. This case is explained in the next diagram.

Example 1

You receive an invoice for 1,000.00 Australian dollars (AUD) from an Australian supplier. Your organization uses spot rates to account for the invoice in your ledger, which is maintained in Canadian dollars (CAD). You use corporate exchange rates to convert amounts to U.S. dollars (USD) for reporting purposes.

Summary of related information:

Transaction Currency: AUD

Ledger Currency: CAD

Reporting Currency: USD

Spot Exchange Rate (AUD to CAD): 0.9181

Corporate Exchange Rate (AUD to USD): 0.6409

This is how the invoice will be converted:

Transaction Amount: 1,000.00 AUD

Ledger Currency Amount: 918.10 CAD (0.9181 * 1,000.00 AUD)

Reporting Currency Amount: 640.90 USD (0.6409 * 1,000.00 AUD)

Transaction Currency Differs from Ledger and Reporting Currency and You Specify the Conversion Exchange Rate

The following diagram illustrates the conversion business rules that apply when the transaction currency is different from both the primary currency and the reporting currency, a variable rate relationship exists between the transaction and reporting currencies, and you specify a transaction-to-ledger currency conversion rate when you enter the transaction:

the picture is described in the document text

Your application converts the transaction to your ledger currency using the rate you specify. The conversion rate type will be User in both your ledger and reporting currencies.

Transactions are converted to your reporting currency using the appropriate reporting conversion type you specified for the journal source and journal category that originated the journal.

Example 2

You receive an invoice for 1,000.00 Australian dollars (AUD) from an Australian supplier. Your contract with the supplier was originally negotiated using prices in Canadian dollars. The exchange rate used at the time of the agreement was 0.8950 (1 Australian dollar = 0.8950 Canadian dollars). This is also the rate specified on the invoice. Your organization uses corporate exchange rates to convert amounts to U.S. dollars for reporting purposes.

Summary of related information:

Transaction Currency: AUD

Ledger Currency: CAD

Reporting Currency: USD

Spot Exchange Rate (AUD to CAD): 0.8950

Corporate Exchange Rate (CAD to USD): 0.6974

This is how the invoice will be converted:

Transaction Amount: 1,000.00 AUD

Ledger Currency Amount: 895.00 CAD (0.8950 * 1,000.00 AUD)

Reporting Currency Amount: 624.17 USD (0.6974 * 895.00 CAD)

Transaction Currency Same as Reporting Currency

The following diagram illustrates the conversion business rules that apply when the transaction currency is the same as the reporting currency:

the picture is described in the document text

When the transaction and reporting currencies are the same, no conversion is needed to your reporting currency. Reporting currency uses the transaction or journal amount as the reporting currency amount.

Your application converts the transaction to your ledger currency using one of these conversion rate types:

Fixed Conversion Rate Relationships

the picture is described in the document text

When both your transaction and reporting currency is the euro or an EMU currency, the conversion rate type EMU Fixed is used when your transaction amount is converted to your reporting currency, unless the transaction and reporting currency are the same. In this case, no conversion is necessary.

Transaction amounts are converted in full compliance with European Commission guidelines that require using the fixed exchange rate between the euro and each EMU currency.

Example

In February 1999, after the transition period to the euro begins, you receive an invoice for 1,000 Belgian francs (BEF). Your ledger is still maintained in your national currency units (Belgian francs), and you are preparing to convert your operations and financial accounting to the euro. For this reason, you have created a reporting currency with a currency of euro for your ledger.

Summary of related information:

Transaction Currency (EMU): BEF

Ledger Currency (EMU): BEF

Reporting Currency: EUR

Fixed Conversion Factor (EUR to BEF): 40.3399

This is how the invoice will be converted:

Transaction Amount: 1,000.00 BEF

Ledger Currency Amount: 24.79 EUR (1,000 BEF / 40.3399)

Related Topics

Reporting Currency Conversion Rules

Conversion Rounding

Defining Conversion Rate Types

Overview of Multi-Currency Accounting

Conversion Rounding

Reporting currency rounds converted and accounted amounts using the same rounding rules used throughout Oracle Applications products. Reporting currency also considers several factors that are a part of all the currencies predefined in Oracle Applications, including:

Related Topics

Reporting Currency Conversion Rules

Defining Currencies

Using Reporting Currencies

Note: Unless otherwise specified in this chapter, the term Reporting Currency refers to subledger or journal-level reporting currency, rather than balance-level reporting currency.

This section discusses considerations for using Reporting Currencies. We have grouped these considerations into three areas:

Related Topics

Considerations for Entering Data into Reporting Currencies

Performing Standard General Ledger Activities

Completing Reporting Currencies-Related Activities in the Correct Order

Considerations For Entering Data into Reporting Currencies

You should be cautious about performing any activity other than reporting when you are using a reporting currency. This is especially true of entering or importing new journals into your reporting currency, since journals are only converted and replicated from your ledger to your reporting currencies - not the other way around.

Caution: Entering new journals or changing existing journals in a reporting currency can make it very difficult to reconcile the reporting currency to the associated ledger.

Generally, you would consider entering new journals or changing an existing journal in a reporting currency when you need to adjust the balances in a reporting currency because the jurisdiction in which you report those reporting currency amounts follows different accounting rules than those you use in your ledger.

Related Topics

Using Reporting Currencies

Performing Standard General Ledger Activities

Performing Standard General Ledger Activities

Some standard General Ledger activities require new steps or additional information when Reporting Currencies are used. Also, certain activities must be performed in both your ledger and reporting currencies. These activities include opening and closing periods and running Revaluation.

Since these activities are performed separately in your ledger and reporting currencies, you can close out your ledger for a specific accounting period while keeping the period open in your reporting currencies. Holding the reporting currencies' period open provides you with more time to reconcile the reporting balances and make adjusting entries.

Opening Periods

You must open and close accounting periods in your ledger and in each of your reporting currencies separately. You may use ledger sets to enable you to open and close accounting periods simultaneously for your ledger and reporting currencies.

See: Opening and Closing Accounting Periods, Oracle General Ledger Implementation Guide and Defining Ledger Sets, Oracle General Ledger Implementation Guide.

Entering and Posting Journals

Some journals are automatically converted to reporting currencies, while others are not.

Converted Journals

GL Posting automatically generates and posts converted journals in your reporting currencies when you post the original journals in the source ledger for the following types of journals:

Note: Optionally, revaluation journals may be converted. See: Revaluation.

Unconverted Journals

Journals from an SLA-supported subledger are not converted by General Ledger. These are converted by SLA, and SLA transfers both the original journal and the reporting currency journal to General Ledger for import and posting.

See:

Creating Journal Batches

Importing Journals

Posting Journal Batches

Retain Journal Creator from Source Ledger

You can specify which user is saved as the Created By person for a reporting currency journal using the profile option GL/MRC Journals: Inherit the Journal Creator from the Primary Book's Journal. The following values are available to you:

Reversing Journals

Notes:

See: Defining Reverse Journal Entries

Approving Journals

As discussed earlier in this chapter, you should generally exercise caution over entering or importing new journals in a reporting currency. As a result, you may wish to use General Ledger's Journal Approval feature to ensure that a reporting currency's journals are processed through your organization's approval hierarchy.

You can enable Journal Approval separately in your source ledger and reporting currencies. Journals are approved as noted in the table below:

Ledger Reporting Currency Approval Processing
Enabled Enabled Journal entered and approved in source ledger: Approval required based on Journal Approval settings in source ledger. Approval status carried over to corresponding converted journal in reporting currency. Separate approval not needed in reporting currency. Journal entered directly in reporting currency: Approval required based on Journal Approval settings in reporting currency. No approval needed in source ledger.
Not Enabled Enabled Journal entered in source ledger: Associated converted journal in reporting currency not required to be approved, regardless of Journal Approval settings in reporting currency. Approval status set to N/A. Journal entered directly in reporting currency: Approval required based on Journal Approval settings in reporting currency. No approval needed in source ledger.
Enabled Not Enabled Journal entered and approved in source ledger: Approval required based on Journal Approval settings in source ledger. Not applicable to reporting currency. Journal entered directly in reporting SOB: No approval needed in source ledger or reporting currency.

Performing Account Inquiries in a Reporting Currency

When you perform an account balance inquiry for a reporting currency, you can drill down to the journal detail that comprises the reporting currency balance. If the journal detail is a converted journal, i.e., one that was converted automatically when the original journal was posted in the source ledger, you can drill down further to see the source ledger currency journal amounts.

Document Numbers

When you enter a journal in your ledger, the document number assigned to the journal is determined by the ledger and the converted journal in the reporting currency is assigned the same document number. However, if you enter a journal in the reporting currency, the document number assigned to the journal is determined by the reporting currency.

See: Entering Journals

Assigning Document Sequences, Oracle General Ledger Implementation Guide

Entering Budgets

In Reporting Currencies, budget amounts or budget journals are not converted from your ledger to your reporting currency. If you need to report budget amounts in your reporting currencies, you can choose from two methods for each reporting currency:

Maintain Translated Budget Amounts in Ledger: In this case, you translate the budget amounts in your ledger to your reporting currency and maintain the converted amounts in the ledger. You can then create FSG reports using these translated budget amounts. For example, a budget variance report can take the translated budget amounts from the ledger and the reporting currency actual amounts from the related reporting currency.

Manually Enter the Reporting Currency Budget Amounts: In this case, you maintain reporting currency budget amounts in a separate budget. To use this method, you must set up a new budget and manually enter the reporting currency budget amounts.

See:

Overview of Budgeting

Importing Journals

Encumbrances and Budgetary Control

For General Ledger, you can automatically create converted encumbrance journals in your reporting currencies when you post the associated encumbrance journal in your ledger.

Note: Encumbrance journals are created in your reporting currencies as journals entered in the reporting currency, not as foreign-currency journals.

To use Reporting Currencies with encumbrance accounting and/or budgetary control, enable budgetary control for your ledger in Accounting Setup Manager, then perform the standard setup tasks in General Ledger.

Note: You cannot enable budgetary control directly for a reporting currency.

See:

Overview of Encumbrance Accounting

Budgetary Control and Online Funds Checking

Setting Up Budgetary Control

Revaluation

When you use Multiple Reporting Currencies, you must periodically run Revaluation in your ledger and reporting currencies as necessary to satisfy the accounting regulations of the country in which your organization operates. Revaluation is a process that adjusts account balances denominated in a foreign currency using a one time, daily, or period-end exchange rate. Revaluation amounts, based on changes in conversion rates between the date of the journal entry and the revaluation date, are posted to the underlying account with the offset posted to an unrealized gain or loss account. All debit revaluation adjustments are offset against the unrealized gain account and all credit adjustments are offset against the unrealized loss account. If the same account is specified in the gain and loss fields, the net of the revaluation adjustments is derived.

Revaluation Gain/Loss Tracking by Secondary Segment

You can track Revaluation by balancing segment and a secondary tracking segment. This revalues foreign currency denominated balances for specific accounts and currencies; the resulting unrealized gain/loss amounts are balanced by the balancing segment value and secondary tracking segment value and are posted to the unrealized gain/loss account.

To enable the secondary tracking segment, assign the Secondary Tracking Segment qualifier to a segment in your chart of accounts. The secondary segment cannot be the balancing, intercompany, or natural account. Enable the Secondary Tracking Segment option in the ledger.

The ledger's revaluation journal entries will be automatically converted and balanced by balancing segment value and secondary tracking segment value pair, to the reporting currency. In the reporting currency, instead of exactly replicating each line of the revaluation journal from the ledger, the revaluation journal is modified to consist of the unrealized gain/loss journal lines from the original revaluation journal, with offsetting lines against the cumulative translation adjustment account. The offsetting cumulative translation adjustment accounts (journal lines) are also balanced by balancing segment value and secondary tracking segment value pair.

If there are exchange differences between the reporting currency and the transaction currency, run revaluation in the reporting currency on the foreign currency denominated balances. The offset applies to the cumulative translation adjustment accounts, again balanced by balancing segment value and secondary tracking segment value pair. Select the cumulative translation adjustment account as the GL account for this second revaluation.

See:

Revaluing Balances

Secondary Tracking Segment

the picture is described in the document text

Revaluation and SFAS #52 Support

Revaluation supports the following SFAS #52 Methods:

SFAS #52 Temporal Method

Revaluation processing supports the remeasurement standards of SFAS #52 (the Temporal translation method). Under the Temporal method, you must revalue foreign currency-denominated accounts in the currency of the statement to be translated. This process generates gains or losses that you record in your local bookkeeping currency. Consistent with SFAS#52 and other Temporal method standards, you must remeasure those gains and losses in the currency of the financial statement to which you are translating. You must also revalue the underlying asset and liability accounts in the target currency, and record the resulting gains and losses in the Cumulative Translation Adjustment account of the reporting currencies.

To facilitate this process, General Ledger can automatically convert and replicate your revaluation journal entries from your ledger to each of your reporting currencies, directing revaluation gains or losses to the appropriate gain/loss or cumulative translation adjustment account. This speeds the closing and consolidation process, and provides for consistent accounting treatment across multiple ledgers.

SFAS #52 Translation Method

Under the SFAS #52 Translation method, you revalue both monetary and non-monetary account balances using the ledger currency balances of the ledger to create revaluation entries for the reporting currency.

Set the profile option GL/MRC Revaluation: Use Primary Currency instead of Entered Currency to Yes to comply with SFAS #52 Translation Method.

Only amounts that exist in the ledger will be processed. Any posting that has occurred directly to the reporting currency without an associated posting in the ledger will be ignored when calculating revaluation amounts.

the picture is described in the document text

In the monetary asset example, Accrued Interest Receivable, the entered balance is revalued to both the ledger currency and the reporting currency. Whether the reporting currency balance is revalued from the entered currency or the ledger currency results in no material difference.

the picture is described in the document text

In the non-monetary asset example, Fixed Assets, the ledger balance is not revalued. Revaluing the reporting currency balance against the entered balance (remeasurement) results in a material difference when compared to revaluing against the ledger currency (translation).

Setting Up General Ledger

There are two ways in which you can set up General Ledger to enhance revaluation processing and support SFAS #52:

Setting Up PTD Revaluation for Income Statement Accounts

You can use the General Ledger profile option, GL Income Statement Accounts Revaluation Rule, to specify whether you want to revalue income statement accounts using period-to-date (PTD) or year-to-date (YTD) balances. If you choose to revalue PTD balances for income statement accounts, the program continues to appropriately revalue YTD balances for balance sheet accounts. Revaluing the PTD balance of your income statement accounts creates weighted average YTD balances using period rates from each corresponding period, and produces more accurate results in compliance with SFAS No. 52 standards.

When you select the PTD option for revaluing your income statement accounts, revaluation produces two separate journal entries; one that revalues your balance sheet accounts and another for your income statement accounts. You will not need to reverse the PTD revaluation journal entry for your income statement accounts in the subsequent period since that revaluation only applied to last period's activity.

Note: Regardless of which option you choose, balance sheet accounts are revalued in accordance with their year-to-date balances. Income statement accounts are revalued using either their period-to-date or year-to-date balances, as defined by profile option set in GL: Income Statement Accounts Revaluation Rule.

You can only review this profile option at the user level. Your System Administrator can set this profile option at the site, application, or responsibility level.

See: Setting General Ledger Profile Options, Oracle General Ledger Reference Guide.

Defining, Saving, and Running Revaluations

You can define new revaluations, update existing revaluations and delete revaluations. You can also group revaluations into a Request Set that can be launched once or scheduled to launch periodically.

See: Revaluing Balances

Setting Up Reporting Currencies for Revaluation

There are two methods for revaluing in Reporting Currencies:

You select the method you want to use for a reporting currency when you define your currency conversion rules during the Reporting Currency setup process in Accounting Setup Manager, as follows:

To prevent conversion of revaluation gains and losses to a reporting currency:

To convert revaluation gains and losses for a reporting currency:

Revaluation Process When Choosing Not to Convert Revaluation Journals

If you choose not to convert revaluation gains and losses, the process to revalue balances requires that you run Revaluation separately in your ledger and your reporting currencies. You also post the resulting revaluation journals in both your ledger and reporting currencies. When the revaluation journal is posted in the ledger, there will be no impact on the reporting currency.

This approach represents standard General Ledger functionality, operating independently in each ledger and reporting currency. You only need to run revaluation in a reporting currency if there are foreign currency entered transactions in it.

See: Revaluing Balances

Revaluation Process When Choosing to Convert Revaluation Journals

The second revaluation method - to convert revaluation gains and losses-is more complicated. The following flowchart depicts the revaluation process:

the picture is described in the document text

For a text description of the flowchart, see: Revaluation Process When Choosing to Convert Revaluation Journals, Oracle General Ledger Reference Guide.

The remainder of this section describes each of the steps in the flowchart in detail, including the accounting entries generated in both the ledger and reporting currency. Use this information to determine which steps to use to satisfy the accounting requirements of the country in which your organization operates.

Step 1: Revalue Ledger

See: Revaluing Balances

Example:

For example, consider the following scenario:

Ledger currency: EUR

Reporting currency: USD

Foreign transactional currencies: CAD, USD

Exchange rates are as follows:

Date CAD to EUR CAD to USD EUR to USD
9/5/99 .632 .670 1.06
9/20/99 .652 .678 1.04
9/30/99 .639 .680 1.06

Also assume that you defined a currency conversion rule to have revaluation journals converted using the rates for the reporting conversion type "Period-Avg". The related Period-Avg rate for Sep-1999 is 1.053.

There are four transactions during September:

Date Account Entered Accounted
9/5 AR 1000 CAD 632.00 EUR
9/20 AP 1250 CAD 822.50 EUR
9/20 AP 500 EUR 500.00 EUR
9/20 AR 500 USD 480.77 EUR

When Revaluation is run at the end of September for the foreign transactional currencies, CAD and USD, the new accounted amounts will be:

Date Account Entered Accounted
9/5 AR 1000 CAD 639.00 EUR
9/20 AP 1250 CAD 798.75 EUR
9/20 AP 500 EUR 500.00 EUR
9/20 AR 500 USD 471.70 EUR

Revaluation is computed by currency.

For CAD Revaluation

When the CAD transactions are revalued in EUR, (AR 632.00 - 639.00) (AP 822.50 - 798.75) there will be an increase of 7 EUR in AR (debit), and a decrease of 23.75 in AP (debit). This will result in the following revaluation journal in the ledger:

Account Debit Credit
Accounts Receivable 7.00  
Accounts Payable 23.75  
Exchange Gain/Loss   30.75

For USD Revaluation

When the USD transaction is revalued in EUR (480.77-471.70), there will be a decrease of 9.07 EUR in AR (credit). This will result in the following revaluation journal in the ledger:

Account Debit Credit
Exchange Gain/Loss 9.07  
Accounts Receivable   9.07

If you combine the results of both journal entries, (30.75-9.07) the net exchange gain/loss for the month is a 21.68 credit to the account. We will continue to build on this example through the remaining discussion in this section.

Step 2: Post Ledger

Example:

Continuing the example introduced in Step 1, the euro ledger’s EUR revaluation journals will be converted to the USD reporting currency as follows:

For CAD Revaluation

The gain is computed as 30.75 (gain from ledger's revaluation journal) times the "Period-Avg" rate for Sep-1999 of 1.053 (EUR to USD):

 30.75 EUR  X  1.053  =  $ 32.38

This results in the following journal entry:

Account Debit Credit
Cumulative Translation Adjustment 32.38  
Exchange Gain/Loss   32.38

For USD Revaluation

The loss is computed as 9.07 (loss from ledger's revaluation journal) times the "Period-Avg" rate for Sep-1999 of 1.053 (EUR to USD):

 (9.07) EUR  X  1.053  =  ($ 9.55)

This results in the following journal entry:

Account Debit Credit
Exchange Gain/Loss 9.55  
Cumulative Translation Adjustment   9.55

The net result of both revaluations is a gain of $22.83 in the Exchange Gain/Loss account.

Caution: Perform the remaining steps ONLY if the currency of the original entered amount in the ledger is different from the currency of the reporting currency. Otherwise, no further action is needed in the reporting currency.

Example:

In our continuing example, the currency of the original entered amounts are USD, CAD and EUR. The reporting currency is USD. Since the currencies for some transactions are different, we would proceed with the remaining steps for the CAD and EUR transactions. It is not necessary to revalue the USD transactions since the reporting currency is in USD.

Step 3: Revalue Reporting Currency

Example:

Continuing our example from the previous steps, we will look at the USD reporting currency. Note that the four original transactions would have been converted to USD, using daily rates as follows:

Date Acct. Entered Daily Rate USD Accounted in Reporting Currency
9/5 AR 1000 CAD .670 $ 670.00
9/20 AP 1250 CAD .678 $ 847.50
9/20 AP 500 EUR 1.04 $ 520.00
9/20 AR 500 USD n/a $ 500.00

Since the original entered currency for the first three transactions is different from USD, we must revalue these currencies as of 9/30 to compute any related translation adjustment. The last transaction was entered in USD, so it does not need to be revalued, and remains at the entered amount of 500 USD in the reporting currency.

When Revaluation is run, the new accounting amounts in the reporting currencies will be:

Date Acct. Entered Period End Rate USD Accounted in Reporting Currency
9/5 AR 1000 CAD .680 $ 680.00
9/20 AP 1250 CAD .680 $ 850.00
9/20 AP 500 EUR 1.06 $ 530.00
9/20 AR 500 USD n/a $ 500.00

Revaluation is computed separately for each currency.

For CAD Revaluation

When the CAD transactions are revalued in USD using the period end rate, (AR 670.00 - 680.00) (AP 847.50 - 850.00) there will be a increase of $ 10.00 in AR (debit), and a increase of $ 2.50 in AP (credit). This will result in the following revaluation journal in the USD reporting currency:

Account Debit Credit
Accounts Receivable 10.00  
Accounts Payable 2.50  
Cumulative Translation Adjustment   7.50

For EUR Revaluation

When the EUR transaction is revalued in USD using the period end rate, (520.00 - 530.00), there will be a decrease of $ 10.00 in AR (credit). This will result in the following revaluation journal in the USD reporting currency:

Account Debit Credit
Cumulative Translation Adjustment 10.00  
Exchange Gain/Loss   10.00

The entered amounts for all three journal lines is zero.

The net effect of the revaluation for both currencies is no increase or decrease in AR, and a net credit in AP of $ 2.50. This results in a net debit of $2.50 to the cumulative translation adjustment account. (Note that the transaction originally entered in USD is not revalued in the USD reporting currency)

Step 4: Post Reporting Currencies

Translation and Consolidation

For Translation and Consolidation Information, see: Translation versus Reporting Currencies

Mass Maintenance

You must run Move/Merge and Move/Merge reversal in your ledger. The changes are automatically made in each of your reporting currencies.

See: Mass Maintenance

Sequential Numbering

If you are using sequential numbering and wish to maintain the same numbering in your reporting currency and source ledger for journals (other than those generated by Receivables, Payables, Purchasing, Projects, and Assets) do not create separate sequences for your reporting currencies. If you do, the sequence defined for the reporting currencies will be used and may cause document numbers not to be synchronized between the ledger and reporting currencies.

Related Topics

Using Reporting Currencies

Considerations for Entering Data into Reporting Currencies

Completing Reporting Currencies-Related Activities in the Correct Order

Completing Reporting Currencies-Related Activities in the Correct Order

There are multiple dependencies between a reporting currency and its source ledger. Therefore, it is important that you complete your period-begin tasks, day-to-day accounting tasks, and period-closing tasks in the correct order. Some guidelines are presented below.

Period-Begin Tasks

Open the accounting period in both your ledger and reporting currencies before you create or import journals for the period. Converted journals will only be generated in your reporting currency if the period is open or future-enterable.

Day-to-Day Tasks

Enter the daily exchange rates to convert your journals to each of your reporting currencies.

Period-End Tasks

You need to be sure to complete the following period-end tasks:

Related Topics

Using Reporting Currencies

Considerations for Entering Data into Reporting Currencies

Performing Standard General Ledger Activities

Implementation Considerations

Note: Unless otherwise specified in this chapter, the term Reporting Currency refers to subledger or journal-level reporting currency, rather than balance-level reporting currency.

There are important issues you should consider before you start using Reporting Currencies for your organization, including

Terms

Terms and their definitions used in this chapter are listed in the table below.

Term   Definition
back-dated transaction   A transaction whose transaction date precedes the dates included in the First Future Conversion Period.
EMU   European Economic and Monetary Union.
first future conversion period   The first period for which you want to convert transactions to your reporting currencies. The First Future Conversion Period is also the period in which account balances are initialized in your reporting currencies.
foreign transaction   A transaction denominated in a currency other than the ledger currency. The currency can be one of your reporting currencies.
initial period   The accounting period that precedes the First Future Conversion Period.
initializing rate   Single rates you define between each transaction currency and reporting ledger currency for the conversion date and conversion type you specify when defining the Reporting Currency in the Historical Conversion region in Accounting Setup Manager. This rate is used to convert transactions and initialize monetary account balances in reporting currencies during the historical conversion process for Upgrade Scenario Two. Note: Conversions involving EMU currencies for dates after 01-JAN-1999 are not made using the initializing rate. In these cases, Reporting Currencies uses the defined fixed-rate relationships between the euro and the EMU currencies, and follows prescribed regulations pertaining to triangulation and rounding.
monetary asset/liability   An asset or liability whose recorded amount is fixed or determinable in the ledger or reporting currency without regard to future prices of specific goods or services. Typical monetary assets include cash, marketable securities, and accounts receivable. Accounts payable is a typical monetary liability.
first historical conversion period   The first period for which the account balances are to be converted by the Reporting Currency - Create Opening Balance Journals in Reporting Currency program.

Type of Installation

You can use Reporting Currencies in three specific types of installations:

Related Topics

How Does My Choice of Periods Affect Conversion?

Defining Reporting Currencies for Fresh Install or Upgrade Scenario One

Defining Reporting Currencies for Upgrade Scenario Two

Translation versus Reporting Currencies

Defining Reporting Currencies for Fresh Install or Upgrade Scenario One

You must initialize the beginning balances in your reporting currencies before you can inquire and report on account balances in your reporting currencies. The steps in this section explain how to initialize your account balances.

Important: Once you begin the initialization process outlined in the steps below, do not post any new journals in General Ledger until the initialization process has been completed successfully. For more information, see: Type of Installation.

Step 1: Perform Reporting Currencies Setup Steps

Perform the Reporting Currencies setup steps.

See: Setting Up Reporting Currencies

Step 2: Initialize Account Balances in New Ledger

Perform this step only for upgrade scenario one when you define Reporting Currencies for a new ledger. You must initialize the account balances in your new ledger for the initial period. These are the balances that are subsequently converted to your reporting currencies during Step 4.

Before you can load the initial balances to the ledger, be sure that the currency conversion rules include the appropriate journal sources and categories, so the initial journal is converted to the reporting currencies.

We suggest you use Journal Import to load the initial balances into your new ledger. These balances might come from a file that you have created manually or automatically. One way to create this file automatically is to write a SQL script to extract the year-to-date entered and accounted actual balances from your old ledger as of the end of the initial period.

Another way to initialize the balances in your new ledger is to enter them manually, using the Enter Journals window in General Ledger.

Note: If you use Translation and Consolidation to initialize your new ledger's balances, your foreign entered amounts and balances will not be carried over.

Step 3: Open the Initial Period in Reporting Currencies

Before you initialize account balances in the next step, make sure you have opened the initial period in your reporting currencies. If you are adding a new reporting currency, choose the first General Ledger period carefully.

Step 4: Post in the Ledger and Reporting Currencies

You must post all journals created from Step 2 in your ledger at the end of the initial period.

Posting all journals ensures that the ending account balances in your ledger are up to date. It automatically creates posted journals for the reporting currencies.

Step 5: Open the First Future Conversion Period

For General Ledger, open the First Future Conversion Period in both your ledger and reporting currencies. This automatically creates your beginning account balances for the First Future Conversion period.

Related Topics

Type of Installation

How Does My Choice of Periods Affect Conversion?

Translation versus Reporting Currencies

Defining Reporting Currencies for Upgrade Scenario Two

After you upgrade an existing Oracle Applications installation, if you want to define reporting currencies for an existing ledger, you must initialize the account balances for each of your reporting currencies using the Reporting Currency - Create Opening Balance Journals in Reporting Currency program.

After you define a reporting currency for an existing ledger, General Ledger begins converting to your reporting currencies any new journals that you enter in the ledger. However, account balances in your reporting currencies are not automatically initialized and synchronized with the account balances in your ledger at the time you define the reporting currency. That is why you must run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program to initialize the balances.

Reporting Currency - Create Opening Balance Journals in Reporting Currency Program

What Does the Program Convert?

Reporting Currency - Create Opening Balance Journals in Reporting Currency Program

You run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program for General Ledger to initialize account balances in your reporting currency based on all of the foreign currency and ledger currency balances in your ledger. You can control the exchange rates used to convert balances to comply with appropriate accounting standards, including the specific currency conversion and rounding requirements defined by the European Commission for the euro and EMU currencies.

The Reporting Currency - Create Opening Balance Journals in Reporting Currency program converts account balances in the ledger beginning from a specified period up to the initial period. You can choose to convert a specified range of accounts in the ledger. If you do not provide a range of accounts, all balances are converted.

How Does My Choice of Periods Affect Conversion?

This section is a general discussion of the importance of determining appropriate dates and periods for initialization, in particular:

Choosing a First Future Conversion Period

Choosing a first Future Conversion Period is a business decision you must make for your organization. Consider choosing a first Future Conversion Period that begins on the first day of your fiscal year. All of the balance types (daily, period-to-date, quarter-to-date, and year-to-date) are fully synchronized on the first day of your fiscal year. Also, you won't need to work with partial year balances in your reporting currencies.

In addition:

The diagram below illustrates the relationship between the first future conversion period and how the Reporting Currency - Create Opening Balance Journals in Reporting Currency program converts balances.

the picture is described in the document text

For a text description of the Reporting Currency Initialization diagram, see: Reporting Currency Initialization Diagram, Oracle General Ledger Reference Guide

What Rates are Used to Convert Transactions?

When you are running the Reporting Currency - Create Opening Balance Journals in Reporting Currency program, you decide the exchange rates to be used to convert balances by setting the Retain the Original Conversion Rate Type option in the Reporting Currency definition, Historical Conversion section in Accounting Setup Manager. If this option is set to:

Retain the Original Conversion Rate Type Option Set to No

When you choose the No for the Retain the Original Conversion Rate Type Option in the Reporting Currency Historical Conversion definition in Accounting Setup Manager, you control what exchange rates are used to convert ledger account balances to your reporting currencies. For example, for General Ledger you can use appropriate period-end daily rates to convert monetary accounts and weighted average rates to convert non-monetary accounts.

If you do not specify rates at specific levels of detail, all transactions and balances will be converted using the initializing rate.

The initializing rate is a single and unique daily rate that you specify for each combination of transaction currency to reporting currency. For example, assume that the journals in your ledger are denominated in three currencies (USD, AUD, and DEM) and you are converting to two reporting currencies (EUR and CAD). Also assume that the first future conversion period falls on or after 01-JAN-1999. You must define an initializing rate for the following currency combinations:

Entered Transaction Rate from Transaction Currency to EUR Reporting Currency Reporting Currency Amount - EUR Rate from Transaction Currency to CAD Reporting Currency Reporting Currency Amount - CAD
100 USD 1.05 105.00 1.75 175.00
250 AUD 0.623 155.75 0.95 237.50
2,000 DEM Fixed: EUR to DEM = 1.95583 1,022.58 Triangulation: EUR to DEM = 1.95583 EUR to CAD = 1.3 1,329.36

the picture is described in the document text

Notice in the example that the EUR to DEM rate is actually the fixed rate that is set on 01-JAN-1999 between the euro and DEM. This rate is needed by the Reporting Currency - Create Opening Balance Journals in Reporting Currency program to perform the DEM to CAD conversion since, after 01-JAN-1999, conversion involving EMU currencies must use the EMU fixed rate. The computation, Reporting Currencies, follows to perform this conversion is as follows:

the picture is described in the document text

The initializing rates must be defined as daily rates using a rate type that you define specifically for the historical conversion process. Once defined, this rate type is entered on the Reporting Currency definition, Historical Conversion section in Accounting Setup Manager and is used to define your initializing rates.

Note: The Multi-Currency chapter explains how to define conversion rate types, how to enter daily rates, and how to define EUR-to-EMU relationships and rates.

General Ledger account balances are converted as follows:

Retain the Original Conversion Rate Type Option set to Yes

You can only choose this conversion option when an EMU-fixed relationship exists between the ledger and reporting functional currencies on or before the first future conversion date. The actual calculation of the reporting currency occurs by converting the ledger currency amount using the EMU-fixed factor between ledger and reporting currencies. Unlike the Use Initialization Rate conversion option, you will not need to specify a single and unique daily rate for each combination of transaction currency to reporting currency.

To illustrate how this conversion option converts journals, assume that the General Ledger journals in your FRF ledger are denominated in three currencies (USD, EUR, and FRF) and you are converting to the EUR reporting currency. Also assume that the EMU-fixed relationship between the ledger and reporting currency exists before the first future conversion period:

Entered Transaction Rate from Transaction Currency to Ledger Currency Ledger Currency Amount Rate from Ledger to Reporting Currency Reporting Currency Amount
100 USD 6.07 607 FRF EMU Fixed 6.55957 92.26 EUR
250 EUR 6.55957 1640 FRF EMU Fixed 6.55957 249.28 EUR
5000 FRF   5000 FRF EMU Fixed 6.55957 760 EUR

Notice that in this example the conversion exchange rate is the EMU fixed factor between the ledger and reporting currency where the rate used between the transaction currency and ledger currency is carried through by taking the ledger currency amount and converting that to the reporting currency.

What are the Conversion Dates for the Exchange Rates Used to Convert Transactions?

Conversion dates for the following conversion options are as follows:

Conversion Summary Information

The following tables summarize information for the Use Initialization Rate conversion option from the preceding sections, including what exchange rates, conversion dates, and associated conversion rate types are used by the Reporting Currency - Create Opening Balance Journals in Reporting Currency program to convert transactions.

For a text description of these tables, see: Conversion Summary Information, Oracle General Ledger Reference Guide

Transactions that are not Future-dated:

Application Rate Used10 Rate Conversion Date Conversion Rate Type
General Ledger Initializing rate for monetary accounts
Weighted average rate for non-monetary accounts
Daily
Historical
Initializing3
Initializing3
User defined1
Historical2

Notes:

1 You specify a conversion rate type for the initializing rate. We recommend you define a new conversion rate type for this purpose.

2 You provide weighted average rates for initializing the non-monetary account balances in your reporting currencies by defining historical rates in GL.

3 The initializing date is the conversion date you specify on the Reporting Currency page in ASM, Historical Conversion section.

How are Reporting Account Balances Initialized?

Reporting account balances are initialized by the General Ledger's Reporting Currency - Create Opening Balance Journals in Reporting Currency program. The basic procedure this utility follows is dependent on what conversion option you choose:

Retained Earnings Calculations

The Reporting Currency - Create Opening Balance Journals in Reporting Currency program balances the initializing journals against the retained earnings account in the reporting currencies. This is necessary to account for the cumulative conversion adjustments that arise when you convert your ledger balances to your reporting currencies using different exchange rates.

How are Encumbrance Balances Initialized?

Encumbrance balances in your reporting currencies are initialized similarly to the actual account balances. The difference arises from the nature of encumbrances in Oracle Applications. When you enter encumbrances in your ledger, you can only enter the encumbrance amount in your ledger currency. The resulting entered and accounted amounts are the same.

When you run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program, the accounted encumbrance amount is converted to your reporting currency. Both the entered and accounted amount for the encumbrance in your reporting currency will be equal to this converted amount.

In both your ledger and reporting currencies, the entered and accounted amounts for encumbrances are always denominated in the respective ledger or reporting currency.

Initialization Tasks

The remainder of this section discusses the following tasks for initializing balances in a new reporting currency once you've already initialized.

Tip: We strongly recommend that you conduct a pilot initialization using a copy of your database before you initialize on your actual production database. This will provide you with valuable information about how long it will take to perform the actual initialization, as well as guidance on setting your rollback segment size. A pilot initialization will also help you identify potential problem areas and develop solutions before you perform the actual initialization.

Plan the Initialization

Upgrading an existing Oracle Applications installation to Release 11 or higher and initializing Reporting Currencies for the first time requires careful planning and preparation. There are numerous interdependent steps that you must complete in the correct order to successfully perform the initialization. The initialization process can also be time consuming, especially if your organization has large volumes of transactions data and account balances that must be converted to one or more reporting currencies.

For these reasons, we highly recommend that you prepare a written initialization plan as the first task in your initialization process. In this section, we provide the minimum required steps to include in your initialization plan. We also discuss the various issues and considerations you need to account for in your plan.

Step 1: Review Reporting Currencies-related Documentation

Read this chapter thoroughly before you start using Reporting Currencies and run the initialization.

Step 2: Determine the Reporting Currencies to Initialize

Because of the large amount of data that needs to be converted to initialize a reporting currency, it is important that you only create reporting currencies for those currencies where you have a definite need to account and report transactions in that reporting currency. For other reporting currencies, in which you only need to occasionally report your account balances and results of operations, consider using General Ledger's translation feature.

See: Translation versus Reporting Currencies

Step 3: Determine the First Future Conversion Period

The first future conversion period is the first accounting period for which you want to be able to report transactions and balances in your reporting currencies.

Note: For purposes of upgrading Oracle Applications, we strongly recommend that you plan to run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program as close as possible to the end of the initial period. See: Step 4: Determine When to Run the Upgrade Utilities.

When determining what period to use for your first future conversion period, ask yourself these questions:

This is a very important issue. To illustrate, assume you are planning to perform the Reporting Currencies implementation in March 1999, such that March 1, 1999 is the first day of your first future conversion period. You've made sure that March 1999 is the first future-enterable period or, if you do not allow future-enterable periods, the first never opened period in General Ledger. Also assume that, before you actually run the program, you open additional accounting periods such that March 1999 is no longer the first future-enterable period or, if you do not allow future-enterable periods, the first never opened period in General Ledger.

As a result of opening the new periods, March 1999 can no longer be your first future conversion period since it is no longer the first future-enterable period or, if you do not allow future-enterable periods, the first never opened period in General Ledger. You will not be able to run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program with March 1999 as your first future conversion period . You must choose a new first future conversion period and date and reschedule your upgrade. You must also ensure that the new period you choose will be the first future-enterable period or, if you do not allow future-enterable periods, the first never opened period in General Ledger when you run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program.

Step 4: Determine When to Run the Reporting Currency - Create Opening Balance Journals in Reporting Currency Program

You need to allow sufficient time to complete the initialization, as detailed in these subsequent sections:

Once you've determined when to run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program, select the date on which you plan to begin performing the initialization, and schedule sufficient time for the initialization process.

Some steps to consider when you perform the initialization process include:

When determining how much time you need to perform the initialization , remember to allow sufficient time to clean up and prepare your ledger before you run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program. Cleaning up your ledger ensures that you convert only the data you need to your reporting currencies.

When determining how much time you need to perform the initialization, you must also consider the volume of transactions you plan to convert. There is some control you can exercise.

You can specify the range of accounts to convert from your ledger. If you are using the Retain Original Conversion Rate Type option set to Yes, you can specify which periods to convert period-to-date account balances for your reporting currencies.

Important: In determining when to run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program, keep in mind these important requirements that you MUST observe during the process:

- Do not post any journals in your ledger or reporting currencies until you have initialized the reporting account balances.

- Do not open the first future conversion period in your ledger or reporting currencies until the initialization has been completed successfully.

For purposes of upgrading Oracle Applications, we strongly recommend that you plan to run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program as close as possible to the end of the initial period. The ideal situation is to run the program at the close of business on the last day of the initial period. However, this is not feasible for many organizations because:

If you are in this situation, we suggest you run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program during a weekend, when you can more easily suspend all transaction processing while you run the program. For example, assume you want your first future conversion period to start on April 1, 1999:

the picture is described in the document text

April 1st falls on a Thursday, which is probably not a good day for you to suspend all transactions processing. You may therefore decide to run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program over the weekend of March 27th or the weekend of April 3rd. See: How Does My Choice of Dates/Periods Affect Conversion?

Step 5: Prepare Your Initialization Plan

Prepare a written initialization plan based on the information presented in this section.

Prepare for the Initialization

In this section we discuss the steps you need to complete when preparing for the initialization:

Step 1: Note Periods and Review Calendars

When preparing for the initialization, make note of the first future conversion period and the initial period that you determined during the planning process. These important periods will be used when you run the initialization.

The first future conversion period:

You should put in place procedures to ensure that the first future conversion period will meet the above criteria on the date you run the initialization.

With respect to the initial period, please note the following:

Step 2: Determine First GL Period for Reporting Currencies

You must determine the first-ever-opened period in General Ledger for your reporting currency. Make sure you choose a first-ever-opened period that precedes the first future conversion period, or first historical conversion period if you plan to convert data to the reporting currency in periods prior to the first future conversion period, and that is early enough to ensure proper accounting for back-dated transactions.

Step 3: Determine Conversion Dimensions

In preparing for the initialization, you must determine the conversion dimensions you will use during the initialization. First you will need to determine your conversion option:

Conversion Option: Determine the conversion option that you will use for the initialization, which will determine the rates used to convert transactions or balances. See: What Rates Are Used to Convert Transactions?

If you choose the Retain Original Conversion Rate Type option set to No, you will need to determine the following conversion dimensions which include conversion option, currencies, conversion date, conversion rate types, and exchange rates.

Step 4: Determine Conversion Extent

Step 5: Determine Rollback Segment Size

To handle the large volume of data processed during the initialization process, you will need to increase the size of your rollback segments. For more information about rollback segments:

Perform the Pre-initialization Tasks

In this section we discuss the steps you need to complete when preparing for the initialization:

Step 1: Define Ledger

See: Step 1: Define Ledger

Step 2: Prepare Your Ledger

For the initial period in your ledger, we strongly recommend that you perform your usual month-end closing procedures so your General Ledger will be as current as possible before you run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program.

In particular, post all journal entries in your ledger for the initial period. Posting all outstanding transactions and journals ensures that the ending account balances in your ledger are up to date.

We also strongly recommend that you:

Step 3: Enable and/or Define the Currency of Reporting Currency

See: Step 3: Enable and/or Define the Currency of Reporting Currency

Step 4: Define Reporting Currencies

See: Step 4: Define Reporting Currencies

Step 5: (Optional) Define Reporting Responsibilities

You define a reporting currency, it is automatically added to the system-generated data access set that is created for the ledger and its reporting currencies. If you have assigned this system-generated data access set to a responsibility, you can access the reporting currency using the same responsibility. If you choose, you can define a separate responsibility for the reporting currency for reporting or processing.

See: Step 5: Define Reporting Responsibilities

Step 6: (Optional) Assign Data Access Sets to Reporting Responsibilities

Assign the General Ledger reporting responsibility you defined in the previous step to your data access set that includes your reporting currencies.

During this step, you have your system administrator set the profile option GL: Data Access Set for the General Ledger reporting responsibility.

See: Step 6: Assign Data Access Sets to Reporting Responsibilities

Step 7: Open Periods in Reporting Currencies

Use the Open and Close Periods window or SRS programs to open the first General Ledger period and any subsequent periods through the initial period in your reporting currencies. You determined the first General Ledger period during the initialization preparation task. See: Determine First GL Period for Reporting Currencies.

Important: Do not open the first future conversion period during this step.

See: Opening and Closing Accounting Periods, Oracle General Ledger Implementation Guide

Step 8: Define Conversion Rate Types

In your ledger, define the conversion rate types you determined during the upgrade preparation task. See: Determine Conversion Dimensions.

See: Defining Conversion Rate Types

Step 9: Enter Conversion Rates

If you are using the Retain Original Conversion Rate Type option set to No in your ledger, enter all of the rates you determined you would need for conversion during the initialization preparation task. See: Determine Conversion Dimensions.

Step 10: Run Month-end Reports

Run your usual set of month-end reports from General Ledger for the ledger. You will use these reports later to reconcile your ledger amounts to the converted amounts in your reporting currencies. Specifically, we recommend that you run the Detail Trial Balance and Entered Currency General Ledger reports.

Note: Run the Entered Currency General Ledger report for each entered currency in your ledger.

Step 11: (Optional) Close Periods in Ledger

We recommend closing, in your ledger, any open periods that precede the first future conversion period. While this step is not required, closing these periods for General Ledger ensures that transactions cannot be entered while the Reporting Currency - Create Opening Balance Journals in Reporting Currency program is running.

See:

Opening and Closing Accounting Periods (GL), Oracle General Ledger Implementation Guide

Step 12: Set Your Rollback Segment Size

Set your rollback segment size to the amount you determined during the initialization preparation task. For more information about rollback segment requirements:

See: MRC Installation Notes, which is available from My Oracle Support.

Perform the Initialization

Complete the steps in this section to perform the initialization.

Step 1: Stop Journal Entry

You MUST suspend all journal entry in the ledger before you run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program. Do not enter journals when you run the program.

Step 2: Back Up Your Production Database

Back up your production database before you begin the initialization process. In the event the historical conversion process fails, use this backup to restore your database to the point it was at before you began.

Note: The Reporting Currency - Create Opening Balance Journals in Reporting Currency program can be restarted if it fails during processing. You only need to restore your production database if you need to change your conversion options or when you are asked to do so by Oracle Worldwide Support.

Step 3: Setup Reporting Currencies

To configure Reporting Currencies for the historical conversion, you must define your reporting currencies. Since the ledger and reporting currencies share the same calendar, the accounting periods you've set up in the ledger will be synchronized with your reporting currencies.

However, in your reporting currencies, you must open the periods you need in General Ledger, separately from opening periods in your ledger. For example, in the next step, you will be instructed to open periods in your General Ledger reporting currencies.

To define reporting currencies and convert historical data:

  1. Log in to General Ledger using a responsibility with access to Accounting Setup Manager. Navigate to the Accounting Setup Manager.

  2. Select your Ledger or Accounting Setup.

  3. From the Accounting Options page, select the Reporting Currency setup step and complete the setup.

    For those reporting currencies for which you plan to run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program now, define the following options for the reporting currency in the Historical Conversion section:

    • First Future Conversion Period

      Specify the first future conversion Period if you plan to run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program to initialize the selected reporting currency's account balances. You can select the first future conversion period from a list of values. Note that the list of values only displays future-enterable or never opened General Ledger periods in your ledger.

      See: Determine the First Future Conversion Period.

      Caution: If you previously ran the Reporting Currency - Create Opening Balance Journals in Reporting Currency program for a reporting currency and posted the results, and you subsequently change the associated first future conversion period, you may get unpredictable initial reporting account balances if you rerun the Reporting Currency - Create Opening Balance Journals in Reporting Currency program for the reporting currency. Also, you risk losing journal reversal integrity between your ledger and reporting currency.

      If you previously ran the Reporting Currency - Create Opening Balance Journals in Reporting Currency program for a reporting currency and you subsequently delete the associated first future conversion period, you will not be able to rerun the Reporting Currency - Create Opening Balance Journals in Reporting Currency program for the reporting currency. You will also lose journal reversal integrity between your ledger and reporting currency.

    • Retain the Original Conversion Rate Type Option

      Note: If the transaction currency is the same as the reporting currency, no conversion occurs and the entered transaction amount is equivalent to the converted amount in the reporting currency.

      Select one of these two options:

      No: converts entered transaction amounts to the reporting currency using the conversion rate determined by the historical conversion rate date and historical conversion rate type.

      Yes: derives the reporting currency amount from the original transaction conversion rate. The actual calculation of the reporting currency amount occurs by converting the ledger currency amount using the EMU fixed rate between the ledger and reporting currencies. The transaction amounts are not implicitly revalued to the initialization rate. Therefore, currency adjustments will not be generated.

      The option to Retain the Original Conversion Rate Type is only available when an EMU fixed rate relationship exists between the ledger currency and the reporting currency on or before the first Reporting Currencies date.

    • Conversion Date: Enter the date of the conversion rate for the conversion rate type you want applied during the historical conversion process. Ensure that it is the same date for which you defined initializing conversion rates. Change the conversion date only if needed.

      For a euro reporting currency, if the conversion date is 01-JAN-1999 or later, the Reporting Currency - Create Opening Balance Journals in Reporting Currency program uses the defined fixed-rate relationships between the euro and EMU currencies when converting journals that are denominated in an EMU currency. The Reporting Currency - Create Opening Balance Journals in Reporting Currency program also uses triangulation when necessary for the conversion, as prescribed by the European Commission. The program rounds converted amounts as required by local legislative regulations.

    • Conversion Type: Enter the conversion rate type you defined earlier for your initializing rates.

      See: Determine Conversion Dimensions

  4. Choose Apply to save the changes.

  5. Repeat the Reporting Currency setup step for each reporting currency you want to assign to the ledger.

    Important: If you are planning a phased implementation of Reporting Currencies, with different first future conversion periods for different reporting currencies, do not define the "future" reporting currencies now. Only define those reporting currencies for which the balances you plan to initialize now with the Reporting Currency - Create Opening Balance Journals in Reporting Currency program.

Step 4: Open Periods in the Reporting Currencies

Before you run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program, make sure you have opened all the periods in General Ledger for your reporting currency from the period prior to the first historical conversion period up to the period before the first future conversion period.

Step 5: Run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program

Run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program for each combination of ledger and reporting currency.

Note: If you choose to convert a range of accounts, make sure you consider alphabetical segment values when you specify the range. For example, if you have a four-character natural account segment and want to convert all accounts above 3999, enter values from 4000 to ZZZZ, rather than 4000 to 9999.

Post the initializing journals that are created in your reporting currency.

Step 6: Close Periods in Reporting Currencies

For General Ledger, close the periods up to the initial period in your reporting currencies. This ensures that journal entries cannot be entered and posted in those periods in your reporting currency.

Step 7: Reconcile Reporting Currencies

Reconcile reporting currency amounts with ledger amounts. Make adjusting entries to reporting currency amounts, as needed, to ensure correct reporting currency balances.

The task below explains how to reconcile General Ledger accounts whose balances are comprised of journals with multiple entered currencies. For accounts whose balance is comprised solely of journals that are denominated in the same currency, you can easily reconcile the account by simply comparing the account balance between the reports you ran before and after the historical conversion process.

To reconcile reporting currency initial account balances with the source ledger's account balances:

  1. In your reporting currencies, run the same General Ledger reports that you ran during the pre-initialization tasks. See: Run Month-end Reports

  2. Use the Entered Currency General Ledger reports you ran for your ledger to determine the portion of each account balance that is derived from journals that were entered in entered currencies. You must have run the report for each entered currency in your ledger.

  3. Determine the portion of each ledger's account balance that is derived from journals that were entered in your ledger currency. To do this, subtract the amount determined in the previous step from the account ending balance shown on the Detail Trial Balance report for your ledger.

    Example:

    Assume your ledger's' currency is USD and the currency of your reporting currency is EUR. Also assume that only three journals have been entered and posted in your ledger. The entered currencies of the journals were CAD, USD, and EUR. Each journal included a credit to Accounts Receivable (AR).

    Further assume that the conversion rates you've defined for the historical conversion process include:

    From Currency To Currency Conversion Rate
    USD EUR .85
    CAD EUR .5667
    • The Detail Trial Balance report for the ledger (pre-historical conversion) shows an ending balance for AR of $5,500, which is the combined accounted amount the three journals posted to AR.

    • The Entered Currency General Ledger report, run in your ledger (pre-historical conversion) for CAD shows an ending balance for AR of 3,000 CAD (entered amount) and $2,000 (accounted amount after ledger currency conversion).

    • The Entered Currency General Ledger report, run in your ledger (pre-historical conversion) for EUR shows an ending balance for AR of 2,125 EUR (entered amount) and $2,500 (accounted amount after functional conversion).

    • To find the portion of the AR account balance that was actually entered in your ledger currency (USD), subtract the CAD and EUR accounted portions from the total AR accounted balance. The USD entered and accounted amount is $1,000 ($5,500 - 2,000 - 2,500).

  4. Use the Entered Currency General Ledger reports you ran for your reporting currencies to determine the portion of each account balance that is derived from journals whose entered currency is not your reporting currency. You must have run the report for each entered currency in your reporting currency.

  5. Determine the portion of each reporting currency's account balance that is derived from journals whose entered currency is your reporting currency. To do this, subtract the amount determined in the previous step from the account ending balance shown on the Detail Trial Balance report for your reporting currency.

    Example (continued):

    • The Detail Trial Balance report for the reporting currency (post-historical conversion) shows an ending balance for AR of 4,675 EUR, which is the combined accounted amount the three journals posted to AR.

    • The Entered Currency General Ledger report, run in your reporting currency (post-historical conversion) for CAD shows an ending balance for AR of 3,000 CAD (entered amount) and 1,700 EUR (accounted amount after ledger currency conversion).

    • The Foreign Currency General Ledger report, run in your reporting currency (post-historical conversion) for USD shows an ending balance for AR of $1,000 (entered amount) and 850 EUR (accounted amount after ledger conversion).

    • To find the portion of the AR account balance that was actually entered in your reporting currency (EUR), subtract the CAD and USD accounted portions from the total AR accounted balance. The EUR entered and accounted amount is 2,125 (4,675 EUR - 1,700 - 850).

  6. Verify that the entered account balances in your ledger and reporting currencies are the same.

    Example (continued): The entered amounts in both ledgers are 3,000 CAD, 2,125 EUR, and 1,000 USD.

  7. Once you've determined the entered and accounted amounts for the account in your reporting currencies, recompute the converted accounted amount by multiplying the entered amounts by the appropriate conversion rates you defined for use by the Reporting Currency - Create Opening Balance Journals in Reporting Currency program.

    Example (continued):

    CAD: 3,000 CAD X .5667 = 1,700 EUR

    USD: $1,000 X .85 = 850 EUR

    EUR: The accounted amount equals the entered amount: 2,125 EUR

  8. If you note any discrepancies between your ledger and reporting currencies, try to determine the cause of the discrepancies, then determine a course of action. You may want to make adjusting entries in your reporting currencies to eliminate the discrepancies. Alternatively, you may want to restore your pre-historical database, make changes in the ledger, then rerun the Reporting Currency - Create Opening Balance Journals in Reporting Currency program using the same first future conversion period.

Step 8: Open the First Future Conversion Period in General Ledger

For General Ledger, open the first future conversion period in both your ledger and reporting currencies. This will automatically create your beginning account balances for the first future conversion period.

Perform the Post-initialization Tasks

Complete the following post-initialization steps:

Step 1: Define Currency Conversion Rules

The Reporting Currency - Create Opening Balance Journals in Reporting Currency program converts all account balances regardless of the source and category of the individual journals that comprise the account balances. If you reverse one of these journals after running this program, the reversal will not occur in your reporting currencies if your currency conversion rules do not encompass the journal source and category of the journal being reversed. As a result, your ledger and reporting currencies will no longer be synchronized, because the reversal will exist in your ledger, but not in your reporting currencies.

For this reason, you must make sure you define currency conversion rules that encompass any potentially reversible journals that existed at the time you ran the Reporting Currency - Create Opening Balance Journals in Reporting Currency program.

See: Journal Source and Category Conversion, Oracle Financials Implementation Guide

Step 2: (Optional) Define Reporting Responsibilities

Define any reporting responsibilities that you did not define earlier.

See: Step 4: Define Responsibilities

Step 3: (Optional) Assign Reporting Currencies to Reporting Responsibilities

Assign any reporting currencies that you did not assign earlier to reporting responsibilities.

During this step, you have your system administrator set the profile options - GL Data Access Set for each reporting responsibility.

See: Step 5: Assign Data Access Sets to Responsibilities

Step 4: (Optional) Run Year End Carry Forward

For General Ledger, Year End Carry Forward will need to be run in the reporting currency if it was already run in the ledger or if your first historical conversion period crosses fiscal years.

This will only carry forward encumbrances as beginning balances in the first period of the next fiscal year, but it does not roll forward encumbrances as period activity in the next month. If you do not carry forward encumbrances at the end of the fiscal year, all encumbrances are automatically set to zero.

Resume Normal Transaction Processing

Once you successfully complete all of the preceding tasks, you are ready to resume your normal transaction processing. You can begin entering journals in your ledger and the posting program automatically converts journals to your reporting currencies as explained earlier.

Related Topics

Performing Standard General Ledger Activities

Using Reporting Currencies

Perform Historical Conversion Maintenance

To ensure the integrity and reconcilability of reporting amounts and balances, we recommend that you disable the Reporting Currency - Create Opening Balance Journals in Reporting Currency program once the historical conversion has been completed successfully. If you subsequently need to convert transactions and initialize account balances for a new reporting currency, you can enable the program again.

To disable or enable Reporting Currency - Create Opening Balance Journals in Reporting Currency program:

  1. Log in to Oracle Applications as the System Administrator.

  2. Navigate to the Concurrent Programs window.

  3. Query GLMRCU, the program short name of the Reporting Currency - Create Opening Balance Journals in Reporting Currency program.

  4. Mark the Enabled check box to enable the program. Unmark the check box to disable the program.

  5. Save your work.

Parameters for Reporting Currency - Create Opening Balance Journals in Reporting Currency Program

In this section, we describe the parameters required to run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program.

Running the Reporting Currency - Create Opening Balance Journals in Reporting Currency Program

Run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program. This program creates journals in your reporting currency `to initialize actual and encumbrance account balances for the periods converted from your ledger.

After you post the initializing journals in your reporting currencies and open the first future conversion period, your actual and encumbrance reporting balances will be initialized.

Regardless of the conversion option you choose, the Reporting Currency - Create Opening Balance Journals in Reporting Currency program:

Reporting Currency - Create Opening Balance Journals in Reporting Currency Program Parameters

You run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program from your ledger responsibility. When you submit the program, you will be asked to provide the following parameters:

Validation Checking

The Reporting Currency - Create Opening Balance Journals in Reporting Currency program performs the following validation checking:

If any of the validation checks fail, the Reporting Currency - Create Opening Balance Journals in Reporting Currency program stops with an error condition before any balances are converted. You can review the log file for any error messages.

Reporting Currency Account Type Specific Conversion

Note: Unless otherwise specified in this chapter, the term Reporting Currency refers to subledger or journal-level reporting currency, rather than balance-level reporting currency.

To report period-end activities in the reporting currency, Account Type Specific Conversion is available so you no longer have to repeatedly run revaluation and translation to get your most current reporting currency balances. This feature applies well to multi-national customers, especially in financial services, where a high volume of feeder system transactions and frequent adjustments occur during the period-end close cycle.

This streamlined process converts transactions directly using SFAS 52 remeasurement compliant period or historical rates according to the natural account type. Transactions entered in the ledger can be converted to the reporting currency using period-end rates for balance sheet accounts and period-average rates for income statement accounts. You can also supply historical rates or historical amounts for individual owner's equity items.

Reporting Currency Account Type Specific Conversion

Reporting Currency Account Type Specific Conversion simulates real-time revaluation and translation system. This eliminates the need to run revaluation and translation multiple times during the period close cycle. Revaluation runs are reduced by posting, in the ledger, all foreign currency balance sheet transactions using period-end rates and all foreign currency income statement transactions using period-average rates. Translation is replaced by the Reporting Currency (journal and subledger level) functionality which maintains reporting currency information at both transaction and balance levels. The reporting currency amounts in the reporting journals are calculated by converting from the ledger currency instead of the transaction currency. Historical rates or historical amounts can be input for any owners' equity or other transaction. If the transaction currency and the reporting currency are the same, the reporting currency amounts may not be the same as the transaction currency amounts since the reporting currency is calculated from the accounted amount, not the entered amount. Any currency conversion differences in the ledger currency are captured in a cumulative translation adjustment account in the reporting currency.

Posting of foreign currency transactions in the ledger using different rates for balance sheet and income statement accounts is supported by ADI 7.0 and higher. Simply select multiple foreign currency journals when you create the Journal Wizard spreadsheet and do not enter any conversion type for the line. For any owners' equity or other transaction requiring an historical rate or amount, just enter the required conversion rate or conversion amount in the appropriate column of the worksheet.

Setup

To support Reporting Currency Account Type Specific Conversion, the following steps are required:

Each of these steps is discussed in detail below.

Note: The reporting conversion type will be ignored when the Account Type Specific Conversion feature is enabled. The conversion to the reporting currency will be from the ledger currency, not the transaction currency

Inherit Conversion Type

This determines whether Reporting Currency should inherit the conversion type used in the primary journals.

Note: This option will be ignored when the Account Type Specific Conversion feature is enabled.

Create Currency Conversion Types

The currency conversion types to hold income statement and balance sheet conversion rates are created through the Conversion Rate Types form. These conversion types are used by ADI to convert to the ledger currency. They are also used when posting to convert from the ledger currency to the reporting currency.

Modify the Journal - Journal Entry Lines Descriptive Flexfield

You will need to define two unique segments for this descriptive flexfield:

These segments will be used exclusively for Reporting Currency Account Type Specific Conversion and must not be used to hold other values. For each of the segments, you will need to uncheck the Value Required field in the Descriptive Flexfield Segments window.

Rate Number Segment

This segment will an overriding historical rate to convert the source ledger currency to the reporting currency for that journal line (rate segment).

Amount Number Segment

This segment will hold the historical amount expressed in the reporting currency (amount segment).

Set the New Profile Options

Six new profile options are provided which are enabled at the site, application, and responsibility levels. If you choose to assign these profile options at the responsibility level, they must be assigned to a responsibility for the ledger.

The profile options are as follows:

GL/MRC: Income Statement Conversion Type

This option specifies the daily conversion type to convert income statement (revenue or expense) transactions from the transaction currency to the ledger currency and from the ledger currency to the reporting currency. Typically, it is the average currency exchange rate of the period. The same rate should be entered for each day in the period.

GL/MRC: Balance Sheet Conversion Type

This option specifies the daily conversion type to convert balance sheet (asset, liability, and owners' equity) transactions from the transaction currency to the ledger currency and from the ledger currency to the reporting currency. Typically, it is the end of period currency exchange rate. The same rate should be entered for each day in the period.

GL/MRC: Reporting Book Using Overriding Historical Rates/Amounts

This option identifies the main reporting currency that overriding historical rates or amounts entered in ADI should apply to. There can be one and only one main reporting currency for each ledger. For all other reporting currencies, no overriding historical rates or amounts will be used and all amounts will be converted based on account type.

GL/MRC: Historical Rate Segment

This is a descriptive flexfield segment name indicating the segment in the journal entry line descriptive flexfield that holds overriding historical rates, typically for owners' equity lines.

Note: A value in this profile option enables this entire feature.

GL/MRC: Historical Amount Segment

This is a descriptive segment column name indicating the segment in the journal entry line descriptive flexfield that holds overriding historical amounts, typically for owners' equity lines.

If the profile options MRC/GL: Reporting Book Using Overriding Historical Rates/Amounts, GL/MRC: Historical Rate Segment, or GL/MRC: Historical Amount Segment are set at the responsibility level, you should ensure that different responsibilities for the same ledger have the same values for these options.

Enable and Set Up Rounding Differences Accounts

When foreign currency transactions are converted to ledger or reporting currency, there may be out-of-balance conditions because journal lines are converted at different currency exchange rates. The Rounding Differences feature tracks these out-of-balance amounts in a separate journal line. This feature is enabled by setting it at the source ledger. When you select this feature, you must also identify the account used to track the rounding differences.

To support FASB 52 criteria, typically the rounding difference is assigned to a gain/loss account in the ledger, and an owners' equity account (CTA) in the reporting currency.

Note: Based on the balancing segment values used in the actual journals being posted, posting will substitute the balancing segment value in the rounding differences account template to derive the actual rounding difference account combination needed.

Populate Currency Conversion Rates

For both daily conversion types, you must populate the conversion rates. Typically, these rates will be the same for every day in the period. The date range feature in the Daily Rates form or the open interface allows users to easily enter rates for all days. If the daily rates were not available when posting to the ledger or reporting currency and prior rates were used, the period-end and period-average rates must be loaded before revaluation can be performed.

Related Topics

For further information about defining descriptive flexfields, see Oracle E-Business Suite Flexfields Guide.

ADI Journal Wizard Entry

The processing changes to ADI Journal Wizard are for the primary journals, not the reporting journals. These changes are only effective when you have enabled the Account Type Specific Conversion functionality. The Journal Wizard changes allow you to enter the overriding historical rates or historical amounts in the new descriptive flexfield segments. The overriding rates or amounts are used to convert to the main reporting currency and are not used by Journal Wizard for processing. Journal Wizard does validate that the amounts entered in these segments are numeric.

There are a number of currency conversion options for foreign currency transactions entered using Journal Wizard. If there is an EMU Fixed Rate relationship between the transaction currency and the ledger or reporting currency, the conversion type automatically defaults to EMU Fixed and the conversion rate is derived by Journal Wizard according to the euro triangulation rules. This overrides any conversion data you have entered. For other foreign currency transactions, the potential conversion options are:

Each of these is described below.

Account Type Conversion

Enter only the conversion date. Journal Wizard determines the conversion rate based on the account type, the values of the "GL/MRC: Income Statement Conversion Type" and the "GL/MRC: Balance Sheet Conversion Type" profile options, and the conversion date.

Historical Rate Conversion

Enter a historical rate in the conversion rate column. Journal Wizard uses that rate to calculate the converted amount. Typically, if you have entered a historical rate to convert to the ledger currency, you will also populate the corresponding descriptive flexfield segment column with the historical rate for converting from the ledger to the main reporting currency.

Historical Amounts

Enter an amount in the converted debit or converted credit columns. Journal Wizard uses this entered amount as the converted amount. Conversion Type, Conversion Date, and Conversion Rate should be left blank by the user in this case. Entered historical amounts override any other entered conversion data. Typically, if you have entered a historical amount for the ledger currency, you will also populate the corresponding descriptive flexfield segment column with the historical amount for the main reporting currency.

Other (Exception Processing)

Enter the conversion type and conversion date. Journal Wizard looks up the rate in the GL_DAILY_RATES table and uses that rate to calculate the converted amount.

Transaction Processing

There are some differences in the processing between transactions entered through ADI Journal Wizard and transactions from automated feeds. The processing for each is discussed below.

ADI Journal Wizard

After you finish entering journals in Journal Wizard, submit the upload to General Ledger. Once you have set up the GL/MRC: Historical Rates Segment profile option, ADI validates that all other associated profile options are assigned properly. If there are not valid values for all required profile options, ADI reports an error. In addition to the standard Journal Wizard validations, the following conditions also create errors for the journal line:

During the upload, Journal Wizard calculates the converted amounts for the primary journals based on the data entered for that journal line as discussed above under Transaction Entry.

Conversion Rate Not Found

If conversion is based on account type, during the upload Journal Wizard looks up the conversion rate based on the conversion date. If no rate is loaded for that date and you have enabled the option when no rate is found to Use Last Rate, Journal Wizard searches back to find the last entered rate and uses that to convert the balances. The only exception is if the number of days between the conversion date and the last entered rate exceeds the value in the profile option MRC: Maximum Days to Roll Forward Conversion Rate, in which case Journal Wizard reports an error for that journal line.

If conversion is based on any other conversion type or the option when no rate is found is set to Report Error, and there is no rate loaded for the conversion date, Journal Wizard reports an error for that journal line.

Note: If up-to-date period-end and period-average rates are not available, when the rates become available, you should populate the rates (period-end and period average) and run revaluation in the ledger and all reporting currencies.

Automated Feeds

You have a number of currency conversion options for foreign currency transactions from the automated feeds. If there is an EMU Fixed Rate relationship between the transaction currency and the ledger currency, the conversion type automatically defaults to EMU Fixed and the conversion rate is derived by Journal Import according to the euro triangulation rules. This overrides any conversion rate or type information provided directly by the feeds. For other foreign currency transactions, the potential conversion options are:

Each of these is described below:

Account Type Conversion

The feed provides period end rates for balancing sheet account lines and period average rates for income statement account lines, directly in the conversion rate column. Conversion type and date columns should be left blank. Alternatively, the feed can choose to provide period end rate type and period average rate type for the appropriate account class lines, and let Journal Import derive the rates accordingly.

Note: As Journal Import groups transaction lines with different provided rates or rate types into different journal headers, the feed should ensure that lines from the same account class be balanced in their entered amounts.

In addition, the feed can choose to perform the account type based conversion and provide the converted amounts directly. This approach allows the feed to group lines from different account classes converted with different rates into the same journal header, as long as the entered amounts are in balance.

Historical Rate Conversion

The feed provides a historical rate in the conversion rate column for an owners' equity account. Journal Import uses that rate to calculate the converted amount.

Historical Amounts

The feed provides a historical amount in the converted debit or converted credit column directly for an owners' equity account. Conversion Type, Conversion Date, and Conversion Rate should be left blank in this case. Any converted amounts provided override other types of conversion information.

Note: The automated feeds can also provide overriding rates or amounts for converting to the reporting currency in the same descriptive flexfield segment columns as specified in the GL/MRC: Historical Rate/Amount Segment profile options.

Foreign Currency Primary Journals Posting

If a primary journal from any source becomes out of balance due to different currency exchange rates used for different journal lines, posting balances the journal in a new journal line with the account specified for rounding differences in the ledger definition. This account should be the income statement gain/loss account.

Reporting Journals Generation

The process to create reporting journals is the same for transactions from both automated feeds and ADI Journal Wizard. Following the same account type based rules, posting determines the conversion type to use through the corresponding profile options. It then looks up the conversion rate using the same conversion date used for the ledger’s journals. This rate is multiplied by the ledger currency amount to calculate the reporting currency amount.

If an overriding historical conversion rate or converted amount was entered in the descriptive flexfield rate segment columns, conversion will not be based on account type. Instead, if a rate was entered in the rate segment, that rate is multiplied by the ledger currency amount to derive the reporting currency amount. If an amount was entered in the historical amount segment, that amount is used as the reporting currency amount.

Any gain/loss lines generated in posting due to different exchange rates used for converting to the ledger currency will be converted into the reporting currency using the rate type for income statement accounts.

Conversion Rate Not Found

If no rate is found for a conversion date, posting follows the No Rate Action option selected for the journal source and category. If Use Last Rate was selected, posting uses the last entered rate for that conversion date. The only exception is if the number of days between the conversion date on the transaction and the date of the last entered rate exceeds the number of days in the Number of Days to Find Last Rate in the reporting currency definition. If that is the case, as well as the case where No Rate Action is set to Report Error, the reporting journal will not be created and posting in the ledger will fail.

Reporting Currency Journals Posting

If a reporting currency journal becomes out of balance due to different currency exchange rates used for the journal lines, posting balances the journal in a new journal line with the account as specified for rounding differences in the ledger definition. For compliance with FASB 52 criteria, the account for this journal line should typically be an owners' equity account (CTA).

Inquiry and Reporting

Once the ledger’s journals have been created, they can be viewed using Journal Inquiry in the ledger. When you select a journal, you will be able to view the entered transaction currency and converted ledger and reporting currency amounts. Any overriding historical rates or amounts for converting to the reporting currency can also be viewed in the journal line descriptive flexfield.

In the reporting currencies, you can view the reporting journals which contain the entered transaction currency and the converted reporting currency amounts. The entered transaction currency amounts are the same as those in the ledger’s journals.

Reporting

You can use the Financial Statement Generator (FSG) to create reports across both the ledger and the reporting currencies. These reports could show transaction, ledger, and reporting currency balances side-by-side on the same report. In General Ledger, you can specify the currency of each column in an FSG report and the ledger or reporting currency the balances should be derived from. The following describes how you would define columns with different currency requirements:

Transaction Currency Column (except amounts entered in the currency of the reporting currency)

Enter a control value number in the Currency field for the column. Enter the name of the ledger in the Ledger field in the Account Assignments window. Assign the transaction currency to the control value number and select the Currency Type as Entered in the report definition.

Entered Reporting Currency Column

Enter a control value number in the Currency field for the column. Enter the name of the reporting currency in the Account Assignments window. Assign the ledger currency to the control value number and select the Currency Type as Entered in the report definition.

Ledger Currency Column

Enter the ledger currency in the Currency field. Enter the name of the ledger in the Ledger field in the Account Assignments window.

Reporting Currency Column

Enter the currency of the reporting currency in the Currency field. Enter the name of the reporting currency in the Ledger field in the Account Assignments window. You can run many standard reports in the ledger for both the transaction and the ledger currencies. In the reporting currency, the same standard reports can be run for both the transaction and the reporting currencies. The standard reports that show transaction currency data include:

Example

Assume there is GBP ledger and a USD reporting currency. Now, suppose a user creates the following EUR journal entry in ADI with an effective date of January 10, 2000. The journal entry is summarized in the following table:

Line Account (Account Type) Entered Debit Entered Credit Ledger Curr. Conv. Debit Ledger Curr. Conv. Credit Ledger Curr. Hist. Conv. Rate Rept. Curr. Hist. Conv. Rate Rept. Curr. Hist. Conv. Amount (+DR/-CR)
10 01.1010 (Asset) 1000            
20 01.3010 (Owner's Equity) 250       .630 1.56  
30 01.3011 (Owner's Equity) 250   170       280
40 01.4002 (Revenue)   1500          

Line 20 contains an owners' equity account and the user has specified a historical rate of .630 for converting EUR to GBP (ledger currency). The user has also specified a historical rate of 1.56 to use when converting this line from GBP to USD (reporting currency) for the reporting journal. For line 30, the user has specified a converted debit of 170 in the ledger and has specified a historical amount of 280 in the reporting currency.

Assume that the "GL/MRC: Income Statement Conversion Type" profile option is set to Period-Average, and the "GL/MRC: Balance Sheet Conversion Type" profile option is set to Period-End. Suppose the daily conversion rates for January 10, 2000 are as listed in the following table:

From Currency To Currency Conversion Date Conversion Type Conversion Rate
EUR GBP January 10, 2000 Period-Average .631
EUR GBP January 10, 2000 Period-End .628
GBP USA January 10, 2000 Period-Average 1.50
GBP USA January 10, 2000 Period-End 1.60

The resulting journal will appear as detailed in the following table:

Line Account (Account Type) Entered Debit Entered Credit Ledger Curr. Conv. Debit Ledger Curr. Conv. Credit Rept. Curr. Hist. Conv. Rate Rept. Curr. Hist. Conv. Amount (+DR/-CR)
10 01.1010 (Asset) 1000   628      
20 01.3010 (Owner's Equity) 250   158   1.56  
30 01.3011 (Owner's Equity) 250   170170     280
40 01.4002 (Revenue)   1500   947    
  TOTALS 1500 1500 956 947    

The asset account on line 10 was converted using the Period-End rate, the owner's equity account on line 20 was converted using the specified historical rate, the owner's equity account on line 30 was converted using the entered historical amount, and the revenue account on line 40 was converted using the Period-Average rate. Due to the different rates, converted debits do not equal converted credits.

Assume that a gain/loss account of 01.5100 has been identified as a rounding differences account for their ledger. Then, after the journal has been posted, it would appear in the ledger as listed in the following table:

Line Account (Account Type) Entered Debit Entered Credit Ledger Curr. Conv. Debit Ledger Curr. Conv. Credit Rept. Curr. Hist. Conv. Rate Rept. Curr. Hist. Conv. Amount (+DR/-CR)
10 01.1010 (Asset) 1000   628      
20 01.3010 (Owner's Equity) 250   158   1.56  
30 01.3011 (Owner's Equity) 250   170170     280
40 01.4002 (Revenue)   1500   947    
50 01.5100 (Gain/Loss)       9 1.50  
  TOTALS 1500 1500 956 947    

Posting has automatically added the gain/loss line to balance converted debits and converted credits. Posting has also loaded the desired GBP to USD conversion rates into the Reporting Currency Historical Conversion Rate descriptive flexfield. For the asset account, the Period-End conversion type was used. For the revenue and expense accounts, the Period-Average conversion type was used. For the owner's equity account on line 20, the conversion rate was already specified, so the value of attribute5 was unchanged. For the owner's equity account on line 30, a historical amount was specified, so the value of Reporting Currency Historical Conversion Rate descriptive flexfield was left empty.

When the above journal is posted, the reporting journal will be created as listed in the following table:

Line Account (Account Type) Entered Debit Entered Credit Converted Debit Converted Credit
10 01.1010 (Asset) 1000   1005  
20 01.3010 (Owner's Equity) 250   246  
30 01.3011 (Owner's Equity) 250   280  
40 01.4002 (Revenue)   1500   1421
50 01.5100 (Gain/Loss) 0     14
  TOTALS 1500 1500 1531 1435

Again, converted debits no longer equal converted credits due to the different exchange rates.

Assume in the reporting currency that the cumulative translation adjustment account 01.5000 has been defined as a rounding differences account. Then, after the reporting journal is posted, it will appear as listed in the following table:

Line Account (Account Type) Entered Debit Entered Credit Converted Debit Converted Credit
10 01.1010 (Asset) 1000   1005  
20 01.3010 (Owner's Equity) 250   246  
30 01.3011 (Owner's Equity) 250   280  
40 01.4002 (Revenue)   1500   1421
50 01.5100 (Gain/Loss)   0   14
60 01.5000 (Owner's Equity)   0   96
  TOTALS 1500 1500 1531 1531

Note that a cumulative translation adjustment line (01.5000) has automatically been added by posting to balance converted debits and converted credits.