Generic Customer Inquiry (Search) API

Generic Customer Inquiry (Search) API

Purpose: Use the generic customer inquiry (search) API in Order Management System to search for a sold-to customer from a remote system. You might use this API to enable a remote system to present customers in list format on its own screens. Also, you can use this API together with the Generic Customer History API to first select a specific customer, and then to request order history for that customer.

How does it work? The basic function of the customer inquiry API is similar to searching for a customer at the Select Customer Sold To Screen in customer maintenance. Your search can include different types of information about the customer, such as Order Management System customer number or alternate customer number, postal code, name, email address, matchcode, or phone number. Unless the customer inquiry request specifies a customer number for an existing customer, the response provides a list of customers in ascending alphanumeric sequence based on the search criteria. For example, if the request is based on last name and first name, the response lists customers in alphanumeric sequence first by last name, and then by first name. The response provides names, addresses, telephone numbers, email addresses, and alternate customer numbers for the customers included in the response.

Subsequent searches: If the initial search request does not include the correct customer record, the remote system can send a follow-up request, continuing the search where the previous response left off. Subsequent searches function similarly to scrolling down at a subsequent search screen in customer maintenance. By sending the information in this way, the process enables the remote system to continue presenting customer information on its own screens as the operator continues the search for the correct customer.

In this chapter:

• Process Overview

- Criterion Hierarchy

- Scanning by Zip or Postal Code

• Customer Search API Setup

• Sample Customer Inquiry Messages

- Search on Alternate Customer Number: Sample Messages

- Search on Zip Code and Last Name with Subsequent Search: Sample Messages

- Search on Existing Customer Number: Sample Messages

- Search on Non-existent Customer Number: Sample Messages

• Inbound Customer Search Message (CWCustomerInqRequest)

• Outbound Customer Search Response (CWCustomerInqResponse)

Process Overview

Overview: The CUST_SRCH process in Working with Integration Layer Processes (IJCT) works as follows:

1. Initial request: The remote system sends the Inbound Customer Search Message (CWCustomerInqRequest), requesting information on customers who match one or more search criteria. For example, the request might specify the Order Management System alternate customer number, which is used as the primary customer number in the remote system.

2. Response: The CUST_SRCH process generates the Outbound Customer Search Response (CWCustomerInqResponse), which provides information on customers in alphanumeric order based on the search criteria. For example, if the search criterion is email address, the response lists customers alphanumerically by email address, starting with the email address specified in the request message.

3. Subsequent request: If the operator on the remote system wants to continue searching, the remote system can send a subsequent search message. In the example using email address, the subsequent message specifies the last customer number provided in the previous response, plus the email address that served as the search criterion for this customer. See below for a discussion.

4. Response: The CST_SRCH generates the subsequent response, which begins with the customer specified in the request it has just received and continues in alphanumeric order based on the search criteria.

The request and response processing can continue as long as necessary to find the correct customer.

Note: See Search on Email Address: Sample Messages for a sample of how a search such as the above would work.

How many customers are listed in the response? The request can specify the maximum number of customer records to include in the response, or use the default of up to 25 customers. Do not request more than 40 customer records at once to insure good performance and to prevent errors that might occur if the maximum message length is exceeded.

Combining search criteria: The CUST_SRCH process evaluates certain search criteria in combination, such as last name and first name, or zip (postal code) and company name. It evaluates other search criteria independently, such as alternate customer number or email address. See Criterion Hierarchy for a listing of all possible criteria the search can use, either alone or in combination.

Using the customer inquiry API: A few things to note:

• Search criteria can be full or partial: It is not necessary for the Inbound Customer Search Message (CWCustomerInqRequest) to specify full and complete information, such as the last name or the email address. The Outbound Customer Search Response (CWCustomerInqResponse) includes customer records that match full or partial search criteria. However, a search on customer sold to number or alternate customer number is an exact match.

• Case not considered: An email address of sbrown@commercialware.com and one of SBROWN@COMMERCIALWARE.COM produce the same search results.

