R12.1.X-Over all Changes (Business Group,L.E, Locations , Address....)

Version 12.1.3 has some significant differences to earlier R12 versions impacting the behavior of the HR Locations records (which are important for the multi-org setup)

 

Business Group (used for employees and HR functions, no difference to 11I

 

Chart of Accounts – basis for all other operational and financial setups) – no difference in setup and structure.

Legal Entity – New  Legal Entity Configurator Responsibility in Web-Form)  - Lots of different setup and decisions to be made (very different from 11I)

 

Create Ledger - New  Accounting Setup Manager Responsibility in Web-Form Lots of different setup and decisions to be made (very different from 11I). Formerly GL Set of Books.

 

Create Operating Unit and assign to Ledger New  Accounting Setup Manager
Responsibility in Web-Form Additional restrictions and impacts, differences between R12 and 11I.

• Responsibilities span multiple Operating Units for transactional capability


• Legal Entity has now become relevant


• UMX – User Management has a implicit role in some tasks


• Multiple forms are now Java/HTML based; often the application jumps between these


• XML Publisher - now BI Publisher is all over the place


• You have to start with creating a Legal Entity to start a Ledger definition


• You cannot use the same name for a Legal Entity


• The key is the Tax ID Number (cannot be re-used)


• You cannot delete these from the system, you can end-date them


• Cash Management now “owns” Banks!


• You need to log in to Cash Management to create Bank and Account Information (Note: 415529.1)


• You MUST assign the Cash Management responsibility using UMX – User Management


• This MUST be done using the SYSADMIN User, not the responsibility!


• Customer form has changed drastically


• The Customer form has been moved to the TCA architecture


• Payment Manager is a new concept for Payment processing.

1. Location Addresses” or “Locations” – Terminology and challenges in visibility of data from both angles Java and Web-Form


2. No easy way to see table used in Web-Form


3. No easy way to see total number of records in Web-Form


4. Locations are not consistently visible across Java and Web Forms. We are not sure what it depends on. Possibly I can see in Web form only those that have been entered in Web-Form. In Java I can see all. Possible strategy is to enter what you can in Web-Form, especially locations, organizations


5. Locations in Java and 11I are called Addresses in Web-Form of 12


6. Business Group Needs Location (HR_Location)


7. Address Validation (HR Address Format and Validation Changes in 12.1.3 & one of patch - Patch 9871990)


8. Data entry through Java form or Web-form?


9. Address default United States – will cause validation (if site profile option is set for HR purpose).

Reference:
1104887.1 : How to Setup a Legal Address Using HR Address Formats in R12 Legal Entity Configurator

  1064366.1 :How to Add a New Legal Entity, Ledger and Operating Unit for a New Country

Revaluation

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.

Revaluation is the process of revaluing accounts that have transactions denominated in foreign currency. This is done for the account balance, not individual transactions. Revaluation can be done on any account, but typically,this is done for balance sheet accounts, whose balance is made up of open transactions (ie. Accounts Payable, Accounts Receivable). Revaluation reflects the change in conversion rates between the date of the transaction and the date of the balance sheet.


When revaluation is run, a journal entry is created that either increases or decreases the functional currency amount for that account, based on the fluctuation of the exchange rate. The offset for this journal is a predefined Unrealized Gain/Loss Account.


The revaluation adjustment is created in the functional currency - this is where the fluctuation is. Remember, the foreign currency of the transaction will stay the same: it is the functional currency equivalent that fluctuates.


When looking at the revaluation entry on the Enter Journals form, Entered Debits/Credits should be equal to zero. The Converted Debits/Credits should be the revaluation adjustment - there should be an amount here.
You can specify period-to-date (PTD) or year-to-date (YTD) to revalue income statement accounts using PTD or YTD balances by setting the profile option 'GL: Income Statement Accounts Revaluation Rule'.

The following values are available:
PTD: Only PTD balances will be revalued for income statement accounts.
If you select PTD, the Revaluation program only revalues the PTD balances of your income statement accounts but continues to revalue YTD balances for balance sheet accounts.

Income Statement Accounts:

Are revalued on the basis of the PTD or YTD balances, in accordance with the
Income Statement Rule profile option


PTD Script:
select code_combination_id,TRANSLATED_FLAG, CURRENCY_CODE,
PERIOD_NET_DR, PERIOD_NET_CR,
PERIOD_NET_DR_BEQ, PERIOD_NET_CR_BEQ,
from GL_BALANCES
where CODE_COMBINATION_ID = 9999
SET_OF_BOOKS_I D = 123
AND PERIOD_NAME = MON


