======================
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.
No comments:
Post a Comment