• Ghosts excluded: Customer records whose Ghost flag is selected are excluded from the Outbound Customer Search Response (CWCustomerInqResponse). The exception is when the Inbound Customer Search Message (CWCustomerInqRequest) specifies a ghost customer as the cst_sold_to_nbr; in this situation, the response specifies the duplicate customer merged with the ghost customer record. See Search on Existing Customer Number: Sample Messages for more information.

Formulating subsequent search requests: The response message indicates the information to include in a subsequent search request based on the following information:

• primary_scan_criteria: Indicates the criterion or criteria from the search request that the CUST_SRCH used in selecting customer records for the response message, and how it determined the information to include in the primary_scan_value. For example, if the search was based on telephone number, the primary_scan_criteria is set to Telephone#. In this situation, the subsequent search request should include the telephone_nbr attribute.

• primary_scan_value: Indicates the value that the CUST_SRCH process used to position the customer record in the response. For example, if the primary_scan_criteria is set to Telephone#, the primary_scan_value indicates the particular telephone number that the CUST_SRCH used to position the customer record alphanumerically. In this situation, the subsequent search request should include the phone number from the primary_scan_value for the last customer included in the previous response as the telephone_nbr attribute.

• cst_sold_to_nbr: The customer number identifying the customer. The subsequent search request should include the cst_sold_to_nbr for the last customer included in the previous response as the starting_sold_to_nbr.

Example: The system receives an initial Inbound Customer Search Message (CWCustomerInqRequest) that specifies a zip of 017 and a last_name of B. The first Outbound Customer Search Response (CWCustomerInqResponse) ends with cst_sold_to_nbr 257, whose zip is 01760 and whose last_name is BROWN. The subsequent Inbound Customer Search Message (CWCustomerInqRequest) would then specify a zip of 01760, a last_name of BROWN, and a starting_sold_to_nbr of 257.

For more information: See Search on Zip Code and Last Name with Subsequent Search: Sample Messages for complete sample messages.

If the primary_scan_value is composed of multiple fields, the remote system needs to parse the contents of this attribute in order to formulate the subsequent search request. See Criterion Hierarchy for more information on how the CUST_SRCH process determines the contents of the primary_scan_value.

Special characters: When calculating the length of each field in the primary_scan_value for the purposes of parsing, each special character takes up a single position. For example, if the company_name includes the ampersand character (&), this character is rendered in XML as & but takes up just a single position for the purposes of parsing the primary_scan_value.

Criterion Hierarchy

The possible search criteria, and the resulting primary_scan_criteria and primary_scan_value settings, are described in the following table. The remote system can use these values to generate a subsequent search request, as described above.

This table also indicates the hierarchy in which the CUST_SRCH evaluates search criteria if multiple criteria are included in the search request. For example, if the request includes the cst_sold_to_nbr, the CUST_SRCH process looks for a matching customer, and ignores any additional search criteria included in the request. If the request includes zip, last_name, and company_name, the search is based on zip and last_name. The hierarchy resembles the results of entering multiple criteria at the Select Customer Sold To Screen in customer maintenance.

Criterion/criteria	primary_scan_criteria	primary_scan_ value	Results sorted on:
1. cst_sold_to_nbr If this number: • matches an existing customer: the response includes information on that customer only. See Search on Existing Customer Number: Sample Messages. • does not match an existing customer: the response message is “empty.” See Search on Non-existent Customer Number: Sample Messages. • matches a ghost customer: the response includes information on the cross-reference customer. See Search on Existing Customer Number: Sample Messages for more information.	Customer#	customer sold to number, zero-filled (for example, a customer number of 1234 is presented as 000001234)	N/A
2. zip and last_name (and first_name) The first name is not required for this type of search; however, if the request does not include the last_name, the CUST_SRCH treats the request like a zip and company_name search.	Zip/Last Name/First Name	positions 1-10: zip positions 11-35: last name positions 36-50: first name See Scanning by Zip or Postal Code for more information.	zip, last name, first name, customer number
3. zip and company_name Note: The CUST_SRCH process uses this type of search if the request includes just the zip but neither the last_name or the company_name.	Zip/Company Name	positions 1-10: zip positions 11-40: company name See Scanning by Zip or Postal Code for more information.	zip, company name, customer number
4. company_name	Company Name	positions 1-30: company name	company name, customer number
5. last_name and first_name	Last Name/First Name	positions 1-25: last name positions 26-40: first name	last name, first name, customer number
6. telephone_nbr	Telephone#	telephone number Note: The telephone number must be formatted	telephone number, customer number
7. interface_cust_nbr The response includes information on customers with an exact match to the alternate customer number.	Alternate#	alternate customer number	alternate customer number, customer number
8. match_code	Match Code	match code	match code, customer number
9. email_addr	Email Address	email address	email address, customer number

