Deep Drive : Customer Interface in AR

Posted on November 8th, 2007 by Sanjit Anand | Print This Post | Email This Post
Have you tried OracleappsHub in ipad/iphone/smart Phone? Don't
wait. try it today
Lot of people requested some more information for customer import. So I decided to clubbed together,
so here to go:
Lets start with Customer ..why it is important in your business.
As per encyclopedia the customer is defined as:
"A customer is someone who makes use of or receives the products or services of an individual or
organization." Its means it is one who become a entity in your business world, irrespective of your line
of business. If you are manufacturer the customer is one to whom you provide the product and get the
money or services for which your get paid.
Time to time the customer definition has been changed and now in today economy it can be redefined
as:
A customer..may include users, consumers, demanders, commanders, and requestors. Any person or
entity who interacts directly or indirectly with any business system, thus it can be a client within
internal departments, a supplier from the procurement process, an employee, or someone who is
ringing up the cash register.
What information is important to keep in Business?
Typical information required for any customer is address, contact, bank , profile,class. Oracle standard
form does have more than 8 tabs which hold most of the information. A typical flow of customer setup
in Oracle is as;

Fig: Standard Setup process for customer

Fig : Entity Model for Customer Setup
What is Customer Interface ?
Customer Interface is a oracle seeded tool that is used to import and validate current or historical
customer information from other systems into Receivables. Once customer information is imported
into the system, you can use Customer Interface to import additional data for that customer (such as
additional contacts or addresses) and to update existing information. This is yet another options to enter
Customer information other than manually update and enter new information using the Customer
windows.
Customer Interface and Customer in pre 11i and 11i
If you are coming from some old version, if have been noticed few things has been changed:
Customer tables have changed, to move customer in TCA model, it means
o The HZ tables
o The role of Parties
Note:Added in order to track prospective customers Due to CRM
integration and adds benefit of having all customer groups
stored in one location.
11i tables used by Customer Interface
Pre 11i versions used only 12 tables
11i version uses 23+ tables
Only 4 of those tables remain the same
Main Customer tables have changed
Revised look and feel to Customer screen, too
The Change
Here is significant changes has been noticed from pre 11i and r11i version.
FIND screen
in 11i Find window automatically appears while calling customer screen.


most important , the Match Results window now is included in 11i, and it represnt multiple lines due to
Parties and Accounts:

Customer screen


Customer Tables
Previous Tables that have changed
o RA_CUSTOMERS
o RA_ADDRESSES
o RA_SITE_USES
o RA_PHONES
o RA_CONTACTS
o AR_CUSTOMER_PROFILES
o RA_CUSTOMER_RELATIONSHIPS
o AR_CUSTOMER_PROFILE_AMOUNTS
Tables that remain the same
o RA_CUST_RECEIPT_METHODS
o AP_BANK_BRANCHES
o AP_BANK_ACCOUNTS
o AP_BANK_ACCOUNT_USES
TCA model - how its drived
RA_CUSTOMERS, previously the main customer table is now a view.This become view
which consists of data in HZ_CUST_ACCOUNTS and HZ_PARTIES tables.
New Customer Tables - also known as HZ Tables
The new HZ Customer Tables have tables for Customer Accounts and Parties
Customer Table Vs HZ Tables
Here is summarize information for both for them:

Considering Customer as Parties
HZ_PARTIES stores information about organizations, groups, and people.
If a party becomes a customer then the information for the customer is stored in the
HZ_CUST_ACCOUNTS table.
A Party record in the Parties table can have multiple customer account records in the
Customer Accounts table.
One row is created in HZ_PARTIES for every customer record that is imported through the
Customer Interface.
CRM uses the customer module making it a requirement for all customers to have a party id
and customer id.
Customer Interface : The Flow:
The following diagram shows how customer information is imported into the customer tables.

11i Customer Interface Vs Oracle Base table
Here is summarize information for interface Vs base table. Once Customer Import get completed
successfully , the data moved to these tables:

Please take a note, the bank model has been changed in r12, this will have till 11.5.10.2. If you are
looking for R12 , refer to trm guide.
Where to start for Customer Interface
1.The first steps would be your is preparing Receivables setup activity
Be sure to set up new data in Receivables that the Customer Interface should import. For
example:
o AutoCash Rule Sets
o AutoInvoice Grouping Rules
o Collectors
o Customer Addresses
o Customer Bank Information
o Customer Exemptions
o Customer Profile Classes
o Demand Classes
o Dunning Letter Sets
o Freight Carriers
o Payment Methods
o Payment Terms
o Statement Cycles
o Tax Codes
Be sure to also set up Lookups in Receivables that the Customer Interface should import.
These are the lookups:
o Countries
o Site Use Codes
o Credit Ratings
o Risk Codes
o Account Statuses
o Communication Types
o Customer Classes
2. Next is to map the Interface Tables
RA_CUSTOMER_INTERFACE_ALL
o ORIG_SYSTEM_CUSTOMER_REF
o CUSTOMER_NAME
o CUSTOMER_STATUS
o INSERT_UPDATE_FLAG
o CUSTOMER_NUMBER
o ORIG_SYSTEM_ADDRESS_REF
o PRIMARY_SITE_USE_FLAG
o SITE_USE_CODE
o ADDRESS1
o COUNTRY
o LOCATION
RA_CUSTOMER_PROFILES_INT_ALL
o CUSTOMER_PROFILE_CLASS_NAME
o ORIG_SYSTEM_CUSTOMER_REF
o INSERT_UPDATE_FLAG
o CREDIT_HOLD
o ORIG_SYSTEM_ADDRESS_REF
RA_CONTACT_PHONES_INT_ALL
o ORIG_SYSTEM_CUSTOMER_REF
o ORIG_SYSTEM_TELEPHONE_REF
o TELEPHONE
o TELEPHONE_TYPE
o INSERT_UPDATE_FLAG
o ORIG_SYSTEM_ADDRESS_REF
o ORIG_SYSTEM_CONTACT_REF
o CONTACT_LAST_NAME
RA_BANKS_INTERFACE
o ORIG_SYSTEM_CUSTOMER_REF
o PRIMARY_FLAG
o START_DATE
o BANK_ACCOUNT_NAME
o BANK_ACCOUNT_CURRENCY_CODE
o BANK_ACCOUNT_NUM
o BANK_BRANCH_NAME
o ORIG_SYSTEM_ADDRESS_REF
RA_CUST_PAY_METHOD_INTERFACE
o ORIG_SYSTEM_CUSTOMER_REF
o START_DATE
o PAYMENT_METHOD_NAME
o PRIMARY_FLAG
o ORIG_SYSTEM_ADDRESS_REF
3. RUN the Import Program
Run Import after AR Customer Interface tables have been populated
Program will validate the data in the interface table before creating records in Receivables
Run the Customer Interface process through the Submit Request window
But, a separate navigational path is also provided
Interfaces -> Customer
Check output file for errors

