Tables involved with security rules in oracle apps R12 & R11i

Tables involved with security rules in oracle apps R12 & R11i

                                                                          

In this post, Let us see the tables involved with Security rules and a query to collect the data related to security rules both in R12 and 11i releases.

TEST INSTANCE: R12.1.3

SELECT frt.responsibility_name,

       frt.responsibility_id,

       ifs.id_flex_num Chart_of_accounts_id,

       led.name ledger_name,

       ffv.flex_value_set_name Value_set_name,

       ifs.segment_name,

       ifs.segment_num,

       fvr.flex_value_rule_name,

       DECODE(fvrl.include_exclude_indicator,

               'E', 'Exclude',

               'I', 'Include',

               'Error') Inc_exc,

       fvrl.flex_value_low,

       fvrl.flex_value_high

  FROM fnd_flex_value_rule_usages fvru,

       fnd_flex_value_rules fvr,

       fnd_flex_value_rule_lines fvrl,

       fnd_responsibility_tl frt,

       fnd_id_flex_segments ifs,

       fnd_flex_value_sets  ffv,

       gl_ledgers led

 WHERE fvru.responsibility_id  = frt.responsibility_id

   AND fvru.flex_value_rule_id = fvr.flex_value_rule_id

   AND fvrl.flex_value_rule_id = fvr.flex_value_rule_id

   AND ifs.flex_value_set_id   = fvr.flex_value_set_id

   and fvr.flex_value_set_id   = ffv.flex_value_set_id

   AND ifs.id_flex_num         = led.chart_of_accounts_id

   AND led.name                = 'Vision Operations (USA)'

   AND ifs.id_flex_code        = 'GL#'

 ORDER BY

       frt.responsibility_name,

       ifs.segment_num,

       fvr.flex_value_rule_name,

       fvrl.include_exclude_indicator Desc;

TEST INSTANCE: 11i

SELECT frt.responsibility_name,

       frt.responsibility_id,

       ifs.id_flex_num Chart_of_accounts_id,

       ifs.segment_name,

       ifs.segment_num,

       fvr.flex_value_rule_name,

       DECODE(fvrl.include_exclude_indicator,

               'E', 'Exclude',

               'I', 'Include',

               'Error') Inc_exc,

       fvrl.flex_value_low,

       fvrl.flex_value_high

  FROM fnd_flex_value_rule_usages fvru,

       fnd_flex_value_rules fvr,

       fnd_flex_value_rule_lines fvrl,

       fnd_responsibility_tl frt,

       fnd_id_flex_segments ifs,

       gl_sets_of_books glsob

 WHERE fvru.responsibility_id  = frt.responsibility_id

   AND fvru.flex_value_rule_id = fvr.flex_value_rule_id

   AND fvrl.flex_value_rule_id = fvr.flex_value_rule_id

   AND ifs.flex_value_set_id   = fvr.flex_value_set_id

   AND ifs.id_flex_num         = glsob.chart_of_accounts_id

   AND glsob.name              = 'Vision Operations (USA)'

   AND ifs.id_flex_code        = 'GL#'

 ORDER BY ifs.segment_num,

       fvr.flex_value_rule_name,

       fvrl.include_exclude_indicator Desc,

       frt.responsibility_name ;

Query to get Customer Role in TCA

Query to get Customer Role in TCA

Below is simple query to get the Customer Role Details in TCA

select a.cust_account_role_id,a.*
from
hz_cust_account_roles a, 

hz_role_responsibility b,

 hz_cust_acct_sites_all c
where
a.role_type = 'CONTACT'
and a.party_id = p_party_id
and a.cust_account_id = p_cust_account_id
and a.cust_acct_site_id = c.cust_acct_site_id
and a.cust_account_id = c.cust_account_id
and c.party_site_id = p_party_site_id
and a.cust_account_role_id = b.cust_account_role_id
and responsibility_type = p_acct_site_type;