Note: To use the hierarchy described above, the Inbound Customer Search Message (CWCustomerInqRequest) should include each attribute only if there is actually data, and should not include any blank attributes. For example, if the request includes match_code=" " and email_addr="jdoe@commercialware.com" then the Outbound Customer Search Response (CWCustomerInqResponse) uses Match Code as the search criterion, even though it is blank; the results start with a blank match code and continue alphanumerically. To have the Email Address be the search criterion, the match_code attribute should not be included at all.

Scanning by Zip or Postal Code

The Postal Code Scan Length (F61) system control value plays a role in selecting customer records for the Outbound Customer Search Response (CWCustomerInqResponse), and also in determining the composition of the primary_scan_value:

• selecting customer records: similar to the search logic used at scan screens in Order Management System, the customer inquiry (search) API returns matching customer records based on the total number of positions in the Postal Code Scan Length (F61) system control value, rather than the total number of positions in the customer’s zip or postal code. For example, if this system control value is set to 5, and the Inbound Customer Search Message (CWCustomerInqRequest) specifies a zip of 01760, the Outbound Customer Search Response (CWCustomerInqResponse) includes customer records alphanumerically based on zip or postal code starting with 01760, but with ZIP+4 results (such as 01760-1234) included in the search results. However, if the Inbound Customer Search Message (CWCustomerInqRequest) specifies a zip of 01760-1234, the Outbound Customer Search Response (CWCustomerInqResponse) starts with customer records whose postal codes are 01761 or later alphanumerically.

• composing the primary_scan_value: when the primary_scan_criteria is Zip/Last Name/First Name or Zip/Company Name, the first ten positions of the primary_scan_value represent the zip or postal code; however, only the number of positions specified in the Postal Code Scan Length (F61) system control value are populated, and the remaining positions are filled with blank spaces. This is because the CUST_SRCH uses the Postal code scan field, rather than the Zip field, from the Customer Sold To table as the first ten positions of the primary_scan_value, and the system updates the Postal code scan field with the number of positions from the system control value each time you create or change a customer.

Note: Multiple blank spaces might not be displayed when you view a message in a browser, but are still present in the table. You an use a text editor to review all blank spaces in a message.

For more information: See the Postal Code Scan Length (F61) system control value for a discussion.

Customer Search API Setup

System control value: The Postal Code Scan Length (F61) system control value determines how many positions of the zip or postal code to consider for scanning, and how many positions to leave blank in the primary_scan_value. See the Process Overview for a discussion of the role this system control value plays in scanning by zip or postal code.

Note: The setting of the Display Alternate Customer Cross Reference Window (I84) system control value does not affect the function of searching by alternate customer number. The customer search API always searches in the Alternate Customer Number Cross Reference table, and does not give priority to the alternate customer number in the Customer Sold To table as a “primary” customer number.

CUST_SRCH process: Use Working with Integration Layer Processes (IJCT) to set up the CUST_SRCH process, including assigning the correct inbound and outbound queues.

CWMessageIn Web Service

You can use the CWMessageIn Web Service to route Customer Search messages. In this situation, the target for each inbound message must match the Inbound program name for the integration layer process queue, as specified at the Integration Layer Process Queue Screen.

The CUST_SRCH integration layer process can remain inactive and a queue is not required if the target is CWCUSTSRCH in the XML message.

Web service authentication? Use the Working with Web Service Authentication (WWSA) menu option to define a valid user for basic web service authentication. If you use Oracle Identity Cloud Service for password authentication, in addition to creating the web service authentication user in Work with Web Service Authentication (WWSA), you must also create a corresponding user profile in Oracle Identity Cloud Service and assign the user to the corresponding web service role defined for the Order Management application.

