Wednesday, October 13, 2010

Deep Drive: Customer Interface in AR



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
    • The HZ tables
    • 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
    • RA_CUSTOMERS
    • RA_ADDRESSES
    • RA_SITE_USES
    • RA_PHONES
    • RA_CONTACTS
    • AR_CUSTOMER_PROFILES
    • RA_CUSTOMER_RELATIONSHIPS
    • AR_CUSTOMER_PROFILE_AMOUNTS
  • Tables that remain the same
    • RA_CUST_RECEIPT_METHODS
    • AP_BANK_BRANCHES
    • AP_BANK_ACCOUNTS
    • 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:
    • AutoCash Rule Sets
    • AutoInvoice Grouping Rules
    • Collectors
    • Customer Addresses
    • Customer Bank Information
    • Customer Exemptions
    • Customer Profile Classes
    • Demand Classes
    • Dunning Letter Sets
    • Freight Carriers
    • Payment Methods
    • Payment Terms
    • Statement Cycles
    • Tax Codes
  • Be sure to also set up Lookups in Receivables that the Customer Interface should import. These are the lookups:
    • Countries
    • Site Use Codes
    • Credit Ratings
    • Risk Codes
    • Account Statuses
    • Communication Types
    • 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
    • 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.
    • 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
    • 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
    • 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.
    • 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.
    • 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
    • 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
    • same as above for party site number set at all leval.
  • HZ: Internal Party
    • 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
    • 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_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 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.

“Party” is an entity in the Trading Community Model that can enter into business relationships. A party is a real person, organization, branch,subsidiary, legal entity, holding company, etc. The attributes of a party are universal. In other words, they are independent of your selling (or ultimately buying) relationship with the party.
“Account” refers to the details of the deploying company’s selling relationship with a particular customer.
Account – the attributes of the selling relationship between the company deploying Oracle Applications and a party. Account attributes do not describe a
party; they only exist when a selling relationship is present between the deploying company and the party.
More over you should note that: An account is created for a party not for a party site. The selling relationship is not with a location but with the party that is using that location.
An Account cannot be created without a Party.
Account Site – a party site that is used within the context of an account; e.g., for billing or shipping purposes.
You need to have 2 tables:
1) HZ_CUST_ACCOUNTS
The HZ_CUST_ACCOUNTS table stores information about customer relationships established with a party. When a party becomes a customer, information about the customer account is stored in this table. Since a party can have multiple customer accounts, this table may contain several records for a single party. For example, an individual person may establish a personal account, a family account, and a professional account for a consulting practice. Note that the focus of this table is a business relationship and how transactions are conducted in the relationship. The primary key for this table is CUST_ACCOUNT_ID.
A single PARTY_ID is stored on this table to designate the customer account owner.
Each customer account may have only one owner (although other parties may be associated to the customer account via the HZ_CUST_ACCOUNT_ROLES table).
2)HZ_CUST_ACCT_RELATE_ALL
HZ_CUST_ACCT_RELATE_ALL stores information about relationships between customer accounts. A flag allows you to indicate whether a relationship is reciprocal. Note that columns also exist to reflect if the account relationship exist to enable shipping or billing to other accounts.

In real business world, these are approch normally we take:
1.Party Centric Approach : where each custmer is traeted as Party.
2.Site Centric Approach
Here are the screen snapshots how it looks:
1.Party Centric Approach



I have done setup for three account, account#1,#2,#3
2.Site Centric Approach

This can be best understood as customer Number 10009831-10009832-10009834

select party_id, party_number,party_name from hz_parties where party_name=’PAULINE’

Means we have 4 party created
Case 1: 3 party as 3 customer name with 3 different account
Case 2: 1 party as 1 Customer name with 3 site , each site pointing to one account.
Case 2, is more popular in industry. Typical Healthcare , uses case 2.
select * from HZ_CUST_ACCOUNTS where party_id in (select party_id from hz_parties where party_name=’PAULINE’)



