Showing posts with label Translation. Show all posts
Showing posts with label Translation. Show all posts

Saturday, February 26, 2011

GL Translation Process

What is Tranlation:
Foreign Currency translation is the process that restates functional currency account balances in another currency.
Translation converts balances from your functional currency to a foreign currency, you can translate both actual and budget balances. if you have average balance processing enabled the system can translate average balances as well.
Tranlation is frequently used to prepare financial reports for consolidation into global financial statements. It is also used in highly inflationary economies to produce reports in a more stable currency.
When do you run translation:
Translation should be run at the end of the period, after all transactions have been processed and reconciled.
How does the system transalte balances:
- Assets and liabilities  are translated by multiplying the YTD balance by the period end
How do I check that the translation has been carried out correctly?
Reconciliation of the Cumulative Translation Adjustment (CTA) Account:
1.Take the total of your P&L (Revenue and Expense) accounts and multiply this amount by the period average rate defined.
2.Take the total of assets and liabilities and multiply this amount by the period end rate.
3.Take the total of your retained earnings and use the historical amount or multiply by historical rate (whichever way you have defined it).
4.Add 1,2 and 3 together. This should equal the amount in your translation adjustment account.
5.Make sure no other entries have been made to the account. If there has been, they would have to be reversed in order to reconcile the amount.
Translation using Historical Amounts.?
In some situations, you may want to use Historical Amounts to translate certain accounts. However, when Historical Amounts are used in the very first period ever translated, this creates a large Rate Adjustment for the same amount which distorts the Cumulative Translation Adjustment account.
The translation code cannot distinguish between how much of the Historical Amount defined is attributable to the Beginning Balance and how much is attributable to rate fluctuation in the period, so the entire amount is thrown into the Rate Adjustment bucket.
For example, in the first period ever translated where there is no period activity for the account, when you use Historical Amounts, you may see:
Beginning Translated Balance = zero.
Rate Adjustment = the Historical Amount defined.
Ending Translated Balance = the Historical Amount defined.

By definition, when translating on YTD basis, the Historical Amount defined is equal to the YTD Translated Balance. You would like to know how to correct the situation so that you do not have a large Rate Adjustment in the first period translated.
The workaround is to "back into" an Historical Rate, based on the Historical Amount that you want to achieve for the period. You should use this Historical Rate in the first period ever translated, then in the subsequent months use the appropriate Historical Amount. This eliminates the large Rate Adjustment in the first period ever translated.

Does the Translation of Owner's Equity Accounts comply with FASB 52?
The profile option GL: Owner's Equity Translation Rule should be set PTD to comply with FASB 52.

Set to PTD:
Ending Translated balance = Beginning Translated Balance +
(Current month activity in Functional Currency * Current Month Historical Rate)

Set to YTD:
Translated Currency YTD = Functional Currency YTD * Rate
YTD translation of Owner's Equity Accounts calculation does not take into account the historical rates that were in effect at the time of each transaction in the account.

How to change Translation from Historical to Period Rates?
1. Delete the historical rate from the Historical Rate Form.
(Note if you have a Prior Historical Rate - this will have to be deleted. You may have a prior historical rate if you deleted the historical rate and reran translation without purging the original translations using the original historical rate).
2. Define a period-end rate in the Period Rates form.
3. Purge translated balances to get rid of the original historical rate.

The amount used depends on whether the account to which the historical rate or amount applies is a revenue/expense, asset/liability, or owners’ equity account:
Revenue/Expense: The amount is treated as translated net activity for the period.
Asset/Liability: The amount becomes the YTD translated balance for the
account.
Owners’ Equity: If the profile option GL: Owners Equity Translation Rule is set
to PTD, the amount is treated as translated net activity for the period. If the profile
option is set to YTD, the amount becomes the YTD translated balance for the
owners’ equity account.

Restating Balances Previously Translated with the Year–to–Date Rule
Older versions of General Ledger always translated owners’ equity accounts using the
Year–to–Date rule. If you subsequently switch to the Period–to–Date rule, your owners’ equity accounts will be translated using this rule for new translations only. Previously translated owners’ equity balances will not change. If you wish, you can restate your previously translated owners’ equity balances.

To restate your previously translated owners’ equity balances using the Period–to–Date rule:
1. Purge the old translated balances for each period to be restated.
2. Change the GL: Owners Equity Translation Rule profile option to PTD.
3. For each period to be restated, use the Historical Rates window to delete the rates used to translate owners’ equity accounts, as follows:
-- Retained Earnings: Delete any non–historical rates.
-- Other Owners’ Equity accounts: Delete any period rates.
4. Run translation. Your owners’ equity balances will be translated using the PTD rule.
Note: If you change a period rate after you’ve already run translation, you must retranslate your account balances for the period whose rate has changed.

Prior: General Ledger uses the most recently entered historical rate or amount for
your balance sheet accounts, and assigns it the rate type Prior. If you have average
balance processing enabled, General Ledger rolls this historical rate or amount
forward using the rate type Prior.