Trading Community Architecture (TCA) 101

Trading Community Architecture (TCA) 

Trading Community Architecture (TCA) is a structure which was based out of R11 Customer Model designed to support complex trading relationships to cater additional need which further extended in R12 with Supplier and Bank. So, TCA is a data model that allows you to manage complex information about the parties, or customers or suppliers or bank who belong to your commercial community, including organizations, locations, and the network of hierarchical relationships among them.

What is Trading Community Architecture (TCA)?

What is TCA, the Trading Community Architecture? Is TCA an Oracle Applications module? Is it functionality within an Oracle module? These are few common question, and there are often many answers given.

The TCA is a data model that supports the entry and management of entities that you interact with. So lets revisit the concept.

Trading Community Architecture is a Very flexible, very robust model which defines the components involve in trading within in E-business Suite.

The implementation of technology and applications to allow users to create and maintain relationships among entities

The universal data schema for customers, prospects, suppliers, distributors, resellers, consortiums, bank across all Oracle EBS applications

TCA not only allows for the tracking of relationships between the implementing organization and its trading partners, but also tracks relationships between the trading partners themselves.

You should also note, TCA is neither an Oracle Applications module nor requires separate license.

If you see TCA guide, you can find these are the key features of TCA

• Provides a foundation for a single source for customer information.
• Ability to represent all business entities as a “Party” (organizations, people, groups, relationships) and to handle them the same way. This approach provides flexibility to accommodate all B2B, B2C and hybrid models in the same repository.
• Many-to-many relationships between Parties and Locations, that allows for less duplication and easier updating.
• Capability for advanced relationship modeling between entities within the trading community. Any party can figure in any number of Party Relationships even within matrix hierarchies (relationship networks).
• Ability to setup and maintain any number of party classifications which can be used for reporting and assignment purposes.
• Extensible data model to enable various business data requirements.
• In reality , three entities Drive in the TCA model , which are Party, Account, and Relationships.

 TCA Terminologies

• Party
  • The concept of ‘Party’ enables the Customer Model to treat all business entities equally, regardless of type. It easily handles B2B, B2C.
    Parties of type ‘Group’ allow for the grouping of any number of other parties into a single entity which enable modeling of households and buying consortiums.
  • Parties of type ‘Relationship’ allow for the relationship between two parties to be viewed as a party in its own right
  • Party - A Party is an entity that can enter into a business relationship and can be of four types.
    • Person - A unique individual (dead or alive) of interest to the owner of the software.
    • Organization - A legal entity recognized by some government authority.
    • Group - a combination of two or more people, organizations or groups of created for the use of the owner of the software.
    • Relationship - The association between an individual person and an organization. Usually a contact at an organization or group.

Fig 1: TCA Logical Diagram

• Account
  • Account - Is a financial roll-up point to track the monitory portion of a customer’s purchases and payments. Stores details about a customer relationship between a Party and your business.
    • This Represents selling-buying relationship such as billing and shipping events
    • Accounts required for a transaction
    • A account cannot exist without a party
  • A Party may have one or more Customer Accounts
    • Account Role - The relationship that a Party has in regard to controlling or using an account.
    • Customer Account Site is a Party Site that is used within the context of a Customer Account (e.g., for billing or shipping purposes).
    • A Customer Account Contact is a Party Contact that is used in the context of a Customer Account.
• Customer
  A customer account represents the business relationship that a party can enter in to with another party. The account has information about the terms and conditions of doing business with the party. For example, you could open a commercial account for purchases to be made by Vision Distribution for its internal use and a reseller account for purchases made by Vision Distribution for sales of your products to end-users .

You can also define contact people, bank accounts, payment methods, telephone numbers, and relationships for each customer account.

You can also maintain multiple customer accounts for a customer that transacts business with more than one line of business in your organization. You maintain separate customer profiles, addresses, and contacts for each customer account.

