Inbound Order XML Message (CWORDERIN)

Inbound Order XML Message (CWORDERIN)

For more information: See:

• Order API Processing Overview for information on how the ORDER_IN process in Working with Integration Layer Processes (IJCT) processes this message.

• Inbound Order Message: Sample XMLs for a sample of the inbound order message.

Numeric values: All numeric values with decimal positions should be passed as explicit decimals. For example, a dollar value of $10.00 should be passed as 10.00. A dollar value passed as 100 indicates a price of $100.00, not $1.00.

Date format: If any date passed is not the right number of positions or indicates a nonexistent month or day of the month, the system ignores the invalid date and uses the default. For example, if the message includes an order_date of 123456, the system ignores this information and uses the current date as the order date.

Case:

• Email addresses are always saved in the database in lowercase.

• Message text (order messages, order line messages, custom personalization text, and standard custom special handling text) is saved in upper and lowercase if that is how they are passed in the inbound message.

• All other alphanumeric fields are saved in all uppercase, regardless of their case in the inbound message.

Invalid data: If invalid data is passed in the message, the order API returns an Invalid XML Message: followed by the submitted message and a listing of the resulting errors. If a credit card is part of the message, all but the last four of the credit card number is masked with asterisks (*). You can review the CWSerenade MQ Message Log for details. To avoid passing invalid data:

• Do not pass an alphanumeric value in a numeric field.

• Do not exceed the specified length of any field that is stored as a non-date number in the database; doing so prevents the system from being able to process the message at all, and the order will not be created.

• Alphanumeric fields that are defined in and validated against the database (such as the item code) or are part of the key identifying fields for a table should not exceed the maximum field length, or they put the order in error status. Other alphanumeric fields (such as order messages and address information) that exceed the maximum field length are truncated.

Invalid message format: If the message is incorrectly formatted, the order API returns a Cannot Parse XML Message: followed by the submitted message. If a credit card is part of the message, the system replaces the credit card number with ** REMOVED **. You can review the CWSerenade MQ Message Log for details.

Message Attribute	Alpha/ numeric	Positions	Comments
Message One Message element is required.
source	alphanumeric		IDC
target	alphanumeric		RDC
type	alphanumeric		CWORDERIN
resp_qmgr	alphanumeric	44	Not currently implemented.
resp_q	alphanumeric	44	Not currently implemented.
Header One header element is required. Special characters: If you pass a special character in the Header element, the system does not process the message and writes a message in the CWDirect Log. Example: • If you pass Mary&Joe in the sold_to_fname tag, an error message similar to the following is written in the CWDirect log: 2008-06-18 11:25:59,934 99184497 ERROR [STDERR] (43049:) (LoggerStream.java:152) [Fatal Error] :1:214: The reference to entity "Joe" must end with the ';' delimiter. • If you pass Mary& in the sold_to_fname tag, the order API returns an Invalid XML response and writes an error message similar to the following to the CWDirect log: 2008-06-18 11:10:29,315 98253878 ERROR [STDERR] (43049:) (LoggerStream.java:152) [Fatal Error] :1:110: The entity name must immediately follow the '&' in the entity reference.
company_code	numeric	3	Identifies the company for the order. Validated against the Company table. Padding with zeroes (for example, 005) is optional. Required.
order_number	alphanumeric	30	Use this number to identify the order in the external system or the session ID from the web storefront. Updates the E-commerce order number in the Order Header Extended table, and creates a record in the E-Commerce Order Reference table. Labeled the Web order number at the Display Order Properties Screen. Important: A unique order_number is required for every order received through the Inbound Order Message to avoid the risk of having an unaccepted order replaced when another order message is received. Note: If the Reject Duplicate Web Orders (K64) system control value is selected, duplicate orders are discarded. Invalid order number? If a payment-only message specifies an order number that does not exist, the order API returns an error: <Message>Error: The order could not be located.</Message> Separate payment message: If the payment is sent in a separate message, the order API uses the order_number to identify the order only if there is not a valid rdc_order_nbr specified. See Sending a Separate Payment Message for more information.
offer_id	alphanumeric	3	The offer to default to each order detail line to control pricing and track demand. The system applies this offer to the order detail line only if there is a record of the item or SKU in this offer. The line_offer, if any is passed, overrides this default. If the message does not specify an offer_id at the header or a line_offer for an item, the offer associated with the source code defaults. However, the offer on the order detail line is overridden if the Override Offer on Order Detail Line (D49) system control value is selected and the price for the item is found in a different offer.
rdc_order_nbr	numeric	9	Indicates the CWSerenade order number to update when the payment information is sent separately from the rest of the order. See Sending a Separate Payment Message.
payment_only	alphanumeric	1	Indicates whether the order message includes just the payment information for an order whose other information was sent on a previous message. Valid values are: • Y = Payment information only • N or blank = Not a payment-only If this flag is set to Y, then the pay_incl flag should also be set to Y. See Sending a Separate Payment Message for more information.
source_code	alphanumeric	9	Updates the Source code field in the Order Header table. If this value exceeds the maximum length of 9 positions, it will be truncated. Source code selection: 1. Valid source? Use the source code specified here if it is valid and unrestricted. Otherwise, if the source code is invalid or restricted or no source code is specified, 2. Line-level source? • Is there a valid, unrestricted line_source_code specified for one of the Item lines on the order? If so, the line-level source code defaults to the header. Note: If a line-level source code is invalid, the order will be suspended with an error of Invalid Source Code. • If there is a line_source_code specified for more than one line, the first one on the order defaults to the header. Otherwise, if no valid or unrestricted line-level source code is specified, 3. Mail history? If the Load Order Header Source from Mailing History (F05) system control value is selected and the customer has mailing history, use the most recent source code from the customer’s mailing history. Otherwise, if the system control value is unselected or the customer has no mailing history,
			4. Current source? If the Use Default Current Source Code (C46) system control value is selected and the customer has a current source code, use that source code. Otherwise, if the system control value is unselected or the customer does not have a current source code, 5. Default source for internet orders: Use the Default Source for Internet Orders (E65). Otherwise, if the system cannot determine the source code for the order, it puts the order in error with a reason of Invalid Source Code. Note: If the order header source code matches the source code in the Default Unknown Source Code (I58) system control value, the system changes the source code on the order header to the source code associated with the offer on the first order detail line; see Default Unknown Source Code Logic.
response_type	alphanumeric	1	Indicates the type of response required. Valid values are: • N or no response_type passed = No response • A = Acknowledge: Send Order Acknowledgement XML Message (CWORDEROUT) • D = Details: Send Detailed Order XML Response (CWORDEROUT) • E = Errors: Send the Detailed Order XML Response (CWORDEROUT), including a listing of any errors found on the order. Note: If the response_type is any setting other than N, A, D, or E, the order API returns a response of <Message>OK</OK>. Available in XML version: A setting of E is valid in version 2.0, available in release 1.1 of CWSerenade. If payment information sent separately: When you receive the payment information separately from the rest of the order, the system always sends a response message upon receiving the first part of the order message. If the response_type is D or E, the system sends the detailed message; otherwise, if the response_type is A or N, or if no response_type is specified, the system sends the acknowledgement.
			For more information: See: • Typical Order Interface Scenarios for examples of when you might choose to include a response. • Sending a Separate Payment Message for a discussion of when you might choose to send payment information separately • Order Creation Errors for a listing of errors that might be included if the response_type = E
