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

R12 Oracle Application Footprint

Release 12 is defined as “The Global Business Release.” Global is
not just a geographic perspective, but also a comprehensive
perspective; release 12 functionality spans across both industries
and business functions.

R12 Foot Print:
============






Key Business Flows :
---------------------
Oracle business flows are a collection of application components
designed for end-to-end business processes. They identify the
critical business processes an organization utilizes to support a
complete business strategy for managing operations, customers,
suppliers, partners, and employees.


Oracle business flows map business processes across multiple
organizations and many applications to represent a streamlined,
efficiently integrated information flow throughout business
organizations and across geographies.

R12 Architecture:
----------------------
Business Architecture: The R12 EBS has 5 principles that drives its business architecture:
-Modern Foundation
-Complete
-End to end Intergration
-Global
-Rapid Implementation.

1. Oracle has embedded all of its new R12 development into open,
scalable standards. These standards include using Java/J2EE,
HTML, JavaScript (JSP), Internet-accessibility, and centralized
management.

2. R12 E-Business Suite is accessible via global networks. It
accommodates multiple languages and currencies; supports
international features, such as flexible date formats and multiple
radix support; supports data in the Unicode Character Set (UTF-8)
and has accounting and business localizations built into it.

Technical Architecture:
PHP (Personal Home Page) or Portal becomes the gateway through
which the user has rights to access all the information to which they
have been granted access. Thus, R12 administrative tasks are
simplified while operations costs are reduced.

- Form based: Forms-based users are typically people involved
in the transactional operations of an organization.
- HTML/JSP's (Self Service): Self-service users are infrequent
users who want their interface with R12 to be as simple and as quick
as possible.
- Business Intelligence: Business intelligence users are senior
executives and managers who want an easy-to-use interface that
can be used to reveal critical business information and reports.
- Mobile: users whose jobs are likely to keep them away from a
readily available, network-connected computer. example : sales
representatives, field representative. By utilizing the mobile
interface, they are able to send and receive information at points
where it is important and convenient for them.

R12 : SLA, SLAM, ASM, Ledger Sets, Data Access Sets

What is Sub ledger Accounting(SLA):

Oracle Sub ledger Accounting (SLA) is a rule based engine for Generating accounting entries based on sub ledger transactions from all oracle applications. It is a rule-based accounting engine that defines how journal entries are generated for sub-ledger transactions in Oracle applications.  SLA also supports 3rd-party applications that generate accounting information that will need to be transferred to the general ledger

Sub ledger accounting is a set of services for R12 that significantly enhance accounting support across the E-Business suite.

R12 introduces some of the changes that will be fully developed in Fusion, so close attention
to the impact of these changes is worthwhile. Sub-ledger accounting may be one of these key
changes.
When Release 12 was first released, there was a lot of publicity about the move from the Set
of Books concept to Ledgers being so fundamental, however experience suggests that the
introduction of sub-ledger accounting (SLA) probably has even more impact. For those not familiar with SLA, it is a new product in Release 12 and a major change, (although it may be almost transparent to many end-users). 

It is both the rules and the engine that generates the accounting representation of your transactions, and it offers some  wonderful opportunities to meet very specific accounting requirements in supportable ways. Participating sub ledgers include Payables, Receivables, Projects, Assets, Cash Management , Purchasing, Cost Management and Process Manufacturing.

In terms of its mechanics, SLA is a new schema into which all accounting entries are processed before being interfaced to the General Ledger - and so it alters the way reconciliation and month-end processes run. This simple statement is both fundamental and important - because many of the skills we have learnt over years to address accounting issues at period end may have to be modified.
Do not underestimate this change and do invest the time to simulate month-end processes
during Testing (CRP and UAT) . Companies should move from utilizing Account Generators in Release 12 to representing their accounting rules in the Sub-ledger Accounting Engine. SLA rules that are in place in Release 12 will be protected in an upgrade to Fusion.


Sub ledger Accounting Methods (SLAM):

The Sub ledger accounting method is required if using Oracle Sub ledger accounting.
A sub ledger level secondary ledger requires a sub ledger accounting method for both the primary ledger and the secondary ledgers.

The accounting method can be changed at any time, it will only affect new journals,additional accounting methods may be defined. This is done in subledger Accounting.

There are 5 Sub ledger Accounting Methods:
1. Accrual with Encumbrance Accounting
2. Cash with Encumbrance Accounting
3. Standard Accrual (Default)
4. Standard Cash
5. US Federal Accounting.