Period: If you have never defined a historical rate or amount for an owners’
equity account, General Ledger uses:
The period– average rate if the profile option GL: Owners Equity Translation Rule is set to PTD.
The period-end rate if the profile option GL: Owners Equity Translation Rule is set to YTD.

Calculated: This rate type is only used when the profile option GL: Owners
Equity Translation Rule is set to YTD. It is only applicable to the first period of
your fiscal year. If you have never defined a historical rate or amount for your
retained earnings account, General Ledger calculates a rate and assigns it the rate
type Calculated.

Profile related to Translation:
GL: Owners Equity Translation Rule
Specify the rule General Ledger follows to translate owners' equity accounts when you
have not entered specific historical rates or amounts.
The following values are available:
PTD: The Period-to-Date rule is used to translate owners' equity accounts. For
each period for which you translate owners' equity accounts, the historical rate is
set to the period-average rate.
YTD: The Year-to-Date rule is used to translate owners' equity accounts. For
each period for which you translate owners' equity accounts, the historical rate is
set to the period-end rate.
The default value for this profile option is PTD.

GL Transaltion : Revenue/Expense Translation Rule:
Revenue and Expenses are translated according to the GL Translation: Revenue/Expense Translation Rule Profile setting (PTD or YTD). If this is not set then Revenue and Expenses are translated by multiplying the PTD balance by the Period Average Rate

Purge, Transaltion and Retranslation:
Retranslation again will be done on the basis of the status column in the gl_translation_statuses table. If the status is current, there will be nothing that will be translated.
Translation will run in 2 phases. First phase gets the out of date records Translation Status - C.Here it translates only those records, which are out of date due to some adjustments.if it is the account adjustment all the foreign currencies need to be translated again. If it is a rate adjustment only that currency needs to be translated Second phase gets the records for periods, which have never been translated.

As an Example, if the Functional Currency is USD and translation is done into GBP, INR and CAD. If there is a change in the accounts in the functional currency, then Translation needs to be run for all the currencies. On the other hand, if there is a change in period rates or Historical Rate/ Amount for any currency, it will be sufficient if Translation is run for that particular currency.
Purge means Translation status for the period will always be Never Translated for the periods for which it is run. It will re-state the values in the gl_translation_tracking table. It essentially is translating every record whether or not that is current or out of date as the foreign currencies will not be there. In a way it can be said to be direct phase 2 of translation.
Running translation for the first time
You cannot translate in the first period in your calendar.
The first Consolidation must be performed as YTD not PTD for two reasons:
1.PTD will not generate a correct Opening Balance figure.
2.The Consolidation Journal maybe unbalanced by the amount of the CTA adjustment if there are Accounts defined with a Historic Conversion Rate.


Source: My OracleSupport.

Sunday, January 31, 2010

Consolidation (GCS, HFM, FCH)

Consolidation:

Consolidation is the period–end process of combining the financial results of separate subsidiaries with the parent company to form a single, combined statement of financial results.

GCS is a multi-source consolidation solution that can accumulate information from diverse financial systems, geographic locations, including Oracle and non-Oracle Applications. With GCS one can consolidate data from multiple SOBs, multiple instances and non-Oracle applications.

With Oracle General Ledger, you can consolidate any number of subsidiaries into parents represented by different sets of books – even those with different Chart of accounts, Currencies and Calendars.

•Consolidation of companies within a Set of books.
•Consolidation of companies across multiple Sets of Books in the same instance.
•Consolidation of companies across multiple Sets of Books across multiple instances.
•Accounting for some companies is maintained in non-Oracle applications.

What you can Consolidate:

1) Chart of Accounts: Map any subsidiary chart of accounts structure into your consolidated parent,regardless of differences in the account structure.
2) Level of Detail: Consolidate detail transactions, detail balances, or summary balances.
Balance Type: Consolidate actual, average, translated, budget, and statistical balances.
3) Calendar: Use any accounting calendar for the parent set of books into which you consolidate your subsidiaries.
4) Currency: Maintain subsidiary sets of books in a different currency than your parent. Simply revalue and translate balances as needed before transferring consolidation data to your parent.

GL Consolidation Steps:

1.Create Consolidation mapping: parent and subsidiary sets of books.
2.Post all Journals in subsidiary set of books.
3.Revalue foreign currency balances in subsidiary sets of books.
4.Translate subsidiary balances to the functional currency of parent set of books
5.Run and review trial balance report.
6.Transfer data from subsidiary to parent.
7.Run Journal import.
8.Post the consolidation journal in parent set of books.
9.Eliminate intercompany balances.
10.Run trial balance and other financial reports.

Steps to perform consolidation:

1.Map Consolidation Data.
2.Prepare Consolidation Data.
3.Transfer Consolidation Data.
4.Review and Post consolidation JE.
5.Generate and review eliminating Entries.
6.Report on Consolidated balances.
7.Analyze Consolidated Results.






