YTD: Only YTD balances will be revalued for income statement accounts.
If you specify YTD, then the revaluation program behaves as it did before, revaluing YTD balances for both your income statement and balance sheet accounts, the balance sheet is always revalued using the YTD method


YTD Script:
select code_combination_id,TRANSLATED_FLAG, CURRENCY_CODE,
PERIOD_NET_DR, PERIOD_NET_CR, BEGIN_BALANCE_ DR , BEGIN_BALANCE_ CR ,
PERIOD_NET_DR_BEQ, PERIOD_NET_CR_BEQ,
BEGIN_BALANCE_DR_BEQ,BEGIN_BALANCE_ CR _BEQ
from GL_BALANCES
where CODE_COMBINATION_ID = 9999
SET_OF_BOOKS_I D = 123
AND PERIOD_NAME = MON.

When you reverse the revaluation entry, General Ledger defaults the reversal period to the next period. You can change the reversal period by choosing More Actions from the Enter Journals form. Choose the period you want to reverse the revaluation in. 
You can rerun revaluation more than once in a period. Based on the Revaluation calculation, any additional journal entries posted after the initial Revaluation journal has been posted, will be picked up in the balances that are subsequently revalued in that same period. The subsequent Revaluation journal entry will then represent the incremental change in the revalued balance, due to the additional journal entries posted after the initial Revaluation.
Choose Revalue. General Ledger launches a concurrent process to revalue your account balances.
The process names your revaluation batch in the following format: Revalue <Period Name> <Concurrent Request Date> <Concurrent Request Time>; for example, Revalue JAN– 11 07– MAR– 11 15:00:00.

Use the Revaluation Execution Report to review the status of your account revaluation. General Ledger automatically generates this report when you run revaluation.

Revaluation Execution Report:

Review the details of your account balance revaluation and the journal batches created after running revaluation. The report includes the currencies and revaluation rates used to revalue your accounts, the unrealized gain/loss account in which you recorded net gains and losses, and the range of accounts revalued. The report also prints the names of batch and journals General Ledger creates for each foreign currency when you revalue your accounts, as well as the total debits and credits of the created batch. General Ledger automatically generates this report when you run revaluation.

Profile options related to Revaluation.
1.GL Revaluation: Days to Roll Forward Daily Rates
2.GL: Income Statement Accounts Revaluation Rule
3.GL Revaluation: Tracking by Cost Center
4.GL Revaluation: Validate Gain/Loss Accounts
5.GL/MRC Revaluation: Use Primary Book Currency Instead of Entered Currency
6.Inflation Accounting Revaluation tolerance

GL Revaluation: Days to Roll Forward Daily Rates:
Use this profile option to determine how many days into the past the Revaluation
program will go to find a daily rate for the currency, when Revaluation is
being run  using Daily Rates. If no rate is defined for the date the Revaluation is
being run for,  General Ledger will use this profile to determine how many days in
the past it can go  to in order to find a rate. If a rate is found, this is used in the
revaluation. If no rate is  found, revaluation for that currency will fail, and the
execution report will show  “Missing Rate”. The default for this profile is 0 –  GL
 will only use the  rates specified for the date requested in the program submission.
You can only review  this profile option at the user level. System Administrator
can set this profile option at  the site, application, or responsibility level.

GL: Income Statement Accounts Revaluation Rule:
Use this profile option to select either period-to-date (PTD) or year-to-date (YTD) income

statement account balances for revaluation.


The following values are available:
PTD: Only PTD balances will be revalued for income statement accounts.
YTD: Only YTD balances will be revalued for income statement accounts.


The default for this profile option is YTD. You can only review this profile option at the
user level. System Administrator can set this profile option at the site, application, or
responsibility level.

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.

R12 Legal Entity Configurator

The Legal Entity Configurator allows you to define legal entities and establishments in the Oracle system to achieve legal compliance for business activities handled by the Oracle E-Business Suite.

In Oracle Ebusiness Suite 11i, the Legal Entity is tied closely to a set of books and operating Unit, so your Legal Structure has to be defined in the way you set up your apps partitions (OU, Set of Books etc.).