All upgraded ledgers in Release 12 will have a sub ledger accounting method assigned during the upgrade. Any reporting currencies assigned to the ledger inherit the subledger accounting method from the source ledger. The sub ledger accounting method enables Oracle General Ledger to integrate with Oracle subledgers using Subledger Accounting.

1. All upgraded, non-public sector ledgers will have a subledger accounting method assigned called Standard Accrual or Standard Cash.
2. All upgraded public sector ledgers will have a subledger accounting method assigned called Encumbrance Accrual or Encumbrance Cash.
3. For US Federal customers, all upgraded ledgers will have the US Federal Accounting subledger accounting method assigned to them.

What is a subledger:
Subledger are applications to manager operational transactions with financials impact. Subledger stores accounting at transaction level of details. Subledger post summarized activity information to a GL Periodically to maintain centralized account balance for the
company.

What is Accounting Setup Manager (ASM):

It is one of the main feature of the Ledger Architecture introduced in R12, which replaces the Set of books from using a web based interface.

Accounting Setup Steps:




Accounting Setup Manager(ASM) is the central place where all the
accounting setup is defined and maintained for:
- Legal Enties.
- Operating Units
- Ledgers.
- Reporting Currencies
- Subledger Accouting.
-Inter and Intra Balancing Segments.
- Sequencing (Accounting and Reporting)
- Other Accounting options like retained earning account, suspense
account, currency conversion types etc.

Accounting Setup Manager Benefits:

• Centralized Accounting Setup for Financials
  –Define all of your accounting-related setup in a central location
  –Reduce setup errors
  –Have clear view of implementation
• Increased Efficiency
  –Access accounting setup information more quickly now that it appears centrally in one location.
• Simplified Processes
• Improved Efficiency
• Strengthens business’s corporate legal structure
• Streamlined on-going maintenance
• User friendly interface
• Facilitates internal control management.
  What is a ledger:
  The Ledger represents an accounting representation for an organization that is accountable in a self- contained way. The ledger represent the core of a company's Financial records where every transaction flow thrugh. " A Legal Entity accounts for itself in a ledger"
  
  Primary Ledger :
  ===========
  -Main , Record keeping ledger
  - Defined by 4C's.
  - Chart of Accounts
  - Accounting Calendar
  - Primary Currency
  - Subledger aCcounting Method - New 4th C (Also Called Convension)
  
  There are 3 types of ledgers: Primary , secondary and reporting currency ledgers.
  
  1. Primary Ledger (PL): it is the main ledger and has the most details of information. It can have more than one secondary ledger assigned.
  
  2. Secondary Ledger(SL): it is optional and differs in one or more of the 4C's from the PL.It provides an additional accounting representation of the PL to comply with legal requirements.
  The SL can only be assigned to one PL.
  
  3. Reporting Currency(RC): Used when the only element that differ from the PL is the Currency. it is stored in the tables as a ledger but does not need to be setup as a ledger via ASM.
  
  Primary and secondary ledgers can have RC's assigned. if a RC has not been assigned to a PL or SL, when a translation is run in a ledger the reporting currency is automatically added
  to the ledger setup.
  
  The Secondary and reporting currency ledgers stores additional accounting representations of the information present in the primary ledger. There are different level of detail in which this information is stored, which are called Conversion levels.
  
  Ledger Sets:
  Ledger Sets enables you to group multiple ledgers that share the same COA and Calendar Combination. Essentially, Ledger Sets allow you to treat multiple ledger as one. for example you can open and close periods for multiple ledgers in a ledger set in a single submission by submitting the new Open and Close Periods Program from the Submit Request Form.
  
  Data Access Sets:
  Data Access Sets enable you to specify read only or read and write access for a legal entity, ledger, Balancing Segment Value or Management segment Value.

Oracle R12

R12 is the latest and most advanced version of the E-Business Suite.

R12 is Defined as Global Business Release Focusing on working , Thinking and Managing Global Organization.

Requirements:

============

•Improve support for shared service operations.
•Ease access to aggregated data for management reporting.
•Ensure accurate accounting, tax and currency treatment of transactions.

Results:

=======
•A single responsibility to access and transact on multiple organizations .
•A single ledger to manage multiple currencies.
•Ledger sets to manage accounting processes across ledgers.
•Centralized rules engines for tax, accounting and inter company.
•A separate and simple payment creation and delivery solution.
•Centralized trading partners (suppliers, banks, first party legal entities).
•Simplified reporting via XML Publisher.
•Netting across trading partners.

