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 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:
You operate in a country that is part of the European Economic and Monetary Union (EMU), and you choose to account for and report both the euro and your National Currency Unit (NCU).
You operate in a country whose unstable currency makes it unsuitable for managing your business. As a consequence, you need to manage your business in a more stable currency while retaining the ability to report in the unstable local currency.
Related Topics
Overview of 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:
Translation converts ledger currency amounts to the designated currency. Reporting currencies convert amounts from the transaction currency to the designated currency.
Reporting currencies uses daily rates to convert transaction amounts. Translation uses period or historical rates to translate account balances.
Before you use your currency's amounts in lieu of translating your ledger's amounts, you need to understand and carefully consider:
How reporting currencies work
The country-specific accounting rules and regulations that govern your parent and subsidiary companies
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:
Translated budget amounts. Your FSG column set can draw these amounts directly from your balance level reporting currency.
Reporting currency actual amounts. Your FSG column set can draw these amounts from your reporting currency.
The variance between budget and actual, expressed in your reporting currency
Related Topics
Translating Balances, Oracle General Ledger User's Guide
Defining Reporting Currencies for Fresh Install and Upgrade Scenario One
Defining Reporting Currencies for Upgrade Scenario Two
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.
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.
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.
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.
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
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
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.
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.
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.
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.
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:
If you have not specified a rounding imbalances account in the source ledger, the rounding difference is posted to the journal line with the largest amount.
If you have specified a rounding imbalances account, the rounding difference is posted to the rounding imbalances account.
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:
Minimizes the effects of exchange rate fluctuations for cross-enterprise budgeting, management reporting, and worldwide financial analysis
Increases accuracy through transaction-level conversion instead of account-level conversion
Shortens the reporting cycle by providing immediate access to information via the reporting currency
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.
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:
This step is generally performed by a system administrator.
Use your standard subledger responsibilities to perform day-to-day activities, such as creating purchase orders or invoices.
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.
Use the Responsibilities window to define your responsibilities.
Note: See: Responsibilities Window, Oracle Applications User's Guide
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 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.
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.
Conversion business rules for variable exchange rate relationships are described below.
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:
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.
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)
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:
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)
The following diagram illustrates the conversion business rules that apply when the transaction currency is the same as the reporting currency:
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:
EMU Fixed: when both of the currencies are either an EMU currency or the euro
User: when you specify a transaction-to-ledger currency conversion rate
A conversion rate type you specify (e.g., Corporate or Spot)
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
Defining Conversion Rate Types
Overview of Multi-Currency Accounting
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:
Currency Precision: the number of digits to the right of the decimal point used in regular currency transactions.
Extended Precision: the number of digits to the right of the decimal point used in calculations for the currency.
Minimum Accountable Unit: the smallest denomination used in the currency. Note that this might not correspond to the precision.
Note: Oracle Applications predefines all currencies specified in ISO (International Standards Organization) Standard #4217.
Related Topics
Reporting Currency Conversion Rules
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:
Considerations For Entering Data into Reporting Currencies: Discusses considerations for entering data into reporting currencies.
Performing Standard General Ledger Activities: Discusses how some standard General Ledger activities require new steps or additional information when Reporting Currencies are used. Also notes which activities must be performed in both your ledgers and reporting currencies.
Completing Reporting Currencies-related Activities in the Correct Order: Discusses the increased importance of completing certain General Ledger activities in the correct order.
Applications Desktop Integrator Journal Wizard: If you have Account Type Specific Conversion enabled, processing changes occur to ADI Journal Wizard for source ledger journals.
Related Topics
Considerations for Entering Data into Reporting Currencies
Performing Standard General Ledger Activities
Completing Reporting Currencies-Related Activities in the Correct Order
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
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.
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.
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:
Manual journals you enter on the Enter Journals window
Recurring journals and MassAllocations
Unposted journals from a non-Oracle feeder system
Unposted journals from an Oracle subledger that does not support Reporting Currencies
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:
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:
Yes: When you post a journal in your ledger, the same username of the individual who created the journal will be used as the creator of the reporting currency journal.
No: When you post a journal in your ledger, the username of the person posting the journal will be used as the creator of the reporting currency journal.
Notes:
If you enter a journal directly in your reporting currency, you can only reverse it in your reporting currency.
When Journal Approval is Enabled: Any reversing journals that are generated in your reporting currencies as a result of reversing an original journal in the source ledger will not require approval, regardless of whether Journal Approval has been enabled in your reporting ledgers. Once the reversal of the original journal for the source ledger is approved, the reporting currency’s reversal journal will not require approval.
See: Defining Reverse Journal Entries
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. |
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.
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
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:
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
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.
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:
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.
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.
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).
There are two ways in which you can set up General Ledger to enhance revaluation processing and support SFAS #52:
set up period-to-date (PTD) revaluation for income statement accounts
set up reusable revaluation ranges
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.
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
There are two methods for revaluing in Reporting Currencies:
Don't Convert: gains and losses arising from revaluation in the ledger are NOT converted to your reporting currencies.
Convert: gains and losses arising from revaluation in the ledger are converted to your 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:
Make sure there is no conversion rule that allows revaluation journals to be converted.
Caution: A conversion rule with the Convert option set to Yes, a Category of Other, and a Source of Other will result in revaluation gains and losses being converted.
Optionally, or if there is a conversion rule that will result in revaluation gains and losses being converted, create a conversion rule that specifically prevents revaluation journals from being converted, by using the following parameters:
Convert option: No
Category: Revaluation
Source: Revaluation
Create a conversion rule using these parameters:
Convert option: Yes
Category: Revaluation
Source: Revaluation
Note: A conversion rule with the Convert option set to Yes, a Category of Other, and a Source of Other will result in the same behavior.
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
The second revaluation method - to convert revaluation gains and losses-is more complicated. The following flowchart depicts the revaluation process:
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.
Run revaluation in your ledger for selected, foreign currencies. This process computes gains and losses from changes in exchange rates for account balances in your ledger that are denominated in a foreign currency. There is no immediate effect in the reporting currency.
See: Revaluing Balances
This process generates revaluation journal entries by currency for the ledger.
Note: If there are no foreign currency-denominated balances in the ledger, no revaluation journal entries are generated (there is nothing to revalue).
Each revaluation journal includes:
Lines to adjust the converted amounts of the foreign currency account balances, to reflect the exchange rate as of the balance sheet date.
The amount needed to balance the journal is recorded as an entry to the exchange gain/loss account you select.
Entered amounts are set to zero.
If the revaluation journal in the ledger created no gain/loss lines because the accounts being revalued offset each other, the converted revaluation journal in the reporting currency will have a header, to indicate that the conversion took place, but no journal lines.
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.
In the ledger, post the revaluation journals generated by Step 1.
Upon posting, revaluation journals are converted to the currency of your reporting currency.
For the converted revaluation journals:
The exchange gain or loss of the ledgers' revaluation journal is converted using the related rate for the reporting conversion type you specified for the conversion rule. Typically, you will use a period average rate.
For example, assume you use the reporting conversion type "Average" for your period average rates and you created the following conversion rule when you set up your reporting currency:
Convert option: checked Yes
Category: Revaluation
Source: Revaluation
Reporting Conversion Type: Average
If the ledger currency is EUR, the reporting currency is USD, and you run Revaluation for Sep-1999, your revaluation journals will be converted using the Average rate type you defined for Sep-1999.
The balancing amount of the reporting currency's revaluation journal is made to the Cumulative Translation Adjustment account. No adjustments are made to other balance sheet accounts.
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.
Run Revaluation in the reporting currency if the currency of the original entered amount in the ledger is different from the currency of the reporting currency. Choose to record any exchange gains or losses to the cumulative translation adjustment account.
This process computes gains and losses from changes in exchange rates for account balances in your reporting currency that are denominated in a foreign currency (i.e., a currency other than the reporting currency).
This process generates revaluation journal entries by currency for the reporting currency.
Each revaluation journal includes:
Lines to adjust the converted amounts of the foreign currency account balances, to reflect the exchange rate as of the balance sheet date.
The amount needed to balance the journal is recorded as an entry to the account you select. You should choose the cumulative translation adjustment account.
Entered amounts are set to zero.
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)
In the reporting currency, post the revaluation journals generated by Step 4.
For Translation and Consolidation Information, see: Translation versus Reporting Currencies
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
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
Considerations for Entering Data into Reporting Currencies
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.
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.
Enter the daily exchange rates to convert your journals to each of your reporting currencies.
You need to be sure to complete the following period-end tasks:
Finish entering all regular and adjusting journals for the period in your ledger.
Post all unposted journals in your ledger if not already done in the previous step.
Post all unposted journals in your reporting currencies if not already done in the previous step.
Run Revaluation in both your ledger and reporting currencies. Post the resulting revaluation batches in each ledger.
See: Revaluation
Generate needed reports from both your ledger and reporting currencies.
Close your accounting period in both your ledger and reporting currencies.
Related Topics
Considerations for Entering Data into Reporting Currencies
Performing Standard General Ledger Activities
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
Type of Installation: Different issues arise when you implement Reporting Currencies for a new Oracle Applications installation versus enabling Reporting Currencies at any time after upgrading from an earlier version of Oracle Applications.
See: Type of Installation
Initializing Account Balances in Reporting Currencies: Explains how to initialize the beginning account balances in your reporting currencies for the different installation types. This includes the procedures to follow whenever you need to add a new reporting currency to a new or existing ledger.
See:
Defining Reporting Currencies for Fresh Install or Upgrade Scenario One
How Your Choice of Periods Affects Conversion: Discusses the importance of determining your First Historical Conversion Period and First Future Conversion Period.
Terms and their definitions used in this chapter are listed in the table below.
You can use Reporting Currencies in three specific types of installations:
Fresh Install: New customers who install Oracle Applications for the first time and define Reporting Currencies.
Upgrade Scenario One: Existing customers who upgrade to Oracle Applications Release 11, or later, then define Reporting Currencies for a new ledger.
Upgrade Scenario Two: Existing customers who upgrade to Oracle Applications Release 11, or later, then define Reporting Currencies for an existing ledger.
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
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.
Perform the Reporting Currencies setup steps.
See: Setting Up Reporting Currencies
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.
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.
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.
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
How Does My Choice of Periods Affect Conversion?
Translation versus Reporting Currencies
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
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.
This section is a general discussion of the importance of determining appropriate dates and periods for initialization, in particular:
First Future Conversion Period
First Historical 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:
We recommend your First Future Conversion Period to be the first period of a quarter to ensure that the quarter-to-date reporting currency balances for the quarter in which you enable Reporting Currencies are correct.
If you use average balance processing and need to report average balances in your reporting currencies, choose a First Future Conversion Period that begins on the first day of a fiscal year. This ensures that your period-average-to-date, quarter-average-to-date, and year-average-to-date reporting currency balances will be correct.
Your First Future Conversion Period must be the first future-enterable period or, if you do not allow future-enterable periods, the first never opened period in General Ledger for the ledger at the time you run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program.
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.
For a text description of the Reporting Currency Initialization diagram, see: Reporting Currency Initialization Diagram, Oracle General Ledger Reference Guide
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:
No: This option converts the account balances from the ledger to the reporting currency using the conversion rate determined by the Historical Conversion Rate date and type indicated in the Reporting Currency Historical Conversion section in Accounting Setup Manager.
Yes: This option, only available when there is an EMU-fixed relationship between the ledger and reporting currency, derives the reporting currency amount from the original transaction conversion rate. EMU fixed rates will be used.
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 |
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 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:
General Ledger Account Balances: Monetary account balances (actuals) and asset account balances (actuals) are converted using the single initializing rate.
Non-monetary account balances (actuals) are converted using weighted average rates when available. Foreign-entered balances are carried over to your reporting currencies.
For encumbrances, amounts are converted using the initializing rate between the ledger currency and the reporting currency. Encumbrances are only entered in the reporting currency. Reporting entered encumbrance amounts will be set equal to the converted reporting accounted encumbrance amounts.
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.
Conversion dates for the following conversion options are as follows:
Retain the Original Conversion Rate Type Option Set to Yes: The same date is used in reporting currency as in the ledger since the conversion is derived from the original transaction rate. If a date does not exist, then the transaction date is used.
Retain the Original Conversion Rate Type Option set to No: The date is the conversion date specified in the Reporting Currency page in ASM, Historical Conversion section.
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
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 |
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.
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:
Retain the Original Conversion Rate Type Option set to Yes
Converts your ledger's period-to-date account balances by entered currency, to your reporting currencies beginning with the first historical conversion period you specify through the initial period and converts year-to-date account balances for the period prior to the first historical conversion period.
Retain the Original Conversion Rate Type Option set to No
Converts your ledger year-to-date account balances, by entered currency, to your reporting currencies for the period prior to the first future conversion period.
For actual amounts, the journal's entered and converted currency amounts are as shown in the following table. For encumbrance amounts, see: How Are Encumbrance Balances Initialized?
Ledger’s Entered Actual Balances Denominated in: | Reporting Currency’s Entered Actual Balances | Reporting Currency’s Actual Balances |
---|---|---|
Foreign currency that is NOT the same as the reporting currency | Ledger’s foreign entered account balances | Ledger’s foreign entered account balances converted using the initializing rate for monetary accounts and weighted average rates for non-monetary accounts OR ledger’s foreign entered account balances converted using the rate derived from the original transaction rate |
Foreign currency that is the same as the reporting currency | Ledger’s foreign entered account balances | Ledger’s foreign entered account balances |
Ledger currency | Ledger’s account balances minus ledger currency equivalent of all foreign entered amounts | Calculated foreign entered account balances converted using the initializing rate for monetary accounts and weighted average rates for non-monetary accounts |
Note: You must manually post the initializing journals in your reporting currencies, and we recommend that you do so before you open the first future conversion period to ensure that your first future conversion period is clean. Posting the journals initializes the reporting account balances converted from the periods in your ledger. When you later open the first future conversion period, the initial period's ending balances roll forward to become the beginning reporting account balances for the first future conversion period.
Caution: We strongly recommend that you do not enter any journals in your reporting currencies until the Reporting Currency - Create Opening Balance Journals in Reporting Currency program has been completed successfully.
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.
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.
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.
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
Step 2: Determine the Reporting Currencies to Initialize
Step 3: Determine the First Future Conversion Period
Step 4: Determine When to Run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program
Step 5: Prepare Your Initialization Plan
Read this chapter thoroughly before you start using Reporting Currencies and run the initialization.
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
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:
From a business perspective, when do you want to begin reporting account balances in your reporting currencies? If the dates are different for each of your currencies, you should consider a phased implementation of reporting currencies.
When does your accounting calendar begin? Reporting Currencies can be enabled at any time. However, it makes great sense to synchronize your first future conversion period with the first period of the year in your accounting calendar. This way, your reporting currencies will include a complete year of income and expense data rather than a partial year of data.
You should also consider synchronizing the first future conversion period with the:
First period of a quarter. This will ensure that quarter-to-date reporting currency balances are properly stated for your first quarter.
First day of your fiscal year if you plan to use average balance processing in your reporting currencies. This will ensure that your period-average-to-date, quarter-average-to-date, and year-average-to-date reporting currency balances are properly stated for the first period of your fiscal year.
Are you operating in a country that is a member of the EMU? If so, coordinate your choice of the first future conversion period with your planned implementation of euro accounting and reporting.
In the euro case, where your ledger is denominated in an EMU currency and your reporting currency is denominated in the euro, if the first future conversion period does not include the first day of the fiscal year the opening year-to-date income and expense account balances in your euro reporting currency will equate to the closing balances of the previous period in your EMU ledger.
Important: The Reporting Currency - Create Opening Balance Journals in Reporting Currency program will validate that the first future conversion period is the first future-enterable period or, if you do not allow future-enterable periods, the first never opened period in General Ledger in the ledger at the time you run the program. If it is not, the program completes with error without converting any of your account balances.
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.
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:
Clean up your ledger
Determine all conversion parameters.
Ensure that the first future conversion period meets all the necessary criteria for running the Reporting Currency - Create Opening Balance Journals in Reporting Currency program. See: Step 3: Determine the First Future Conversion Period.
Back up existing data
Define Reporting Currencies, responsibilities, and periods
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:
You must suspend all transactions processing during the initialization process
The initialization process may take longer than one night for some organizations that have large volume databases.
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:
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?
Prepare a written initialization plan based on the information presented in this section.
In this section we discuss the steps you need to complete when preparing for the initialization:
Step 1: Note Periods and Review Calendars
Step 2: Determine First GL Period for Reporting Currencies
Step 3: Determine Conversion Dimensions
Step 4: Determine Conversion Extent
Step 5: Determine Rollback Segment Size
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:
Must be the first future-enterable period or, if you do not allow future-enterable periods, the first never opened period in General Ledger in your ledger at the time you run the initialization
Can be an adjustment 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:
The initial period is the period preceding the first future conversion period.
The initial period cannot be an adjustment period.
Note: If the first future conversion period precedes an adjustment period, in General Ledger, then we recommend that you select the adjustment period as your first Reporting Currency period for purposes of the initialization. For example, assume your accounting calendar includes the following periods and you want to begin reporting transactions and balances in your reporting currencies in January 1999:
DEC-98
ADJ-98
JAN-99
You cannot choose JAN-99 as your first future conversion period for purposes of the Reporting Currency - Create Opening Balance Journals in Reporting Currency program, since that would make the initial period an adjustment period (ADJ-98). Therefore, choose ADJ-98 as the first future conversion period, which makes DEC-98 the initial period.
Run the program as close as possible to the last day of DEC-98 or the first day of JAN-99.
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.
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.
Currencies: Determine all of the currencies in which your journals are denominated.
Also, determine all of the ledger currencies of all the reporting currencies for which you plan to run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program. You determined these reporting currencies during the planning process. See: Step 2: Determine the Reporting Currencies to Initialize.
Conversion Date: Determine the conversion date to use on the Reporting Currency page in Accounting Setup Manager, Historical Conversion region. This is the currency conversion date of the initializing rate that the Reporting Currency - Create Opening Balance Journals in Reporting Currency program uses to initialize your reporting account balances.
See: What Rates are Used to Convert Transactions?
Note: In the case of the euro, changing the conversion date may affect how transactions and balances are converted to your reporting currencies. If you enter a conversion date of 01-JAN-1999 or later, the fixed rate relationships between the euro and EMU currencies are enforced. Also, transactions are converted using the triangulation rules prescribed by the European Commission. For example, assume your transaction currency is CAD, your reporting currency is BEF, and the conversion date is 01-JAN-1999. In this case, the transaction is converted first from CAD to the euro, using the daily rate that exists between CAD and the euro for 01-JAN-1999. Next, the euro amount is converted to BEF using the fixed rate that exists between the euro and BEF.
If you enter a conversion date that is earlier than 01-JAN-1999, variable daily exchange rates are used to convert transactions and balances to or from EMU currencies. For example, assume your transaction currency is CAD, your reporting currency is BEF, and the conversion date is 31-DEC-1998. In this case, the transaction is converted using the daily rate that exists between CAD and BEF for 31-DEC-1998.
Conversion Rate Types: During the initialization, you need to define two conversion rate types:
Historical Conversion Rate Type: This conversion rate type is specified on the Reporting Currency page in Accounting Setup Manager, Historical Conversion region. Rates with this conversion rate type are used to convert balances and transactions for the Reporting Currency - Create Opening Balance Journals in Reporting Currency program, as explained earlier. See: What Rates are Used to Convert Transactions.
Default Rate Type: This conversion rate type is specified on the Currency Conversion Options region. Rates with this conversion rate type are used to convert transactions once Reporting Currencies is enabled. See: What Rates are Used to Convert Transactions.
Important: We recommend that you define new conversion rate types to use specifically for the Reporting Currency - Create Opening Balance Journals in Reporting Currency program. Do not use the conversion rate types you use for normal transaction processing, which includes foreign currency transactions entered in your ledger and all transactions that Reporting Currencies converts after the program has completed successfully.
Using separate conversion rate types will make it easier to reconcile your primary and reporting currencies after running the Reporting Currency - Create Opening Balance Journals in Reporting Currency program, since you will be able to easily determine whether a reporting amount was converted during the initialization or during normal processing.
Conversion Rates: Consider your ledger's chart of accounts and current accounting standards (for example, SFAS #52 (U.S.). Determine what conversion rates you need to provide to ensure that all transaction amounts and account balances can be converted when you run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program.
Determine all of the daily rates you will need for successful conversion.
For non-monetary General Ledger accounts, determine what weighted average historical rates you want to use to convert each account. Note that you will define these rates later (during the pre-initialization) for the initial period. When you choose the Retain Original Conversion Rate Type option set to Yes option, historical rates are not used.
Determine whether to initialize all General Ledger account balances or only a specific range of accounts. Be careful when choosing to initialize only a range of accounts, since your ledger and reporting currencies may not be synchronized and reconcilable after you run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program.
In addition, with the Retain Original Conversion Rate Type option set to Yes, you can choose a First Historical Conversion Period to determine the number of periods before the first future conversion period for which you want to convert account balances. We recommend that you select a First Historical Conversion Period based on when you want to start inquiring and reporting on period-to-date account balances in your reporting currencies.
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:
In this section we discuss the steps you need to complete when preparing for the initialization:
Step 1: Define Ledger
Step 2: Prepare Your Ledger
Step 3: Enable and/or Define the Currency of Reporting Currency
Step 4: Define Reporting Currencies
Step 5: (Optional) Define Reporting Responsibilities
Step 6: (Optional) Assign Data Access Sets to Reporting Responsibilities
Step 7: Open Periods in Reporting Currencies
Step 8: Define Conversion Rate Types
Step 9: Enter Conversion Rates
Step 10: Run Month End Reports
Step 11: (Optional) Close Periods in Ledger
Step 12: Set Your Rollback Segment Size
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:
Clear out any clearing and suspense accounts.
Reconcile your account balances and resolve any remaining open issues.
You must suspend all journal posting before you begin running the Reporting Currency - Create Opening Balance Journals in Reporting Currency program. Once you have finished preparing your ledger, do not post any new journals until after the Reporting Currency - Create Opening Balance Journals in Reporting Currency program has completed successfully.
See: Step 3: Enable and/or Define the Currency of Reporting Currency
See: Step 4: Define Reporting Currencies
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
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
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
In your ledger, define the conversion rate types you determined during the upgrade preparation task. See: Determine Conversion Dimensions.
See: Defining Conversion Rate Types
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.
Daily Rates: Use the General Ledger Daily Rates window to enter the initializing rates for the Historical Conversion Date and Conversion Type you determined during the initialization preparation process. See: Determine Conversion Dimensions. You must enter one initializing rate for each combination of transaction currency entered in your ledger and reporting currency to which you are converting.
Also use the Daily Rates window to enter daily rates from the first day of the first future conversion period and forward. Use the conversion rate type you defined in the Reporting Currencies page in Accounting Setup Manager, in the Currency Conversion Options section.
Note: Alternatively, you can load daily rates automatically into the General Ledger Daily Rates Interface table or use the Currency Rates Manager spreadsheet upload.
See:
Weighted Average Rates: Use the Historical Rates window to enter your weighted average rates for the initial period. Use the conversion type Historical.
Note: If you already have historical rates defined for some accounts for the initial period and do not want to use these rates to convert the account balances, delete the existing historical rates. Enter any weighted average rates you want to use to convert those specific account's balances.
After the Reporting Currency - Create Opening Balance Journals in Reporting Currency program has completed successfully, delete the weighted average rates you entered for the purposes of running this program, and re-enter the historical rates you deleted earlier.
EUR-to-EMU Fixed Rates: If you've not already done so, enter the fixed rates for converting from the euro to your EMU currencies.
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.
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
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.
Complete the steps in this section to perform the initialization.
Step 1: Stop Journal Entry
Step 2: Back Up Your Production Database
Step 3: Setup Reporting Currencies
Step 4: Open the Periods in the Reporting Currencies
Step 5: Run the Reporting Currency - Create Opening Balance Journals in Reporting Currency program
Step 6: Close the Initial Period in Reporting Currencies
Step 7: Reconcile Reporting Currencies
Step 8: Open the First future conversion Period in General Ledger
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.
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.
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.
Log in to General Ledger using a responsibility with access to Accounting Setup Manager. Navigate to the Accounting Setup Manager.
Select your Ledger or Accounting Setup.
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.
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.
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.
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.
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.
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.
In your reporting currencies, run the same General Ledger reports that you ran during the pre-initialization tasks. See: Run Month-end Reports
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.
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).
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.
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).
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.
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
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.
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.
Complete the following post-initialization steps:
Step 1: Define Currency and Journal Conversion Rules
Step 2: Define Reporting Responsibilities
Step 3: Assign Reporting Currencies to Reporting Responsibilities
Step 4: (Optional) Run Year End Carry Forward
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
Define any reporting responsibilities that you did not define earlier.
See: Step 4: Define 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
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.
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
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.
Log in to Oracle Applications as the System Administrator.
Navigate to the Concurrent Programs window.
Query GLMRCU, the program short name of the Reporting Currency - Create Opening Balance Journals in Reporting Currency program.
Mark the Enabled check box to enable the program. Unmark the check box to disable the program.
Save your work.
In this section, we describe the parameters required to run 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:
Uses the converted amounts to create initializing journal entries in the reporting currencies.
The initializing journals use the Journal Source and Journal Category named Reporting Currencies Open Balances. The effective date of the journals is the last day of the period it was converted from in the ledger. The journal line descriptions will display different information, as follows:
Journal lines of amounts that are converted using the initializing rate will have the description, Journal Import Created.
Journal lines of amounts from non-monetary accounts, that are converted using a weighted average rate, will have the description, Converted using historical rate <rate>, where rate is the weighted average rate used to perform the conversion.
The adjustment for retained earnings will have the description, Cumulative Conversion Adjustment.
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:
Ledger: Enter the name of the ledger whose balances you want to convert.
Reporting Currency: Enter the reporting currency name whose account balances you want to initialize.
Flexfield From/To: (Optional) Enter a range of accounts whose balances you want to convert to your reporting currency. If you leave these parameters blank, all account balances will be converted.
Note: When you convert selected accounts, make sure you consider alphabetical segment values in the range of accounts. 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.
First Historical Conversion Period: This parameter automatically defaults to the first future conversion period. If you choose the Retain Original Conversion Rate Type option set to No, you cannot change the default. If you choose the Retain Original Conversion Rate Type option set to Yes, enter the first period whose period-to-date account balances are to be converted by entered currency in your ledger. The utility will convert account balances from the first historical conversion period through the initial period.
The Reporting Currency - Create Opening Balance Journals in Reporting Currency program performs the following validation checking:
First future conversion Period - Validates the first future conversion period to ensure that it is the first future-enterable period or, if you do not allow future-enterable periods, the first never opened period in General Ledger in the ledger.
First Historical Conversion Period - The program validates that the first historical conversion period you choose is a valid period that precedes the first future conversion period if not the first future conversion period in the reporting currency.
Reporting Currency - Ensures that the specified reporting currency is a valid reporting currency and that it is defined for the specified ledger when you choose the Retain Original Conversion Rate Type option set to Yes.
Journal Source and Journal Category - Ensures that the new Journal Source and Journal Category, Reporting Currencies Open Balances, exists in your database.
Conversion Rates - Checks to make sure that an initializing rate exists for each combination of entered currency to reporting currency, for all balances in your ledger.
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.
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 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.
To support Reporting Currency Account Type Specific Conversion, the following steps are required:
Create currency conversion types
Modify the Journal - Journal Entry Lines descriptive flexfield
Set the new profile options
Enable and set up rounding differences accounts
Populate currency conversion rates
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
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.
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.
You will need to define two unique segments for this descriptive flexfield:
Rate Number
Amount Number
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.
This segment will an overriding historical rate to convert the source ledger currency to the reporting currency for that journal line (rate segment).
This segment will hold the historical amount expressed in the reporting currency (amount segment).
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:
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.
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.
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.
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.
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.
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.
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.
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:
Account Type Conversion
Historical Rate Conversion
Historical Amounts
Other (Exception Processing)
Each of these is described below.
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.
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.
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.
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.
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.
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:
A conversion rate needed cannot be found (see below).
The user supplies both a historical rate and a historical amount in the descriptive flexfield segments.
The data entered in either of the descriptive flexfield segments is not numeric.
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.
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.
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:
Account Type Conversion
Historical Rate Conversion
Historical Amounts
Each of these is described below:
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.
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.
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.
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.
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.
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.
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).
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.
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:
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.
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.
Enter the ledger currency in the Currency field. Enter the name of the ledger in the Ledger field in the Account Assignments window.
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:
Foreign Currency Account Analysis Report
Foreign Currency General Ledger Report
Foreign Currency Journals Report
Journal Entry Report
Journal Line Report
Trial Balance Reports
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.