order_date	numeric	8	Updates the Order date in the Order Header table. Displayed on the Order Inquiry Header Screen. Uses a date in the past if provided in the message; otherwise, if the message does not provide a date or if the date is invalid, uses the current date. MMDDYYYY format.
enter_date	numeric	8	Updates the Entered date in the Order Header table. Uses a date in the past if provided in the message; otherwise, if the message does not provide a date or if the date is invalid, uses the current date. A past or future date does not create an error. MMDDYYYY format.
enter_time	numeric	6	Entered time in the Order Header table, which you can review at the Display Order Properties Screen.
order_channel	alphanumeric	2	Updates the Internet order field in the Order Header table. A value of I indicates an internet order. Internet orders are treated differently in evaluating orders for automatic email confirmations, authorizations, and determining whether the customer can maintain the order on the web storefront. A value of P indicates a retail channel order. If the order_channel is P and the order is not part of a batch, the system places the order in the Batch Number for Retail Channel Orders (I78) if it has errors. If this value exceeds the maximum length of 2 positions, it will be truncated.
customer_ number	numeric	9	Updates the Customer # field in the Order Header table. See Customer Creation, Matching and Update Logic in the Order API for an overview.
alternate_sold_to_id	alphanumeric	15	Used to identify the sold-to customer; see Customer Sold To Selection, Creation and Update. Updates the Alternate customer # for the customer; see the Alt cust # field at the Second Create Customer Sold To Screen. This update always takes place, regardless of the setting of the sold_to_address_ update flag if you also pass the customer number.
prospect_id	alphanumeric	8	Used to identify the sold-to customer. See Customer Sold To Selection, Creation and Update.
Note: • See Customer Creation, Matching and Update Logic in the Order API for an overview on how each of the customer sold to name and address fields listed below are updated. • When creating or updating a customer address, the system validates the customer address and ship via as it does in order entry. See Adding Customer/Address Information for more information.
Note: If you leave any of the customer name fields blank when you are updating the customer name and address, then the system deletes the fields left blank in the message provided the result is a complete, valid customer record. For example, if an existing customer record includes the first and last names, and the CWOrderIn specifies a company name but no first or last names, then the existing first and last names are deleted from the customer record.
sold_to_prefix	alphanumeric	3	Maps to the Prefix field in the Customer Sold To table. If the Validate Prefix (I27) system control value is selected, the prefix is validated against the Prefix table; see Working with Prefix Codes (WPFX). In this situation, if the customer’s prefix is invalid, the order will be in error with a reason of Invalid Prefix Code (however, this message can also indicate a problem with the bill_to_prefix). Otherwise, if the system control value is not selected, a prefix that exceeds the field length of three positions is truncated.
sold_to_fname	alphanumeric	15	Maps to the First name field in the Customer Sold To table.
sold_to_initial	alphanumeric	1	Maps to the Initial field in the Customer Sold To table.
sold_to_lname	alphanumeric	25	Maps to the Last name field in the Customer Sold To table. Note: • If you change a customer address but do not specify either a last name or a sold_to_company, none of the changes specified for the Customer Sold To table will take place; however, updates to related tables, such as the Customer Sold To Phone # or Customer Sold To Extended, will still take place.
sold_to_suffix	alphanumeric	3	Maps to the Suffix field in the Customer Sold To table.
sold_to_ company	alphanumeric	30	Maps to the Company name field in the Customer Sold To table. If you change a customer address but do not specify either a sold_to_lname or a company, none of the changes specified for the Customer Sold To table will take place; however, updates to related tables, such as the Customer Sold To Phone # or Customer Sold To Extended, will still take place.
sold_to_busres	alphanumeric	1	Maps to the Delivery code field in the Customer Sold To table. Valid values are: • B = business • R = residence If this value is not specified and you are creating or updating the customer address, the system uses the Default Delivery Code for New Order Entry Customers (D13).
sold_to_ address1	alphanumeric	32	Maps to the Street address field in the Customer Sold To table. Shipping to a Post Office Box To ship to a Post Office Box, enter POST OFFICE BOX, POST BOX, or any variation of PO BOX (with or without spaces or non-alphabet characters, such as P.O. BOX), and the box number in the customer’s street address. During order processing, the system validates that the carrier can ship to a post office box (as defined in the Ship Via table). Example: Enter P.O. Box 9999 in the Street field to indicate delivery to a post office box instead of a home or company address. Note: If you type POST OFFICE BOX, POST BOX, or any variation of PO BOX in the customer’s street address during order entry or through the Order API, the system automatically selects the PO box field for the customer. However, if you remove this text from the customer’s street address, the system does not automatically unselect the PO box flag.
sold_to_ address2	alphanumeric	32	Maps to the Address line 2 field in the Customer Sold To table.
sold_to_ address3	alphanumeric	32	Maps to the Address line 3 field in the Customer Sold To Extended table.
sold_to_ address4	alphanumeric	32	Maps to the Address line 4 field in the Customer Sold To Extended table.
sold_to_ apartment	alphanumeric	10	Maps to the Apartment field in the Customer Sold To table. Typically includes a preface such as “Apt” so the apartment number is easily identified in the printed address.
sold_to_city	alphanumeric	25	Maps to the City field in the Customer Sold To table. If this field is not passed but a valid postal code (zip) is passed and the Use Zip/City/State Defaulting? (B13) system control value is selected, the city associated with the postal code defaults.
sold_to_state	alphanumeric	2	Maps to the State field in the Customer Sold To table. If this field is not passed but a valid postal code (zip) is passed and the Use Zip/City/State Defaulting? (B13) system control value is selected, the state associated with the postal code defaults. Required only if the Require state? flag is selected for the country.
sold_to_zip	alphanumeric	10	Maps to the Zip field in the Customer Sold To table. Required only if the Require postal code? flag is selected for the country. If a postal code is required, it is validated against the Zip/City/State (Postal Code) table; see Setting Up the Zip/City/State (Postal Code) Table (WZIP). If the SCF related to the zip code is invalid, the order will be in error with a reason of SCF not Found (however, this message can also indicate a problem with the bill_to_zip). If the SCF or the ship via/SCF combination is not valid, the order will be in error with the reason of Invalid Ship Via for SCF. This error occurs only if the Perform ship via edit? flag is selected for the country.
sold_to_country	alphanumeric	3	Maps to the Country field in the Customer Sold To table. If no country code is specified here, the Default Country for Customer Address (B17) defaults when you are creating a new customer or updating an existing customer. If the country is invalid, the order will be in error with a reason of Country Not Found (however, this message can also indicate a problem with the bill_to_country).
sold_to_email	alphanumeric	50	If the sold_to_email_update flag is set to Y, updates an existing customer’s email address at the customer sold-to level, and primary email address in the Customer Sold To Email table.See Working with Customer Email Addresses for an overview. If the email address is not properly formatted, the order will be in error. See Email Address Validation. Case: The email address is always saved in lowercase; for example, if the sold_to_email is JSMITH@FUNMAIL.COM, the system saves it as jsmith@funmail.com. Also, the system does not consider case in evaluating whether the sold_to_email matches the email address for an existing customer; the two email addresses above would be considered exact matches. If the sold_to_email_update flag is not set to Y, then the order API does not update an existing customer’s email address.
sold_to_email_update	alphanumeric	1	If set to Y, indicates to update an existing customer’s primary email address. When you update the email address, the new email address is added to the Customer Sold To Email table, and is flagged as the primary email address. See Working with Customer Email Addresses for an overview.
sold_to_day_ phone	alphanumeric	14	Used to identify the sold-to customer. The phone number should be unformatted; or, if it is formatted, it should be correctly formatted based on the phone number formatting specified for the customer’s country to create, match, or update the customer correctly. See Customer Sold To Selection, Creation and Update for more information on how the system finds a matching customer based on phone numbers. The system updates these phone numbers, if provided, regardless of the setting of the sold_to_address_ update flag (provided it did not select the customer based on name/address or phone number information).
sold_to_eve_ phone	alphanumeric	14
sold_to_fax_ phone	alphanumeric	14	Updates the third (fax or mobile) number for the customer; see the Fax or Mobile field at the Second Create Customer Sold To Screen. The third phone number should be unformatted; or, if it is formatted, it should be correctly formatted based on the phone number formatting specified for the customer’s country to create, match, or update the customer correctly. The system updates this field, if provided, regardless of the setting of the sold_to_address_ update flag (provided it did not select the customer based on name/address or phone number information).
sold_to_opt_in	alphanumeric	2	Updates the Opt-in out setting for the customer’s primary email address; see the Opt in/opt out field at the First Create Sold To Customer Screen. The system updates this field, if provided, regardless of the setting of the sold_to_address_ update flag. If no value is specified in the message and you are creating a new customer, the Default Opt In/Opt Out Flag (G97) defaults. If a value is not specified for this system control value or an invalid value is passed, O2 defaults.
sold_to_ address_ update	alphanumeric	1	Indicates whether to update an existing Customer Sold To with name and address information in the message. Valid values are: • Y = Update the existing Customer Sold To • N = Do not update the Customer Sold To Regardless of the setting of this flag, the system always updates the following fields if they are provided in the message: • alternate customer number • phone numbers (daytime, evening, or third (fax or mobile)) • opt-in/out flag • rent flag • mail flag • customer class • customer price group See Customer Creation, Matching and Update Logic in the Order API for more information. Note: The system checks this setting only if name and address information is provided in the message.
allow_rent	alphanumeric	1	Updates the Rent flag for the customer; see the Rent flag at the First Create Sold To Customer Screen. The system updates this field, if provided, regardless of the setting of the sold_to_address_ update flag. If no value is specified in the message and you are creating a new customer, the Default Rent Name (D11) setting defaults. Valid values are: Y = allow rent N = do not allow rent
allow_email			Not currently implemented.
allow_mail	alphanumeric	1	Updates the Mail flag for the customer; see the Mail flag at the First Create Sold To Customer Screen. The system updates this field, if provided, regardless of the setting of the sold_to_address_ update flag. If no value is specified in the message and you are creating a new customer, the Default Mail Name (D10) setting defaults. Valid values are: Y = allow mail N = do not allow mail
nbr_ship_tos			Not currently implemented.
pay_incl	alphanumeric	1	Indicates whether the message includes payment method information. If the payment method information will be sent in a separate message, the order remains suspended until the payment method message is received. Valid values are: • Y = payment method information is included in the message, or this is a payment-only message (see Sending a Separate Payment Message) • N = payment information will be sent in a separate message. Note: If this flag is set to N, no payment methods will be added to the order even if the information is included in the message. Require Payment on Quotes? If the message does not include payment information and the Quote field for the order type is selected, the program looks at the setting of the pay_incl tag in the message. • If the pay_incl tag is N, the system places the quote in an error status and waits for a second CWOrderIn message that includes the payment information to complete the quote. • If the pay_incl tag is Y, the system looks at the Pay method required field for the order type on the quote. • If Pay method required is selected, the system requires a pay method on the quote. If a pay method is not defined, the system places the quote in an error status. You will need to correct the quote in batch order entry. • If Pay method required is unselected, the system does not require a pay method on the quote and continues with regular processing.
Note: See Creating and Updating Individuals for more information on each field. If any of the information provided for the individual is invalid, the order will be in error with a reason of Placer Invalid.
ind_number	numeric	3
ind_dept	alphanumeric	3
ind_position	alphanumeric	3
ind_prefix	alphanumeric	3
ind_fname	alphanumeric	15
ind_initial	alphanumeric	1
ind_lname	alphanumeric	25
ind_suffix	alphanumeric	3
ind_day_phone	alphanumeric	14	The phone number should be unformatted; or, if it is formatted, it should be correctly formatted based on the phone number formatting specified for the customer’s country to create, match, or update the customer correctly. The third number is displayed on screens and reports as the fax or mobile number, based on the setting of the Third Phone Number Type (L53) system control value.
ind_eve_phone	alphanumeric	14
ind_fax_phone	alphanumeric	14
ind_email_ address	alphanumeric	50	If the Default Individual Email Address (J17) system control value is selected, and an order_email is not specified, the system defaults the individual’s email address to the Order email address field on the order. Case: The email address is always saved in lowercase; for example, if the ind_email_address is JSMITH@FUNMAIL.COM, the system saves it as jsmith@funmail.com.
ind_opt_in	alphanumeric	2	If you do not specify a setting here, the OptIn setting for the individual defaults from the Default Opt In/Opt Out Flag (G97) system control value.
ind_mail_flag	alphanumeric	1	If you do not specify Y here, the Mail flag for the individual will be unselected.
ind_rent_flag	alphanumeric	1	If you do not specify Y here, the Rent flag for the individual will be unselected.
bill_to_number	numeric	7	Updates the CBT Account # field in the Order Header table. See Customer Bill To Selection and Creation for an overview. Note: • The system does not update an existing bill-to customer record through the Inbound Order Message. • Having the Create/Assign Bill To Customers in Order Entry (A76) system control value unselected does not prevent you from specifying an existing bill-to here and assigning it to the order. • If the payment method on the order is accounts receivable and there is not currently a valid bill-to customer assigned to the customer placing the order, the system creates a new bill-to customer based on the sold-to customer’s name and address, and assigns that bill-to customer to the order and to the sold-to customer. This assignment takes place regardless of the setting of the Create/Assign Bill To Customers in Order Entry (A76) system control value and regardless of whether the customer placing the order is a new or existing customer.
Note: • If bill-to name and address information is specified in the following attributes, it is used to create a new bill-to customer (A/R account) and assign it to the order. See Customer Bill To Selection and Creation for an overview. • If you are creating a new bill-to customer, but the bill-to name and address provided in the message does not specify a complete, valid bill-to name and address, the order will be in error. See Creating and Updating Bill-to Customers (WCBT) for more information on requirements and validation. However, the order API sets certain required fields to their default settings automatically to prevent the order from being in error if all other bill-to information is valid, since these fields are not included in the CWOrderIn message. The fields and their default settings are: • Fax flag = N • EDI flag = N • Delivery code = B • The bill-to information, if any, provided in the following attributes is used on the order, regardless of whether the customer sold-to is already assigned to another bill-to. • When the system creates a new bill-to based on the sold-to information in the message and the customer sold-to is not already assigned to a bill-to, the sold-to will be assigned to that bill-to. • For more information on the bill-to name and address fields that map to the attributes listed below, see Creating and Updating Bill-to Customers (WCBT). If any of the bill-to information in the message is invalid, the order will be in error with a reason of Invalid Bill to Address.
alternate_bill_to_id			Not currently implemented.
bill_to_prefix	alphanumeric	3	If the Validate Prefix (I27) system control value is selected, the prefix is validated against the Prefix table. See the sold_to_prefix for more information. Otherwise, if the system control value is not selected, a prefix that exceeds the field length of three positions is truncated.
bill_to_fname	alphanumeric	15
bill_to_initial	alphanumeric	1
bill_to_lname	alphanumeric	25
bill_to_suffix	alphanumeric	3
bill_to_company_name	alphanumeric	30
bill_to_address1	alphanumeric	32
bill_to_address2	alphanumeric	32
bill_to_address3	alphanumeric	32
bill_to_address4	alphanumeric	32
bill_to_apt	alphanumeric	10
bill_to_city	alphanumeric	25	If this field is not passed but a valid postal code (zip) is passed and the Use Zip/City/State Defaulting? (B13) system control value is selected, the city associated with the postal code defaults.
bill_to_state	alphanumeric	2	If this field is not passed but a valid postal code (zip) is passed and the Use Zip/City/State Defaulting? (B13) system control value is selected, the state associated with the postal code defaults. Required only if the Require state? flag is selected for the country.
bill_to_zip	alphanumeric	10	Required only if the Require postal code? flag is selected for the country.
bill_to_country	alphanumeric	3	Required if the message includes bill-to information.
bill_to_email	alphanumeric	50	Case: The email address is always saved in lowercase; for example, if the bill_to_email is JSMITH@FUNMAIL.COM, the system saves it as jsmith@funmail.com.
bill_to_day_ phone	alphanumeric	14	The phone number should be unformatted; or, if it is formatted, it should be correctly formatted based on the phone number formatting specified for the bill-to customer’s country to create, match, or update the customer correctly. The third number is displayed on screens and reports as the fax or mobile number, based on the setting of the Third Phone Number Type (L53) system control value.
bill_to_eve_ phone	alphanumeric
bill_to_fax_ phone	alphanumeric
bill_to_print_ statement	alphanumeric	1	Valid values are: Y = Print statement N or blank = Do not print statement
bill_to_opt_in	alphanumeric	2	Not currently implemented.
user_hold_ reason	alphanumeric	2	Updates the Hold reason field in the Order Header table, displayed at the Order Inquiry Header Screen and puts the order on hold. Defined in and validated against the Order Hold Reason table; see Establishing Order Hold Reason Codes (WOHR). If this value exceeds the maximum length of 2 positions, it will be truncated.
Note: See Batching Orders Through the Order API for an overview on how to use the following attributes.
batch_number	numeric	12	Must be a number that has not yet been used for an order batch. When the system receives the beginning order for a batch it confirms that the batch number does not exist in the Used Phone Batch table; however, it then assigns a different batch number to the batch. All orders that are received with the same batch_number are assigned to the same batch number in CWSerenade. For example, if the first order you send has a batch_number of 782, and the order API assigns the order to batch 888, all subsequent orders received with batch_number 782 are also assigned to batch 888.
batch_date	alphanumeric	8	Updates the Batch date in the Order Batch table. MMDDYYYY format. Indicates the date of the batch, as displayed at the Work with Order Batches Screen. Specify this date for the first order in the batch.
batch_beg_end_flag	alphanumeric	1	Indicates when a batch begins or ends; otherwise, this value should be blank. Valid values are: • B = Begin batch; use for the first order in a batch. • E = End batch: use for the last order in a batch. Note: Even after you have sent a batch_beg_end_flag of E, if you send an additional order message with the same batch_number, the additional order is assigned to the same batch. For example, if you send an order with a batch_number of 782 and the batch_beg_end_flag set to E, then subsequently send an additional order that also has a batch_number of 782, the additional order will be added to the existing batch.
approve_batch	alphanumeric	1	Not currently implemented. The batch remains open until you select Edit/Accept on the Work with Order Batches Screen to edit and approve it manually.
batch_order_ count	numeric	5	Indicates the number of orders in the batch, as displayed at the Work with Order Batches Screen. The batch will be out of balance if the number of orders received for the batch is not the same as this value. Specify this quantity for the first order in the batch.
batch_qty_ count	numeric	7	The total order line quantity of all orders in the batch, as displayed in the # of units field at the Change Order Batch Screen. The batch will be out of balance if the total number of units is not the same as this value. This quantity should be specified for the first order in the batch. Specify this quantity for the first order in the batch.
batch_prepaid_total	numeric	9.2	Updates the Actual $ received field in the Order Batch table. The total amount of cash payments for all orders in the batch. This amount should be specified for the first order in the batch. Specify this total for the first order in the batch.
order_type	alphanumeric	1	Updates the Order type field in the Order Header table. Defined in and validated against the Order Type table; see Establishing Order Types (WOTY). If this value exceeds the maximum length of one position, it will be truncated. If no order_type is specified here, the system uses the E-Commerce Order Type (G42). If the Retail warehouse field for the order type contains a non-allocatable warehouse and the Reserve from Non-Allocatable Warehouse (J25) system control value is selected, the system allows you to reserve inventory against the non-allocatable warehouse defined for the order type. However, if a warehouse override is defined for the ship to or for an order line, the system uses the warehouse override.
sales_rep_number	numeric	7	Updates the Salesman # field in the Order Header table. See Selecting the Sales Rep for more information on how the system assigns a salesrep to the order. Error: If the salesrep is not active, the system places the order in error: Sales Rep Inactive. Salesrep store: If you do not pass a sales_rep_store and a Home Store is defined for the sales_rep_number assigned to the order, the system defaults this store number to the Originating Store field in the Order Header table. However, if the Store Cross Reference record for the Home Store defined for the salesrep is inactive, the system places the order in error: Sales Rep Store Inactive. Creating a salesrep: If the system creates a new salesrep (see Selecting the Sales Rep), the system sets the Active flag for the new salesrep in the Salesman table to Y. The system will NOT assign the store number defined for the order to the new salesrep. Note: Because the sales rep number is a numeric field, if the number passed here exceeds seven positions, the order API returns an “Invalid XML” error and cannot process the order.
sales_rep_name	alphanumeric	30	See Selecting the Sales Rep.
entered_by_ user	alphanumeric	10	Updates the USR user field in the Order Header table, labeled Entered by at the Display Order Properties Screen. If no user is specified in the message, your default user defaults. If the entered_by_user exceeds the maximum length of 10 positions, it will be truncated. This field does not need to be a valid user.
customer_class	alphanumeric	2	Updates the Customer class for the customer; see the Class field at the First Create Sold To Customer Screen. The system updates this field, if provided, regardless of the setting of the sold_to_address_ update flag. If no customer_class is provided in the Inbound Order Message, the system uses the Default Customer Class in Order Entry (D63). If there is no customer_class in the message, no default customer class specified in the system control value, and the Require Customer Class in OE, WCAT, and WCST (H85) system control value is selected, the order will be in error with a reason of Invalid/Missing Cust Cls.
order_email	alphanumeric	50	Updates the order-level email address. If no order_email is provided, the system uses the: • ind_email_address or existing email address for the placer on the order if the Default Individual Email Address (J17) system control value is selected • sold_to_email or existing primary email address for the sold-to customer • See Email Address Updates through the Generic Order Interface for an overview. Case: The email address is always saved in lowercase; for example, if the order_email is JSMITH@FUNMAIL.COM, the system saves it as jsmith@funmail.com.
ip_addr	alphanumeric	15	Updates the IP address in the Order Header Extended table, displayed at the Display Order Properties Screen. IP address validation: If the IP address is invalid, the system writes an Order Transaction History message such as INVALID IP ADDRESS: 1.2.3 where 1.2.3 represents the invalid IP address received, and does not update this field. The IP address is made up of a series of four numbers separated by three periods (for example, 192.168.255.255). Each number between the periods must be from 1 to 255. The IP address must: • not include any non-numeric characters besides the periods • not include any blank spaces • include all three periods • include all four numbers, each from 1 to 255
			Fraud checking: If the IP address received matches an entry in the Miscellaneous Fraud table, the system puts the order on IP (IP address) hold and writes a message reading SYS HLD---IP ADDRESS HOLD to the Order Transaction History table. See Working with Miscellaneous Frauds (WMFF) for more information on IP addresses and fraud checking.