Centralized Financials Architecture:

==========================

TOP Changes in Oracle Release 12:
===========================
1.Multiple Ledgers- From Set of Books to Ledgers and Ledger Sets.
2.Legal Entities and Accounting Setup.
3.From Product Accounting to Subledger Accounting. (SLA)
4. Shared Service Access Controls - From Multi-Org to Multi-Access- MOAC (Multi Org Access Control) - Role based access to Operating Unit.
5.Oracle Payments and Banking - Centralized Bank Model- Centralized Payment Processing (Shared Services Disbursements and Receipts)
6.From Multi-Tax Codes to E-Business Tax(EB Tax).
7. Intercompany using Advanced Global Intercompany (AGIS).

Changes between 11i and R12 high level details:

Oracle TCA - R12

TCA- What's New in R12:
======================
What is Oracle TCA:

Trading Community Architecture (TCA) is a model for maintaining
information about parties and customers who belong to an
enterprise's commercial community. Parties can be people or
organizations that can enter into business relationships accross
the e-Business Suite.

The main purpose of TCA is to provide a single source of information
in the TCA Registry for all Oracle e-Business Suite Applications.


















R12 - Intergration Capabilities:












R12- TCA:

















Trading Community Manager:















This is predefined for country United States in any new instance as
STATE, COUNTY, CITY and POSTAL CODE. For other countries,
you can simply create the geography structure depending on your
requirement or just use the Copy Structure feature to create the
geography structure based on the geography structure of another
country.

First query the country for which you want setup Address Validation
by Country Code or Name.

















Real-time address validation validates addresses during address
entry. For Oracle Trading Community Architecture, and other
Oracle E-Business Suite applications, this validation is based on the
information and setup of Geography Hierarchy.

Real-time address validation is performed only for addresses created
in the HZ_LOCATIONS table and countries that are set up in
Geography Hierarchy.

Geography Hierarchy Overview:
Geography Hierarchy is a data model that lets you establish conceptual parent-child relationships between geographies. Oracle Trading Community Architecture (TCA) and other Oracle E-Business Suite applications can leverage Geography Hierarchy for various uses related to locations, such as real-time address validation and tax calculation.

The geography information is centrally located in TCA and share among all the applications.

An ability to create and maintain hierarchies between multiple address elements or tax authorities for the purpose of real time address validation and/or tax calculation.

- Does not include street level Data. - Hierarchies can be created from Tax Vendor provided Data using utility provided by eBusiness Suite Tax Application. - Users can further extend the hierarchies that were created based on data provided by Tax Vendors.

Configuration: - Define Country specific structures for geographic hierarchies. - Manage Geography Details. - Manage Data Validation Levels during Data Entry.

Geography Validation: For example, for the United States, you specified the North America address style for HZ_LOCATIONS addresses. Then for that combination, you map the US country structure to HZ_LOCATIONS attributes, and specify that Country, State, and Postal Code values are used for geography validation.

When the user enters a US address using this address style, the address must have the correct country , state, and postal code combination, based on Geography Hierarchy data, to be considered geographically valid. Use the Geography Validation check box to specify which address elements are mandatory during address entry, based on the geography validation level for country selected.

The Geography Validation Level for Country can be:
1. Error: Only completely valid addresses can be saved, with all mandatory address elements entered.
2. Mandatory Fields Only: Invalid addresses can be saved without warning users, but only if users enter a value for all mandatory addresses elements, as defined by the geography types selected for Geography Validation usage.
3. No Validation: All addresses can be saved including incomplete and invalid addresses.
4. Warning: Invalid addresses are saved after warning users.

The Geography Validation usage determines which address elements re mandatory during ddress entry, based on the geography validation level selected. For example, if the validation level is Mandatory Fields Only, then users must enter address elements that have Geography Validation usage, but the address can still be saved if values are invalid.

Tax Validation: For example, for the United States, you had specified the North America address style for HR_LOCATIONS_ALL. Then for that combination, you map the US country structure to HR_LOCATIONS_ALL attributes, and specify that County, State, and City are used for tax validation. When a sales transaction involves an address with the North America address style, the address must have the correct county, state, and city combination, based on Geography Hierarchy data, to be considered valid for tax calculation.