In R12 financials breaks away from that with the introduction of the Legal Entity Configurator allowing you to model your Legal Structure separately from the partitions in your ERP system. Then you mark certain items with an owning LE, rather than use the OU or set of books to derive the LE.

A Legal Entity is an entity identified through the registration with the legal authority. A Legal entity represents a legal company for which you prepare fiscal or tax reports. You assign tax identifiers and other Legal entity information to these types of organizations.

Legal Entities have the right to:

•Own property (assets, inventory, receivable, other LEs)
•Trade (borrow, sell, buy, incur expenses, employ)

Responsibility to:
•Repay debt (liabilities, equity)
•Pay Taxes
•Account for themselves (legal reports, audits) .

What we map Legal Entities to
1. Accounting Structures - Balancing Segment Values and Ledgers
2. Tax Rules in eTax - Who I am and where I am registered/located determines what tax I need to pay
3. Bank Account - Who owns that bank account and the cash in it
4. Payables and Receivalbes Invoicing - the owner of that transaction, sometimes referred to as LE stamping
5. Intercompany Accounts and Intercompany Processing Rules

The Features for Legal Entity are:
1.Legal Entity Setup
2.Establishments Setup
3.Legal Entity Search
4.Legal Authorities and Jurisdictions and
5.Legal Associations

Legal Entity setup : Is the main component within Oracle’s Legal Entity Solution to meet the enterprises’ global Legal requirements. To be able to operate, a Legal Entity may be required to register with different Legislative Authorities depending on the Legal Entity’s activity and locations in order to comply with the law in the territory of operation. Users will use the Registration User Interface pages to create registrations for a Legal Entity in the Oracle System. The Registration User Interface will enable users to enter required registration related information that is needed for legal compliance in a given Oracle Applications instance.

Establishments are made up of a Main Establishment and additional Establishments. Conceptually, the Legal Entity and Main Establishment are tightly coupled. Therefore, every Legal Entity must have a Main Establishment. Whenever a Legal Entity is created, a Main Establishment will automatically be created. A main Establishment is always located in the same Legal Entity’s country. Legal Entities may or may not have additional Establishments.

Additional Establishments are required only in countries where other Legal Entity location needs to register with legal authorities (e.g. India, Brazil, Germany). Some Establishment attributes are required to provide information for current functionality (e.g. Registration Number- SIRET for DAS2 in France). Additional Establishments may or may not be located in the Legal Entity’s country. Main Establishments as well as additional Establishments may follow different set of rules if they do business in different activities or are located in different areas.

Legal Entity Search page : The purpose of the Search Page is to manage Legal Entities, Establishments, and Parties. In order to avoid duplication, users can identify existing Parties of type Organization and update them to be Legal Entities or Establishments.

Users will be able to:
•Update existing Legal Entities or Establishments
•Update an existing Organization Party to be a Legal Entity or a Establishment
•Configure a Trading Community Architecture Party type of Organization as a Legal Entity or Establishment.

The Legal Entity Search Page only displays Trading Community Architecture (TCA) parties of type “Organization.”

All Legal Entities must be registered against a Jurisdiction that is governed by a Legal Authority. The Jurisdiction is a formulation of a legislative category and territory to which legal rules are grounded. The Legal Authority is an executive power that operates within the jurisdiction to enforce legal rules, collect fees/taxes, and make financial appropriations within the territory. In order to support the legal world on which the legal entity is founded, both the legal authority and jurisdiction is clearly defined as part of the Legal Entity Solution.

Legal Associations is part of the Legal Entity Solution which consolidates and provides a centralized solution for Legal Entity related data in Oracle Applications. Various processes like Tax calculation and intercompany transaction processing are dependent on the knowledge of the owning Legal Entity or Establishment. Given that the legal context is not directly stated in Applications transactions today, Legal Associations provides a method to derive the Legal Context by building associations between business and accounting information that are available on transactions and Legal context. Legal Associations will also provide the ability to build associations between Legal Contexts.

A legal entity is the organization unit level at which you report taxes and maintain the corporate banking relationships. The LEGAL_ENTITY_ID column is added to the transaction tables in 12, allowing the ability to track transactions at a Legal Entity level. In R12, you assign a Legal Entity to a Ledger instead of to a Set of Books. It is recommended that you assign one (or more) balancing segment values in your chart of accounts to a legal entity.

Territory:
The territory where the legal entity is registered. This list displays territories at the country level and shows only territories for which the identifying jurisdiction has been defined. Therefore, the territory determines the identifying jurisdiction to which the legal entity needs to register. The territory also determines the context for the information that needs to be displayed in the General Information region. For Canada the BIN number is one such field.