These are the error message , sharing for the rest of people who seek some information.
These are the message codes and their meaning:
A1 –> The customer reference for update does not exist in RA_CUSTOMERS
A2 –> The address reference for update does not exist in RA_ADDRESSES
A3 –> Customer reference for insert is already defined in RA_CUSTOMERS
A4 –> Site use for this address reference already exists in the database
A5 –> Customer Number already assigned to a different customer
B1 –> ORIG_SYSTEM_ADDRESS_REF is mandatory when specifying an address
B2 –> ADDRESS1 is mandatory when specifying an address
B3 –> COUNTRY is mandatory when specifying an address
B4 –> SITE_USE_CODE is mandatory when inserting an address
B5 –> PRIMARY_SITE_USE_FLAG is mandatory when inserting an address
B6 –> CUSTOMER_CLASS_CODE is not defined in AR_LOOKUPS
B7 –> CUSTOMER_PROFILE_CLASS_NAME has an invalid value
B8 –> STATE is not defined in AR_LOCATION_VALUES
B9 –> COUNTRY is not defined in fnd_territories
B0 –> SITE_USE_CODE is not defined in AR_LOOKUPS
C1 –> This customer reference has two different customer names defined
C2 –> This customer reference has two different customer numbers defined
C3 –> This customer reference has two different parent customer references
C5 –> Customer reference has two different customer class codes defined
C6 –> This customer reference has two identical primary site uses defined
D1 –> Address reference has two different ADDRESS1 values
D2 –> Address reference has two different ADDRESS2 values
D3 –> Address reference has two different ADDRESS3 values
D4 –> Address reference has two different ADDRESS4 values
D5 –> Address reference has two different cities
D6 –> Address reference has two different postal codes
D7 –> Address reference has two different states
D8 –> Address reference has two different provinces
D9 –> Address reference has two different counties
D0 –> Address reference has two different countries
E1 –> Address reference has two identical site use codes
E2 –> Address reference has two different customers
F1 –> ORIG_SYSTEM_TELEPHONE_REF mandatory for telephone information
F2 –> TELEPHONE is mandatory when specifying telephone information
F3 –> TELEPHONE_TYPE is mandatory when specifying telephone information
F4 –> TELEPHONE_TYPE is not defined in AR_LOOKUPS
F5 –> Telephone reference for insert is already defined in RA_PHONES
F6 –> Telephone reference for update does not exist in RA_PHONES
G1 –> ORIG_SYSTEM_CONTACT_REF mandatory for contact information
G2 –> LAST_NAME is mandatory when specifying a contact
G3 –> CONTACT_TITLE is not defined in AR_LOOKUPS
G4 –> Contact reference for insert is already defined in RA_CONTACTS
G5 –> Contact reference for update is not defined in RA_CONTACTS
G6 –> The address reference specified is not defined for this customer
G7 –> CONTACT_JOB_TITLE must be defined in AR_LOOKUPS
H1 –> Contact reference has two different first names
H2 –> Contact reference has two different last names
H3 –> Contact reference has two different titles
H4 –> Contact reference has two different job titles
H5 –> Contact reference has two different customers
H6 –> Contact reference has two different addresses
I1 –> Telephone reference has two different phone numbers
I2 –> Telephone reference has multiple extensions
I3 –> Telephone reference has two different types
I4 –> Telephone reference has two different area codes
I6 –> Telephone reference has two different customers
I7 –> Telephone reference has two different addresses
J1 –> SITE_USE_CODE is not updateable
J2 –> PRIMARY_SITE_USE_FLAG is not updateable
J3 –> LOCATION is not updateable
J4 –> CUSTOMER_TYPE is not defined in AR_LOOKUPS
J5 –> PRIMARY_SITE_USE_FLAG has an invalid value
J6 –> CUSTOMER_NUMBER must be null when auto-numbering is set to “Yes”
J7 –> CUSTOMER_NUMBER is mandatory when auto-numbering is set to “No”
J8 –> INSERT_UPDATE_FLAG has an invalid value
J9 –> CUSTOMER_STATUS must have a value of ‘A’ or ‘I’
K1 –> Concurrent request failed
K3 –> This customer reference has two different customer types defined
L1 –> COLLECTOR_NAME is mandatory when no profile class specified
L2 –> TOLERANCE is mandatory when no profile class specified
L3 –> DISCOUNT_TERMS is mandatory when no profile class specified
L4 –> DUNNING_LETTERS is mandatory when no profile class specified
L5 –> INTEREST_CHARGES is mandatory when no profile class specified
L6 –> STATEMENTS is mandatory when no profile class specified
L7 –> CREDIT_BALANCE_STATEMENTS mandatory when no profile class specified
L9 –> DUNNING_LETTER_SET_NAME is mandatory when DUNNING_LETTERS is “Yes”
L0 –> CHARGE_ON_FINANCE_CHARGE_FLAG mandatory when INTEREST_CHARGES is “Yes”
M1 –> INTEREST_PERIOD_DAYS is mandatory when INTEREST_CHARGES is “Yes”
M3 –> COLLECTOR_NAME has an invalid value
M4 –> CREDIT_CHECKING has an invalid value
M5 –> TOLERANCE has an invalid value
M6 –> DISCOUNT_TERMS has an invalid value
M7 –> DUNNING_LETTERS has an invalid value
M8 –> INTEREST_CHARGES has an invalid value
M9 –> STATEMENTS has an invalid value
M0 –> CREDIT_BALANCE_STATEMENTS has an invalid value
N1 –> CREDIT_HOLD has an invalid value
N2 –> CREDIT_RATING has an invalid value
N3 –> RISK_CODE has an invalid value
N4 –> STANDARD_TERM_NAME which contains the payment terms has an invalid value
N5 –> OVERRIDE_TERMS has an invalid value
N6 –> DUNNING_LETTER_SET_NAME has an invalid value
N7 –> STATEMENT_CYCLE_NAME has an invalid value
N8 –> ACCOUNT_STATUS has an invalid value
N9 –> PERCENT_COLLECTABLE has an invalid value
N0 –> AUTOCASH_HIERARCHY_NAME which contains the AutoCash rule has
an invalid value
O1 –> STATEMENT_CYCLE_NAME is mandatory when STATEMENTS is “Yes”
O2 –> LOCATION must be null when auto-numbering is set to “Yes”
O3 –> LOCATION is mandatory when auto-numbering is set to “No”
O4 –> CREDIT_CHECKING is mandatory when profile class is null
O5 –> CHARGE_ON_FINANCE_CHARGE_FLAG must be null if INTEREST_CHARGES is No
O6 –> INTEREST_PERIOD_DAYS must be null if INTEREST_CHARGES is “No”
O7 –> INTEREST_PERIOD_DAYS must be greater than zero
P1 –> Postal Code is not in the defined range of system options
Q1 –> A new location was created for a value in an address segment field
Q2 –> Validation failed for the key location flexfield structure
R1 –> CUST_SHIP_VIA_CODE is not defined in ORG_FREIGHT
R2 –> CUSTOMER_CATEGORY_CODE is not defined in AR_LOOKUPS
R3 –> CUSTOMER_CATEGORY_CODE is not enabled in AR_LOOKUPS
R4 –> CUST_TAX_CODE is not defined in AR_VAT_TAX
R5 –> CUST_TAX_REFERENCE cannot be null when CUST_TAX_CODE is ‘EXEMPT’
R6 –> SITE_USE_TAX_CODE is not defined in AR_VAT_TAX
R7 –> SITE_USE_TAX_REFERENCE is required when SITE_USE_TAX_CODE is ‘EXEMPT’
R8 –> Invalid demand class code.
R9 –> SITE_SHIP_VIA_CODE not defined in ORG_FREIGHT
S1 –> The customer reference specified is invalid
S2 –> The address reference specified is invalid
S3 –> The address reference specified is not valid for this customer
S4 –> Payment Method is not defined in AR_RECEIPT_METHODS
S5 –> A bank account does not exist for the specified customer
S6 –> The end date specified cannot be before the start date
S7 –> The address specified must have an active BILL_TO site defined
T1 –> Customer payment method already active between the dates specified
T2 –> Customer site payment method already active between the dates specified
T3 –> Customer already has a primary payment method for specified dates
T4 –> Customer site has a primary payment method on the dates specified
T5 –> This customer payment method is already active in this date range
T6 –> Multiple primary payment methods defined
V2 –> The bank account specified must be of type ‘EXTERNAL’
V3 –> Customer bank account is already active between the dates specified
V4 –> Customer site bank account already active between these dates
V5 –> This customer already has primary bank account for specified dates
V6 –> Customer site can have only 1 primary bank account for the dates
specified
V7 –> Duplicate rows exist in Interface table for this Customer Bank and
date run
V8 –> Duplicate primary customer banks defined within the interface table
W1 –> BANK_NAME is mandatory when creating a new bank account
W2 –> BANK_BRANCH_NAME is mandatory when creating a new bank account
W3 –> BANK_ACCOUNT_CURRENCY_CODE is mandatory creating a new bank account
W4 –> BANK_ACCOUNT_CURRENCY_CODE is not defined in FND_CURRENCIES
W5 –> Bank number already exists.
W6 –> Duplicate bank number in interface table.
W7 –> Primary flag should be ‘Y’ or ‘N’.
W8 –> Duplicate bank and branch name in interface table.
W9 –> Duplicate Location
W0 –> Bank and branch name already exists.
X1 –> AUTO_REC_INCL_DISPUTED_FLAG mandatory when profile class is null
X2 –> TAX_PRINTING_OPTION is mandatory when no profile class specified
X3 –> GROUPING_RULE_NAME is mandatory when no profile class is specified
X4 –> CHARGE_ON_FINANCE_CHARGES_FLAG has an invalid value
X5 –> GROUPING_RULE_NAME has an invalid value
X6 –> CURRENCY_CODE has an invalid value
X7 –> CREDIT_BALANCE_STATEMENTS is mandatory when STATEMENTS is “Yes”
X8 –> CREDIT_BALANCE_STATEMENTS must be “No” when STATEMENTS is “No”
X9 –> STATEMENT_CYCLE_NAME must be null when STATEMENTS is “No”
X0 –> OVERRIDE_TERMS is mandatory when no profile class is specified
Y1 –> PARTY_NUMBER must be null when auto-numbering is set
Y2 –> PARTY_NUMBER is mandatory when auto-numbering is set to “No”
Y3 –> Party Number already assigned to a different party.
Y4 –> This party reference has two different party numbers defined in
RA_CUSTOMERS_INTERFACE.
Y5 –> PERSON_FLAG has an invalid value
Y6 –> Party Site Number already assigned to a different address
Y7 –> Address reference has two different party site numbers defined in
RA_CUSTOMERS_INTERFACE.
Y8 –> PARTY_SITE_NUMBER must be null when auto-numbering is set
Y9 –> PARTY_SITE_NUMBER is mandatory when auto-numbering is set to “No”
Z1 –> CREDIT_BALANCE_STATEMENTS must be null when STATEMENTS is null
Z2 –> STATEMENT_CYCLE_NAME must be null when STATEMENTS is null
Z3 –> CHARGE_ON_FINANCE_CHARGE_FLAG must be null when INTEREST_CHARGES is null
Z4 –> INTEREST_PERIOD_DAYS must be null when INTEREST_CHARGES is null
Z5 –> DISCOUNT_GRACE_DAYS must be null when DISCOUNT_TERMS is null
Z6 –> DISCOUNT_GRACE_DAYS must positive
Z7 –> DISCOUNT_GRACE_DAYS must be null when DISCOUNT_TERMS is “No”
Z8 –> DUNNING_LETTER_SET_NAME must be null when DUNNING_LETTERS is “No”
Z9 –> DUNNING_LETTER_SET_NAME must be null when DUNNING_LETTERS is null
Z0 –> CURRENCY_CODE is mandatory when a profile amount value is populated
a1 –> Customer record for insert must have validated profile record defined
a2 –> TAX_PRINTING_OPTION has an invalid value
a3 –> The customer profile for this customer reference already exists
a4 –> The customer profile class for update does not exist
a7 –> Duplicate record within the interface table
a8 –> Conflicting profile classes specified for this customer/site
b1 –> Both TRX_CREDIT_LIMIT and OVERALL_CREDIT_LIMIT must be populated
b2 –> TRX_CREDIT_LIMIT may not be greater than the OVERALL_CREDIT_LIMIT
b3 –> DUNNING_LETTER_SET_NAME must have a unique value
b4 –> COLLECTOR_NAME must have a unique value
b5 –> STANDARD_TERM_NAME must have a unique value
b6 –> STATEMENT_CYCLE_NAME must have a unique value
b7 –> BANK_ACCOUNT_NUM is mandatory when creating a new bank account
b8 –> AUTO_REC_INCL_DISPUTE_FLAG has an invalid value
b9 –> PAYMENT_GRACE_DAYS must be a positive value
e2 –> Bill_to_orig_address_ref should only be defined for Ship-to Addresses
e3 –> Bill_to_orig_address_ref is not a valid bill-to address
f1 –> You may have only one active Dunning site use for each customer
f2 –> For each customer, you may only have one active “Statements” type
f3 –> For each customer, you may only have one active Legal site
f4 –> Clearing Days must be greater than or equal to zero
f5 –> Address language is not installed
f6 –> Address reference has different languages
f7 –> Duplicate telephone reference in table RA_CONTACT_PHONES_INTERFACE
f8 –> A bank and branch with this bank number and branch number already exists
f9 –> Customer Prospect Code must be either CUSTOMER or PROSPECT
g1 –> This customer reference has two different customer prospect codes
u5 –> Contact reference has two different e-mail addresses
w2 –> CREDIT_CLASSIFICATION must have a valid value
w3 –> You cannot update the PARTY_TYPE using Customer Interface.
Please do not specify a value for PARTY_TYPE when the
INSERT_UPDATE_FLAG is set to U.
w4 –> When you create a PERSON party_type, you must provide
PERSON_FIRST_NAME or PERSON_LAST_NAME.
y0 –> CONTACT_JOB_TITLE is not defined
y1 –> PHONE_COUNTRY_CODE is not defined in HZ_PHONE_COUNTRY_CODES
y2 –> This customer is already assigned to a different party
y3 –> This customer is already assigned to a different party
y4 –> LOCKBOX_MATCHING_OPTION must have a valid value
y6 –> TELEPHONE_TYPE cannot be updated from telex to any other type or any
other type to telex.
y7 –> You cannot update this address. A printed, posted, or applied
transaction with an associated tax line exists for this address
y8 –> ADDRESS_CATEGORY_CODE does not exist. Please enter a valid adress
category code or define a new one using the Receivables Lookups
window.
y9 –> ADDRESS_CATEGORY_CODE is not enabled. Please enable this address
category by updating the Enabled flag in the Receivables Lookups window.

No comments:

Post a Comment