If you are using the CWMessageIn RESTful web service: You POST inbound CWMessageIn messages to the web service’s URI, or endpoint, of the RESTful service. The individual URL for the CWMessageIn RESTful service uses the following format: http://server:port/SerenadeSeam/sxrs/application/CWMessageIn, where server:port identifies the application server where the RESTful service is located and CWMessageIn is the name of the web service to call.

If you are using the CWMessageIn SOAP-based web service: The endpoint specified in the CWMessageIn.wsdl file is where you need to post messages in order for the CWMessageIn web service to process them. The endpoint is typically set to http://server:port/CWDirectCPService/services/CWMessageIn, where server:port identifies the application server where the wsdl is located and CWMessageIn is the name of the web service to call. The CWMessageIn SOAP-based web service requires that inbound messages be embedded in SOAP envelope tags.

Sample Customer Inquiry Messages

The following sample searches are provided:

• Search on Email Address: Sample Messages

• Search on Alternate Customer Number: Sample Messages

• Search on Zip Code and Last Name with Subsequent Search: Sample Messages

• Search on Existing Customer Number: Sample Messages

• Search on Non-existent Customer Number: Sample Messages

Search on Email Address: Sample Messages

In this sample search, the request provides the email address.

Request message:

</Message>

Response message: Note that, for a search criterion such as email address, the same customer can be included multiple times. For example, customer 49 is listed twice: once for an email address of JONES@EXAMPLE2.COM, and once for an email address of jonesshelone@example.com. This situation can also occur in a search based on telephone number, which permits multiple entries for a single customer.

</Emails>

</Customer>

</Emails>

</Customer>

</Emails>

</Customer>

</Emails>

</Customer>

</Emails>

</Customer>

</Emails>

</Customer>

</Customers>

</Message>

Search on Alternate Customer Number: Sample Messages

In this sample search, the request provides the alternate customer, which serves as the primary customer number in the external system.

Request message:

</Message>

Response message: The response includes customers whose alternate customer number is an exact match to the interface_cust_nbr passed in the request.

</Alternates>

</Telephones>

</Emails>

</Customer>

</Alternates>

</Telephones>

</Emails>

</Customer>

</Customers>

</Message>

Search on Zip Code and Last Name with Subsequent Search: Sample Messages

In this type of search, the search criteria of zip and last name are concatenated in the primary_scan_value. Because the zip code is allotted ten positions, the last name always begins in the eleventh position in the primary_scan_value.

The primary_scan_value is concatenated in the same way when the search criteria are zip code and company name, or last name and first name. See Criterion Hierarchy for more information.

Request message:

</Message>

Response message:

</Alternates>

</Telephones>

</Emails>

</Customer>

</Alternates>

</Telephones>

</Emails>

</Customer>

</Alternates>

</Telephones>

</Emails>

</Customer>

</Alternates>

</Telephones>

</Emails>

</Customer>

</Alternates>

</Telephones>

</Emails>

</Customer>

</Customers>

</Message>

Subsequent request message: The following is an example of a subsequent search request that provides information on the last customer record from the previous results. It specifies the customer number and the two other values (zip code and last name) that make up the primary_scan_value from the last record received.

</Message>

Subsequent response message:

</Alternates>

</Telephones>

</Emails>

</Customer>

</Alternates>

</Telephones>

</Emails>

</Customer>

</Alternates>

</Telephones>

</Emails>

</Customer>

</Alternates>

/Telephones>

</Emails>

</Customer>

</Alternates>

</Telephones>

</Emails>

</Customer>

</Customers>

</Message>

Search on Existing Customer Number: Sample Messages

When the Inbound Customer Search Message (CWCustomerInqRequest) specifies an existing customer, the Outbound Customer Search Response (CWCustomerInqResponse) includes information on that customer only.

Ghost? If the inbound message specifies a customer number that is flagged as a ghost (a customer record that you can retain on the system after you purge duplicates), the outbound message includes information on the customer record that was merged with the ghost record, identified by the Customer number cross reference field in the Customer Sold To table. See the discussion of the Ghost flag for more information.

Request message:

</Message>

Response message:

</Alternates>

</Telephones>

</Emails>

</Customer>

