Chapter 121: Generic Customer Inquiry (Search) API

Chapter 121: Generic Customer Inquiry (Search) API

Purpose: Use the generic customer inquiry (search) API in CWDirect 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 CWDirect 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, you can have the response provide 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 and an exact match is not specified in the request, 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 pressing Page 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 CWDirect alternate customer number, which is used as the primary customer number in the remote system. Optionally, the request can specify to include exact matches only in the response.

2. Response: The CUST_SRCH process generates the Outbound Customer Search Response (CWCustomerInqResponse), which provides information on customers who either match the criteria exactly or are listed in alphanumeric order based on the search criteria. For example, if the search criterion is alternate customer number, the response either lists customers alphanumerically by alternate customer number, starting with the alternate customer number specified in the request message, or else is limited to customers whose alternate customer number matches the search criterion exactly.

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 alternate customer number, the subsequent message specifies the last customer number provided in the previous response, plus the alternate customer number 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 if an exact match was not requested.

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

Note: See Search on Alternate Customer Number: 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. MICROS does not recommend requesting 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.

Exact match? If the search request indicates that the response should include exact matches only, then the customer records included in the response message are limited to those that match all search criteria included in the primary scan values exactly. If exact match is not requested, then the response begins with customer records that match the search criteria exactly, and continues with additional customer records in alphanumeric order by the search criteria.

Example: If the customer provides a telephone number, then it is not useful to receive a list of customers with similar phone numbers; only an exact match is required.

There are situations in which restricting the response to exact matches is less helpful, such as when you are not sure of the spelling of a customer’s last name. For example, you know a customer lives in postal code 02134 and are not sure whether she spells her name Brown or Browne; if you include the zip code and a last name of Brown in the search request, then the response begins with customers who spell their names Brown and continues alphanumerically.

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

• Search criteria can be full or partial if not using exact match: If the request does not specify exact match only, then 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.

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

• Ghosts excluded: Customer records whose Ghost flag is set to Y 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 and does not request exact match. 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. See Translating Special Characters in Outbound Messages for more information.

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 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. Exact match: If your request specifies an exact match and there is no company name specified, then the search results include customer records whose zip codes are an exact match and whose Company fields are blank.	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
3. 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. Exact match: If your request specifies an exact match and there is no first name specified, then only customer records whose First name fields are blank are included in the response.	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
4. company_name	Company Name	positions 1-30: company name	company name, customer number
5. last_name and first_name Exact match: If your request specifies an exact match and there is no first name specified, then only customer records whose First name fields are blank are included in the response.	Last Name/First Name	positions 1-25: last name positions 26-40: first name	last name, first name, customer number
6. telephone_nbr Exact match: If your request specifies an exact match, then only customer records whose daytime, evening, or third (fax or mobile) phone numbers match the telephone number in the search request are included in the response.	Telephone#	telephone number Note: The telephone number must be formatted.	telephone number, customer number
7. interface_cust_nbr	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@example.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 CWDirect, 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 file 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 file. 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 file, and does not give priority to the alternate customer number in the Customer Sold To file 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 WebSphereMQ queues.

Sample Customer Inquiry Messages

The following sample searches are provided:

• 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 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. Note that this request does not indicate to include exact matches only.

Request message:

</Message>

Response message: Note that, for a search criterion such as alternate customer number, the same customer can be included multiple times. For example, customer 39 is listed twice: once for an alternate customer number of A1234, and once for an alternate customer number of A123459 (for example, if there was a data entry error). This situation can also occur in a search based on telephone number or email address, which permit multiple entries for a single customer.

Note: If the request message had specified exact matches only, then the response would have included only the first two customer records.

</Alternates>

</Telephones>

</Emails>

</Customer>

</Alternates>

</Telephones>

</Emails>

</Customer>

</Alternates>

</Telephones>

</Emails>

</Customer>

</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.

Note that this request does not indicate to include exact matches only.

Request message:

</Message>

Response message:

Note: If the request message had specified exact matches only, then the response would have included only the first customer record.

