The generic Customer business object contains values that correspond to a customer record or object in an application. The values include accounting, address, bank, billing, credit, foreign trade, organization, profile, sales order, shipping, and tax data.
IBM defines a customer as any business partner with whom a company maintains at least relationship number 1 and possibly one or more of relationships 2 - 4:
Relationship | Description |
---|---|
1 | Sells products or services to the business partner |
2 | Ships products to the business partner |
3 | Bills the business partner for products or services |
4 | Receives payment from a business partner for products or services |
IBM further defines a Customer as the entity that exists at the highest level of the company's customer hierarchy, the customer that is referenced in Sales Order Processing. This high-level customer is often referred to as the "SoldTo" Customer.
In most applications, the SoldTo customer can fulfill all of these relationships. However, if a customer record or object fulfills only relationships 2-4, IBM does not represent the record as a Customer business object. Instead, it represents such a record as the generic CustomerPartner business object.
CustomerPartner represents an entity that is related to the SoldTo customer. The entity can be another customer object (such as a ShipTo or BillTo) or it can be an associated address (such as Billing or Shipping). The IBM Customer business object template contains a reference to each of its related CustomerPartner business objects.
Note: Each Customer business object has only one address, which is the SoldTo address. All other addresses (such as shipping or billing) must be represented as CustomerPartner business objects.
Applications store customer relationship information in one of two ways:
Some Customer Interaction Management (CIM) or Enterprise Resource Planning (ERP) applications store a customer's address data as dependent records. In other words, the addresses do not exist independently of the customer data and can be accessed only through their parent customer object. These addresses are not used by more than one SoldTo customer.
When working with these applications in IBM WebSphere Business Integration Server Express Plus, each address is represented as a CustomerPartner business object. Because the address is dependent upon the Customer, it is created only after the parent SoldTo customer is created. Synchronization occurs as a multi-step process in which IBM WebSphere Business Integration Server Express Plus:
Examples of applications that store the information in this way are Baan, Oracle, Vantive, and Trilogy.
Some CIM and ERP applications store customer data in a hierarchy of independent objects. The customer role at the top of the hierarchy represents the customer with whom an order can be placed. This SoldTo customer links to other customer objects through roles. These roles consist of, but are not limited to, ShipTo, BillTo, and Payer.
Figure 1 illustrates a typical SoldTo customer with its relationship to other customer objects.
In these applications, the subordinate customer objects can be associated with more than one SoldTo customer and can be created before the SoldTo customer is created. Because the SoldTo customer stores the links to its related customers, the subordinate customers must exist before the SoldTo customer can contain the links to them.
When working with these applications in IBM WebSphere Business Integration Server Express Plus, each subordinate customer is represented as a CustomerPartner business object. Synchronization occurs as a multi-step process in which IBM WebSphere Business Integration Server Express Plus:
Note: IBM has designed the Customer and CustomerPartner business objects so that the relationship between a SoldTo customer and its subordinate customer or address is always stored in the parent object (that is, the Customer business object references the CustomerPartner business object). Applications that store the relationship in the child object must be configured to trigger an application-specific business object that maps to the Customer business object.
Examples of applications that store information this way are SAP, PeopleSoft, and Clarify.
Because sales orders must reference a SoldTo customer and billing documents are sent only to customers who play a BillTo role, IBM categorizes every Customer and CustomerPartner business object by type. The type represents the way the customer or address is defined in the application.
To allow an application to handle each customer type in its own way, the generic Customer business object allows only one type for each Customer and CustomerPartner business object. This type is stored as an attribute (CustomerType or PartnerType).
Due to the way IBM has defined a customer, the value of CustomerType on the Customer business object is typically SoldTo and the value of PartnerType on the CustomerPartner object can be any other type (such as ShipTo, BillTo, Payer, Postal, or Delivery). Therefore, a customer can be a ShipTo customer or a BillTo customer, but not both.
Note: The value of the CustomerType or PartnerType attribute cannot be changed after the customer data has been created in a destination application. However, for those applications that support role functions, Customer and CustomerPartner allow a customer object to assume additional (non-SoldTo) roles.
Some applications allow customer objects to serve as more than one type by using what is known as the "RoleFunction". For example, a SoldTo customer might reference itself so that it can also act as the ShipTo and BillTo customer. Such an application would create the object as a SoldTo customer that references itself as the BillTo and ShipTo.
In this example, the CustomerType would be SoldTo, and the Customer business object would have two RoleFunctions, ShipTo and BillTo. The role functions are stored in Customer's RoleUsage child business object. CustomerPartner also contains a RoleUsage child business object, which allows a subordinate customer or address to have more than one function.
For more information on application-specific business objects, refer to the specific application business object's reference page.
Note: A SoldTo usually can not serve as a customer role for another SoldTo. Therefore, even applications that allow this relationship may require configuration to represent a SoldTo as the BillTo for another SoldTo.
In summary, Type indicates the kind of customer and Function indicates the kind of roles it plays.
In some applications, each customer object is associated with multiple organizations. For example, a company might sell to Customer X from both its US and European sales organizations.
Applications that store multiple organizations for each customer can store all general customer information at the top level and organization-specific information at a subordinate level. Figure 2 illustrates such an organizational hierarchy.
Figure 2. Customer with multiple organizations
Because the generic Customer business object contains data for only one organization per customer, each extension of a customer into an organization requires separate instances of the Customer business object.
For example, given the organizations illustrated for Customer X, synchronizing data for both sales organizations would involve the following steps in IBM WebSphere Business Integration Server Express Plus:
Therefore, if the source application represents customer data with multiple organizations, the source adapter must create an event for each unique organization's data.
If you are synchronizing from a source application that stores multiple organizations to a destination application that stores a single organization, you have the following implementation options:
This version of the generic Customer business object contains additional attributes and several additional child business objects, providing the opportunity to synchronize more customer information. Use this version of Customer when you want to synchronize data provided in these additional business objects:
Because this version of Customer also contains separate child business objects for Sales Order, Billing, and Shipping data, it provides additional attributes for synchronizing information in these areas.
To use this version of Customer, you must install and use the CustomerSync Collaboration Template instead of the Customer Manager Collaboration template.
Customer is a hierarchical business object. Figure 3 illustrates its child business objects.
Figure 3. Child business objects
Customer contains information about the SoldTo customer, which is considered the primary customer in most applications. It contains such information as the customer's name, number as used in the application, type, language, organization, person who opened the account, and status. Customer contains the following child business objects:
Child business object | Description | Cardinality |
---|---|---|
CustomerAddress | Contains the address information for the SoldTo Customer. CustomerAddress contains PhoneInfo and RoleUsage. | 1 |
PhoneInfo | Contains phone information for the SoldTo customer. | n |
RoleUsage |
|
n |
RelatedCustomerRef | Contains the reference to any associated customer partners or addresses that are linked to the SoldTo customer. RelatedCustomerRef contains RoleUsage. Note: This object contains only the reference to the associated entity and not the values for the entity. | n |
CustomerInformation |
Contains all the child business objects that represent customer information:
|
1 |
CreditAreaCreditData | A child of CustomerCreditData: contains credit data for the SoldTo customer for specific credit areas (such as when the European credit area has different information from the USA credit area). Attributes include the credit control area (which is an organization that checks credit for a customer), credit limit, currency code for the credit limit, risk category for a credit check, credit representative group for credit management, the employee responsible for handling credit-related activities, credit insurance data (such as the limit that has been insured with credit insurance and the credit insurance company), a flag that indicates whether the customer is exempt from Credit hold or Credit block, and Dun & Bradstreet and TRW ratings. | n |
CustomerAccountingData | A child of CustomerInformation: contains Accounts Receivable data for the SoldTo customer. | 1 |
CustomerBankData | A child of CustomerInformation: contains such banking data for the SoldTo customer as the bank's country and number, the bank account number and type, and a flag that indicates whether there is collection authorization. | n |
CustomerBillingData | A child of CustomerInformation: contains such billing data for the SoldTo customer as freight terms, payment terms and method, and billing schedule. | 1 |
CustomerCreditData | A child of CustomerInformation: contains such credit data for the SoldTo customer as the credit limit, the maximum credit limit in any credit control area, and the currency code for the credit limit. CustomerCreditData contains CreditAreaCreditData. | 1 |
CustomerForeignTradeData | A child of CustomerInformation: contains such Export Control information about the SoldTo customer as flags that indicate if the customer is on the Table of Denials list or on the Specially Designated Nationals list (lists of countries with which the USA should not trade) and the last date that the customer was checked against these lists; and a flag that indicates if the customer appears on your company's boycott list and the date that the customer was checked against the criteria for this list. | n |
CustomerProfileData | A child of CustomerInformation: contains such marketing data about the SoldTo customer as its total revenue, number of employees, stock symbol, standards organization, web site address, type of ownership (for example, Public or Private), and industry. | 1 |
CustomerSalesOrderData | A child of CustomerInformation: contains such sales and pricing data about the SoldTo customer as its sales office and sales group, the identifier of the sales person responsible for this customer, the customer group (usually used for business rules or future processing), the price group and identifier of the price list, currency code, and the minimum and maximum order values allowed the customer. This data is often used as the default information on a sales order. | 1 |
CustomerShippingData | A child of CustomerInformation: contains such shipping data about the SoldTo customer as the shipping carrier, preferred delivery option, the number of deliveries allowed for a line item, and flags that indicate whether order line items can be split into multiple shipments, whether the customer allows back orders, and whether incomplete orders can be shipped. | 1 |
CustomerTaxData | A child of CustomerInformation: contains such tax data for the SoldTo customer as its tax identifier, code, and jurisdiction and a flag that indicates whether the customer requires a 1099 form. CustomerTaxData contains CustomerTaxExemptLicenseData. | 1 |
CustomerTaxExemptLicenseData | A child of CustomerTaxData: contains the exemption licenses for the SoldTo customer. | n |
Notes | A child of CustomerInformation: contains notes for the SoldTo customer. Examples are Shipping instructions and Billing instructions. | n |
The generic Customer business object supports the following verbs:
For a listing of the generic Customer business object's attributes, use System Manager or Process Designer Express.