</Customers>

</Message>

Search on Non-existent Customer Number: Sample Messages

The “empty” Outbound Customer Search Response (CWCustomerInqResponse) indicates that the Inbound Customer Search Message (CWCustomerInqRequest) did not provide the required information for a customer search. Reasons why the system might generate the “empty” response message include:

• the company specified in the request message does not exist

• there is no company specified in the request message

• the customer number specified in the request message does not exist

• the information provided in the request message occurs after the last records in the table (for example, the request message specifies a customer last name starting with Z, but the last customer name alphanumerically starts with Y)

Empty response message:

</Customers>

</Message>

Inbound Customer Search Message (CWCustomerInqRequest)

When the CUST_SRCH process receives this request, it generates the Outbound Customer Search Response (CWCustomerInqResponse). See the Process Overview for more information, and see the Sample Customer Inquiry Messages for examples of requests and responses.

Attribute Name	Type	Length	Comments
Message
source	alpha	20	Informational.
target	alpha	20	Informational.
type	alpha	20	Informational. Typically set to CWCustomerInqRequest.
CustRequest See the Process Overview for information on how the CUST_SRCH process uses the search criteria specified in the request to find one or more customers.
company_nbr	numeric	3	Required. Identifies the company where the CUST_SRCH process should look for customers.
interface_cust_nbr	alpha	15	Optional. A valid interface_cst_nbr is used for searching only if customer number, zip, name, company name, or phone number are not included in the request. Searches the Alternate Customer Number Cross Reference table for an exact match, and responds with customers in alphanumeric alternate customer number, sold to customer number order. See Search on Alternate Customer Number: Sample Messages for examples. Note: Because the alternate customer number search is an exact match search, you must include any leading zeros defined for the alternate customer number. See Working with Alternate Customer Number Cross-References for more information on the Alternate Customer Number Cross Reference table.
cst_sold_to_nbr	numeric	9	Optional. If a customer number is specified in the request: • if there is a matching customer in the Customer Sold To table, the response includes that customer; otherwise, • if the inbound message specifies a customer number that is flagged as a ghost (a customer record that you can retain on the system after you purge duplicate records), the outbound message includes information on the customer record that was merged with the ghost record. See the discussion of the Ghost flag for more information; otherwise, • if the customer number specified does not match an existing customer, the CUST_SRCH process returns an empty response. See Search on Existing Customer Number: Sample Messages and Search on Non-existent Customer Number: Sample Messages for examples.
zip	alpha	10	Optional. Validated against the Zip/City/State table. A full or partial zip or postal code is used for searching only if cst_sold_to_nbr is not specified in the request. The CUST_SRCH process uses the zip or postal code together with the company name or last and first name in searching for customers: • If both the company name and the last name are specified, the process uses the zip, the last name, and the first name, if indicated, for searching; • Otherwise, if the zip and the company name are specified, the process uses these two fields for searching; • Otherwise, the search process still considers the search to be based on zip and company name, but with a company name that is blank; as a result, customers whose company name fields are blank are listed first in the search results. Note: The zip should not exceed the number of positions specified in the Postal Code Scan Length (F61) system control value in order to select customers correctly. See Scanning by Zip or Postal Code for a discussion.
last_name	alpha	25	Optional. A full or partial last name is used for searching only if the cst_sold_to_nbr is not specified in the request: • If there is also a zip or postal code specified in the request, the CST_SRCH process uses the zip, last name, and first name if indicated for searching; • Otherwise, if there is no zip or postal code and no company name, the process uses the last name together with the first name for searching. When the system searches on zip or postal code, last name, and first name, or on last name and first name, these fields are concatenated in the primary_scan_value in the search results. See the Criterion Hierarchy for more information.
first_name	alpha	15	Optional. A full or partial first name is used for searching only if the cst_sold_to_nbr, zip, and company_name are not specified in the request; also, used only with last_name or with zip and last_name. Concatenated with the last_name in the primary_scan_value. See Criterion Hierarchy for more information.
company_name	alpha	30	Optional. Used for searching only if the cst_sold_to_nbr is not specified in the request: • If both the company_name and the zip are specified but not the last_name, the process uses both the zip and the company_name for searching; • Otherwise, if the zip is not specified, the process uses the company_name for searching. If the search uses both the zip and the company_name, these two fields are concatenated in the primary_scan_value. See Criterion Hierarchy for more information.
telephone_nbr	alpha	14	Optional. A full or partial phone number is used for searching only if the cst_sold_to_nbr, zip, last_name, and company_name are not specified in the message. The CUST_SRCH process checks all three telephone number types: evening, day, and third number (fax or mobile). Searches the Customer Sold To Phone # table. Formatting: The phone number in the request message needs to be formatted the same way that it is formatted in the Customer Sold To Phone # table. For example, if the phone number is formatted as (123) 456-7890, then the telephone_nbr in the request message should also include the parentheses, space, and hyphen.
email_addr	alpha	50	Optional. Used for searching only if the cst_sold_to_nbr, zip, last_name, company_name, telephone_nbr, and match_code are not specified in the message. Searches the Customer Sold To Email table. See Working with Customer Email Addresses for more information on email addresses.
match_code	alpha	15	Optional. Used for searching only if the cst_sold_to_nbr, zip, last_name, company_name, and telephone_nbr are not specified in the message. Searches the Match Code table for the standard match code. See Setting Up Match Codes (MMCH) for more information on match codes.
nbr_of_records	numeric	5	Optional. Restricts the number of customers included in the response to this number. If you do not specify a number of records, the CUST_SRCH restricts the number of records to 25. The search does not use this number if you search based on the cst_sold_to_nbr, because your result must be an exact match. Note: Setting this number too high can negatively affect performance. Also, setting this number over 40 has the potential to cause the request to fail if the response exceeds the maximum message length.
starting_sold_to_ nbr	numeric	9	The first matching customer to include in the response, based on other criteria specified in the request. Used to send subsequent requests.