Organization Number:
The organization number is a number used to identify organizations. This field is displayed only when the HZ: Generate Party Number profile option is set to No. In this case, the main establishment organization number is built as a concatenation of the legal entity organization number and ETB (establishment). Otherwise it is not displayed and is generated automatically. For example, if the legal entity organization number entered is 12536, the establishment's organization number will be 12536ETB.

Legal Entity Identifier:
The identification number used to uniquely identify the legal entity. It is displayed only when the LE: Generate Legal Entity Identifier profile option set to No and you must enter it manually. If this option is set to Yes, the legal entity identifier is generated automatically based on the International Organization for Standardization (ISO) code of the country of registration, plus the registration number of the identifying jurisdiction, which qualifies an entity to be a legal entity in that particular territory.
Example:
Territory: Singapore
ISO Country Code: SG
Registration number of the identifying jurisdiction (RCN number) = 23231 (this is a user enterable field)

If the profile option is set to Yes, the legal entity identifier will be SG23231, otherwise you are required to enter the legal entity identifier manually. If you enter an identifier that is not unique, an error message will be displayed.

Registration Number:
The identifying jurisdiction determines the prompt for the registration number (in the U.S., the EIN/TIN). The Establishment registration prompt is displayed if it is defined for the identifying jurisdiction. In this case the main establishment is created with this registration number. The registration number must be unique within a jurisdiction.

Legal Address:
A Legal Address is the address a legal entity uses to register with a legal authority. A legal entity may use different addresses for different authorities and hence, may have more than one registered address. This legal address must be located within the territory governed by the legal authority.

Oracle Legal Entity Configurator has adopted the use of the HR Address formatting and validation Model

Place Of Registration: Optionally enter the place of the legal entity registration.
Inception Date Optionally enter the date of legal entity registration (creation). It can be on or before the system date and on or after legal entity's inception date but must not be a future date.

Source: My OracleSupport:
Note:396752.1Oracle Legal Entity Configurator Documentation Resources, Release 12
NOTE:1104887.1 - How to Setup a Legal Address Using HR Address Formats in R12 Legal Entity Configurator

How are the Transactions populated in the RA Interface table

Invoice processing in Order Management is the process by which data from Orders and Returns is interfaced to Oracle Receivables.

1. After shipping the order, the order lines get eligible to get transferred to RA_INTERFACE_LINES_ALL.
2. Workflow background engine picks those records and post it to RA_INTERFACE_LINES_ALL. This is also called Receivables interface that mean information moved to accounting area for invoicing details.
3. Invoicing workflow activity transfers shipped item information to Oracle Receivables. At the same time records also goes in the table RA_INTERFACE_SALESCREDITS_ALL which hold details of sales credit for the particular order.
4. Sales order line status is closed and shipping line status is interfaced then RA_INTERFACE table will get populated.
5. Once all the data is in ra_interface_lines_all, Then Auto-invoice program imports data from this table which get affected into this stage are receivables base table. At the same time records goes in ra_customer_trx_all and ra_customer_trx_lines_all.

The Order Management Invoice Interface activity interfaces sales order line details to Oracle Receivables. Order lines with any of the following conditions are not eligible for Invoice interface:
1. Item with Invoiceable attribute set to No or
2. Item with Enabled Invoicing attribute set to No or
3. Included item type or
4. Configure item type or
5. Item inactivated.

For all conditions listed above, the Invoice Interface workflow activity is completed with a status of Not Eligible.

i) Order Hold: Order or return lines will not be interfaced to Oracle Receivables if there is a hold on the line or on the order. When the invoice interface activity encounters an order or return line with a status of On Hold, the Invoice Interface workflow activity will also complete with a status of On Hold. You can perform the manual ‘Progress Order’ concurrent program to continue with the order processing, or the order or return line will automatically be re-evaluated at a 12 hour interval after the hold is released.

ii) Detailed Flow Statuses for Invoice Interface:
These statuses/messages help you understand when the line is not progressed from invoice interface because of a specific reason.

When using the header level invoice interface, the order flow status is set to identify the Header invoice workflow status. For the header level only, the following statuses are set:
- Awaiting Invoice Interface -- On Hold
i) When at least one order line/header is on hold
- Awaiting Invoice Interface -- Incomplete Data
i) When at least one order line is not able to process due to incomplete data
-Invoice Interface – Complete
i) When all the lines are processed.