A party site is the location where a particular party is physically located. Every party has only one identifying address, but a party can have multiple party sites.

A customer address is a party site used in the context of a customer account for billing, shipping, or other purposes.

A contact communicates for or acts on behalf of a party or customer account. A contact can exist for a customer at the account or address level. A person usually acts as a contact for an organization, but can also be a contact for another person. For example, an administrative assistant could be the contact for an executive.

Old Model vs New Customer Model

Fig 2; Customer old model and TCA model

• Locations/site :A Location is a point in geographical space described by an address. A party site is a location.
• Party Relationship :Any relationship between two parties of the above type (person and organization) that needs to be stored as its. own record. Data that directly corresponds to this relationship (contact info etc.) is stored as well. Relationships are stored in the HZ_PARTY_RELATIONSHIPS table.

Factors which you can consider for TCA entities

• Business requirement including your reporting
• System/application requirement
• Country or Organization Legal Requirement
• Global Consideration
• Process standardization

TCA Setup Considerations

When you are doing TCA customer Modeling, keep these things in mind;

• Party be any real Person or Organization.
• Party sites are locations for Party or Organization.
• Relationships are generally used to construct hierarchical structure of Organizations.
• Party becomes a Customer/Account, once a selling relationship is established.
• An account should typically have at least one active ‘bill_to’ site. It helps for accounting and reporting purposes.
• When creating Parties, what all party sites can be or should be created as Parties.
• Generally, if you want to see activities for site level separately from your parent level party, you should create that Site as a separate Party/Entity.
• An account is a separate entity. Create account only where you have selling relationship i.e. only for customers. It identifies selling attributes e.g.payment terms, shipping and billing preferences etc. of the relationship.
• You can have multiple accounts, for each relationship between external party and your business entity. It enables you to have multiple
  sets of selling attributes e.g. payment terms etc.
• You can build relationship between accounts and have one account to pay for another.
• If transaction needs to be segregated within a party to perform granular analysis based on selling or business relation,separate accounts with a party should be created.

TCA Integration with Other Oracle Products

This is how TCA data is tighten with other Oracle products.

 TCA Technical Tables

• TCA - Customer : Here are Technical details for 11i/R12 customer in TCA. You can also refer old post for customer model.

• TCA - Suppliers

Here are Technical details for R12 Supplier in TCA. You can also refer old post for more details.

