Deep Drive : Customer Interface in ARPosted 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 meanso The HZ tableso 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 changedo RA_CUSTOMERSo RA_ADDRESSES o RA_SITE_USESo RA_PHONESo RA_CONTACTSo AR_CUSTOMER_PROFILESo RA_CUSTOMER_RELATIONSHIPSo AR_CUSTOMER_PROFILE_AMOUNTS

Tables that remain the sameo RA_CUST_RECEIPT_METHODSo AP_BANK_BRANCHESo AP_BANK_ACCOUNTSo 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 Setso AutoInvoice Grouping Ruleso Collectorso Customer Addresseso Customer Bank Informationo Customer Exemptionso Customer Profile Classeso Demand Classeso Dunning Letter Setso Freight Carrierso Payment Methods

o Payment Termso Statement Cycleso Tax Codes

Be sure to also set up Lookups in Receivables that the Customer Interface should import. These are the lookups:

o Countrieso Site Use Codeso Credit Ratingso Risk Codeso Account Statuseso Communication Typeso Customer Classes

2. Next is to map the Interface Tables

RA_CUSTOMER_INTERFACE_ALLo ORIG_SYSTEM_CUSTOMER_REFo CUSTOMER_NAMEo CUSTOMER_STATUSo INSERT_UPDATE_FLAGo CUSTOMER_NUMBER o ORIG_SYSTEM_ADDRESS_REFo PRIMARY_SITE_USE_FLAGo SITE_USE_CODEo ADDRESS1o COUNTRY o LOCATION

RA_CUSTOMER_PROFILES_INT_ALLo CUSTOMER_PROFILE_CLASS_NAMEo ORIG_SYSTEM_CUSTOMER_REFo INSERT_UPDATE_FLAGo CREDIT_HOLDo ORIG_SYSTEM_ADDRESS_REF

RA_CONTACT_PHONES_INT_ALL o ORIG_SYSTEM_CUSTOMER_REFo ORIG_SYSTEM_TELEPHONE_REFo TELEPHONEo TELEPHONE_TYPEo INSERT_UPDATE_FLAGo ORIG_SYSTEM_ADDRESS_REFo ORIG_SYSTEM_CONTACT_REFo CONTACT_LAST_NAME

RA_BANKS_INTERFACEo ORIG_SYSTEM_CUSTOMER_REFo PRIMARY_FLAGo START_DATEo BANK_ACCOUNT_NAMEo BANK_ACCOUNT_CURRENCY_CODEo BANK_ACCOUNT_NUMo BANK_BRANCH_NAMEo ORIG_SYSTEM_ADDRESS_REF

RA_CUST_PAY_METHOD_INTERFACEo ORIG_SYSTEM_CUSTOMER_REFo START_DATEo PAYMENT_METHOD_NAMEo 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 addresso 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/siteo 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 Numbero 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 Numbero same as above for party site number set at all leval.

HZ: Internal Partyo 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 bethrough SQLPlus and that would not be supported.

To set the sequence number

Step 1. In the Application Developer responsibility,Menu: Application=>Database=>SequenceStep 2. Query on sequence RA_CUSTOMERS_NUM_SThis 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 OptionsStep 2. Region - Invoicing and CustomersStep 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 enterprise’s 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.

Let’s 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 levelo More flexibility and control

Take a looks of some of the releases

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

Bank Namepo_vendor_sites.bank_number => ap_bank_branches.bank_namepo_vendor_sites.bank_number => ap_bank_branches.bank_number

Bank Numberpo_vendor_sites.bank_num => ap_bank_branches.bank_numpo_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 attributes2. 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 AccountsIn 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.