R12 Decision To Re-implement or Upgrade

The information below offers best practices and advice to customers currently in 11.5.X who are not able to take decision to upgrade or re-Implement and who are in dilemma. After going through these details they can understand the benefits, pro and cons and decide either to upgrade or re-implement based on the business goals and requirements.

R12 is the latest and most advanced version of the E-Business Suite running on Fusion Middleware. Many of the technology components and new features in R12 will carry over to the Fusion Applications. For customers running earlier release of 11i, upgrading/Re-implementation to R12 will allow you to move to the Fusion Architecture in an incremental manner. Here are a few things to consider for R12

If you are moving from an existing release of Oracle E-Business Suite to Release 12, you should consider whether to perform a standard upgrade versus a reimplementation.

Let us understand the definition of Re-implementation and Upgrade.

Re-Implementation: If the legacy system from which you migrate your historical data is an earlier release of the E-Business Suite (i.e. Treat Current System as Legacy System) then your fresh implementation may be described as a “reimplementation”.

-Setup applications.

-Migrate data

-Migrate customizations

-Go live with small data

-Phased conversion of remaining data

Upgrade: Use of a process or Oracle Tool kit to ‘convert’ data from current Oracle Applications release to R12.

- Supported tools, utilities, and documentation used

- Entire data and application available after upgrade

- Clear, straightforward, proven method

Source: My Oracle Support
Note: Extended Support for Release 11i10 requires the minimum baseline patches defined in My Oracle Support Document 883202.1(Minimum Baseline Patch Requirements for Extended Support on Oracle E-Business Suite 11.5.10).

EBS Release Road Map:

Source:oracle open world/stevenChan

Release 12, which became available in January 2007, included major architectural improvements to the Financials products to support global and shared service operations, improve operational efficiencies, and reduce risk. It also incorporated the latest revisions to Oracle’s middleware and database technologies.

Release 12.1, which became available in May 2009, rounds out Release 12 with significant enhancements to the other product areas, including Procurement, Supply Chain Management, Human Capital Management, Customer Relationship Management and Master Data Management. It also contains usability improvements and centralized life cycle management.

There are few customers who are still in dilemma and not able to decide to go with Upgrade or re-Implementation but few customer based on the business goals and requirements have decided In favor of re-implementation and few in favor of upgrade

Gartner, the IT research and advisory firm, published research in February 2009 that advised caution and careful planning for the 11i to R12 transition. They found some customers experienced problems due to the architectural changes in the Financials, both with the end state software and with the transitional upgrade process. The paper recognizes that customers may use reimplementation as an opportunity to make fundamental changes to the configuration setups. “In a reimplementation, the user wants to leverage the new global financials functionality and may therefore revisit the whole conceptual design of their financials implementation.”

R12 has several important new capabilities, but this doesn't mean all customers should start planning an upgrade/Re-implement now. Existing customers should use the decision Criteria parameters to plan when they should consider moving to R12.

Decision Criteria:
- Current Oracle EBS Version.
- Oracle Skills
- Geographic’s Focus
- Legal Compliance and Market Force
- Implementation Scope
- Customizations
- Fusion Middle ware
- Risk Aversion
: Source: Gartner 

Why should Companies move to R12:
- Stay in Oracle Support to eliminate the de-support risk since older versions of Oracle EBS applications are not supported by Oracle Suppoort.
- Obtain better support when patches currently.
- Take advantage of Tech Stack improvements.
- Change in business directions.
- New Features and functionalities to assist business
- Replicate customization with oracle standard features and retire RICE components
Get Ready for Fusion.

Driving Factors:
- IT Drivers: Supportability, Stability, Improved performance, New Features, Reduce , maintenance cost, Out of box use, Retire Customizations.

- Business Drivers: New modules, New features and functionality, New requirements, Operational efficiency, Design improvements, Opportunity to re-engineer,More business-handling Capabilities.

Upgrade vs Reimplementation:















Before suggesting any approach or its pros and cons we should understand the requirments, Issues and business goals by raising few questions like.
1. What are the issue in the current 11i Version.
2. What is the scope of the resounces availability
3. What are the key reasons to go to R12.
4. What is the budget.
5. What is the scope of the Project (any new additions to the business , any additions to the existing modules).