Important: For either usage, do not skip more than one consecutive level unless you are certain that the selected geography types can uniquely identify geographies. For example, the country structure is: State, County, City, and Postal Code, and you want to select just State and Postal Code for geography or tax validation. However, for the combination of California and 94065, the city can be either Redwood Shores or Redwood City. In this case, you should also select at least City for geography or tax validation.

AR - New Customer User Interface:
- Customer Standard form that has been existing till R11i is finally gone.
- Oracle Introduced a brank new HTML UI built using OA Frame works leveraging TCA that can be used to manage Customers, Accounts, etc.
- New UI Displays both Party Level as well as Account Level information
which is sepearted into Customer Overview and Account Overview.



















Find Customer screen now uses DQM (Simple and Advanced Search
Match Rules) similar to what you see in Customers Online or Customer Data Librarian.
- After search, you can create new customer or see customer
overview. From here you can add accounts or modify accounts
and so on.
- You can update customer information from customer overview
page.


R12- Customer Tab Structure:


















R12 Supplier is part of TCA:

Supplier can be setup from many different application, but the
datails stored in a single repository called the Trading Community
Architecture.

TCA Provides a single, common definition that can be used to
identify customer,suppliers and organziations that provide you with
goods or services.

Supplier information is shared by the following applications.

1. TCA:
All Supplier information is defined in TCA.

2. Purchasing:
Purchasing uses supplier defaults, such as freight terms, shipping
details,on requisitions, purchase orders, request for Quotations, etc.

3. Payables:
Payables uses supplier defaults, such as method of payment and bank
account information during invoice entry and payment processing.

4. Fixed Asssets:
Assets maintains the supplier name and number for each asset record.

5. Property Manager:
Property Manager exports lease invoces for suppliers to payables so
they may be paid.

6. iSupplier Portal:
iSupplier Portal allows you to grant acces to supplier to review order,
receipt and payment details for the supplier. Supplier can enter
planned (with PO) or unplanned (without PO) invoices and update
supplier information.

MOAC: if you are using Multi organization support feature, you
cannot enter the following information at the supplier level, only at
the supplier site level they can be entered.

- Liability Account
- Prepayment Account
- Distribution set
- Invoice Tax Code
- Future Dated Payment Account.

As we know in R12 Supplier is part of TCA , thus the link between
PO_VENDORS and HZ_PARTIES is PO_VENDORS.party_id.
The link betweenPO_VENDOR_SITES_ALL and
HZ_PARTY_SITES is PO_VENDOR_SITES_ALL.party_site_id.
When a Supplier is createdRecord will be Inserted in HZ_PARTIES.
When the Supplier Site is created Record will be Inserted in
HZ_PARTY_SITES. When Address is created it will be stored
in HZ_LOCATIONS.

Bank Model is part of TCA in R12.

If we compare the bank setup in R11i and R12, we can notice
that banks was utilized into three different places Finance ,
Payroll and Treasury, which requires altogether a different
setup.

We have notice in 11i there was functionality in which Payables in
which we will create an employee type supplier from HR data and
it will contain name and address info but not bank information.

The reason for this is that HR/Payroll does not store the bank
information in a standard way that makes the integration possible.

Bank Account Data Model in R12 is consolidated in TCA Model.

Overview of Bank Model:

The Bank Model feature allows you to define and keep track of all
banks accounts in the e-Business suite in one place and explicity
grant account access to multiple operating Units and users.

The bank model is based on the following concept:

- Centrally located in Cash Managment.
- TCA Parties associated with bank branches.
- Owned by LE's.
- Applications that use Bank Accounts are AR, AP, Treasury
and Payroll.
- Grouped by Country.

In Prior release AP owned banks, bank branches and bank accounts,
such bank accounts could be used by AR, Payroll and Treasury.
In R12, Banks and Bank Branches are created as TCA parties,
The bank Accounts are associated with Bank Branches but reside
with in the Cash Management Application.
During the Bank Account creation, you are able to define in which
application this bank account can be used.
















TCA Tables:




















Bank Accounts will be stored in a new table called
CE_BANK_ACCOUNTS and will be located at a Bank Branch.
The new table which hold the bank information are as:
CE_BANK_ACCOUNT:stores bank account attributes
CE_BANK_ACCT_USES_ALL : This stores the bank account
use attributes specific to Operating Unit (AR, AP) and Legal
Entity (Treasury).
CE_GL_ACCOUNTS_CCID :The accounting data pertaining to
the bank account use will be stored in the table.