Outbound Customer Search Response (CWCustomerInqResponse)

The CUST_SRCH process generates this message when it receives the Inbound Customer Search Message (CWCustomerInqRequest). See the Process Overview for more information, and see the Sample Customer Inquiry Messages for examples of requests and responses.

Attribute Name	Type	Length	Comments
Message
source	alpha	20	Informational only
target	alpha	20	Informational only
type	alpha	20	CWCustomerInqResponse
date_created	alpha	10	YYYY-MM-DD format
time_created	alpha	8	HH:MM:SS format
Customer See Creating and Updating Sold-to Customers (WCST) for a discussion of the fields in the Customer Sold To table.
company_nbr	numeric	3	The company_nbr from the request message.
cst_sold_to_nbr	numeric	9	A unique number to identify the customer.
prefix	alpha	3	From the Prefix, if any, for the customer.
first_name	alpha	15	From the First Name, if any, for the customer.
initial	alpha	1	From the Initial, if any, for the customer.
last_name	alpha	25	From the Last Name, if any, for the customer.
suffix	alpha	3	From the Suffix, if any, for the customer.
addr_line1	alpha	32	The Street field for the customer.
addr_line2	alpha	32	Additional Address lines, if any, for the customer.
addr_line3	alpha	32
addr_line4	alpha	32
apartment	alpha	10	From the Apt/suite (Apartment/suite), if any, for the customer.
city	alpha	25	From the City for the customer.
state	alpha	2	From the St (State) for the customer.
zip	alpha	10	From the Postal code for the customer.
country	alpha	3	From the Country for the customer.
company_name	alpha	30	From the Company, if any, for the customer.
match_code	alpha	15	A code generated for each customer by the system in order to identify duplicate customers. When you create a new customer, the system creates the standard match code automatically, based on selected elements of the customer's name and address. Also, the system updates the match code automatically when you change any of the related elements.
mail_name	alpha	1	The setting of the Mail flag for the customer. Possible values are: Y = Mail catalogs to the customer N = Do not mail catalogs to the customer
rent_name	alpha	1	The setting of the Rent flag for the customer. Possible values are: Y = Sell the customer's name to another company N = Do not sell the customer's name to another company
rent_email	alpha	1	From the Rent e-mail flag in the Customer Sold To table. This flag is not displayed on any screen.
primary_scan_ criteria	alpha		Indicates the criterion or criteria the CUST_SRCH process used to create the response, and used as the primary_scan_value. Possible primary scan value settings are: • Customer# = cst_sold_to_nbr (In this situation, there is only one customer in the response) • Zip/Last Name/First Name = the zip last_name, and first_name are concatenated • Zip/Company Name = the zip and company_name are concatenated • Company Name = company_name • Last Name/First Name = the last_name and first_name are concatenated • Telephone# = telephone_nbr. This can be the daytime, evening, or third (fax or mobile) phone number. • Alternate# = interface_cust_nbr • Match Code = match_code • Email Address = email_addr See the Criterion Hierarchy for more information on the hierarchy in selecting search criteria, and on how to parse the primary_scan_criteria.
primary_scan_value	alpha		The value that the CUST_SRCH process used to position the customer record in the response.
cpg_price_group	alpha	4	The price group code, if any, assigned to the customer. This price group is displayed at the Second Create Customer Sold To Screen. See Working with Customer Price Groups (WCPG) for background. Available in: Version 2.0 in Order Management System 3.5.1 or later.
Note: The three fields below are available through the Working with Customer Price Groups (WCPG) option only if the Customer Price Group Code for CPG Pricing Only (L58) system control value is not blank.
cpg_discount_pct	numeric	5.2	The default percentage off the initial price for customers in the price group. From the Discount specified at the Work with Customer Price Groups Screen. Available in: Version 2.0 in Order Management System 3.5.1 or later.
cpg_current_discount_pct	numeric		A percentage discount that is currently in effect to override the default cpg_discount_pct for customers in the price group. Included only if the cpg_current_discount_pct_effective_date is not in the future. From the Discount specified at the Work with Customer Price Group Details Screen. Available in: Version 2.0 in Order Management System 3.5.1 or later.
cpg_current_discount_pct_effective_date	numeric	8	The date when the customer price group detail discount (cpg_current_discount_pct) became effective. Included only if this date is not in the future. From the Effective Date specified at the Work with Customer Price Group Details Screen. MMDDYYYY format. Available in: Version 2.0 in Order Management System 3.5.1 or later.
Alternate A customer can have one or more alternate customer numbers. The CUST_SRCH process selects customers based on the alternate customer numbers in the Alternate Customer Number Cross Reference table. The process selects customers whose alternate customer number is an exact match. See Working with Alternate Customer Number Cross-References for more information on this table.
interface_cust_nbr	alpha	15	The Alternate customer # from the Alternate Customer Number Cross Reference table.
primary_alternate	alpha	1	Indicates whether this alternate customer cross-reference number is also the Alternate customer number, as displayed in customer maintenance. Possible values are: Y = This is also the Alternate customer number N = This is not the Alternate customer number
Telephone Each phone number for the customer is indicated in the response.
telephone_nbr	alpha	14	The complete, formatted phone number. See Phone # (Day, Eve, Fax or Mbl) for a discussion.
telephone_type	alpha	1	The type of phone number. Possible types are: D = daytime phone number E = evening phone number F = fax or mobile
Email Each email address for the customer is indicated in the response. See Working with Customer Email Addresses for a discussion.
email_addr	alpha	50	The Email address for the customer.
email_status	alpha	2	The Opt in/out setting for the email address. Possible values are: O1 (Email): Email is the preferred method of correspondence. O2 (Order-only email): Use email for order-related correspondence only; generate a document for other correspondence. O3 (No email): Do not use email for any correspondence; generate a document instead. O4 (Do not ask the customer): Do not ask the customer for his/her email address; the customer has already been asked and has declined to provide it. The system does not generate any email correspondence to the customer, even if an email address is specified. Note: The above values use the letter O, not the number 0 (zero).
primary_email	alpha	1	Indicates whether this is the customer’s primary email address. The primary address is the one that defaults in order entry; it also defaults in catalog requests. Possible values are: Y = This is the customer’s primary email address N = This is not the customer’s primary email address

Generic Inventory Download API

Contents

SCVs

Search

Glossary

Reports

Solutions

XML

Index

Work with Store Cross Reference (WSCR)

Legal

ST01_12 OMSCS 19.0 December 2019 OHC