In upgrade if there are more number of customizations then it will take more time, oracle provided scripts for the entire standard /seeded components, the customization requires careful planning and development effort for non standard components. In Re-Implementation , taking the advantage of new features and functionalities customer have the opportunity to improve upon the existing components either by eliminating or retiring few of the RICE components.

Upgrade:

Pros:

- Least Expense option
- Less Implementation time with low customization
- Shared services will work as prescribed
- No Major Process changes
- No changes to COA, Currency, Calendar
- No major Business/organizational restructuring
- No Data conversion.
- Small team compared to re-Implementation.

Cons:

-User Interface overhaul will change to look and feel of the application.
-Limited ability to change configuration.
-Certain Modules have significant modifications and enhancements
-Critical upgrade issues require oracle support for fix/solution.
- Reporting tools have been impacted hence Technical/Development cost will increase.
- Have to leave with existing Issues.
- Continue use of Tax code.
- May not be able to use the new tax accounting and compliance model (EBtax).

Re-Implementation:
Pros:
1. Reconfigure of existing Process hence opportunity to correct mistakes and optimize process.
2. Opportunity to cleanup existing bad data.
3. Opportunity to change configuration may improve data quality and optimize process.
4. Opportunity to use new features and functionalities there by reduces issues.
5. Avoid catch-up Patching.
6. Opportunity to eliminate /retire RICE componets by using addded features and functionalites and centralized architecture .

Cons:
1. Implementation Time will be high.
2. Expensive cost option (Training/Development/Resource/tesing etc)
3. Configuration time willl be high
4. Data convertion would be required.
5. Big team size compared to Upgrade.
6. Most complicated and Resource intensive option.

Options available:

1. Stay put on 11.5.10, Not Ready for R12.X. Do not see the business benefits to upgrade . Delay and  hope that 11i  supported will be extended for another 2 – 3 years as the deadline comes closer. Ready to pay higher support cost for extended support as applicable..( 20 % to 25 % extra license fee post Nov 2012 ).


2.  Ready for upgrade: Treat it as a necessary level. Do a Technical Upgrade with minimum cost and least disruption.


3. Embrace R12.X, as a Functional Upgrade; Treat it as a stepping-stone to Fusion. Adopt new processes, fusion middleware and new R12.X modules as applicable.


4. Re-implement to R12.X. Look to adopt more out of box solutions. Treat it as a Re-engineering exercise and simplifying business processes.


5. Expanding your Foot Print: You want to add more EBS Products to your footprint :Oracle recommends to  move to the higher version R12.1.3 frist as there would be number of new features and change to data model  and then implement the new Product. 

Refer the following documents for more information on oracle my support:
1104163.1 - R12.1 Financials Pre-Upgrade, Setup, and Operational Tips
889733.1 - R12: Upgrade Considerations by Product (FINANCIALS)
987516.1 - Planning Your Oracle E-Business Suite Upgrade from Release 11i to Release 12.1
954704.1 - EBS: R12.1 Oracle Financials Recommended Patches
1127593.1 - R12.1: Oracle Financials Pre-Upgrade Patch Supplemental List for EBS CUP
•394692.1 -Oracle Applications Documentation Resources, Release 12