Make corrections and repeat import process
Not Surprise , if you get these....Common Errors..very common
a3: Bill_To_Orig_Address_Ref is not a valid bill-to address
o Verify the Bill-To address reference is valid. Keep in mind that when using the bill-
to reference with a ship-to address record... the bill-to must already exist in
Receivables.
o Note: Ran into this issue. Try running bill-to records through the interface first and
ship-to records as second batch - this will resolve the error. Do not Interface with
both in the same batch.
a1:Customer record for insert must have validated profile record defined
o New customers and each Bill-To record must have a customer level profile in the
RA_CUSTOMER_PROFILES_INT_ALL table.
a8: Conflicting profile classes specified for this customer/site
o Profile classes for customer and bill-to must be the same. Sites cannot have a profile
class different from the customer.
J1: Site_USE_CODE is not updateable.
J3: LOCATION is not updateable.
J2: PRIMARY_SITE_USE_FLAG is not updateable.
o Keep in mind that site_use_code, primary_use_flag, and location may not be
updateable through the Customer Interface
A3: Customer reference for insert is already defined.
A5: Customer Number already assigned to a different customer.
o Customer reference and Customer number are values that must be unique. Verify the
customer reference or customer number does not already exist for another customer.
Tips and Technique
1. Check out some of the Profile Options hitting Customer Import
HZ: Generate Party Number
o This the profile option can be updated at Site, Application, Responsibility and User
levels.This profile option determines whether party number should be auto-
generated. If value is 'No',means party number must be passed in by the user else if
'Yes' or if the value is not set, party number will be auto-generated.
HZ: Generate Party Site Number
o same as above for party site number set at all leval.
HZ: Internal Party
o This profile option is used as a part of CRM setup. This must be set if CRM is
installed. It is used for data migration purpose.
HZ: Generate Contact Number
o This profile option determines whether contact number should be auto-generated.If
the value is 'No', contact number must be passed in by the user. If the value is 'Yes' or
if the value is not set, contact number will be auto-generated.
2. Automatic sequence number for customer number
Many times AR department is not like oracle seeded number which start by default 1000.Options are
there:
From R11 and 11i, you cannot change the sequence via the forms and therefore any change that you
make to the sequence would have to be
through SQLPlus and that would not be supported.
To set the sequence number
Step 1. In the Application Developer responsibility,
Menu: Application=>Database=>Sequence
Step 2. Query on sequence RA_CUSTOMERS_NUM_S
This will bring up the sequence for the customer numbers and you can enter the number that you want
it to start from.
To set automatic numbering for customer after setting the sequence:
Step 1. Menu:=>System=>System Options
Step 2. Region - Invoicing and Customers
Step 3. Check the box for Automatic Customer Numbering.
3. When doing Migration from other system, adviced to use TRIM Function
When loading interface tables remove all trailing spaces from import data.
Example: LTRIM(RTRIM(customer_name))
4.If importing large number of customers, run in smaller batches instead of all at once.
Oracle benchmark is about 10,000 records per batch is ideal, it is suggested to keep the batch size
small.
5.When rolling out in Multi-Org , then you must populate the org_IDs in the interface tables and
run the customer interface for each organization set-up responsiblity.
The New Model called " LEA(Legal Entity Architecture)"
Legal Entity architecture, which is new in this release, provides users with the ability to model an
enterprises legal organizational structure and define rules and attributes specific to legal entities.
Bank Account whether its is remittance bank or internal bank is now owned by the Legal Entity instead
of Operating Unit, and can be used by any of the Operating Units sharing the same Ledger as that
Legal Entity.