• TCA - Bank
  
  

  R12 : Bank & Trading Community Architecture(TCA)

  Three key CE tables now as:

  • CE_BANK_ACCOUNTS for bank accounts
  • CE_BANK_ACCT_USES_ALL for account uses by Operating Units & Legal Entities
  • CE_GL_ACCOUNTS_CCID for bank account use accounting data

  TCA and Bank

  The TCA party model is being used to model banks and bank branches as parties with the associated attributes of Relationships, Address, Contact and Locations. The TCA tables used by Cash Management for modeling Banks and Bank Branches are listed below:

  1. HZ_PARTIES
  2. HZ_RELATIONSHIPS
  3. HZ_RELATIONSHIP_TYPES
  4. HZ_ORG_CONTACTS
  5. HZ_ORG_CONTACT_ROLES
  6. HZ_CONTACT_POINTS
  7. HZ_PARTY_SITES
  8. HZ_LOCATIONS
  9. HZ_ORGANIZATION_PROFILES

  The HZ_ORGANIZATION_PROFILES table stores additional attributes of banks and bank branches along with the history of changes made to Banks and Bank Branches. The contact person at the bank, bank branch and bank account is defined as a party in HZ_PARTIES, while the contact details will be stored in HZ_CONTACT_POINTS (stores contact methods), HZ_ORG_CONTACTS (stores the contact’s title) and HZ_ORG_CONTACT_ROLES (stores the contact’s purpose or role). The address details of Banks and Bank Branches will be in HZ_LOCATIONS (stores addresses) and HZ_PARTY_SITES (stores party sites).

  The new table CE_BANK_ACCOUNT stores bank account attributes while the CE_BANK_ACCT_USES_ALL table stores the bank account use attributes specific to Operating Unit (AR, AP) and Legal Entity (Treasury).

  The accounting data pertaining to the bank account use will be stored in the CE_GL_ACCOUNTS_CCID table.

  All of the bank, branch and bank account related attributes in AP_BANK_BRANCHES and AP_BANK_ACCOUNTS_ALL tables will be upgraded to HZ_PARTIES and the new tables in Cash Management.

  Within TCA model, here is various attributes how they fits inside the model.

  
  

  

  
  

  R12 : EBS Banking Model in demanding and Changing World

  Hey did you notice there is one thing that keep changing since last 2 releases ...the bank. We have seen there was once from pre 10.x to 11i when supplier bank separated from suppliers data and now its again in R12 when it become part of TCA.This time , because of changing business need and high demand of global partners working model. Not only your company is operating globally,your partner too operating global,then why not use them. In typical business cost model, if corporate office is using Citibank for payroll for USA operation then why not Citibank Singapore branch is used for payroll for Singapore if they are operating there. Sound bit low...why ..

  As we aware the key message of R12 while release was .

  • Think Globally - using business intelligence and analysis tools
  • Work Globally - using the global capabilities of the applications
  • Manage Globally - using the latest system architecture and middleware

  so what , think globally and work globally is factor driving for the changes .This release have witness the great changes ever into the bank model. Now the bank accounts is attached to your legal entity level rather than Operating Unit in which current and existing versions Offers. This makes bank with strong capability to pay across operating units. More over its important to understand banks accounts can be shared by applications and can be designed for use by Payables, Receivables and Payroll.

  What is new in R12 for Bank

  These changes make easier and more reliable by

  • Single access point
  • Single Legal Entity ownership
  • Usage rights granted to one or more Organizations
    • Reconciliation option defined at Bank Account level
    • More flexibility and control

  Take a looks of some of the releases

  Release 10.6 character/10.7 NCA to 11i
  How 10.x supplier banks are mapped to 11i

  • Bank Namepo_vendor_sites.bank_number => ap_bank_branches.bank_name
    po_vendor_sites.bank_number => ap_bank_branches.bank_number
  • Bank Number
    po_vendor_sites.bank_num => ap_bank_branches.bank_num
    po_vendor_sites.bank_num => ap_bank_branches.bank_branch_name
  • Bank Account Namepo_vendor_sites_all.bank_account_name => ap_bank_accounts_all.bank_account_name
  • Bank Account Numberpo_vendor_sites_all.bank_account_num => ap_bank_accounts_all.bank_account_num

  Release 11i

  These are tables which hold the bank details irrespective of supplier or internal banks.

  • ap_bank_branches
  • ap_bank_accounts_all

  Comparing the 11i Vs R12

  If we compare the bank with 11i vs R12, we can notice the bank was utilized into three different places , finance ,payroll and treasury, which requires altogether a different setup. It was one of the big issues with integration aspect, as significant problem was recognized once the Expense management and payroll uses same bank for the respective person.

  There was a common question/confusion between the Integration Existence between Bank Data in Accounts Payable and Bank Data In Payroll ?

  As discussed above , you know most of release of 11i family of oracle Application does not have integration between HR and AP for bank account data.

  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.

  So now r12 this was well taken care and integration is built. There are plans under way for all bank account data models in the various products to be consolidated in the new TCA architecture. The Cash Management team is working on this project. Payables and HR/Payroll are working so that the eventual idea will be that you can set up bank accounts in one place and then indicate the usage (pay, expense reimbursement, etc).

  For understanding it is comparison between 11i and release 12 , where TCA community take cares of every things.

  

  Release 12 , what is new than

  

  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:

  1. CE_BANK_ACCOUNT:stores bank account attributes
  2. CE_BANK_ACCT_USES_ALL : This stores the bank account use attributes specific to Operating Unit (AR, AP) and Legal Entity (Treasury).
  3. CE_GL_ACCOUNTS_CCID :The accounting data pertaining to the bank account use will be stored in the table.

  This new data model allows the bank and bank branch entities to be defined separately allowing users to establish a hierarchical relationship between them.

  Missing link between Supplier And Supplier Banks?

  You should know

  • The link between PO_VENDORS and HZ_PARTIES is PO_VENDORS.party_id.
  • The link between PO_VENDOR_SITES_ALL and HZ_PARTY_SITES is PO_VENDOR_SITES_ALL.party_site_id.
  • When a Supplier is created Record 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
  • When a bank Is Created, the banking information will be stored in

  IBY_EXT_BANK_ACCOUNTS IBY_EXT_BANK_ACCOUNTS.BANK_id = hz_paties.party_id

  • When the Bank is assigned to Vendors then it will be updated in HZ_CODE_ASSIGNMENTS.

  HZ_CODE_ASSIGNMENTS.owner_table_id = IBY_EXT_BANK_ACCOUNTS.branch_id.

  Internal Bank Accounts & Supplier and Customer Bank Accounts in R12

  Internal Bank Accounts
  In Release 12, each internal bank account is assigned to a Legal Entity. Any or all operating units associated with that legal entity are permitted to use that bank account.
  Supplier and Customer Bank Accounts
  In Release 12 provides a centralized repository for suppliers’ and customers’ bank account and credit card information. All data is stored in one, secure place, providing shared service centers and collection departments consistent information that they need.

  
  

  
  

  Welcome to R12 Account Payable

  ---

  
  As we learnt during Release 12, the E-Business Suite has couple of new products like Subledger Accounting, E-Business Tax thus significant changes have been observed in Account Payable data module as some of functionality is shared by some other products. Thus it is important to understand what is new. I would like to briefly outline the details of some of new changes and underlying impact on the objects. More details can be found in R12 release documents published by Oracle a month ago.

  ---

  Let’s have a dissection view of R12 payable, with some of its core objects

  Supplier

  We have seen in 11i

  • Suppliers defined in AP.
  • Supplier contacts replicated for each supplier site.

  Where as in R12

  • Supplier becomes as TCA Party.
  • Suppliers Sites as TCA Party Site for each distinct address.
  • Contacts for each supplier/address , it means Single supplier address and contact can be leveraged by multiple sites, for each OU
    • A single change to an address can be seen instantly by all OUs
    • No longer need to manually 'push' updates across OUs.This can be best understood by the figure below.

  

  Then the question is what will happen if any one can come from existing financial products. The Impact from upgrade can summarize as:

  1. When we upgrade supplier tables replaced with backward compatible views.

  2. One party site for each distinct supplier site address

  Country and address line1 are required, this is because creation of suppliers in Party in TCA data model would requires Country and address information, but it also understood if there is no country or address line 1 specified for a supplier site in cases when upgrades takes place, Payables derives the country based on the most frequently used operating unit of the Supplier's historical transactions.

  3. Employee as suppliers: address NOT migrated to party site in TCA remains in Oracle HR for data security reasons.

  As we know in 11i employees are part of internal supplier's record in order for Oracle Payables to create payments for their expense reports. Employees defined in Oracle Human Resources and associated with an Oracle Payables supplier record have existing party information. During the upgrade, Oracle Payables updates the existing party information to have a party usage of supplier but it does not migrate the employee address to the party site in TCA, they remain in Oracle Human Resources for data security reasons.

  4. Utilize TCA Party relationships for franchise or subsidiary and its parent company.

  Invoice

  Till 11i version, we have seen invoices:

  • Had only distributions line.
  • Allocation of freight and special charges are captured at the distribution level only
  • Tax and payment and Project accounting Payment was captured through global Descriptive Flexfields.

  But in R12,

  1. Invoice Lines as a new additional line accommodated in Invoice data model.

  

  Because of introduction of invoice line there is significant improvement of data flow with n other oracle modules like

  • Fixed Asset - Asset Tracking
  • Business Tax - Tax line
  • Payment - Payment
  • SubLedger Accounting - Accounting

   

  2. Allocate freight and special charges are captured to the lines on the invoice
  3. Invoice distributions created at the maximum level of detail similar to 11i.
  4. Core functionality

  The impact with Upgrade can be summarized as:

  1. One invoice line for every distribution in 11i
  2. Sub Ledger Accounting requires that Payables transform the invoice distributions to be stored at the maximum level of detail
  3. Global Descriptive Flexfields migrated to named columns.

            That's means functional testing is more required while upgrade takes place.

  Banks and Bank Details

  Now a days corporate treasury role has been greatly enhanced thus picking up a global bank as partner for all banking need is demand of time in global working model. The recent couple of years have seen drastic increase in acquisition and merger of company thus global working as well as global instance get popularity in ERP areana, and this is one of reason of the reason bank data model has been significant changes from 11 to 11i and 11i to R12.

  Internal Bank AccountsIn 11i we have seen internal Banks defined in AP and that is shared by AP/AR/CE, Payroll and Treasury and they are bank accounts often replicated in multiple OUs

  Where as in R12,

  • Bank and Branch become part of TCA Parties.
  • Internal Bank Account in Cash Management which is owned by a Legal Entity. Here the Operating units have granted usage rights.

  Suppliers Bank Accounts
  In 11i

  • Banks/Branches defined in AP
  • Bank accounts often replicated in multiple OUs Before

  R12

  • Suppliers, Banks and Branches are defined as Parties in TCA
  • Supplier (party's) payment information and all payment instruments (Bank Accounts, Credit Cards) moved into Oracle Payments.

  The typical data model for bank can be summarized as:

  

  Impact of Upgrade

  1. With Upgrade banks and branches migrated to TCA parties
  2. Banks merged if the following attributes are all the same:

  • a. Bank Number
    b. Institution type
    c. Country
    d. Bank admin email
    e. Bank name alt
    f. Tax payer ID
    g. Tax reference number
    h. Description, Effective dates

  3. Bank accounts, bank account uses are migrated into cash management.
  4. Transactions are stamped with the bank account uses identifiers as part of the upgrade

   Integration with Oracle E-Business Tax

  In 11i

  • Oracle standard functionality was based out of User which determines tax by assigning Tax Codes at line level of invoice and Tax rules was controlled at underline code.
  • There was global descriptive flex fields were captured for country-specific tax attributes.
  • More importanta most of the setup performed at OU level.

  In R12

  • A new module eBusinessTax determines tax based on facts about each transaction, this is reason why Oracle has introduced additional line information at invoice level.
  • The module "ebusiness Tax" set and configure Tax rules which can be viewed
  • Tax attributes collected in fields on key entities
  • Configure tax rules once per regime and share with your legal entities

  Impact of Upgrade
  1. Payables Tax setup, Tax Code defaulting rules defined per OU are migrated to eBusiness Tax.
  2. OUs migrated to tax content owner in R12
  3. Tax information in tax codes are transformed to Regime-Rate flow.
  4. E-Business Tax takes information from the AP invoice lines and creates summary and detail tax lines in the E-Business Tax repository.

  Multi Org Access Control

  MOAC is new enhancement to the Multiple Organizations feature of Oracle Applications.

  This feature enables user to access data from one or many Operating Units while within a set given responsibility. Due to this change, all processing and some Reporting in Oracle Payables is available across Operating Units from a single Applications responsibility. Hence you can isolate your transaction data by Operating unit for security and local level compliance while still enabling shared Service centre processing.Data security is maintained using the Multiple Organizations Security Profile, defined in Oracle HRMS, which specifies a list of operating units and determines the data access privileges for a user.

  Impact of UpgradeR12 Upgrade does not automatically create security profiles, thus is important if any one want to use Multiple Organizations Access Control, the first things is to define security profiles, then link them to respective responsibilities or users.

  Reference: Details can be found more on R12 RCD documents, from Oracle site.

AP Suppliers in R12

AP Suppliers in R12

In R12 Accounts Payables, that there is no more supplier form. The Suppliers have gone to self-service now. This is not the only change in the supplier. The suppliers objects have moved from AP product to TCA (Trading Community Architecture) DataModel. Due to this, even the underlying tables have changed. Supplier information is no more stored in PO_VENDORS Table now.

3 new tables have been introduced.

• AP_SUPPLIERS

• AP_SUPPLIER_SITES_ALL

• AP_SUPPLIER_CONTACTS

But don't panic as your customizations can still work as there are views created with names of PO_VENDORS, PO_VENDOR_SITES_ALL and PO_VENDOR_CONTACTS for backward compatibility.

Being a part of the TCA, these tables are closely linked to the hz tables. Here is the list of few imp HZ Tables that are affected when a new supplier is added.

TABLE NAME	DESCRIPTION
HZ_PARTIES	Master table along with AP_SUPPLIERS instead of PO_VENDORS
HZ_PARTY_SITES	Master table for supplier sites along with AP_SUPPLIER_SITES_ALL instead of PO_VENDORS_SITES_ALL
HZ_LOCATIONS	Contains the party sites information
HZ_PARTY_USG_ASSIGNMENTS	Stores party usages
HZ_ORGANIZATION_PROFILES	Captures additional Supplier information, e.g. credit scoring details of Supplier or the Number of Employees working in Supplier Organization
IBY_EXTERNAL_PAYEES_ALL	Captures Payment related details of the Supplier
POS_SUPPLIER_MAPPINGS	It holds the mapping between the AP_SUPPLIERS.VENDOR_ID and HZ_PARTIES.PARTY_ID

This is useful in cases whereby two vendors effectively belong the same HZ_Party Record.

See the diagram below for Supplier/Sites Mappings to TCA Objects.

So whenever a supplier is added in R12, an entry is made in all these tables. Functionally also, creating the supplier is different from 11i. Here are the steps to create a new supplier.
1. Hit the CREATE SUPPLIER button

2. Enter a unique supplier name (Organization Name) along with other optional other information like Alias, Tax Registration Number, D-U-N-S number.

3. If the Supplier Number Entry option in the Payables System Setup window is set to Automatic, Payables automatically enters a Supplier Number for you. If this option is set to Manual, you must enter a unique Supplier Number.

4. Click Apply. The system creates the supplier record and accesses the Suppliers: Quick Update page.
5. To create Supplier Sites, you will have to create the locations for that supplier. For that, click on the "Address Book" Button.

6. On the Address Book page, click the Create button.
7. Fill all the address details and address purpose. i.e. Purchasing, Payment or RFQ Only.
8. You can add as many locations as you wish.

9. When created, you can manage the addresses for other information.




<< Click to view the image in large size >>
10. The system only displays sites that are in your MOAC profile

11. The address status indicates whether the supplier has provided any updates for the address. Using iSupplier Portal's Supplier Profile Management tools, suppliers can enter address book information online, creating any number of new addresses, modifying the details for existing addresses, and indicating how each address is used.

12. Suppliers can also inactivate addresses that are obsolete. Buyer administrators need to approve any changes in order to update the master supplier details.
13. Address statuses include:

• New. A supplier has created a new address.

• Change Pending. A supplier has changed the address details. Click the Update icon to review the changes that have been made. The page displays the original address details and the changes, indicated by a blue dot. Buyer administrators can approve or make additional modifications to the changes before approving or rejecting the change. If the supplier has indicated that the address should be removed, there is a status change from Active to Inactive.

• Current. There are no pending updates for the address.

14. Since suppliers are stored in TCA, the address details for the supplier may be used by other Oracle products so be careful if removing supplier addresses. If the address is inactivated, the system no longer associates it to any contacts, and any bank account assignments to the address are inactivated. Methods to inactivate addresses include:

• You can click the Remove button on the Address Book page. This sets the address status to inactive and sets the Inactive Date for every site that is associated with the address in all operating units to today's date.

• You can update the address and set its status to Inactive. This changes the address status and does not inactivate any of the sites that are using the address.

• You can use the Manage Sites page to manually update the Inactive Date for each site.

R12 Oracle Application Footprint

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.1. version New Features

R12.1.X New Features

Ledger Architecture
- Ledgers: Define by Chart of Accounts, Calendars, Currency and Accounting Conventions.
- Ledger Sets: Group of Ledgers sharing the Same Chart of Accounts and Currency.

Centralized and Flexible Rules based Accounting Engine
- Ruled based engine with configurable accounting rules
- Single source of truth for accounting, reconciliation and reporting with common data model and repository and posting engine.
- Consistent data model and user interface across all subledgers.

Centralized Legal Entity Management
- Manage Legal Corporate Structure
- Link tax, intercompany, bank account and accounting functions
- Isolate legal compliance issues at legal entity from the management and security issues at operating Unit.

Centralized Banking and Payments
-Single user interface for all setup and maintenance related to banks and internal bank accounts.
-Centralized management of all funds capture and disbursements
-Centralized credit card management.

Centralized Global Tax Processing
-Centralized Tax Engine with single data model for rules and transations across geographes and applications
-Centralized tax repository for global visibility
-Simplified tax configuration across legal entities and oracle apps.

Advanced Global Intercompany system
- Centralized intercompany and intracompany accounts setup
- Fully configurable approval rules and invoicing options.
- Physical Payables and Receivables intercompany invoice generation.

Oracle General Ledger:

- Single Page for all accounting setup with Accounting Setup Manager.
- Prevent Accounting errors with Alternate accounts
-Replacement for Disabled Accounts
-Prevent unauthrized posting with Control Accounts
-Simplify security and Data Access and Definition Access sets.
-Sequential numbering of accounting entries
-Journal line reconciliation-Journal Batch Copy
-Historical Data initialization for new reporting currencies and secondary ledgers.

Oracle Payables:

- Pay on behalf of a different party with 3rd party payments
- Greater flexibility in defining and calculating discounts for quick payments.
-Application of withholding taxes at time of invoice validation and during payment
-Improved resolution for dispute processing with suppliers.
-Imporve invoice data entry and management with line level entry, approval, matching and tax calculation.
-Automated netting of Customer and Supplier balance
-Self-Service invoivce allows employees and suppliers to enter various invoice type online.
-New interface and data model for supplier managment in TCA.


Oracle Receivables:
-Streamlined receipt porcessing with cash application work queue.
-Enhanced performance for high volume receivables processing.
-Synchronize Cost of Goods Sold(COGS) with Revenue.
-Increased efficiency with line level cash application.
-Improved billing communcation with balance forward billing.
-Create standard late charge polices that can be assigned to customer accounts or account sites.

Oracle Advanced Collections:- Assign bankruptcy status at the customer level
- Effetively manage later stage delinquency status assignment at case and contract level.
- Internal only comment visibility for dispute processing.
- Streamline system setup and operational maintenance with implementation checklist.
-Consolidation of collections features provides collections workbench
-Improved ability to collect with enhanced dispute management.

Oracle Assets:- Flexible accounting configuration
- Automated depreciation rollback for selected assets
- Enhanced mass additions interface for legacy conversions
- Unplanned depreciation(impairments) for energy industry
- Unit of production and straight line depreciation methods for O&G industry.
- Flexible reporting with BI Publisher.