780989.1 -R12: Upgrade vs. Reimplementation (Financials)
1098650.1 Oracle E-Business Suite Technology Stack Release Notes for Release 12.1.3
•1080973.1 Oracle E-Business Suite Release 12.1.3
Upgrade Advisor: Oracle E-Business Suite Financials and Projects Upgrade from 11.5.10.2 to 12.1.3 and 12.1.2 [ID 256.1]
394692.1-Oracle Applications Documentation Resources, Release 12
747735.1 - Oracle Financials and Oracle Procurement: Functional Upgrade Guide: Release 11i to Release 12
806593 1 – R12 1 Info Supply
•806593.1 R12.1 Center
398877.1 – R12.1 Live Advisor
804373.1 – R12.1 Value Proposition documents
461709.1- Oracle E-Business Suite Upgrade Guide
557869.1 -EBS: R12.0 ORACLE FINANCIALS CRITICAL AND RECOMMENDED PATCHES 
405627.1- Oracle Payables Release 12 Known Issues
549024.1 -11i Payment Documents Do not Exist in R12--How to create the payment documents from 11i data
578232.1-R12 Proactive Intelligence Center: Oracle Payables
471418.1-Oracle Payments Minimum/Dummy Setup For Direct Debit Funds Capture Processing
399362.1-Oracle Applications Release 12 Upgrade Sizing and Best Practices.
418649.1 -Advanced Global Intercompany (AGIS) in Release 12  - Setup, Transaction   Processing and Reports
552745.1 R12: Unable to Update Location Address for Locations Created in Accounting Setups In GL
415529.1 R12: Unable to See the Legal Entity List of Value in the Bank Account Owner Field 
•B31566-01-Oracle Applications Upgrade Guide: Release 11i to Release 12
810443.1 of the R12 E-Business Tax (EBTax) Upgrade for Order to Cash 
733855.1 Inventory Structure (Chapter 2: R12 Inventory User's Guide in a Note) 
463997 .1R12 New Business Group Not Shown in LOV when attempting to create Organization
784666.1TECHNICAL AND OPERATIONAL STANDARDS
987097.1 E-Business Suite Manufacturing Standalone Documentation - Release 12.1

Cost of Goods Sold Account

What is Cost of Good Account:

The Cost of Goods Sold Account is used to determine the profit realized from selling a product. For each item in an inventory organization Oracle Applications has the ability to record the type and amount of costs to maintain the item. To view the associated cost for an item use the Item Costs Details form.
- Generate Cost of Goods Sold Account
- OM: Generate Cost of Goods Sold Account Both processes are used to derive account for cost of good sold (COGS). The workflow process will kick in when an item is shipped or returned.
- Generate Cost of Goods Sold Account the old process of 10.7 Oracle Shipping owns this process,
- OM: Generate Cost of Goods Sold Account is new and default process for 11i, Order Management owns this process.

• Inventory COGS Account Generator
– Item Type = INVFLXWF
– Display Name = ‘Inventory Cost of Goods Sold Account’
– Run by the concurrent program ‘Create Intercompany AP Invoices’, short name INCIAP

• OM COGS Account Generator
– Item Type = OECOGS
– Display Name = ‘OM : Generate Cost of Goods Sold Account’
– Run by the concurrent program ‘Interface Trip Stop’, short name WSHINTERFACE

Seeded Account Generators:

11i10 provides the ability to register custom processes for the following account generators:

• OM: Generate Cost of Goods Sold Account (OECOGS) – generates the cost of goods sold
  account when invoices imported into AR.
• PO Account Generator (POWFPOAG) – used by Purchasing to derive the charge, budget,variance, and accrual accounting distributions for each PO line – MUST be customized ifusing Oracle Projects.
• PO Requisition Account Generator (POWFRQAG) – used by Purchasing to derive thecharge, budget, variance, and accrual accounting distributions for each requisition line –MUST be customized if using Oracle Projects.
• Inventory Cost of Goods Sold Account (INVFLXWF) – called while processingIntercompany Transactions.
• Generate Cost of Goods Sold Account (SHPFLXWF) – Pre-11i Cost of Goods Sold AccountGenerator – see Metalink note 260697.1
• AR: Substitute Balancing Segment (ARSBALSG) – updates the balancing segment duringvarious accounting activities against transactions and receipts.
• PSB Account Generator for OLD Integration (PSBLDMAG) – Public Sector Budgeting –
  used to derive accounts for positions with POETA charging instructions that are then
  used to import salary distribution information from LD.
• ITR Account Generator (ITRWKFAG) – Account Generator for self-service ITR. This
  workflow will build creation and receiving accounts for ITR service lines.
• IAC account Generator (IGIIACWF) – used in Public Sector Assets.
• MHCA Account Generator (IGIAMAWF) – used in Public Sector Assets.
• IGC Charge Account Generator (IGCACGNC) – Public Sector Contracts, this workflow is
  used to generate charge account for contract commitment.
• IGC Budget Account Generator (IGCACGNB) – Public Sector Contracts, this workflow is
  used to generate charge account for contract commitment.
• Project Budget Account Generation (PABDACWF) – used by Projects to generate
  accounting combinations for all budget items in an integrated project budget.
• FA Account Generator (FAFLEXWF) – used by Assets to generate the accountingcombinations for each asset transaction.
• Project Supplier Invoice Account Generation (PAAPINVW) – used by Payables to derivethe invoice distribution accounting combination if the distribution is Project related –MUST be customized.
• Project Web Employees Account Generator (PAAPWEBX)– used by iExpenses to deriveaccounting combinations for expense report lines that reference a project – MUST becustomized.