As marked (dotted red line) in above figure the relationship between legal Entity and Operating Unit is
no more active. This concept allows Operating Units to be governed by more than one jurisdiction, but
the accounting is still performed in a single ledger.
Multiple Legal Entities can be associated with a single Ledger, allowing the LEs to share the same
ledger and chart of accounts, calendar and currency. Each LE points to one Ledger.
Multiple Operating Units can also be associated with a single Ledger. Each OU points to only on
Ledger.
Thanks to David, who pointed out last week regarding Bank Uptake in LE side in reference to my old
post. Check his post for further information.
Take a note; in R12 EBS multiple legal entities can be associated with a single Ledger, allowing the
LEs to share the same ledger and chart of accounts, calendar and currency. Each LE points to one
Ledger. Multiple Operating Units can also be associated with a single Ledger. Each OU points to only
on Ledger.
Where it affects:
"Most of the Financial Application Products"
Cash Management (Bank)
As discussed in earlier, in Release 12 Bank Accounts are owned by Legal Entities and can be accessed
by multiple Operating Units.
As we know in 11i the Bank Accounts were Operating Unit Specific.
For all Internal Banks should be assigned to a Legal Entity.
Receivables:
Now all REC activity must have a legal owner, so Legal Entity is stamped on every transaction.
Receivables activity such as transaction whether credit memo or debit memo or invoice must have
stamps on it and receipt header with the Legal Entity information.
Because there can be multiple legal entities using the same ledger, it may be necessary for the user to
assign the LE. Each transaction can only belong to one Legal Entity, so when multiple legal entities
exist, either the system or the user will assign the LE.
Transaction
The defaulting hierarchy for a transaction comes from the setup of the Transaction Type and
Transaction Batch Source. Receivables will look first to the Transaction type. If a LE has not been
assigned, then Receivables will look to the Batch Source. The assignment of the LE to the Transaction
Type and Transaction Batch Source is option, so if Receivables cannot find a default LE, then it is up
to the user to provide the LE value.
Receipts
The LE defaulting for receipts works differently than transactions.
Lets look at how defaulting occurs for the Receipt Header.
As we know , internal Bank Accounts is not owned by legal entities instead of operating units, so LE
defaults from internal (remittance) bank account.
The Receipt Method in Receivables has the bank account assignment, which determines what bank
account gets assigned to the receipt.
Take a note in version 11 the receipt Method was called the Payment Method. Now in Release 12 this
featured with same name Payment Method now used by new application called Oracle
Payments. Therefore in AR, you will now see a Receipt Method, which is part of receipt setup; and
Payment Method, which is part of Payments setup.Once the bank account is assigned to a receipt
header, this information can be used to find the appropriate LE.Because the LE comes from only one
source, the bank account, there is no special setup to be performed in Receivables.Defaulting of the
single LE always occurs, so the user does not need to assign or update LE on receipts.
How LE affects receipts and there applications and refunds
We seen the receipts inherit the LE from the bank account weather its is manual, Automatic, Lockbox
and Post Quick Cash Programs.There is no way that user can change the value.
Receipt application across Legal Entities is allowed if the receipt and transactions are in same OU and
Sub Ledgers Accounting will performed by inter-company accounting for cross-LE receipt applications
or cross-LE receipt clearing.
SLA will create inter-company accounting as long as LE is setup as one of the CCID (Account Code
Combination) segment derivation sources in SLA.
Payable
Invoices and Payments indicate the operating unit and the legal entity owner of the transaction. The
legal entity can be used as selection criteria when preparing pay runs.
Projects
As we know in 11i in EBS maintains the default legal context on the Operating Unit. There is not much
impact in Projects model. Earlier in 11i we used to consider the Legal Entity of the Operating Unit as
the Legal Entity of the Projects Transactions. Now the Legal Entity attached at the Default Legal
Context of the Operating Unit is the Legal Entity of the Projects Transactions.
So the Legal Entity of the Projects expenditure transactions will be the Legal Entity attached at the
Default Legal Context of the Expenditure Operating Unit and the Legal Entity of the Project will be the
Legal Entity attached at the Default Legal Context of the Project owning operating unit.
LE and TCA
Legal Entity is still dependent on TCA. A party (supplier, customer, bank, student etc) is an entity that
can enter into business relationships. As we know the Oracle TCA's model supports four types of
parties: organization, person, group, and party relationship. Under the TCA model, Parties (including
Legal Entities) exist just once in our E-business Suite system for single maintenance and consistency.
Legal Entities will be stored in TCA as Parties of party type 'ORGANIZATION'. A Legal Profile,
containing specific Legal Entity attributes, will be associated to the TCA Party. In addition, other TCA
components will be used for Addresses, Contacts, Party Information, etc.
Where to do the setup
There should be no confusion.
May be , some may think if this is just extension of GRE/LE from old version , then Why this required
to do set up from both ASM and HR in R12?
In R12 ,it is separate the legal entity from the GRE which is a HR organization. We did not link the 2
entities together as they serve 2 different purposes altogether.
The HR model does not look at the new Legal Entity model. It continues to use the GRE/LE as a legal
entity. So the HR requirement can be achieved using the HR organization of type GRE/LE.
Therefore, Legal Entities do have to be set up in both ASM and HR in R12.
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
o Reconciliation option defined at Bank Account level
o 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 Name
po_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 Name
po_vendor_sites_all.bank_account_name =>
ap_bank_accounts_all.bank_account_name
Bank Account Number
po_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.