Consolidation workbench:
The Consolidation Workbench provides a central point of control for consolidating an unlimited number of subsidiaries to your parent, while keeping you informed about each subsidiary’s consolidation status. The workbench also monitors subsidiary account balances for any changes that occur after the subsidiary data has already been transferred to your parent set of books.

Functional Step State Controller Buttons
Map Consolidation Data -- Mapping, Mapping Set
Prepare Subsidiary Data -- Translation Status
Transfer Consolidation Data --Transfer, Transfer Set
Post Consolidation Data -- Review Journal, Post
Eliminating Entries -- Eliminate, Elimination Set
Report on Consolidated Balances --Report


Consolidation Process:


1.Define Consolidation Charts of Accounts: Make sure your parent and subsidiary charts of accounts can help simplify the consolidation process.
2.Map Consolidation Data: The first step in an actual consolidation is to define how your subsidiary accounts map to your parent accounts. The mapping determines how your subsidiary balances roll up into the consolidated ledger.
3.Prepare Consolidation Data: You should revalue and translate any foreign currency amounts from your subsidiaries before consolidating them to the parent set of books.
4.Transfer Consolidation Data: Once your subsidiary data has been prepared, transfer it to the parent, where it will be consolidated.


Preparing Consolidation Data:

1.Revalue Balances: if any sets of books have balance sheet or income statement accounts denomination in a foreign currency.
2.Translate Balances: for any subsidiary books that use a functional currency that differs from the parent.
3.Run a trial balance: for each subsidiary set of books using the parent set of books functional currency.
4.Review: subsidiary balances before transferring them to the parent.

Foreign Currency Concept:
There are 3 Concepts in Oracle General Ledger that pertains to foreign Currency

Conversion: conversion refers to foreign currency transactions that are immediately converted at the time of entry to the functional currency of the set of books in which the transaction takes place.
Revaluation: Revaluation adjusts liability or asset accounts that may be understated or overstated at the end of a period due to a significant fluctuation in the exchange rate between the time the transaction was entered and the end of the period. It restates balances using proper period end rate.
Translation: Translation refers to the act of restating an entire set of books or balances for a company from the functional currency to a foreign currency.

Consolidation Methods
When the consolidation is run, consolidation journal entries are created in the parent set of books for all the subsidiaries selected.

•If you choose the Balances method, the resulting consolidation journal will include the account balances for all the subsidiaries that were run.
For example, if a subsidiary had five transactions that made up the balance of the sales account, the consolidation journal entry will include the balance of the sales account, and not the individual transactions (based on the mapping rules).

• If choose the Transactions method, the resulting consolidation journal will include the transactions for all the subsidiaries that were run.
For example, if a subsidiary had 5 transactions for the sales account, the consolidation journal entry will include each transaction.

When a Consolidation is run, Oracle General Ledger submits a Concurrent process that populates the GL_INTERFACE table with Consolidation data.


The table below lists all possible statuses for consolidation processes displayed in the status column.

Reports:
  • Use the FSG as the mechanism to sum up the subsidiaries to produce consolidated results in case of Single SOB.
  • In case of companies having multiple SOB / non-Oracle Application, use FSG to report on consolidated results.
  • Use the ADI to extend reporting to the spreadsheet environment. ADI allows to create and publish consolidated reports in HTML format to the Internet or corporate intranet.
  • Run a Trial Balance Report for each subsidiary after revaluation and translation.
  • Consolidation Rules Report.
  • Consolidation Unmapped Subsidiary Report
  • Disabled Parent Accounts Report.
  • Consolidation Rules Report.
  • Consolidation Journals Report.
  • Consolidation Audit Report.
  • FSG reports.
Oracle Hyperion Financial Management (HFM) is a financial consolidation and reporting application built with advanced Web technology, but used and maintained by the finance team. It provides financial managers the ability to rapidly close and report financial results, meet global regulatory requirements, reduce the cost of compliance and deliver confidence in the numbers.

Features:

•Simple to Customize
•Easy to Integrate
•Financial Data Quality
•Complete Audit Trails
•Flexible Workflow
•Powerful Reporting
•Finance owned & operated

Benefits:

•Confidence in the numbers
•Reduce cycle time
•Automate collection & validation
•Lower cost of compliance
•Speed and agility





















Oracle Financial Consolidation Hub: (OFCH/FCH)
Oracle Financial Consolidation Hub is a key component of Oracle Corporate Performance Management, a comprehensive solution for improving performance across your business

OFCH is
•A comprehensive consolidation and reporting solution that brings together financial data from different sources to create a single, global view of financial information across the entire enterprise.
•A critical bridge between traditional financial applications and analytic applications by using Enterprise Planning and Budgeting

FCH Features:

  • Data collection from different sources
  • Automated consolidation processing
  • Flexible eliminations and calculations
  • Acquisition and disposal handling
  • Multi-dimensional reporting and analysis
  • Consolidation dashboard
FCH Big Picture:


Source: My OracleSupport