</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, regardless of whether an exact match is specified in the search request.

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 file. 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 file (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.

For more information: See XML Messages for a table that provides links to the DTD, schema, and a sample XML layout for each XML message.

Attribute Name	Type	Length	Comments
Message
source	alpha	20	Informational.
target	alpha	20	Informational. Typically set to CWDirect.
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 full or partial 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 file, and responds with customers in alphanumeric order by alternate customer number. See Search on Alternate Customer Number: Sample Messages for examples. Note: • Because a customer can have multiple alternate customer numbers, it is possible for the same customer to be included more than once in the search results. • Searching on alternate customer number is case-sensitive; if the request includes interface_cst_nbr 123abc, then a customer record whose alternate customer number is 123ABC is returned in the response. See Working with Alternate Customer Number Cross-References for more information on the Alternate Customer Number Cross Reference file.
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 file, 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. Note: The setting of the exact_match attribute does not affect search based on customer number; a customer number search is always an exact-match search. 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 file. 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.
			Exact match: The search logic is never based on zip code alone, and if the exact_match attribute in the search request is set to Y, then the response includes customer records only if all fields in the search criteria are exact matches. For example, if the search request includes the zip code and the last name, then the complete search criteria are zip code, last name, and first name; as a result, the response includes customer records only if they are exact matches based on all criteria (that is, the first name is blank).
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. Exact match: The search logic is never based on last name alone, and if the exact_match attribute in the search request is set to Y, then the response includes customer records only if all fields in the search criteria are exact matches. For example, if the search request includes just the last name, then the complete search criteria are last name and first name; as a result, the response includes customer records only if they are exact matches based on both criteria (that is, the first name is blank).
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. Note: If your request based on zip code and last name specifies an exact match and there is no first name specified, then only customer records whose First name fields are blank are included in the response.
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. Note: If your request based on zip code specifies an exact match and there is no company name specified, then only customer records whose company name fields are blank are included in the response.
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 fax/mobile). Searches the Customer Sold To Phone # file. 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 # file. 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. Note: If your search is based on telephone number and specifies an exact match, then customer records are included in the response only if their daytime, evening, or fax/mobile phone numbers match the telephone_nbr in the request.
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 file. 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 file 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.
exact_match	alpha	1	Indicates whether the Outbound Customer Search Response (CWCustomerInqResponse) should only include customer records that match the search criteria exactly. Valid values are: Y = Include customer records in the response only if they match all the primary search criteria exactly. See the Criterion Hierarchy for information on possible combinations of primary search criteria. N or blank = Start the list of customer records in the response with customer records that match the search criteria exactly, and continue with customer records in alphanumeric order by the search criteria until the nbr_of_records is reached. Note: It is not necessary to include the exact_match attribute if exact match is not required. Also, it is not necessary to include it for searches based on customer number, because in this situation the response can include no more than a single exact match. For more information: See Process Overview for examples. Available in XML version: Version 2.0 in release 11.5 of CWDirect.

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.

For more information: See XML Messages for a table that provides links to the DTD, schema, and a sample XML layout for each XML message.

Attribute Name	Type	Length	Comments
Message
source	alpha	20	CWDirect
target	alpha	20	CWIntegrate
type	alpha	20	CWCustomerInqResponse
date_created	alpha	10	YYYY-MM-DD format
time_created	alpha	8	HH:MM:SS format
Customer For more information: See Creating and Updating Sold-to Customers (WCST) for a discussion of the fields in the Customer Sold To file.
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 file. 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/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.
Alternate A customer can have one or more alternate customer numbers. The CUST_SRCH process selects customers based on alternate customer number based on the contents of the Alternate Customer Number Cross Reference file. See Working with Alternate Customer Number Cross-References for more information on this file.
interface_cust_nbr	alpha	15	The Alternate customer # from the Alternate Customer Number Cross Reference file.
primary_alternate	alpha	1	Indicates whether this alternate customer cross-reference number is also the Alt cust (Alternate customer number), as displayed in customer maintenance. Possible values are: Y = This is also the Alt cust (Alternate customer number) N = This is not the Alt cust (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 numbers 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 spool file for other correspondence. O3 (No email): Do not use email for any correspondence; generate a spool file 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 unless there is an individual placer on the order; 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

Chapter 120: Merchandise Locator Searching through JAVA

Contents

SCVs

Search

Glossary

Reports

XML

Index

Chapter 122: Order Broker Integration

ST01_12 CWDirect 18.0 August 2015 OTN