sold_to_price_group	alphanumeric	4	The customer price group to assign to the sold-to customer. Available in XML version: 4.0 (release 2.5 of CWSerenade). About price groups: You can use a customer price group to control quantity price matrix pricing, customer price group pricing, or as a qualifier for promotions. If you assign a price group through the CWOrderIn message, the order is eligible for any pricing or promotions related to the price group. Updated when? If the message specifies a valid customer price group and the customer does not already have a Price group assignment, the system updates the customer record regardless of the setting of the sold_to_address_ update flag. The system does not update the customer’s Price group if there is already a group assigned. Default: If you do not assign a customer price group to a customer, the system assigns the customer price group defined in the Customer Price Group Code for CPG Pricing Only (L58) system control value to the customer. Errors? The system continues with normal processing and does not put the order in error status if the price group code specified is not valid, or if the customer is already assigned to a price group. For more information: See Working with Customer Price Groups (WCPG).
sales_rep_ store	alphanumeric	10	The store number assigned to the order. Store numbers are defined in and validated against the Store Cross Reference table; see Work with Store Cross Reference (WSCR). The store number assigned to the order displays in the Sales Rep Store field on the Display Order Properties Screen. Errors: • If the store number passed is not a valid store number in the Store Cross Reference table, the system places the order in error: Sales Rep Store Invalid. • If the Active flag for the store number passed is not set to Y in the Store Cross Reference table, the system places the order in error: Sales Rep Store Inactive. Default: If you do not pass a sales_rep_store and a Home Store is defined for the sales_rep_number passed in the message, the system defaults this store number to the Originating Store field in the Order Header table. However, if the Home Store defined for the salesrep is inactive, the system places the order in error. Included in CWEmailOut: If the order is not a retail pickup, delivery, ship-to-store, or store pickup order, the CWEmailOut message includes the store’s description, phone number, and address. See the OriginatingStore element in the Outbound Email XML Message (CWEmailOut) for more information. Available in XML version: 6.0 (release 3.5 of CWSerenade).
ecommerce_id	alphanumeric	32	The customer number identifying the customer in the e-commerce site. Used as part of the Relate Customer Integration to help synchronize customer information between CWSerenade and Relate. Used only if the Relate Customer Integration (L37) system control value is set to INTERACT. See Customer Synchronization through the Order API for a discussion. Available in XML version: 8.0 (release 4.5 of CWSerenade).
relate_cust_ sync_success	alphanumeric	1	Indicates whether the e-commerce site has successfully synchronized information about the customer with Relate. Used as part of the to help synchronize customer information between CWSerenade and Relate. Used only if the Relate Customer Integration (L37) system control value is set to INTERACT. See Customer Synchronization through the Order API, especially What Does the relate_cust_sync_success flag Control?, for a discussion and complete definition. Available in XML version: 8.0 (release 4.5 of CWSerenade).
CustOwnership If you pass valid data in the following attributes, it updates the Customer Ownership table, available for review at the Work with Customer Ownership Screen in customer maintenance. The CustOwnerships element, if provided, can include one or more CustOwnership elements.
cust_own_ID	alphanumeric	10	A code that represents a product the customer owns or previously owned. Updates the Ownership ID field in the Customer Ownership table. Required to create or update a customer ownership record. If a CustOwnership does not include cust_own_ID but does include other values, the system creates a customer note: Missing Ownership ID: Ownership Description. The system does not place the order in an error status because of customer ownership errors.
cust_own_desc	alphanumeric	40	A description of the product. Updates the Description field in the Customer Ownership table.
cust_own_active	alphanumeric	1	Indicates if the customer currently owns the product. • Y = The customer currently owns the product. • N = The customer previously owned the product. Updates the Act field in the Customer Ownership table. If this attribute is included but does not specify one of the valid values listed above, the order API sets the flag to Y.
cust_own_entry_date	numeric	8	The date the customer ownership record was created, in MMDDYYYY format. If passed, updates the Entry date field in the Customer Ownership table. If a valid date is not passed and you are creating a new ownership, the current date defaults.
cust_own_confirm_date	numeric	8	The most recent date when the customer confirmed ownership of the product, in MMDDYYYY format. If passed, updates the Confirm date field in the Customer Ownership table. If a valid date is not passed and you are creating a new ownership, the current date defaults.
CustUserField Use the following attributes to update the Customer Sold To User Field table, available for review at the Work with User Fields Screen in customer maintenance. The CustUserFields element, if provided, can include one or more CustUserField elements.
cust_usr_fld_dtl_seq_nbr	numeric	3	Identifies the Sequence # in the Cust Sold To User Field table, labeled the Key at the Change User Field Screen. Required to update a customer user field if you do not specify a cust_usr_fld_label. If this entry does not match an existing customer user field, as specified through Setting Up User-Defined Fields (WUDF), the user field data in the message will not be saved. Note: The Sequence # in the Cust Sold To User Field table is not the same as the display sequence number.
cust_usr_fld_ label	alphanumeric	15	Identifies the field label for a customer user field, as displayed at the Work with User Fields Screen in customer maintenance. If you specify either the cust_usr_fld_dtl_seq_nbr or the label, or both, the system updates the customer user field identified by the sequence number.
cust_usr_fld_ data	alphanumeric	30	Updates the Text, Number, or Date field in the Cust Sold To User Field table. Note: • If the data exceeds 16 positions for a Number field, it is truncated. • If the data for a Number field includes non-numeric characters, they are removed. • Dates must be passed in MMDDYYYY format in order to update the Cust Sold To User Field table.
UserField Note: The contents of the Order Header User Field table is not available for display on any screen. The UserFields element, if provided, can include one or more UserField elements. For more information: See User-Defined Fields in the CWOrderIn Message for a complete overview.
usr_fld_dtl_seq_number	numeric	3	Identifies the Sequence # in the Order Header User Field table.
usr_fld_label	alphanumeric	15	Identifies the type of field to update in the Order Header User Field table.
usr_fld_data	alphanumeric	30	Updates the Text, number, or Date field in the Order Header User Field table. If the field is a date, the information passed must be a valid date in MMDDYYYY format, or the order API sets the date field to 0.
Payment The Payments element can include one or more Payment elements. At least one payment method is required.
payment_type	numeric	2	Identifies the Pay type field in the Order Payment Method table. If the message does not include a valid payment method, it will be in error status with an error reason of Invalid Pay Type, and the system creates a payment method on the order of 0. Defined in and validated against the Pay Type table. See Working with Pay Types (WPAY).
charge_ sequence	numeric	2	Updates the Charge sequence field in the Order Payment Method table. See the Chg seq field at the Display Order Payment Methods Screen.
suppress_ deposit_flag	alphanumeric	1	Updates the Suppress deposit field in the Order Payment Method table; see Suppressing Deposits and Refunds. Valid values are: Y = Suppress deposit N or blank = Do not suppress deposit You can review the setting of this flag at the Display Order Pay Type Screen (1 of 2).
suppress_ refund_flag	alphanumeric	1	Updates the Suppress refund field in the Order Payment Method table; see Suppressing Deposits and Refunds. Valid values are: Y = Suppress refund N or blank = Do not suppress refund You can review the setting of this flag at the Display Order Pay Type Screen (1 of 2).
cc_name			Not currently implemented.
cc_type			Not currently implemented.
cc_number	alphanumeric	20	Updates the Credit card number field in the Order Payment Method table; see the Credit card # field at the Display Order Pay Type Screen (1 of 2). CWSerenade retains the case of the value passed in this field. Required for credit card payment methods except for Bill Me Later and On Account, or the order will be in error with a reason of Invalid Credit Card. See Types of Credit Cards for more information. Tokenization: If you use credit card tokenization, the system looks at the setting of the already_tokenized tag to determine if the number in the cc_number tag is the actual credit card number or a token provided by the service bureau. Encryption: If you use credit card encryption, once the order is created in CWSerenade, the system encrypts the value in this field in the CWSerenade database to provide additional security of credit card data. See the Data Security and Encryption Guide.
cc_exp_month	numeric	2	Updates the first two positions of the Expiration date field in the Order Payment Method table; see the Expiration date at the Display Order Pay Type Screen (1 of 2). The Require expiration date flag for the pay type controls whether an expiration date is required for credit card payment methods. The expiration month passed must represent a valid month of the year; that is, it must be a number from 1 or 01 (January) to 12 (December); also the expiration month and year must not be more than 20 years in the future. If the pay type requires an expiration date and it is not passed correctly in the message, the order will be in error with a reason of CC Expiration/Start Date.
cc_exp_year	numeric	2	Updates the second two positions of the Expiration date field in the Order Payment Method table; see the Expiration date at the Display Order Pay Type Screen (1 of 2). The Require expiration date flag for the pay type controls whether an expiration date is required for credit card payment methods. The expiration month and year must not be more than 20 years in the future. If the pay type requires an expiration date and a valid date is not passed in the message, the order will be in error with a reason of CC Expiration/Start Date.
cc_sec_value			Not currently implemented.
cc_sec_presence			Not currently implemented.
cc_iss_bank	alphanumeric	10	Updates the Issuing bank field in the Order Payment Method table. This field is not currently used.
defer_bill	alphanumeric	1	Indicates whether to automatically apply a default payment plan if the order qualifies, using the selection process described under Assigning a Payment Plan to the Order. Valid values are: • Y = Automatically assign a payment plan to the order using the normal hierarchy; however, if there is a flexible_payment_code specified in the message, use that payment plan • N or blank = Do not assign a payment plan automatically See Deferred/Installment Billing Overview for general information.
flexible_ payment_code	alphanumeric	5	Updates the FPO payment code field in the Order Payment Method table; this value indicates the deferral or installment details to specify for the order payment method. If this attribute specifies a valid payment plan, the system does not use the regular hierarchy to select a payment plan for the order. Used for credit card payment methods. Defined in and validated against the Flexible Payment Option table; see Working with Flexible Payment Options (WFPO) for more information. See the Display Order Pay Type Screen (2 of 2) for the flexible payment code assigned to the order. If the flexible payment code specified is not valid, the order will be in error.
amt_to_charge	numeric	9.2	Updates the Amount to charge field in the Order Payment Method table; see the Amount to charge field at the Display Order Pay Type Screen (1 of 2). For a coupon/gift certificate or cash/check payment method, also updates the Amount collected field. Required if the payment method is not the only one on the order. A negative amount represents a credit against the payment method. If you do not specify an amount and there is another payment method on the order without an amount specified, the order will be in error with a reason of Multiple CCs with $0. This error indicates that the order can have only one “catch-all” payment method; see the discussion of catch-all payment methods at the Enter Payment Method Screen.
auth_number	alphanumeric	16	Used for credit card payment methods. Relate stored value card integration: If you are using the Relate Stored Value Card Integration and the web order contains an approved Relate stored value card pay type, the auth_number attribute should contain the transaction ID received from Relate and not the authorization code received from Relate. Updates the Authorization number field in the Order Payment Method table; see the Authorization number at the Display Order Pay Type Screen (1 of 2). Creates an authorization history record; see Creating Authorization History for Orders Authorized on the Web.
auth_date	numeric	8	Updates the Authorization date field in the Order Payment Method table; see the Authorization date at the Display Order Pay Type Screen (1 of 2). MMDDYYYY format. Used for credit card payment methods.
auth_amount	numeric	9.2	Updates the Manual auth amount field in the Order Payment Method table; see the Authorization amount at the Display Order Pay Type Screen (1 of 2). Used for credit card payment methods.
gc_type			Not currently implemented.
gift_certificate_number	numeric	7	Updates the Gift cert/coupon field in the Order Payment Method table. Required if the payment_type in the message is a coupon/credit. If this number: • Matches a record in the Coupon Redemption table, this coupon, credit or gift certificate is applied to the order as a payment method; the Coupon $, if any, specified in the table updates the Amount to charge at the Display Order Pay Type Screen (1 of 2). In this situation, the amount_to_chg specified in the message is ignored when creating the payment method. • Does not match a record in the Coupon Redemption table, the system creates a coupon or credit payment method on the order; however, the Dynamic Creation of Coupons (B21) system control value must be selected, or the order will be in error because of an Invalid coupon.
gift_certificate_amount			Not currently implemented.
expiration_date			Not currently implemented.
hold_id			Not currently implemented.
ar_type			Not currently implemented.
po_number			Not currently implemented.
check_number	numeric	9	Updates the Check number field in the Order Payment Method table. Used for cash/check payment methods.
check_amount			Not currently implemented.
checking_ account	alphanumeric	20	Updates the Checking account field in the Order Payment Method table; see the Acct# field at the Display Order Pay Type Screen (1 of 2). Used for cash/check payment methods.
routing_number	numeric	9	Updates the Routing number field in the Order Payment Method table; see the Routing# field at the Display Order Pay Type Screen (1 of 2). Used for cash/check payment methods.
svc_id	numeric	9	The ID number for the stored value card payment. Define an ID number only if your stored value card processor supports it. CWSerenade stores the ID number in the OPM SVC ID Storage field in the Order Payment Method table and includes it in the authorization request and deposit request sent for the stored value card payment. Available in XML version: 4.0 (release 2.5 of CWSerenade).
cash_control_ number	numeric	5	Updates the Cash control number field in the Order Payment Method table; see the Cash control # at the Display Order Pay Type Screen (1 of 2). Used for cash/check payment methods.
start_date	numeric	4	Indicates the first date when the card is effective. MMYY format. The Require start date flag for the pay type controls whether a start date is required for credit card pay types. If a start date is required and it is not provided in the message, the order will be in error with a reason of CC Expiration/Start Date. Typically used for debit card or stored value card pay types. See Types of Credit Cards for more information.
card_issue_nbr	alphanumeric	2	A sequential issue number, issued by the bank, indicating how many times the card has been replaced. The Require issue # flag for the pay type controls whether an issue number is required for credit card pay types. If an issue number is required and it is not provided in the message, the order will be in error with a reason of Invalid Card Issue#.
soc_sec_nbr	numeric	9	Used for a Bill Me Later pay type. Because the social security number is treated here as a numeric value, it should be zero-filled if just the last four digits are included. For example, if the customer enters 1234 as the last four digits of the social security number, this attribute should be set to 000001234 in order to update the Customer Sold To BML table correctly. The social security number is not required if the customer already has a Bill Me Later account number, as shown at the Display Customer Order History Screen. However, if the customer does not already have a Bill Me Later account and the last four digits of the social security number are not provided, the order will be in error with a reason of Invalid social security number. The system updates the Customer Sold To BML table with the social security number provided, so this information will be available when you send the order out for authorization. See Bill Me Later Processing for more information.
bml_version	numeric	5	Used as the terms and conditions (T&C) code when creating an account for a customer with a Bill Me Later payment method. If a T&C code is not included in the message, the system uses the BML T&C (terms and conditions) version (web site) specified for the Bill Me Later pay type. The terms and conditions code should be zero-filled in order to update the Customer Sold To BML table correctly. For example, a terms and conditions code of 123 should be passed as a bml_version of 00123. See Bill Me Later Processing for more information.
birthdate	numeric	8	Used for a Bill Me Later pay type. MMDDYYYY format. The date of birth should be zero-filled in order to update the Customer Sold To BML table correctly. For example, if the customer’s date of birth is August 25, 1953, the birth date should be 08251953. The date of birth is not required if the customer already has a Bill Me Later account number, as shown at the Display Customer Order History Screen. However, if the customer does not already have a Bill Me Later account and the date of birth is not provided, the order will be in error with a reason of Invalid date of birth. The system updates the Customer Sold To BML table with the birth date provided, so this information will be available when you send the order out for authorization. See Bill Me Later Processing for more information.
authentication_value	alpha	40	A code received from an authentication service, such as Visa’s Verified by Visa program or MasterCard’s SecureCode program, indicating whether the card authentication password the cardholder provided was approved for the credit card.See Credit Card Authentication Service for more information. Updates the Authentication value field in the Order Payment Method table.
ecommerce_ indicator	alpha	4	Represents either: • An electronic commerce indicator code, received from an authentication service such as Visa’s Verified by Visa program or MasterCard’s SecureCode program, indicating the level of security provided for a credit card transaction placed over the internet. See Credit Card Authentication Service for a discussion. • A value indicating if the order was placed on a web storefront. Valid values are: • YES = The order was placed over the web storefront. • NO = The order was not placed over the web storefront. Updates the Ecomm Indic field in the Order Payment Method table.
cc_last_four	numeric	4	The last four digits of the credit card number in order to verify the card with the customer. Updates the CC Last 4 field in the Order Payment Method table. If this value is not passed, the system updates the CC Last 4 field with the last four digits of the cc_number. Available in XML version: 4.0 (release 2.5 of CWSerenade).
already_ tokenized	alphanumeric	1	Indicates whether the number in the cc_number tag is a token. See the Data Security and Encryption Guide. Y = The number in the cc_number tag is a token and not the actual credit card number. N or blank = The number in the cc_number tag is the actual credit card number. If the Use Credit Card Tokenization (L18) system control value is selected, the Request token field for the service bureau defined for the pay type is selected, the system performs credit card tokenization when CWSerenade receives the web order; see the Data Security and Encryption Guide for processing details. Updates the Tokenized field in the Order Payment Method table. Available in XML version: 4.0 (release 2.5 of CWSerenade).
cc_bin_nbr	alphanumeric	6	The first six digits of the actual credit card number in order to perform Level II and III Discounting on the card during deposit processing. Updates the Bin field in the Order Payment Method table if the credit card number is replaced with a token (the Tokenized field for the Order Payment Method record is Y; otherwise, the system does not store the bin number. If this value is not passed and the credit card number is replaced with a token, the system updates the Bin with the first 6 positions of the cc_number. Available in XML version: 5.0 (release 3.0 of CWSerenade).
transaction_id	alphanumeric	40	The transaction ID, or reference number, associated with the authorization defined for the credit card payment. If a transaction ID and authorization number are defined for a credit card payment, the system creates an authorization history record for the payment when the web order is successfully created in CWSerenade; you can review authorization history on the Display Authorization History Screen in Order Inquiry. See Creating Authorization History for Orders Authorized on the Web. Updates the Transaction ID in the Authorization History table. Available in XML version: 5.0 (release 3.0 of CWSerenade).
vendor_ response	alphanumeric	10	The authorization response code received from the authorization service for the credit card payment method. If a vendor response and authorization number are defined for a credit card payment, the system creates an authorization history record for the payment when the web order is successfully created in CWSerenade; you can review authorization history on the Display Authorization History Screen in Order Inquiry. See Creating Authorization History for Orders Authorized on the Web. The system looks at the Credit Card Vendor Response table to find a match to the authorization response code from the authorization service. If the authorization response is associated with a hold reason, the system: • places the order on AT Declined Credit Card hold. • places the credit card payment method on the hold reason defined in the CC Vendor Response table. If the response does not exist in the CC Vendor Response table, the system places the payment method on AV Invalid Response Code hold. • if the credit card is approved, but is placed on AVS or CID hold, updates the status of the authorization history record to O Authorized But Not Used.
			If an entity dollar limit by item class or postal code is defined for the response code, the system: • places the order on hold using the hold reason defined for the entity dollar limit if the authorization amount exceeds the dollar limit. See Vendor Response Processing above for the updates the system performs. • releases the order from AVS hold if the authorization amount is less than the dollar limit. Note: CWSerenade does not validate that the response code is a valid response for the authorization service defined for the credit card payment method. Updates AUH vendor response in the Authorization History table. Available in XML version: 6.0 (release 3.5 of CWSerenade).
avs_response	alphanumeric	10	The address verification response code received from the authorization service for the credit card payment method. If a vendor response, AVS response, and authorization number are defined for a credit card payment, the system creates an authorization history record for the payment when the web order is successfully created in CWSerenade; you can review authorization history on the Display Authorization History Screen in Order Inquiry. See Creating Authorization History for Orders Authorized on the Web. The system looks at the Credit Card Vendor Response table to find a match to the AVS response code from the authorization service. If the AVS response is associated with a hold reason, the system: • places the order on AT Declined Credit Card hold. • places the credit card payment method on the hold reason defined in the CC Vendor Response table. If the response does not exist in the CC Vendor Response table, the system places the payment method on AV Invalid Response Code hold. • if the credit card is approved, but is placed on AVS or CID hold, updates the status of the authorization history record to O Authorized But Not Used.
			If an entity dollar limit by item class or postal code is defined for the response code, the system: • places the order on hold using the hold reason defined for the entity dollar limit if the authorization amount exceeds the dollar limit. See Vendor Response Processing above for the updates the system performs. • releases the order from AVS hold if the authorization amount is less than the dollar limit. Note: CWSerenade does not validate that the response code is a valid response for the authorization service defined for the credit card payment method. Updates AUH AVS response in the Authorization History table. Available in XML version: 6.0 (release 3.5 of CWSerenade).
cid_response	alphanumeric	10	The credit card identification response code received from the authorization service for the credit card payment method. If a vendor response, CID response, and authorization number are defined for a credit card payment, the system creates an authorization history record for the payment when the web order is successfully created in CWSerenade; you can review authorization history on the Display Authorization History Screen in Order Inquiry. See Creating Authorization History for Orders Authorized on the Web. The system looks at the Credit Card Vendor Response table to find a match to the AVS response code from the authorization service. If the AVS response is associated with a hold reason, the system: • places the order on AT Declined Credit Card hold. • places the credit card payment method on the hold reason defined in the CC Vendor Response table. If the response does not exist in the CC Vendor Response table, the system places the payment method on AV Invalid Response Code hold. • if the credit card is approved, but is placed on AVS or CID hold, updates the status of the authorization history record to O Authorized But Not Used.
			If an entity dollar limit by item class or postal code is defined for the response code, the system: • places the order on hold using the hold reason defined for the entity dollar limit if the authorization amount exceeds the dollar limit. See Vendor Response Processing above for the updates the system performs. • releases the order from AVS hold if the authorization amount is less than the dollar limit. Note: CWSerenade does not validate that the response code is a valid response for the authorization service defined for the credit card payment method. Available in XML version: 6.0 (release 3.5 of CWSerenade).
ShipTo The ShipTos element can include one or more ShipTo elements. At least one ship to is required.
arrival_date	numeric	8	The date when the customer wants to receive the order. MMDDYYYY format. You can enter a future date to ship the order at a later date. If the message does not provide a date or if the date is invalid, the system uses the current date. Note: The system allows you to pass an arrival date earlier than the order date. Influence on Reservation The arrival date on the order controls whether inventory is reserved for each order detail line. The system uses this calculation: arrival date - reservation lead days (B27) = reservation date. The system will not reserve inventory if the system calculated date is greater than today’s date. This is considered a future order. The system identifies each item on the order as a future order line and assigns a backorder status to each item. Note: If the Reservation Lead Days (B27) system control value is 0, the system does not calculate whether the order is a future order and reserves inventory for the lines on the order. Updates the Arrival date in the Order Ship To table; see the Arrival date at the Display Order Properties Screen.
cancel_bo	alphanumeric	1	Updates the Cancel BO? field in the Order Ship To table; see the Cancel BO field at the Display Order Properties Screen. Defaults to N if this value is not set to Y. If this field is selected, any unshipped line on an order will be canceled during billing using the Auto Soldout Cancel Reason (C20), provided this system control value specifies a valid cancel reason code. Note: If you do not pass a value in the cancel_bo attribute and the Auto Cancel B/O field for the sold to customer is selected, the system updates the Cancel BO? field in the Order Ship To table to Y. However, if you pass N in the cancel_bo attribute and the Auto Cancel B/O field for the sold to customer is selected, the system updates the Cancel BO? field in the Order Ship To table to N.
cancel_bo_date	numeric	8	Updates the Cancel date field in the Order Ship To table; see the Cancel date at the Display Order Properties Screen. Uses a date in the past if provided in the message; otherwise, if the message does not provide a date or if the date is invalid, leaves the cancel date blank. If the cancel date has already passed, the order will be in error. MMDDYYYY format.
contact_name	alphanumeric	30	Updates the Contact name field in the Order Ship To table; see the Attention field at the Work with Order Screen in Order Maintenance.
fedex_number	alphanumeric	10	Updates the Federal express # field in the Order Ship To table; see the Carrier # at the Display Order Properties Screen. See Working with Ship Via Codes (WVIA) for an overview on ship vias.
freight	numeric	7.2	A flat freight fee for the order ship to. This fee will be used as the shipping charge on the order, regardless of any system-calculated freight charges. Updates Freight in the Order Ship To table, and sets the Freight override? flag to Y. Use the freight_tax_amount attribute to define the tax override amount on freight. Note: If a freight override exists, the system does not apply any additional freight, item charges, weight charges, or service charges to the order. See the Freight field at the Order Inquiry Header Screen and the Freight override flag at the Display Order Properties Screen.
freight_tax_amount	numeric	7.2	The tax override amount on freight. If an override amount is passed, the system does not calculate tax on freight. Note: Used only if a freight override amount is passed in the freight attribute. Updates OST Freight tax override in the Order Ship To table. The system uses the freight tax amount to calculate the tax rate for the freight override using the following calculation: (freight override amount / freight tax override) x 100 = freight tax rate The system stores the tax rate for the freight override in the OST Freight tax rate field in the Order Ship To table; the system uses the freight tax rate during return and cancellation processing to determine the amount of tax on freight that should be returned or deducted during cancellation. No freight tax amount will be charged for the order if you pass the freight_tax_amount as 0.00 or blank and enter Y in the freight_tax_override attribute. See the Freight tax override field on the Display Order Properties Screen. Vertex: See the Send Tax to Vertex as Quote Not Invoice (L11) for information on how the Vertex interface sends a tax override. Available in XML version: 6.0 (release 3.5 of CWSerenade).
freight_tax_override	alpha	1	If set to Y and you pass the freight_tax_amount as 0.00 or blank, no freight tax amount will be charged for the order. The system also updates the Freight Tax Override Y/N field in the Order Ship To table to Y. If any other value is passed, the order API uses the amount, if any, passed in the freight_tax_amount as the tax override amount on freight. Vertex: See the Send Tax to Vertex as Quote Not Invoice (L11) for information on how the Vertex interface sends a tax override. Available in XML version: 6.0 (release 3.5 of CWSerenade).
shipping_ method	numeric	2	Updates the VIA ship via code in the Order Ship To table; see the Ship via at the Display Order Properties Screen. The ship via must be eligible to ship the items on the order; see Item Ship Via Override Logic. Ship via codes are defined in and validated against the Ship Via table; see Working with Ship Via Codes (WVIA) for an overview. If the shipping address on the order qualifies for van delivery, the system defaults the ship via code defined in the Default Van Delivery Ship Via (L07) system control value to the order header. If you define the van delivery ship via in this attribute, the system validates that the shipping address on the order qualifies for van delivery and that the ship_to_warehouse is either blank or contains the Reserve warehouse defined for the shipping address. See Van Delivery Processing through the Generic Order Interface (Order API). If no shipping method is specified here and the shipping address on the order does not qualify for van delivery, the system uses the Default Ship Via (A77) from the System Control table. If this ship via matches the Best Way Ship Via for Auto-Assignment (J67), then the system automatically assigns the “best way” ship via with the lowest overall shipping charges to the order. See the Best Way Ship Via for Auto-Assignment (J67) system control value for more information.
			SCF/ship via validation: The Perform ship via edit? flag for the country controls whether to validate the SCF and ship via on an order or order line against the SCF Ship Via table. See Working with SCF/Ship Via Values (WSHV) for a discussion.
gift	alphanumeric	1	Updates the Gift order flag in the Order Ship To table; see the Gift flag at the Display Order Properties Screen. Defaults to N if this value is not set to Y.
tax_exempt	alpha	1	Allows you to pass exemption/resale information for the order ship to, regardless of the tax status of the sold to customer on the order. • E = Exempt. Indicates that the order ship to is considered tax-exempt. A tax-exempt certificate number is required in the resale_exempt_id attribute if an exempt certificate is not defined for the sold to customer; otherwise, the system ignores the setting of this attribute. The system does not calculate standard tax or VAT, if applicable, on the order ship to. • R = Resale. Indicates that the order qualifies as a reseller. A reseller is a person or company who purchases goods to sell to someone else. A reseller certificate number is required in the resale_exempt_id attribute if an exempt certificate is not defined for the sold to customer; otherwise, the system ignores the setting of this attribute. The system does not calculate standard tax or VAT, if applicable, on the order ship to. • Blank or any other value= Use existing logic to determine whether the purchases for the order ship to are taxed, and if they are, how to calculate tax. Updates Tax code in the Order Ship To table; see the Tax code field on the Work with Order Screen.
			Note: • The exemption/resale information you pass applies to the order ship to only; the system does not update the customer sold to with the exemption/resale information. • If the sold to customer on the order is tax exempt (the Tax exempt field is set to either Exempt or Resale for the sold to customer) and you do not pass a tax_exempt code, the system places the order in error: Invalid Tax Code. Tax Code Required. • If you pass a freight override and freight tax override in the freight and freight_tax_amount attributes, the system applies tax and freight charges to the order, regardless of whether the sold to customer or order is exempt from tax. Available in XML version: 6.0 (release 3.5 of CWSerenade).
resale_exempt_id	alphanumeric	15	The resale or exempt certificate number. Used if the sold to customer is tax exempt (the Tax exempt field is set to either Exempt or Resale for the sold to customer) or if you pass E (Exempt) or R (Resale) in the tax_exempt attribute. Note: • The exemption/resale information you pass applies to the order ship to only; the system does not update the customer sold to with the exemption/resale information. • If the sold to customer on the order is tax exempt (the Tax exempt field is set to either Exempt or Resale for the sold to customer) and you do not pass a tax_exempt code, the system places the order in error: Invalid Tax Code. Tax Code Required. • If you pass a freight override and freight tax override in the freight and freight_tax_amount attributes, the system applies tax and freight charges to the order, regardless of whether the sold to customer or order is exempt from tax. See Customer Tax Overview. Updates the Resale/exempt # in the Order Ship To table; see Resale/exempt at the Display Order Properties Screen.
ship_complete	alphanumeric	1	Updates the Ship complete? field in the Order Ship To table; see the Ship complete flag at the Display Order Properties Screen. Defaults to N if this value is not set to Y.
priority	numeric	1	Updates the Priority field in the Order Ship To table. If no priority is passed in the message, this field defaults from the source code. See B/O priority at the Display Order Properties Screen.
calc_frt	alphanumeric	1	Updates the Calc freight (Calculate freight) flag for the order ship-to. Valid values are: • blank or Y = calculate freight using the regular calculation • N = do not calculate freight (no freight will be added)
discount_pct	numeric	5.2	Updates the Discount % field in the Order Ship To table.See the Discount % at the Work with Order Screen. If a discount percentage is specified here, the system applies it to item prices in addition to other discounts that might apply, such as a Price discount % specified for the customer (see the Second Create Customer Sold To Screen) or a Discount % for the source code (see the Create Source Code Screen (1 of 2)).
customer_ship_to_number	numeric	9	Updates the CST customer # field in the Order Ship To table. Complete this attribute only when the order is shipping to: • another customer sold-to, different from the customer who places the order, who receives all or part of the order (recipient customer). In this situation, the ship_to_type is 2; or, • a permanent ship-to address for the customer. In this situation, the ship_to_type is 3, and this number should identify the sold-to customer number for the order. See Creating or Selecting Shipping Addresses or Customers for an overview.
ship_to_type	alphanumeric	1	Indicates the type of shipping address to use for the order. Valid values are: • 1 = order-level shipping address • 2 = recipient customer sold-to, indicate with the customer_ship_to_number • 3 = permanent ship-to, indicated with the permanent_ship_to_number; in this case, the customer_ship_to_number should match the sold-to customer • blank = use the shipping address of the sold-to customer on the order If no ship_to_type is specified and there is an alternate shipping address in the message, the Default Recipient Type for E-Commerce Orders (H33) defaults. See Creating or Selecting Shipping Addresses or Customers for an overview.
Use the following attributes if the shipping address is different from the sold-to customer. The system uses the ship_to name and address attributes listed below to: • match to an existing sold-to or permanent ship-to customer, or • create a new sold-to or permanent ship-to customer See Creating or Selecting Shipping Addresses or Customers for an overview. Note: • If you are creating a new sold-to or permanent ship-to customer and the name and address information specified in the message does not represent a complete, valid name and address, the order will be in error. Also, the order will be in error if the information in the message represents an existing sold-to or permanent ship-to customer whose name and address is currently invalid. See Creating and Updating Sold-to Customers (WCST) and Creating and Updating Ship-to Customers (WCST) for name and address requirements and validation.
ship_to_prefix	alphanumeric	3	If the Validate Prefix (I27) system control value is selected, the prefix is validated against the Prefix table. See the sold_to_prefix for more information. Otherwise, if the system control value is not selected, a prefix that exceeds the field length of three positions is truncated.
ship_to_fname	alphanumeric	15
ship_to_initial	alphanumeric	1
ship_to_lname	alphanumeric	25
ship_to_suffix	alphanumeric	3
ship_to_ company	alphanumeric	30
ship_to_ address1	alphanumeric	32	Shipping to a Post Office Box To ship to a Post Office Box, enter POST OFFICE BOX, POST BOX, or any variation of PO BOX (with or without spaces or non-alphabet characters, such as P.O. BOX), and the box number in the customer’s street address. During order processing, the system validates that the carrier can ship to a post office box (as defined in the Ship Via table). Example: Enter P.O. Box 9999 in the Street field to indicate delivery to a post office box instead of a home or company address. Note: If you type POST OFFICE BOX, POST BOX, or any variation of PO BOX in the customer’s street address during order entry or through the Order API, the system automatically selects the PO box field for the customer. However, if you remove this text from the customer’s street address, the system does not automatically unselect the PO box flag.
ship_to_ address2	alphanumeric	32
ship_to_ address3	alphanumeric	32
ship_to_ address4	alphanumeric	32
ship_to_ apartment	alphanumeric	10
ship_to_city	alphanumeric	25
ship_to_state	alphanumeric	2	Required only if the Require state? flag is selected for the country.
ship_to_zip	alphanumeric	10	Required only if the Require postal code? flag is selected for the country.
ship_to_country	alphanumeric	3	Required if a ship-to address is provided.
ship_to_email	alphanumeric	50	If the email address is not properly formatted, the order will be in error. See Email Address Validation. Case: The email address is always saved in lowercase; for example, if the ship_to_email is JSMITH@FUNMAIL.COM, the system saves it as jsmith@funmail.com.
ship_to_busres	alphanumeric	1	Valid values are: • B = business • R = residence
ship_to_day_ phone	alphanumeric	14	The phone numbers, if provided, should be unformatted; or, if it is formatted, it should be correctly formatted based on the phone number formatting specified for the customer’s country to create, match, or update the customer correctly. The third number is displayed on screens and reports as the fax or mobile number, based on the setting of the Third Phone Number Type (L53) system control value. Updating the one-time ship-to address: If the ship_to_type is 1, indicating to create a one-time ship-to address, the phone number for the one-time ship-to address is derived from the ship_to_day_phone, if it is provided in the message; otherwise, the one-time ship-to phone number is from the ship_to_evening_phone. The ship_to_fax_phone does not update the one-time ship-to address, even if it is the only phone number provided for the ship-to address. You can use the Display Alternate Address Screen to review the one-time ship-to address.
ship_to_evening_phone	alphanumeric
ship_to_fax_ phone	alphanumeric
email_gc	alphanumeric	1	Updates the Email gift certificate field in the Order Ship To table; see the Email gift certificate flag at the Display Order Properties Screen. Defaults to blank if this value is not set to Y. See the Gift Certificate E-Mail Program (H07) for an overview of how this flag is used.
permanent_ship_to_number	numeric	3	Used for ship_to_type 3 to identify the permanent shipping address to use. In this case, the customer_ship_to_number should indicate the sold-to customer on the order. See Creating or Selecting Shipping Addresses or Customers.
ship_to_ warehouse	numeric	3	The warehouse used to ship the entire ship-to order; this warehouse code defaults to the order header. Leave blank if you want the system to select the warehouse. Warehouse Default Hierarchy for the Ship-To 1. Use the ship_to_warehouse attribute in the CWOrderIn message. Overrides all warehouse codes except those entered for an individual order line. 2. Use the Reserve warehouse from the shipping address on the order if it qualifies for van delivery. See Van Delivery Processing for an overview. 3. Use the non-allocatable warehouse from the order type on the order if the Reserve from Non-Allocatable Warehouse (J25) system control value is selected. 4. Leave the Warehouse field on the order header blank. Updates the warehouse for the order ship to; see the Warehouse at the Display Order Properties Screen. Defined in and validated against the Warehouse table; see Creating and Maintaining Warehouses (WWHS).
ship_to_po_ number	alphanumeric	15	Updates the Purchase order # field in the Order Ship To table; see the Purchase order # at the Display Order Properties Screen. If the Verify Duplicate PO Numbers for A/R Orders (D80) system control value is selected and the purchase order number is a duplicate, the order will be in error with a reason of Duplicate PO#. Also, if the PO Required for A/R Orders (D79) system control value is selected and no purchase order number is specified, the order will be in error with a reason of Missing PO#-Req for A/R.
gift_message	N/A	N/A	Not currently implemented.
promotion	alphanumeric	7	If the Allow Manual Entry of Promotion Code (I63) system control value is: • selected: the promotion listed here is applied to the order, provided the order qualifies, the promotion’s Required entry flag is selected, and there is not another promotion of the same type that comes before this promotion in the hierarchy (described under (Promotion Logic and Processing). If a promotion is specified and the order does not qualify for it, the system continues creating the order and writes an order history message such as: Promotion (ADDFRT) not applied. However, if a promotion code specified in the message does not actually exist, the order will be in error with a reason of Invalid Promotion Code. Also, additional promotions whose Required entry flag are unselected might also apply to the order. • unselected: the system ignores any promotion code passed and determines which promotions, if any, to apply to the order based on the hierarchy based on the setting of the Best Way Promotions (K44) system control value. Note: You can use this promotion attribute to apply a promotion to the order, or you can use the Promotion element to apply one or more promotions. See the Allow Manual Entry of Promotion Code (I63) system control value and Promotion Logic and Processing for a complete discussion.
store_code	alphanumeric	12	The store code where the customer wants to pick up a ship-to-store or store pickup order. Must be a valid store code identifying a store location; see below for more information on validation of the store_code and the delivery_type. The name and address from the Store Cross Reference record defaults as the ship-to address for the order. See Store Pickup Orders or Ship-to-Store Orders for an overview. Available in XML version: 4.0 (release 2.5 of CWSerenade).
delivery_type	alphanumeric	1	A setting of P identifies a store pickup order, and a setting of S identifies a ship-to-store order. Not included for any other type of order; see below for more information on validation of the store_code and the delivery_type. Errors: • For a store pickup order, the customer must have an email address with its opt-in/out flag set to either O1 (all emails) or O2 (order-related emails) or the order will be in error with a reason of Email Missing/Ineligible. See Store Pickup Orders or Ship-to-Store Orders for an overview. • If the Payment at POS for Ship to Store (L60) system control value is selected, this is a ship-to-store order, the order type does not match the Order Type for Special Orders (L15) system control value, and the order includes a payment method that is not a credit card with a Card type of Credit, the order will be in error with a reason of Non-CC on Ship To Store. See Ship-to-Store Orders for an overview. Available in XML version: 5.0 (release 3.0 of CWSerenade).
Validation of the store_code and delivery_type: • If the delivery_type is S (ship-to-store) or P (store pickup) and the store_code is a valid store, creates a ship-to-store or store pickup order. • If the delivery_type is anything but S or P or is not included, or if there is a delivery_type but no store_code, creates a regular order with no error (assuming no other problems with the order). • If the delivery_type is S or P and there is not a valid store_code, puts the order in error; however, you can correct the order in batch order entry and when you accept the batch, the order is created correctly. (To correct, select a store for a ship-to-store order, or do a store pickup search for a store pickup order.)
alternate_ship_to_id	N/A	N/A	Not currently implemented.
add_chg_count	N/A	N/A	Not currently implemented.
already_eval_ by_promote	alphanumeric	1	Defines whether the order has already been evaluated by an external promotion engine for eligible discounts. • Y = The order has already been evaluated by an external promotion engine for eligible discounts. • N or blank = The order has not been evaluated by an external promotion engine for eligible discounts. Updates Promote already evaluated in Order Ship To table. Note: This field is not currently implemented. Available in: 7.0 (release 4.0 of CWSerenade).
promote_ maint	alphanumeric	1	Defines whether the system calls an external promotion engine during Order Maintenance for this order. • Y = The system calls an external promotion engine during Order Maintenance for this order. • N or blank = The system does not call an external promotion engine during Order Maintenance for this order. Updates Allow Promote in OM in Order Ship To table. Note: This field is not currently implemented. Available in: 7.0 (release 4.0 of CWSerenade).
relate_award_amount	numeric	7.2	The award coupon amount to apply to the order as a pro-rated merchandise discount. Evaluated only if the amount is .01 or greater and the Use Relate Loyalty (M06) and Prorate Dollar Discounts and Coupons (D90) system control values are selected. See the Relate Loyalty Integration, specifically, Applying Awards during the Generic Order Interface (Order API) for more information. Available in: 8.0 (release 4.5 of CWSerenade).
AdditionalCharge The AdditionalCharges element, if provided, can include one or more AdditionalCharge elements.
additional_charge_seq_nbr	numeric	3	Not currently implemented.
additional_ charge_code	alphanumeric	2	Updates the Add’l chg code in the Order Additional Charge table; see the Display Additional Charges Screen. Not validated against the Additional Charge table.
additional_charge_amount	numeric	7.2	Updates the Add’l charges field in the Order Additional Charge table; see the Display Additional Charges Screen. Can include a minus sign before or after the amount if the charge is negative, applying a credit to the order. Note: If no additional_charge_amount is passed in the message and there is a Default charge amount specified for the additional charge code, the default charge applies.
Ord_Msg The Ord_Msgs element, if provided, can include one or more Ord_Msg elements. Note: You can include up to 250 order message lines.
ord_msg_text	alphanumeric	60	Updates the Message field in the Order Message table; see the Work with Order Messages Screen. Saved in the upper and lowercase if that is how the text is passed in the inbound message. Messages longer than 60 positions are truncated. Note: The User displayed for the message is the first six positions of the entered_by_user.
ord_msg_code	alphanumeric	1	Updates the Print? flag in the Order Message table. See the Work with Order Messages Screen. Note: If the value specified here is not a valid value for the Print flag, or if no value is specified here, the message is still created, but the Print flag is set to blank (which is the same as N or do not print).
Promotion If the Allow Manual Entry of Promotion Code (I63) system control value is: • selected: the promotions listed here are applied to the order, provided the order qualifies, the promotion’s Required entry flag is selected, and there is not another promotion of the same type that comes before this promotion in the hierarchy (described under (Promotion Logic and Processing). If a promotion is specified and the order does not qualify for it, the system continues creating the order and writes an order history message such as: Promotion (ADDFRT) not applied. However, if a promotion code specified in the message does not actually exist, the order will be in error with a reason of Invalid Promotion Code. Also, additional promotions whose Required entry flag is unselected might also apply to the order. • unselected: the system ignores any promotion code passed and uses its regular hierarchy in determining which promotions, if any, to apply to the order. Note: You can use this promotion attribute to apply one or more promotions to an order, or use the promotion attribute to apply a single promotion to the order. See the Allow Manual Entry of Promotion Code (I63) system control value and Promotion Logic and Processing for a complete discussion. Available in XML version: 3.0 (release 2.0 of CWSerenade).
promotion_code	alphanumeric	7	The promotion code to apply to the order. See the description of the Promotion element, above, for more information.
Certificate Certificates are coupons provided by the Rewards system that a sold to customer who is enrolled in the Rewards membership program can apply to an order. The setting of the Rewards Certificates Pay Type (L54) system control value controls whether the system applies the certificates to the order as order payments or as a pro-rated merchandise discount. See Applying Rewards Certificates to an Order for an overview. Available in XML version: 4.0 (release 2.5 of CWSerenade).
certificate_number	alphanumeric	40	The certificate number to apply to the order. Updates the Certificate # field in the Order Rewards Certificate table.
certificate_amount	numeric	7.2	The dollar amount of the certificate to apply to the order. Updates the Certificate amount field in the Order Rewards Certificate table.
transaction_id	alphanumeric	40	The transaction ID returned by the Rewards system, authorizing the certificate as a discount for the order. Updates the Transaction # field in the Order Rewards Certificate table.
Item The Items element can include one or more Item elements. At least item is required. Note: To create an order that includes a set or continuity item, the message should include the master set or continuity item only. The set or continuity will be "exploded" once the order is created, and all of the component items will be added to the order.
drop_ship	alphanumeric	1	If the item is not flagged as Drop ship in the Item table: enter D to update the Drop ship flag field in the Order Detail table. Flagging the item as a drop ship on the order prevents it from reserving, even if you have inventory available, and prevents the system from submitting the order line as a brokered backorder to Locate. If the item is flagged as Drop ship in the Item table: enter O to override the order line to exclude it from drop ship processing and fulfill it from your warehouse.
no_charge	alphanumeric	1	Updates the No charge field in the Order Detail table. If this flag is set to Y, the order detail line will be “no charge”; otherwise, regular pricing applies. See the N/C flag at the Display Order Detail Screen (Reviewing Order Line Detail). A prc_ovr_rsn is required for a no-charge order line.
affect_inventory	alphanumeric	1	Updates the Affect inventory? field in the Order Detail table; see the Affect inventory flag at the Display Order Detail Screen (Reviewing Order Line Detail). Valid values: • Y or blank = Update inventory. If this is an express-bill order and the item does not exist in the line_warehouse specified, the order will be in error. If this is an express-bill order and the item exists in the line_warehouse and location, but there is no inventory available, the system creates an inventory transaction (WITE) error. • N = Do not update inventory. The system does not perform an inventory transaction and does not create an inventory transaction error.
line_arrival_ date	numeric	8	The date when the customer wants to receive the item. MMDDYYYY format. You can enter a future date to ship the item at a later date. If the message does not provide a date or if the date is invalid, the system uses the current date. Note: The system allows you to pass an arrival date earlier than the order date. Influence on Reservation The arrival date on the order line controls whether inventory is reserved for the line. The system uses this calculation: arrival date - reservation lead days (B27) = reservation date. The system will not reserve inventory if the system calculated date is greater than today’s date. This is considered a future order line. The system identifies the item on the order as a future order line and assigns a backorder status to the item. Note: If the Reservation Lead Days (B27) system control value is 0, the system does not calculate whether the order line is a future order line and reserves inventory for the line on the order. Updates the Arrival date field in the Order Detail table; see the Arr date at the Display Order Detail Screen (Reviewing Order Line Detail).
line_cancel_date	numeric	8	Updates the Cancel date field in the Order Detail table; see the Cancel date at the Display Order Detail Screen (Reviewing Order Line Detail). Uses a date in the past if provided in the message; otherwise, if the message does not provide a date or if the date is invalid, leaves the line cancel date blank. MMDDYYYY format.
cord_group	numeric	3	Updates the Coordinate group field in the Order Detail table. See the C/G at the Display Order Detail Screen (Reviewing Order Line Detail).
actual_price	numeric	7.2	Updates the Price field in the Order Detail table if a prc_ovr_rsn is specified and the price_override flag is set to Y. See the Price field at the Display Order Detail Screen (Reviewing Order Line Detail).
prc_ovr_rsn	alphanumeric	1	Updates the Price Override Code field in the Order Detail table and the actual_price is used if the price_override attribute is set to Y; see the Ovr field at the Display Order Detail Screen (Reviewing Order Line Detail). If the price override reason code specified here is not valid, the system uses the Price Override Reason for E-Commerce (G73), if any, or the Default Price Override Reason (B35); however, if no price override reason code is passed in the message, the system does not override the price on the order detail line, even if an actual_price is specified. See Price Override Reason for E-Commerce (G73) for an overview. Price table override: If the order uses price table pricing, no actual_price is specified for the item in the message, and the prc_ovr_rsn matches the Price Table Level Override Code (E05), then the order API applies the best price level available to the order line. See the Price Table Level Override Code (E05) system control value for a discussion.
			Quantity price matrix: If the order uses quantity price matrix pricing and no actual_price is specified for the item in the message, then the order API uses the Quantity Price Matrix Price Hierarchy to apply a quantity price matrix price to the order line. If the item on the order line qualifies for a Quantity Price Matrix Customer Special, the system applies the discount price to the order line and assigns the Price Override Reason for Price Matrix Customer Specials (K42) to the order line during End of Order Quantity Price Matrix Pricing. See Working with Quantity Price Matrix (WQPM) for more information on quantity price matrix pricing. Note: Do not use the Price Override Reason for Price Matrix Customer Specials (K42) as the override reason code for any manually entered price that you define in the actual_price. Order history message: Unlike interactive order entry, the order API does not write an order history message when the price is explicitly (rather than automatically) overridden.
quantity	numeric	5	Updates the Qty ordered field in the Order Detail table. If no quantity is specified here, the system uses the Default Order Quantity (B30). A negative quantity (indicated by a minus sign (-) preceding the number) indicates a return. See Processing a Return for an overview. If the quantity specified here is not evenly divisible by the Sell quantity for the item/SKU, the order line will be in error with a reason of Multiples error.
bypass_reserve	alphanumeric	1	Updates the Bypass reservation field in the Order Detail table, and prevents the line from being reserved when set to Y.
tax_override	alphanumeric	1	Updates the Tax override field in the Order Detail table. If this flag is set to Y, the system does not call the regular tax routine or Vertex to calculate tax, and instead just uses the tax_amount passed in the message. Shipments: If you process multiple shipments against the line, the system prorates the tax override amount across the units shipped on the order line to determine the new tax override amount and the tax amount to apply to each shipment. Example: If the tax override amount for the order line is 9.00 and the order quantity is 3, the system charges 3.00 if you ship 1 unit of the item and then charges 6.00 if you ship the remaining 2 units of the item. Returns: If you process a return, the system prorates the tax override amount across the units ordered on the order line to determine the new tax override amount and the tax amount to return. See Tax Overrides and Return Processing for an overview. Vertex: See the Send Tax to Vertex as Quote Not Invoice (L11) for information on how the Vertex interface sends a tax override.
tax_amount	numeric	10.5	Updates the Tax field in the Order Detail table if the tax_override flag is set to Y. See the Tax field at the Display Order Detail Screen (Reviewing Order Line Detail).
gst_amount	numeric	10.5	Updates the GST field in the Order Detail table if: • the tax_override flag is set to Y • the tax_amount specifies a total tax amount for the order detail line • the customer is subject to Canadian tax (GST and PST) based on regular tax logic Note: The total GST and PST should equal the tax_amount; however, the system does not validate that the total gst_amount and pst_amount does not exceed the tax_amount specified. Vertex: See the Send Tax to Vertex as Quote Not Invoice (L11) for information on how the Vertex interface sends a tax override.
pst_amount	numeric	10.5	Updates the PST field in the Order Detail table if: • the tax_override flag is set to Y • the tax_amount specifies a total tax amount for the order detail line • the customer is subject to Canadian tax (GST and PST) based on regular tax logic The total GST and PST should equal the tax_amount; however, the system does not validate that the total gst_amount and pst_amount does not exceed the tax_amount specified. Vertex: See the Send Tax to Vertex as Quote Not Invoice (L11) for information on how the Vertex interface sends a tax override.
gift_wrap	alphanumeric	1	If set to Y, updates the Gift wrap flag in the Order Detail table and adds the gift wrap charge to the order; see the G/W and G/W $ at the Display Order Detail Screen (Reviewing Order Line Detail). If the item/offer or SKU/offer does not allow gift wrap, the order will be in error with a reason of Gift wrap not allowed.
cost_override_amount	numeric	11.4	Updates the Cost override field in the Order Detail table. See the Cost override field at the Display Order Detail Screen (Reviewing Order Line Detail).
line_priority	numeric	1	Updates the Priority field in the Order Detail table. See the Priority field at the Display Order Detail Screen (Reviewing Order Line Detail).
line_freight_ override	alphanumeric	1	If set to Y, updates the Freight override? field in the Order Detail table and applies the line_freight_override_amount as the freight amount for the order detail line; see the Freight field at the Display Order Detail Screen (Reviewing Order Line Detail). If any other value is passed, the order API sets the Freight override? field to N. If the line_freight_override_amount is blank, then no freight will be charged for the order detail line. If the freight method on the order is not a line-level freight method, the order will be in error with a reason of Invalid line frt override.
line_freight_ override_ amt	numeric	7.2	If the line_freight_override is set to Y and the freight method on the order is a line-level freight method, updates the Freight charge field in the Order Detail table; otherwise, the system ignores this value. See the Freight field at the Display Order Detail Screen (Reviewing Order Line Detail).
line_coupon_flag	alphanumeric	1	If set to Y, indicates that the line_coupon_amount should be applied to the order detail line. The same as setting the Cpn field at the Work with Order Line Screen (Changing/Adding an Item) in interactive order entry.
line_coupon_amount	numeric	7.2	The discount amount to apply to the order detail line. This discount amount is the same as entering the Coupon amt field at the Work with Order Line Screen (Changing/Adding an Item) in interactive order entry.
personalization_id	alphanumeric	2	Updates the Add’l chg code in the Order Detail table. Overrides the additional charge code, if any, from the Item Offer or SKU Offer. Required if the item should have special handling; if no personalization_id is specified, the additional charge code from the Item Offer or SKU Offer does not default, regardless of the setting of the Suppress S/H window flag for the additional charge code. Use the personalization_line element to specify the special handling details for the order line. If the Item Offer or SKU Offer does not have the Special handling flag selected, the order will be in error with a reason of S/H code not allowed. See the Create Item Offer Screen for more information on specifying special handling for an Item Offer or SKU Offer. If the value specified here does not represent a special handling code as set up through Establishing Additional Charge Codes (WADC), the order will be in error with a reason of S/H code is invalid. You might use pass a personalization_id but no personalization charges or information in order to automatically put an order line on hold if the special handling format’s S/H hold flag is selected. See Putting a Line on Hold through a Special Handling Format for a discussion.
personalization_cost	numeric	7.2	Updates the Special handling $ field in the Order Detail table. If no charge is specified here, the system uses the regular hierarchy to determine the special handling charge or price; see Special Handling Overview. Note: It is possible to add special handling charges without actually creating the special handling instructions for the order line if: • complete instructions are not specified in the personalization_line element, and • a personalization_id is specified, and • a personalization_cost is specified here, or • a S/H price is specified for the Item Offer or SKU Offer You might use the above information to automatically put an order line on hold if the special handling format’s S/H hold flag is selected. See Putting a Line on Hold through a Special Handling Format for a discussion.
gc_number	numeric	7	The system uses this number only when: • the item ordered on this order detail line is a gift certificate • the gift certificate number specified here is not already assigned Otherwise, if the item is a gift certificate, the system assigns a gift certificate number through the normal process; see Working with Gift Certificates. Note: Do not specify a gift certificate number if the quantity for the order detail line is more than 1; if you specify a gift certificate number, the system creates just one gift certificate.
alias_item	alphanumeric	12	Updates the Alias field in the Order Detail table. Used to identify the item and SKU for the order detail line. See Resolving the Item and SKU in the Order API. If Display Item Alias (D56) is selected, order inquiry displays the alias rather than the item code when you pass the alias rather than the item code in the message.
item_id	alphanumeric	12	Updates the ITM number field in the Order Detail table. Used to identify the item and SKU for the order detail line. Must be a valid item code in CWSerenade. See Resolving the Item and SKU in the Order API. Note: • To create an order that includes a set or continuity item, the message should include the master set or continuity item only. The set or continuity will be “exploded” once the order is created, and all of the component items will be added to the order. • To create a customer membership, the item_id needs to be an item code that is identical to an active membership program. For example, to create a customer membership for membership program MEMB01, the item_id needs to be MEMB01; and MEMB01 needs to be a valid item code flagged as a membership item. • When a customer purchases a membership item and the payment information is passed separately, the system does not create the customer membership or apply any membership discount until receiving the payment message. In this situation, the system initially applies an error to the order: Missing Membership.
sku	alphanumeric	14	Updates the SKU code field in the Order Detail table. Used to identify the item and SKU for the order detail line. See Resolving the Item and SKU in the Order API.
short_sku_number	numeric	7	Used to identify the item and SKU for the order detail line. See Resolving the Item and SKU in the Order API. Note: When passing the UPC code, make sure to include any leading zeros. For example, if the UPC code is 06012011, pass 06012011 and not 6012011.
retail_ref_number	numeric	15
upc_type	alphanumeric	3
upc_code	alphanumeric	14
line_offer	alphanumeric	3	Updates the OFR number field in the Order Detail table to control pricing and track demand. The system applies the offer to the order detail line only if there is a record of the item or SKU in this offer. See the Ofr at the Display Order Detail Screen (Reviewing Order Line Detail) and see the Override Offer on Order Detail Line (D49) for information on how this system control value affects how to determine pricing and post demand when the message specifies an offer at the order detail level.
line_source_ code	alphanumeric	9	Updates the Source code field in the Order Detail table; see the Source at the Display Order Detail Screen (Reviewing Order Line Detail). Also defaults to the order header if no header-level source code is specified in the message; see the source_code attribute for more information. Note: If a line-level source code is invalid, the order will be suspended with an error of Invalid Source Code.
line_shipping_ method	numeric	2	Updates the VIA ship via code field in the Order Detail table. The ship via must be eligible to ship the item on the order line; see Item Ship Via Override Logic See the Ship via at the Display Order Detail Screen (Reviewing Order Line Detail). If you leave this attribute blank and the order line does not qualify for an item ship via override, the system uses the ship via code defined on the order header for the order line. If the ship via in this attribute matches the ship via in the Default Van Delivery Ship Via (L07) system control value, or if you leave this attribute blank and the ship via on the order header matches the van delivery ship via, the system validates that the shipping address on the order qualifies for van delivery and that the line_warehouse either contains the Reserve warehouse defined for the shipping address or is blank and the warehouse on the order header matches the Reserve warehouse defined for the shipping address. See Van Delivery Processing through the Generic Order Interface (Order API).
Returns and express bills: You can use the following values to process a return (see Processing a Return) or an express bill if the order has already shipped. If the message does not specify a warehouse and location for a return or express bill, the system uses the default warehouse and primary primary location for the item from the SKU table. Inventory transaction errors: Whether the warehouse and location are specified in the message or default from the SKU table, they must be eligible for the transaction or an inventory transaction error occurs with an error reason of Negative On Hand. A warehouse and location cannot process an express bill or a return if: • the location is frozen • the location is not pickable • the warehouse is not allocatable • there is no record of the item in the location, or not a sufficient quantity on-hand to process the express bill Even though the order API creates the inventory transaction error record, it still creates the order without leaving it suspended due to the inventory transaction error, and the order is then eligible to be processed for billing. See Working with Inventory Transaction Errors (WITE) for more information on reviewing inventory transaction errors. Order errors: If the warehouse or location that default or that are specified in the message are invalid, the order API does not create an inventory transaction error; instead, it leaves the order suspended and returns an error in the Detailed Order XML Response (CWORDEROUT) if the response_type is E. The warehouse or location are invalid if: • the warehouse does not exist • the location does not exist in the warehouse See Order Creation Errors for more information on possible order API errors. Note: If an express-billed order includes an A/R payment method, the order might briefly go into held status before it is processed by billing and its status changes to closed.
line_warehouse	numeric	3	Defines the warehouse where the item will be reserved from. If the item cannot be reserved from this warehouse, the system places the item on backorder in this warehouse. Also used when processing a return (the quantity is negative) or an express bill. If the warehouse is not eligible for the express bill or return transaction, the order API creates an inventory transaction error. Updates the WHS warehouse field in the Order Detail table; see the Warehouse at the Display Order Detail Screen (Reviewing Order Line Detail). If no warehouse is specified here, the order API: • uses the warehouse defined on the order header. • looks for a warehouse list for the SCF of the order ship to address. • uses the default warehouse for the item from the SKU record. If the item warehouse does not exist, the order will be in error with a reason of Item not valid for whs.
location	alphanumeric	7	Indicates the location where the returned merchandise is placed, or where to affect inventory for an express bill line. If the item has not been previously placed in this location, the system creates an Item Location record. If no location is specified here, the order API uses the primary primary location for the item from the SKU record. If the location does not exist in the specified warehouse, the order will be in error with a reason of Missing Whse/Loc-No IT Ln. If the location is not eligible for the express bill or return transaction, the order API creates an inventory transaction error; see the discussion above for more information.
return_reason	numeric	3	Used to track a return. Use the Display Order Line History Screen to review the return reason code used for an order detail line. The system leaves the return reason code for the order line blank if no reason is specified in the message. Similarly, if the message specifies a return reason code that does not exist in the Return Reason table, the system does not put the order in error; instead, it writes the value passed to the Order Line History and other tables that are normally updated as part of processing a return.
return_ disposition	alphanumeric	2	Used to indicate how to process a return. If the message does not specify a valid return disposition value (that is, the return_disposition is invalid or is blank), the system uses the Default Disposition Code (C18). Note: The system uses this return disposition code to determine whether the return updates inventory and the warehouse and location to which the item is returned; however, the system does NOT store this return disposition on the RA Detail record.
price_override	alphanumeric	1	If this field is set to Y and there is no prc_ovr_rsn specified, the system uses the Price Override Reason for E-Commerce (G73), if any, or the Default Price Override Reason (B35) when creating the order line. See Price Override Reason for E-Commerce (G73) for an overview.
Note: The following three values relate to creating a store fulfillment request. This option is not currently implemented.
pickup_type	alphanumeric	2	Not currently implemented.
pickup_system_location	alphanumeric	10	Not currently implemented.
pickup_location	alphanumeric	10	Not currently implemented.
line_entered_ date			Not currently implemented.
line_entered_ time			Not currently implemented.
line_hyperlink	alphanumeric	256	Updates the Hyperlink field in the Order Detail table. If a link is passed, you can review it from the Display Hyperlink Screen in order inquiry. Saved in upper and lowercase if that is how the link is passed in the inbound message. See Translating Special Characters for information on how to pass certain special characters using replacement text strings. Available in XML version: Version 4.0 (release 2.5 of CWSerenade).
Lin_Msg The Lin_Msgs element, if provided, can include one or more Lin_Msg elements.
lin_msg_code	alphanumeric	1	Updates the Print? field in the Order Line Message table. See Work with Order Line Messages Screen for more information.
lin_msg_text	alphanumeric	60	Updates the Message field in the Order Line Message table. See Work with Order Line Messages Screen for more information. Saved in upper and lowercase if that is how the text is passed in the inbound message. Messages longer than 60 positions are truncated.
personalization_line The personalization_lines element, if provided, can include one or more personalization_line elements. The system uses the following information to build special handling instructions for the order detail line if a valid personalization_id is specified: • Standard special handling: • The personalization_type should be set to S (standard). • You can include one or more standard_text attributes to build one or multiple lines of custom special handling instructions. If any standard_text entry exceeds 30 positions, the additional data in the special handling instructions is truncated. • Custom special handling: • The personalization_type should be set to C (custom). • The message should always include data or a blank space in each personalization line, and all lines sent in the sequence in which they were set up through Establishing Custom Special Handling Formats (WSHF). If the personalization lines do not represent a complete, valid set of instructions according to the special handling format, the special handling code and charge are still added to the order; however, the order will either be in error, or the order line will include the special handling code and charge, but the instructions will be incomplete or missing. Putting the order line on hold: If you use a special handling format whose S/H hold flag is selected, the order API automatically puts the order line on hold. See Putting a Line on Hold through a Special Handling Format for a discussion. For more information: See the sample message formats under Inbound Order Message: Sample XMLs.
personalization_type	alphanumeric	1	Indicates the type of special handling. Valid values are: • C = Custom • S = Standard Note: If this value is the wrong type for the personalization_id, the order will not be in error; however, no special handling instructions will be built.
personalization_text	alphanumeric	45	Used for custom special handling instructions. Updates the Input field in the Order Special Format table for custom special handling. Saved in the upper and lowercase if that is how the text is passed in the inbound message. You should send the personalization_line with the personalization_text set to “ “ in order to create a blank custom special handling line for the order so that the personalization information is created correctly. Note: Default text defined for the special handling format does not default for orders created through the Inbound Order Message.
			Errors: If the text is not a valid entry for the custom special handling format, the order is in error with a reason of Input not valid response. If the text exceeds the maximum specified for the custom special handling format, the order is in error with a reason of Exceeds maximum character. If the text does not conform to a rule set up for the custom special handling format, the order is in error with a reason of SH Resp fail defined rule. See Work with Special Format Rules Screen for background.
standard_text	alphanumeric	30	Used for standard special handling instructions. Updates the S/H info field in the Order Special Handling table for standard special handling. Saved in the upper and lowercase if that is how the text is passed in the inbound message. There can be more than one lines of standard text included in multiple standard_text attributes. Any standard_text entry that exceeds 30 positions is truncated from the special handling instructions.
CouponDetail Available in XML version: 2.0 (release 1.1 of CWSerenade).
coupon_ detail_code	alphanumeric	6	Optionally, specify a detail-level coupon (Coupon type = D) to apply against an order detail line, or an order-level coupon (Coupon type = O) to apply against the order. The customer can apply multiple coupons against an item or order provided they pass all coupon edits. See Working with Coupon Promotions (WCPR) for an overview on coupons, and see Understanding Coupon Error Messages through the Order API for possible error messages.
Profile The profile data, if any, passed through this element updates the customer’s demographic data. You can review a customer’s demographic data at the Work with Customer Profile Screen. You define customer profile categories, such as age, income, or gender, and the valid values for each category through Setting Up Customer Profiles (WPFL). Available in XML version: 3.0 (release 2.0 of CWSerenade).
profile_code	numeric	3	Optionally, specify a profile code to identify demographic data for the customer. The profile_code represents the Profile code specified through Setting Up Customer Profiles (WPFL). In order to update the customer’s demographic data, the profile code you pass must already exist in the Profile table; however, if the profile code specified is invalid, the system does not put the order in error. You can review a customer’s demographic data at the Work with Customer Profile Screen. • If the profile value you pass does not currently exist for the customer, the system creates the value for the customer. • If the profile value you pass already exists for the customer, the system updates the value. Updates the Profile code in the Customer Profile table.
profile_value	alphanumeric	1	The valid value set up for the Profile code. See Setting Up Customer Profiles (WPFL) for setup information. In order to update the customer’s demographic data, the profile value you pass must already exist in the Profile Data table; however, if the profile value specified is invalid, the system does not put the order in error. You can review a customer’s demographic data at the Work with Customer Profile Screen. • If the profile value you pass does not currently exist for the customer, the system creates the value for the customer. • If the profile value you pass already exists for the customer, the system updates the value. Updates the PDA Profile data code in the Customer Profile table.
Coupon Available in XML version: 2.0 (release 1.1 of CWSerenade).
coupon_code	alphanumeric	6	Optionally, specify an order-level coupon (Coupon type = O) to apply against the order. The customer can apply multiple coupons against an order provided they pass all coupon edits. See Working with Coupon Promotions (WCPR) for an overview on coupons, and see Entering Coupon Promotions on an Order for possible error messages.

Inbound Order Message: Sample XMLs

Samples of the Inbound Order XML Message (CWORDERIN) are presented below.

Initial order message

</Payments>

<Items>

</Items>

</ShipTo>

</ShipTos>

</Header>

</Message>

Payment-only order message

</Payments>

</Header>

</Message>

Sales transaction order message

</Payments>

<Ord_Msgs>

<Ord_Msg ord_msg_text="POS Transaction #30000049" />

</Ord_Msgs>

<Items>

<Lin_Msgs>

<Lin_Msg />

</Lin_Msgs>

</Item>

</Items>

</ShipTo>

</ShipTos>

</Header>

</Message>

Quote order message

<Items>

</Items>

</ShipTo>

</ShipTos>

</Header>

</Message>

Customer return order message

</Payments>

<Ord_Msgs>

<Ord_Msg ord_msg_text="POS Transaction #30000047" />

<Ord_Msg ord_msg_text="Original Transaction #30000016" />

</Ord_Msgs>

<Items>

<Lin_Msgs>

<Lin_Msg />

</Lin_Msgs>

</Item>

</Items>

</ShipTo>

</ShipTos>

</Header>

</Message>

CWOrderIn message with custom special handling

</Payments>

<Items>

<personalization_lines>

<personalization_line personalization_type="C" personalization_text="first" />

<personalization_line personalization_type="C" personalization_text="blue" />

<personalization_line personalization_type="C" personalization_text=" " />

</personalization_lines>

</Item>

</Items>

</ShipTo>

</ShipTos>

</Header>

</Message>

Order Interface XML Message Formats

Contents

SCVs

Search

Glossary

Reports

Database

Solutions

XML

Index

Detailed Order XML Response (CWORDEROUT)

GO01_01x Serenade 5.0 March 2015