Generic Order Interface (Order API) | Contents | SCVs | Search | Glossary | Reports | Solutions | XML | Index | Order Creation Errors |
Order Interface XML Message Formats
In this chapter:
• Inbound Order XML Message (CWORDERIN)
• Inbound Order Message: Sample XMLs
- Sales transaction order message
- Customer return order message
- CWOrderIn message with custom special handling
• Detailed Order XML Response (CWORDEROUT)
- Detailed Order Response Message: Sample XML
• Order Acknowledgement XML Message (CWORDEROUT)
- Order Acknowledgement Message: Sample XML
• Order Reject Request Message (CWORDERREJECT)
- Order Reject Request Message: Sample
- Order Reject Response Message: Samples
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 MQ 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 MQ Log for details.
Message Attribute |
Type |
Length |
Comments |
One Message element is required. |
|||
source |
alpha |
|
IDC |
target |
alpha |
|
RDC |
alpha |
|
CWORDERIN |
|
resp_qmgr |
alpha |
44 |
Not currently implemented. |
resp_q |
alpha |
44 |
Not currently implemented. |
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. |
|||
numeric |
3 |
Identifies the company for the order. Validated against the Company table. Padding with zeroes (for example, 005) is optional. Required. |
|
alpha |
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 Alternate order 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 |
alpha |
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. |
numeric |
9 |
Indicates the Order Management System order number to update when the payment information is sent separately from the rest of the order. See Sending a Separate Payment Message. |
|
alpha |
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. |
|
alpha |
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. |
alpha |
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: A setting of E is valid in version 2.0, available in release 1.1 of Order Management System. 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. |
|
|
|
|
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 |
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. |
|
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. |
|
numeric |
6 |
Entered time in the Order Header table, which you can review at the Display Order Properties Screen. |
|
alpha |
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, 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. |
|
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. |
|
alpha |
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. |
|
alpha |
8 |
Not implemented. |
|
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. |
|||
alpha |
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 |
alpha |
15 |
Maps to the First name field in the Customer Sold To table. |
sold_to_initial |
alpha |
1 |
Maps to the Initial field in the Customer Sold To table. |
sold_to_lname |
alpha |
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 |
alpha |
3 |
Maps to the Suffix field in the Customer Sold To table. |
sold_to_company |
alpha |
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. |
alpha |
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 |
alpha |
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 |
alpha |
32 |
Maps to the Address line 2 field in the Customer Sold To table. |
sold_to_address3 |
alpha |
32 |
Maps to the Address line 3 field in the Customer Sold To Extended table. |
sold_to_address4 |
alpha |
32 |
Maps to the Address line 4 field in the Customer Sold To Extended table. |
sold_to_apartment |
alpha |
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 |
alpha |
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 |
alpha |
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 |
alpha |
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 |
alpha |
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). |
alpha |
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. |
|
alpha |
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. |
|
alpha |
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). |
|
alpha |
14 |
||
sold_to_fax_phone |
alpha |
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). |
alpha |
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. |
|
alpha |
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 |
alpha |
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 |
alpha |
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. |
alpha |
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. |
|
numeric |
3 |
Not implemented. |
|
ind_dept |
alpha |
3 |
Not implemented. |
ind_position |
alpha |
3 |
Not implemented. |
ind_prefix |
alpha |
3 |
Not implemented. |
ind_fname |
alpha |
15 |
Not implemented. |
ind_initial |
alpha |
1 |
Not implemented. |
ind_lname |
alpha |
25 |
Not implemented. |
ind_suffix |
alpha |
3 |
Not implemented. |
ind_day_phone |
alpha |
14 |
Not implemented. |
ind_eve_phone |
alpha |
14 |
|
ind_fax_phone |
alpha |
14 |
|
alpha |
50 |
Not implemented. |
|
alpha |
2 |
Not implemented. |
|
ind_mail_flag |
alpha |
1 |
Not implemented. |
ind_rent_flag |
alpha |
1 |
Not implemented. |
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. |
|
Note: • If bill-to name and address information is specified in the following attributes, it is used to create a new bill-to customer 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. |
alpha |
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 |
alpha |
15 |
|
bill_to_initial |
alpha |
1 |
|
bill_to_lname |
alpha |
25 |
|
bill_to_suffix |
alpha |
3 |
|
bill_to_company_name |
alpha |
30 |
|
bill_to_address1 |
alpha |
32 |
|
bill_to_address2 |
alpha |
32 |
|
bill_to_address3 |
alpha |
32 |
|
bill_to_address4 |
alpha |
32 |
|
bill_to_apt |
alpha |
10 |
|
bill_to_city |
alpha |
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 |
alpha |
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. |
alpha |
10 |
Required only if the Require postal code? flag is selected for the country. |
|
alpha |
3 |
Required if the message includes bill-to information. |
|
bill_to_email |
alpha |
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 |
alpha |
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 |
alpha |
||
bill_to_fax_phone |
alpha |
||
bill_to_print_statement |
alpha |
1 |
Not implemented. |
bill_to_opt_in |
alpha |
2 |
Not currently implemented. |
user_hold_reason |
alpha |
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. |
numeric |
12 |
Not implemented. |
|
alpha |
8 |
Not implemented. |
|
alpha |
1 |
Not implemented. |
|
alpha |
1 |
Not implemented. |
|
numeric |
5 |
Not implemented. |
|
numeric |
7 |
Not implemented. |
|
numeric |
9.2 |
Not implemented. |
|
alpha |
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. |
|
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. |
|
alpha |
30 |
||
alpha |
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 or if the user ID is invalid, your default user ID defaults. |
|
customer_class |
alpha |
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. |
alpha |
50 |
Updates the order-level email address. If no order_email is provided, the system uses the 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 |
alpha |
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 |
alpha |
4 |
The customer price group to assign to the sold-to customer. Available in: 4.0 (release 2.5 of Order Management System). 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. |
alpha |
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-for-pickup, 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: 6.0 (release 3.5 of Order Management System). |
|
ecommerce_id |
alpha |
32 |
The customer number identifying the customer in the e-commerce site. Used as part of the Customer Engagement Customer Integration to help synchronize customer information between Order Management System and Oracle Retail Customer Engagement. Used only if the ORCE Customer Integration (L37) system control value is set to INTERACT. See Customer Synchronization through the Order API for a discussion. Available in: 8.0 (release 4.5 of Order Management System). |
relate_cust_ sync_success |
alpha |
1 |
Indicates whether the e-commerce site has successfully synchronized information about the customer with Oracle Retail Customer Engagement. Used as part of the to help synchronize customer information between Order Management System and Oracle Retail Customer Engagement. Used only if the ORCE 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: 8.0 (release 4.5 of Order Management System). |
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. |
|||
alpha |
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 |
alpha |
40 |
A description of the product. Updates the Description field in the Customer Ownership table. |
cust_own_active |
alpha |
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. |
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 |
alpha |
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 |
alpha |
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. |
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. 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 |
alpha |
15 |
Identifies the type of field to update in the Order Header User Field table. |
usr_fld_data |
alpha |
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. |
The Payments element can include one or more Payment elements. At least one payment method is required. |
|||
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. |
alpha |
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). |
|
alpha |
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. |
alpha |
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). Order Management System retains the case of the value passed in this field. Required for credit card payment methods 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 Order Management System, the system encrypts the value in this field in the Order Management System database to provide additional security of credit card data. See the Data Security and Encryption Guide. |
|
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. |
|
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 |
alpha |
10 |
Updates the Issuing bank field in the Order Payment Method table. This field is not currently used. |
defer_bill |
alpha |
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 |
alpha |
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. |
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 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. |
|
alpha |
16 |
Used for credit card payment methods. Oracle Retail Customer Engagement stored value card integration: If you are using the Customer Engagement Stored Value Card Integration and the web order contains an approved Oracle Retail Customer Engagement stored value card pay type, the auth_number attribute should contain the transaction ID received from Oracle Retail Customer Engagement and not the authorization code received from Oracle Retail Customer Engagement. 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. |
|
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. |
|
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. |
numeric |
7 |
Not currently implemented. |
|
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. |
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 |
alpha |
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. Order Management System 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: 4.0 (release 2.5 of Order Management System). |
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. |
|
alpha |
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 |
Not currently implemented. |
bml_version |
numeric |
5 |
Not currently implemented. |
birthdate |
numeric |
8 |
Not currently implemented. |
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. |
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: 4.0 (release 2.5 of Order Management System). |
|
alpha |
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 Order Management System receives the web order; see the Security Guide for processing details. Updates the Tokenized field in the Order Payment Method table. Available in: 4.0 (release 2.5 of Order Management System). |
|
alpha |
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: 5.0 (release 3.0 of Order Management System). |
|
alpha |
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 Order Management System; 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: 5.0 (release 3.0 of Order Management System). |
|
alpha |
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 Order Management System; 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 Decision Manager code should not be passed in this field. It should only be used to represent the successful/declined authorization of the gift card or credit card. See Cybersource Decision Manager Fraud Scoring for background. 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: Order Management System 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: 6.0 (release 3.5 of Order Management System). |
alpha |
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 Order Management System; 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: Order Management System 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: 6.0 (release 3.5 of Order Management System). |
alpha |
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 Order Management System; 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: Order Management System does not validate that the response code is a valid response for the authorization service defined for the credit card payment method. Available in: 6.0 (release 3.5 of Order Management System). |
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 |
alpha |
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 |
alpha |
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 |
alpha |
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. |
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. |
|
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. Tax System: See the Send Tax to Tax Interface as Quote Not Invoice (L11) for information on how the an external tax system sends a tax override. Available in: 6.0 (release 3.5 of Order Management System). |
|
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. Tax System: See the Send Tax to Tax Interface as Quote Not Invoice (L11) for information on how an external tax system sends a tax override. Available in: 6.0 (release 3.5 of Order Management System). |
|
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. |
alpha |
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. |
|
alpha |
1 |
Allows you to pass 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 tax identification information you pass applies to the order ship to only; the system does not update the customer sold to with the tax identification information. • If the sold to customer on the order is tax exempt (the Tax code 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: 6.0 (release 3.5 of Order Management System). |
alpha |
30 |
The customer’s tax identification number, typically the resale or exempt certificate number assigned to a customer who is identified as tax exempt (E) or as a reseller (R). Any combination of letters, numbers, or special characters is accepted. Used if the sold to customer is tax exempt (the Tax code 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 tax identification information you pass applies to the order ship to only; the system does not update the customer sold to with the tax identification information. • If the sold to customer on the order is tax exempt (the Tax code 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. Updates the Resale/exempt # (Tax identification) in the Order Ship To table; see Tax identification at the Display Order Properties Screen. |
|
ship_complete |
alpha |
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 |
alpha |
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)). |
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. |
|
alpha |
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. |
|||
alpha |
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 |
alpha |
15 |
|
ship_to_initial |
alpha |
1 |
|
ship_to_lname |
alpha |
25 |
|
ship_to_suffix |
alpha |
3 |
|
ship_to_company |
alpha |
30 |
|
ship_to_address1 |
alpha |
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 |
alpha |
32 |
|
ship_to_address3 |
alpha |
32 |
|
ship_to_address4 |
alpha |
32 |
|
ship_to_apartment |
alpha |
10 |
|
ship_to_city |
alpha |
25 |
|
ship_to_state |
alpha |
2 |
Required only if the Require state? flag is selected for the country. |
ship_to_zip |
alpha |
10 |
Required only if the Require postal code? flag is selected for the country. |
ship_to_country |
alpha |
3 |
Required if a ship-to address is provided. |
ship_to_email |
alpha |
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 |
alpha |
1 |
Valid values are: • B = business • R = residence |
ship_to_day_phone |
alpha |
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 |
alpha |
||
ship_to_fax_phone |
alpha |
||
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. |
|
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). |
|
alphanumeric |
15 |
Updates the Purchase order # field in the Order Ship To table; see the Purchase order # at the Display Order Properties Screen. |
|
gift_message |
N/A |
N/A |
Not currently implemented. |
alpha |
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 |
alpha |
12 |
The store code where the customer wants to pick up a ship-for-pickup 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-for-Pickup Orders for an overview. Available in: 4.0 (release 2.5 of Order Management System). |
delivery_type |
alpha |
1 |
A setting of P identifies a store pickup order, and a setting of S identifies a ship-for-pickup 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-for-Pickup Orders for an overview. • If the Payment at POS for Ship for Pickup Orders (L60) system control value is selected, this is a ship-for-pickup 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 for Pickup. See Ship-for-Pickup Orders for an overview. Available in: 5.0 (release 3.0 of Order Management System). |
Validation of the store_code and delivery_type: • If the delivery_type is S (ship-for-pickup) or P (store pickup) and the store_code is a valid store, creates a ship-for-pickup 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-for-pickup order, or do a store pickup search for a store pickup order.) |
|||
alternate_ship_to_id |
|
|
Not currently implemented. |
add_chg_count |
|
|
Not currently implemented. |
already_eval_by_promote |
alpha |
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 Order Management System). |
promote_maint |
alpha |
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 Order Management System). |
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 ORCE Loyalty (M06) and Prorate Dollar Discounts and Coupons (D90) system control values are selected. See the Customer Engagement Loyalty Integration, specifically, Applying Awards during the Generic Order Interface (Order API) for more information. Available in: 8.0 (release 4.5 of Order Management System). |
The AdditionalCharges element, if provided, can include one or more AdditionalCharge elements. |
|||
additional_charge_seq_nbr |
numeric |
3 |
Not currently implemented. |
additional_charge_code |
alpha |
2 |
Updates the Add’l chg code in the Order Additional Charge table; see the Display Additional Charges Screen. 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. |
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 |
alpha |
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 |
alpha |
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). |
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: 3.0 (release 2.0 of Order Management System). |
|||
promotion_code |
alpha |
7 |
The promotion code to apply to the order. See the description of the Promotion element, above, for more information. |
Not implemented. |
|||
certificate_number |
alpha |
40 |
Not implemented. |
certificate_amount |
numeric |
7.2 |
Not implemented. |
transaction_id |
alpha |
40 |
Not implemented. |
The Items element can include one or more Item elements. At least item is required. Note: To create an order that includes a set item, the message should include the master set item only. The set will be “exploded” once the order is created, and all of the component items will be added to the order. |
|||
drop_ship |
alpha |
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 Oracle Retail Order Broker. 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. |
alpha |
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 |
alpha |
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). |
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). |
|
alpha |
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. |
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 |
alpha |
1 |
Updates the Bypass reservation field in the Order Detail table, and prevents the line from being reserved when set to Y. |
tax_override |
alpha |
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 an external tax system 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. Tax System: See the Send Tax to Tax Interface as Quote Not Invoice (L11) for information on how an external tax system 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. The system uses the tax amount to calculate the tax rate for the tax override using the following calculation: (tax amount / extended amount) x 100 = tax override rate The system stores the tax rate for the tax override in the ODT Tax Override Rate field in the Order Detail table; the system uses the tax rate during Order Maintenance if you use the Discount Price window to apply a discount to a shipped item. Billing also uses this tax rate to create the credit invoice and calculate the tax credit amount using the new tax amount. See the Discount Price Window (Applying a Discount to an Item) for an example. See the Tax field and Tax override % 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. The system uses the GST amount to calculate the GST tax rate for the tax override using the following calculation: (GST amount / extended amount) x 100 = GST override rate The system stores the GST tax rate for the GST tax override in the ODT GST Tax Override Rate field in the Order Detail table; the system uses the GST tax rate during Order Maintenance if you use the Discount Price window to apply a discount to a shipped item. Billing also uses this GST tax rate to create the credit invoice and calculate the tax credit amount using the new tax amount. See the Discount Price Window (Applying a Discount to an Item) for an example. Tax System: See the Send Tax to Tax Interface as Quote Not Invoice (L11) for information on how an external tax system 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 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. The system uses the PST amount to calculate the PST tax rate for the tax override using the following calculation: (PST amount / extended amount) x 100 = PST override rate The system stores the PST tax rate for the PST tax override in the ODT PST Tax Override Rate field in the Order Detail table; the system uses the PST tax rate during Order Maintenance if you use the Discount Price window to apply a discount to a shipped item. Billing also uses this PST tax rate to create the credit invoice and calculate the tax credit amount using the new tax amount. See the Discount Price Window (Applying a Discount to an Item) for an example. Tax System: See the Send Tax to Tax Interface as Quote Not Invoice (L11) for information on how an external tax system sends a tax override. |
gift_wrap |
alpha |
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 |
alpha |
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 |
alpha |
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. |
alpha |
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. |
alpha |
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. |
|
alpha |
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 Order Management System. See Resolving the Item and SKU in the Order API. Note: • To create an order that includes a set item, the message should include the master set item only. The set 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. |
|
alpha |
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. |
|
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. |
|
numeric |
15 |
||
alpha |
3 |
||
alpha |
14 |
||
alpha |
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. |
|
alpha |
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. |
|
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. |
|||
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. |
|
alpha |
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. |
|
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. |
|
alpha |
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. |
|
alpha |
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 |
alpha |
2 |
Not currently implemented. |
pickup_system_location |
alpha |
10 |
Not currently implemented. |
pickup_location |
alpha |
10 |
Not currently implemented. |
line_entered_date |
|
|
Not currently implemented. |
line_entered_time |
|
|
Not currently implemented. |
line_hyperlink |
alpha |
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: Version 4.0 (release 2.5 of Order Management System). |
The Lin_Msgs element, if provided, can include one or more Lin_Msg elements. |
|||
lin_msg_code |
alpha |
1 |
Updates the Print? field in the Order Line Message table. See Work with Order Line Messages Screen for more information. |
lin_msg_text |
alpha |
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. |
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. See the sample message formats under Inbound Order Message: Sample XMLs. |
|||
alpha |
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 |
alpha |
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. |
alpha |
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. |
|
Available in: 2.0 (release 1.1 of Order Management System). |
|||
coupon_detail_code |
alpha |
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. |
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: 3.0 (release 2.0 of Order Management System). |
|||
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 |
alpha |
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. |
Available in: 2.0 (release 1.1 of Order Management System). |
|||
coupon_code |
alpha |
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.
<Message source="String" target="String" type="CWORDERIN" >
<Header company_code="6" order_number="ABCDE" payment_only="N" nbr_ship_tos="1" pay_incl="Y" source_code="SOURCE" response_type="E" order_channel="I" sold_to_fname="Eddie" sold_to_lname="Conga" sold_to_address1="10 Main Street" sold_to_city="NATICK" sold_to_state="MA" sold_to_zip="01760" sold_to_country="USA" order_type="W" >
<Payments>
<Payment payment_type="45" cc_number="************1111" start_date="0108" card_issue_nbr="2" />
</Payments>
<ShipTos>
<ShipTo shipping_method="04" customer_ship_to_number="13163" ship_to_type="3" permanent_ship_to_number="1" discount_pct="5.00" ship_to_po_number="PONBR" >
<Items>
<Item quantity="10" item_id="AB100" > </Item>
</Items>
</ShipTo>
</ShipTos>
</Header>
</Message>
<Message source="String" target="String" type="CWORDERIN" >
<Header company_code="6" order_number="ZXYZ" payment_only="Y" nbr_ship_tos="1" pay_incl="Y" source_code="SOURCE" response_type="E" order_channel="I" >
<Payments>
<Payment payment_type="45" cc_number="************1111" start_date="0108" card_issue_nbr="2" />
</Payments>
</Header>
</Message>
Sales transaction order message
<Message source="cws_85_doc" target="cws_xx_doc" type="CWORDERIN">
<Header company_code="5" order_number="30000049" source_code="RETAIL" response_type="N" order_date="10132008" order_channel="P" customer_number="705" pay_incl="Y" order_type="P">
<Payments>
<Payment payment_type="1" suppress_refund_flag="Y" amt_to_charge="500" />
<Payment payment_type="1" suppress_refund_flag="Y" amt_to_charge="-288" />
</Payments>
<ShipTos>
<ShipTo>
<Ord_Msgs>
<Ord_Msg ord_msg_text="POS Transaction #30000049" />
</Ord_Msgs>
<Items>
<Item affect_inventory="N" actual_price="20.2" prc_ovr_rsn="P" quantity="1" tax_override="Y" tax_amount="0.01010" cost_override_amount="0.0000" item_id="KABSKU1 " sku="GRN " line_shipping_method="98">
<Lin_Msgs>
<Lin_Msg />
</Lin_Msgs>
</Item>
</Items>
</ShipTo>
</ShipTos>
</Header>
</Message>
<Message source="IDC" target="RDC" type="CWORDERIN" resp_qmgr="CWIAS400">
<Header company_code="7" order_number="120121" payment_only="N" source_code="SOURCE7" response_type="E" customer_number="56" pay_incl="N" order_type="T" sales_rep_number="1">
<ShipTos>
<ShipTo arrival_date="01042010" ship_to_number="1" shipping_method="" gift="N">
<Items>
<Item quantity="1" item_id="RF1234567890" />
<Item quantity="1" item_id="RF123SKU4567" sku="ROSE XSML WMNS" />
</Items>
</ShipTo>
</ShipTos>
</Header>
</Message>
<Message source="cws_xx_doc" target="cws_xx_doc" type="CWORDERIN">
<Header company_code="5" order_number="30000047" source_code="RETAIL" response_type="N" order_date="10132008" order_channel="P" alternate_sold_to_id="439" sold_to_prefix="MS." sold_to_fname="SARAH" sold_to_lname="BROWN" sold_to_address1="257 APPLE Street" sold_to_city="Worcester" sold_to_state="MA" sold_to_zip="01602" sold_to_country="USA" sold_to_day_phone="5085550100" sold_to_eve_phone="5085550101" sold_to_address_update="N" pay_incl="Y" order_type="P">
<Payments>
<Payment payment_type="99" suppress_deposit_flag="Y" suppress_refund_flag="Y" cc_number="************1111" cc_exp_month="01" cc_exp_year="39" auth_date="10132008" auth_amount="-26.25" />
</Payments>
<ShipTos>
<ShipTo>
<Ord_Msgs>
<Ord_Msg ord_msg_text="POS Transaction #30000047" />
<Ord_Msg ord_msg_text="Original Transaction #30000016" />
</Ord_Msgs>
<Items>
<Item affect_inventory="N" actual_price="25.00" prc_ovr_rsn="P" quantity="-1" tax_override="Y" tax_amount="-1.25000" cost_override_amount="0.0000" item_id="2VSSHIRT-976" line_shipping_method="98" return_reason="44" return_disposition="SR">
<Lin_Msgs>
<Lin_Msg />
</Lin_Msgs>
</Item>
</Items>
</ShipTo>
</ShipTos>
</Header>
</Message>
CWOrderIn message with custom special handling
<Message source="string" target="string" type="CWORDERIN" >
<Header company_code="6" payment_only="N" source_code="SOURCE" response_type="E" order_channel="I" customer_number="13108" pay_incl="Y" order_type="P" order_number="special10">
<Payments>
<Payment payment_type="5" cc_number="************1111" cc_exp_month="12" cc_exp_year="10" auth_number="AUTH" auth_date="07082008" auth_amount="50.00"></Payment>
</Payments>
<ShipTos>
<ShipTo shipping_method="04">
<Items>
<Item quantity="2" item_id="YOURNAME" personalization_id="C" >
<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>
Detailed Order XML Response (CWORDEROUT)
The system generates this response to the Inbound Order XML Message (CWORDERIN) if the response_type is D (detail) or E (errors).
Note:
• All numeric values with decimal positions are passed as explicit decimals. For example, a dollar value of $10.00 is passed as 10.00.
• Attributes are included in the response only if they contain a value. Blank attributes are not passed.
See Detailed Order Response Message: Sample XML for a sample message.
Message Attribute |
Type |
Length |
Comments |
source |
alpha |
|
Identifies the source of the XML message. RDC indicates the XML message originates from Order Management System. |
target |
alpha |
|
Identifies the target of the XML message. |
type |
alpha |
|
Identifies the type of information in the XML message. |
company_code |
numeric |
3 |
The company_code from the Inbound Order Message. |
order_id |
numeric |
8 |
The order number assigned by the system. |
reference_order_number |
alpha |
30 |
The order_number from the Inbound Order Message. |
customer_number |
numeric |
9 |
The number identifying the customer specified in the Inbound Order Message, or created by the system. See Customer Sold To Selection, Creation and Update. |
alternate_sold_to_id |
alpha |
15 |
The Alt cust # field at the Second Create Customer Sold To Screen. |
bill_to_number |
numeric |
7 |
The number identifying the bill-to customer specified in the Inbound Order Message, created by the system, or assigned to the sold-to customer. See Customer Bill To Selection and Creation. Passed only if the customer or order has a bill-to account. |
numeric |
8 |
The order_date from the Inbound Order Message. MMDDYYYY format. |
|
alpha |
2 |
The order_channel from the Inbound Order Message. |
|
alpha |
1 |
Not currently implemented. |
|
alpha |
1 |
The current status of the order. Valid values are: • H = Held • S = Suspended • E = In error Included only if the status is not open (blank). Note: If the Delay Order API Edit (I56) system control value is selected, the status returned will always be E because the system sends the response message before the order edit completes. |
|
order_type |
alpha |
1 |
The order_type from the Inbound Order message or from the E-Commerce Order Type (G42). |
order_type_description |
alpha |
30 |
The description from the Order Type table; see Establishing Order Types (WOTY). |
entered_date |
numeric |
8 |
The enter_date from the Inbound Order Message. MMDDYYYY format. |
entered_time |
numeric |
6 |
The enter_time from the Inbound Order Message. HHMMSS format. |
email_confirm_date |
numeric |
8 |
From the email confirmation date on the Order Header. MMDDYYYY format. |
source_code |
alpha |
9 |
The source_code assigned to the order. |
offer_id |
alpha |
3 |
The offer associated with the source code assigned to the order header. |
Each of the components of the sold-to customer’s name and address, listed below, are passed only if the related field for the customer record has a value specified. |
|||
sold_to_prefix |
alpha |
3 |
|
sold_to_fname |
alpha |
15 |
|
sold_to_initial |
alpha |
1 |
|
sold_to_lname |
alpha |
25 |
|
sold_to_suffix |
alpha |
3 |
|
sold_to_company |
alpha |
30 |
|
sold_to_busres |
alpha |
1 |
|
sold_to_address1 |
alpha |
32 |
|
sold_to_address2 |
alpha |
32 |
|
sold_to_address3 |
alpha |
32 |
|
sold_to_address4 |
alpha |
32 |
|
sold_to_apartment |
alpha |
10 |
|
sold_to_city |
alpha |
25 |
|
sold_to_state |
alpha |
2 |
|
sold_to_state_description |
alpha |
25 |
As set up through Setting Up the Country Table (WCTY). |
sold_to_zip |
alpha |
10 |
|
sold_to_country |
alpha |
3 |
|
sold_to_day_phone |
alpha |
14 |
|
sold_to_eve_phone |
alpha |
14 |
|
sold_to_fax_phone |
alpha |
14 |
This phone 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. |
allow_rent |
alpha |
1 |
|
allow_mail |
alpha |
1 |
|
sold_to_opt_in |
alpha |
2 |
|
Note: The bill-to name and address is from the Customer Bill To table, and is included only if there is a bill-to customer on the order. See Creating and Updating Bill-to Customers (WCBT) for a description of the bill-to information. |
|||
bill_to_prefix |
alpha |
3 |
|
bill_to_fname |
alpha |
15 |
|
bill_to_initial |
alpha |
1 |
|
bill_to_lname |
alpha |
25 |
|
bill_to_suffix |
alpha |
3 |
|
bill_to_company |
alpha |
30 |
|
bill_to_busres |
alpha |
1 |
|
bill_to_address1 |
alpha |
32 |
|
bill_to_address2 |
alpha |
32 |
|
bill_to_address3 |
alpha |
32 |
|
bill_to_address4 |
alpha |
32 |
|
bill_to_apartment |
alpha |
10 |
|
bill_to_city |
alpha |
25 |
|
bill_to_state |
alpha |
2 |
|
bill_to_state_description |
alpha |
25 |
As set up through Setting Up the Country Table (WCTY). |
bill_to_zip |
alpha |
10 |
|
bill_to_country |
alpha |
3 |
|
bill_to_day_phone |
alpha |
14 |
|
bill_to_eve_phone |
alpha |
14 |
|
bill_to_fax_phone |
alpha |
14 |
This phone 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. |
sales_rep_number |
numeric |
7 |
The salesman number assigned to the order. From the SLS Salesman # field in the Order Header table. Available in: 4.0 (release 2.5 of Order Management System). |
sales_rep_name |
alpha |
30 |
The name of the salesman assigned to the order. From the SLS Name field in the Salesman table. Available in: 4.0 (release 2.5 of Order Management System). |
sales_rep_store |
alpha |
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). Note: The store number defined for the order does not have to be associated with the salesrep defined on the Order Header. Available in: 6.0 (release 3.5 of Order Management System). |
See the Display Order Pay Type Screen (1 of 2) for more information on order payment methods. |
|||
payment_seq_number |
numeric |
2 |
Indicates the sequence in which the payment methods were added to the order. From the Order Payment Method table. |
pay_type |
numeric |
2 |
The payment_type from the Inbound Order Message. |
pay_type_desc |
alpha |
30 |
The description associated with the pay type. See Working with Pay Types (WPAY). |
credit_card_nbr |
alpha |
20 |
The cc_number from the Inbound Order Message. If you use credit card encryption, the system decrypts the credit card number before sending it to the external system. See the Data Security and Encryption Guide for an overview. The number is masked (for example, credit_card_nbr="************3456). |
credit_card_exp_dt |
numeric |
4 |
The cc_exp_month and the cc_exp_year from the Inbound Order Message. |
credit_card_auth_dt |
numeric |
8 |
The auth_date from the Inbound Order Message. MMDDYYYY format. |
credit_card_auth_nbr |
alpha |
16 |
The auth_number from the Inbound Order Message. |
start_date |
numeric |
4 |
The start_date from the Inbound Order Message. |
card_issue_nbr |
alpha |
2 |
The card_issue_nbr from the Inbound Order Message. |
check_nbr |
numeric |
9 |
The check_number from the Inbound Order Message. |
gift_cert_nbr |
numeric |
7 |
The gift_certificate_number from the Inbound Order Message. |
numeric |
9.2 |
The amt_to_charge from the Inbound Order Message. |
|
cc_last_four |
numeric |
4 |
The last four digits of the credit card number on the order. From the IPM CC Last 4 field in the Order Payment Method table. Available in: 9.0 (release 15.0 of Order Management System). |
Note: The dollar totals for the ship-to are subject to change until payment is received and the order goes into open status because repricing, promotions, and other final calculations take place at that point. |
|||
ship_to_number |
numeric |
3 |
The number identifying the ship-to address on the order. Assigned by the system. |
sub_total |
numeric |
9.2 |
The merchandise total on the order ship-to, after applying any repricing or discounts. |
discount_total |
numeric |
11.2 |
The discount total on the order ship-to. |
numeric |
7.2 |
Total freight charges for the order ship-to. If the system calculates freight as a percentage of the merchandise charges, there might be a penny variation in total freight amount due to rounding differences. Not included if the order qualifies for free shipping. |
|
tax |
numeric |
7.2 |
The total tax for the order ship-to. |
additional_shipping |
numeric |
7.2 |
The total additional freight (Freight +) for the order ship-to. |
numeric |
7.2 |
The total additional charges for the order ship-to. |
|
handling |
numeric |
7.2 |
The total handling charges for the order ship-to. |
order_total |
numeric |
11.2 |
The total of all merchandise, shipping, charges, handling, and tax for the order ship-to. |
alpha |
1 |
Indicates the status of this shipping address. This status could differ from the order_status if, for example, the order has multiple shipping addresses and you canceled just one. Included only if the status is not open (blank). |
|
numeric |
7.2 |
The total Canadian Goods and Service Tax, if any, that applies to the order shipping address. The GST and the PST are included in the tax total. |
|
numeric |
7.2 |
The total Canadian Provincial Services Tax, if any, that applies to the order shipping address. The GST and the PST are included in the tax total. |
|
alpha |
1 |
The gift flag from the Inbound Order Message. |
|
order_nbr |
alpha |
15 |
The ship_to_po_number from the Inbound Order Message. |
numeric |
5.2 |
The discount percentage, if any, from the Order Ship To table. |
|
numeric |
2 |
The shipping_method from the Inbound Order Message, or the current ship via if the system has overridden it. See Ship Via Override Logic for more information. |
|
alpha |
30 |
The description of the ship via, as set up through Working with Ship Via Codes (WVIA). |
|
shipping_override |
alpha |
1 |
Indicates whether the Freight override flag is set. Set to Y if a freight amount was specified in the inbound order message; otherwise, not included. The Display Order Properties Screen displays the Freight override flag on the order. |
customer_number |
numeric |
9 |
Indicates the recipient customer for the order. Passed only if the shipping address is not the same as the sold-to customer. See Creating or Selecting Shipping Addresses or Customers. |
permanent_ship_to_number |
numeric |
3 |
Indicates the permanent ship-to customer on the order. Passed only if there is a permanent ship-to. |
See Creating or Selecting Shipping Addresses or Customers for an overview of how you specify various types of shipping addresses in the Inbound Order Message. Each of the ship_to name and address attributes listed below is passed only if the related field for the customer, recipient, permanent ship-to or order ship-to specifies a value. |
|||
ship_to_prefix |
alpha |
3 |
|
ship_to_fname |
alpha |
15 |
|
ship_to_initial |
alpha |
1 |
|
ship_to_lname |
alpha |
25 |
|
ship_to_suffix |
alpha |
3 |
|
ship_to_ company |
alpha |
30 |
|
ship_to_busres |
alpha |
1 |
|
ship_to_address1 |
alpha |
32 |
|
ship_to_address2 |
alpha |
32 |
|
ship_to_address3 |
alpha |
32 |
|
ship_to_address4 |
alpha |
32 |
|
ship_to_apartment |
alpha |
10 |
|
ship_to_city |
alpha |
25 |
|
ship_to_state |
alpha |
2 |
|
ship_to_state_description |
alpha |
25 |
As set up through Setting Up the Country Table (WCTY). |
ship_to_zip |
alpha |
10 |
|
ship_to_country |
alpha |
3 |
|
cancel_date |
numeric |
7 |
The date when the order will be canceled if all lines have not shipped, in MMDDYY format. The system will not reserve inventory one day prior to the cancellation date, because the order would not reach the customer in time. Any items that have not shipped one day prior to the cancellation date display on the Order Cancellation List. Customer service uses this list of pending order cancellations to contact each customer and request more time. If this is not possible, Customer Service must cancel the order manually through Order Maintenance. For pre-order quotes, this is the date the quote for an order expires; see Cancelling a Quote through Order Maintenance. From the OST Cancel date field in the Order Ship To table. Available in: 4.0 (release 2.5 of Order Management System). |
delivery_type |
alpha |
13 |
Identifies an order using the Order Broker integration: Store Pickup = the customer picks the entire order up at a store location where the inventory is available Ship for Pickup = the order is shipped to a store location, where the customer picks it up after arrival The ship-to address indicates the selected store for either a store pickup or a ship-for-pickup order. The Detail element in the response message for a store pickup order also includes the order broker status, pickup location, and pickup system. See Ship-for-Pickup Orders or Store Pickup Orders for more information. Available in: 5.0 (release 3.0 of Order Management System). |
line_seq_number |
numeric |
3 |
A unique number to identify each detail line on the order. |
short_sku_number |
numeric |
7 |
From the SKU table; see short_sku_number for more information. Passed regardless of whether the short SKU was specified in the Inbound Order Message. |
retail_ref_number |
numeric |
15 |
See retail_ref_number. Passed only if a retail reference number exists for the item, but regardless of whether it was specified in the Inbound Order Message. |
status |
alpha |
1 |
C = the item is cancelled. P = the item is a store pickup item; see Store Pickup Orders for an overview. S = the item is sold out. X = the item is closed. |
item_id |
alpha |
12 |
Always passed. |
item_description |
alpha |
40 |
The description of the item. |
sku |
alpha |
14 |
Passed only if the item has SKUs. |
sku_description |
alpha |
40 |
The description of the SKU. |
numeric |
7.2 |
The unit price of the item from the Order Detail table. Not included for free gift or no-charge items. |
|
numeric |
7.2 |
The unit price of the item as defined for the Item Offer or SKU offer and saved in the Order Detail table. |
|
original_retail_price |
numeric |
7.2 |
The original retail price from the SKU table. |
drop_ship |
alpha |
1 |
A Y indicates the item is a drop ship item; otherwise, N is passed. |
detail_ship_via |
numeric |
2 |
Passed only if the order detail line has a ship via override. See line_shipping_method. |
The three following values are related to store pickup orders. See Store Pickup Orders for an overview. |
|||
pickup_type |
alpha |
2 |
Set to SP for a store pickup order. |
pickup_system_location |
alpha |
10 |
A code identifying the system associated with the store pickup location. From the Name in OROB for Point of Sale (L09) system control value. Passed only for a store pickup order. |
pickup_location |
alpha |
10 |
A code identifying the location where the customer picks up the item. Passed only for a store pickup order. |
order_quantity |
numeric |
5 |
The quantity from the Inbound Order Message. Always passed. |
cancel_quantity |
numeric |
5 |
From the Order Detail table. Not used in the order API. If you enter a cancel quantity, the system recalculates the tax on the order. |
ship_quantity |
numeric |
5 |
From the Order Detail table. Not used in the order API. |
return_quantity |
numeric |
5 |
From the Order Detail table. Not used in the order API. |
reserved_warehouse |
numeric |
3 |
The warehouse where the item is reserved. Passed only if the item is reserved. If the order detail line is reserved across multiple warehouses, the message specifies the first reserved warehouse only. |
reserve_quantity |
numeric |
5 |
Passed only if the item is reserved. May be less than the order_quantity. If the order detail line is reserved across multiple warehouses, the message specifies the total reserved quantity across all warehouses. |
sold_out_quantity |
numeric |
5 |
Passed only if the item is sold out. May be less than the order_quantity. If you enter a sold out quantity, the system recalculates the tax on the order. |
expected_ship_date |
numeric |
8 |
Passed only if the item is backordered and there is an open purchase order for the item. MMDDYYYY format. This date is included for drop ship items only if the Assign Drop Ship Expected Ship Date (I59) system control value is selected. See that system control value for more information. |
last_ship_date |
numeric |
8 |
From the Order Detail table. MMDDYYYY format. Not used in the order API. |
tax |
numeric |
10.5 |
The total tax amount applied to the order detail line. |
gst_tax |
numeric |
10.5 |
The total GST tax, if any, applied to the order detail line. See GST Rate (A90) for a discussion. |
pst_tax |
numeric |
10.5 |
The total PST tax, if any, applied to the order detail line. See GST Rate (A90) for a discussion. |
set_main_item |
alpha |
1 |
Indicates whether the item is the main item of a set: Y = a main set item N = not a main set item Available in: 2.0 (release 1.1 of Order Management System). |
set_component_item |
alpha |
1 |
Indicates whether the item was added to the order as a component of a set: Y = a set component N = not a set component Available in: 2.0 (release 1.1 of Order Management System). |
set_seq_number |
numeric |
3 |
Indicates the sequence number that uniquely identifies a set and its components on this order. The main set item and its components have the same set sequence number. This attribute is not included for items that are not part of a set. Available in: 2.0 (release 1.1 of Order Management System). |
sku_country_of_origin |
alpha |
3 |
A code representing the country where the item originated. From the SKU Country of Origin field in the SKU table. Available in: 4.0 (release 2.5 of Order Management System). |
harmonize_code |
alpha |
16 |
A code that prints on customs documents for international shipments. If you charge duty on international orders, use this field to define the item’s duty rate. From the Harmonize code field in the SKU table. Available in: 4.0 (release 2.5 of Order Management System). |
broker_status |
alpha |
15 |
A status of Acknowledged indicates that a store pickup order has been submitted to Oracle Retail Order Broker, where it was created successfully. Otherwise, not used as part of the Generic Order Interface (Order API). See the Order Broker Integration for an overview. Available in: 5.0 (release 3.0 of Order Management System). |
line_locate_eligible |
alpha |
1 |
Indicates if a backordered line meets the Rules for Submitting Backorders to the Order Broker, except that the order does not yet need to be fully paid and authorized. Note: This flag is included regardless of whether the order is suspended, provided the item is valid. Even if this flag is set to Y, it is possible that the line cannot be fulfilled as a brokered backorder if, for example, the Order Broker cannot find a location that has the item available. Available in: 6.0 (release 3.5 of Order Management System). - |
gift_wrap |
alpha |
1 |
Indicates whether the item is gift wrapped. Y = The item is gift wrapped. The system also includes order messages with a Print flag of G Gift Message in the Ord_Msg element. N = The item is not gift wrapped. From the Gift wrap field in the Order Detail table. Note: Any gift wrap charges are included in the Handling field for the Order Ship To. Available in: 7.0 (release 4.0 of Order Management System). |
The information in this element is derived from PC manifesting, the generic pick in API, or the Order Broker integration. See PC Manifesting Interface, Generic Pick In API (Shipments, Voids, and Backorders), or Brokered Backorders for background. Note: This element is not used as part of the Generic Order Interface (Order API). See Generic Customer History API. |
|||
invoice_nbr |
numeric |
7 |
A unique number to identify an invoice. The system creates an invoice when you confirm shipment or process a return. |
invoice_ship_quantity |
numeric |
5 |
The total unit quantity of the item shipped and billed on this invoice. The quantity is negative for a return. |
invoice_ship_date |
numeric |
8 |
The date when the shipment was confirmed, or when the return was credited. MMDDYYYY format. |
alpha |
30 |
From the Manifest Upload Audit table. The system includes all tracking numbers in the Manifest Upload Audit table that are defined for the invoice detail (for example, the item shipped in more than one carton). See PC Manifesting Interface for an overview. Brokered backorders: Since there is no Manifest Upload Audit record for a brokered backorder, the message includes a tracking number if there is an Order Transaction History record of a shipment for the same date as the invoice. The system identifies the tracking number for an order line based on Order Transaction History notes, including: • the line number in a note such as Ln#: 5 Shipped by Broker • the tracking number in a note beginning with ----TRK#. Anything to the right of ----TRK#. in the invoice_tracking_nbr attribute. For example, if the Order Transaction History note is ----TRK#: GHI123, the invoice_tracking_nbr is GHI123. Note: If the system writes the Order Transaction History for the shipment of a brokered backorder on a date that differs from the invoice date, then no tracking information is included in the customer history response. This situation might occur if, for example, Order Management System receives the status update of the shipment before midnight, but the billing async job does not create the invoice until after the job is automatically stopped and restarted, so that the next date is assigned to the invoice. |
|
invoice_ship_via_code |
numeric |
2 |
From the Manifest Upload Audit table. See PC Manifesting Interface for an overview. Not included for brokered backorders. |
invoice_ship_via_desc |
alpha |
30 |
From the ship via description, as set up through Working with Ship Via Codes (WVIA). Brokered backorders: From the Order Transaction History note beginning with ----VIA. See the invoice_tracking_nbr, above, for a discussion. |
invoice_ship_via_type |
alpha |
2 |
The one-position or two-position code that identifies the type of ship via. Included for brokered backorders only if the shipping agent passed from the Order Broker matches a valid ship via in Order Management System. Available in: 6.0 (release 3.5 of Order Management System). |
invoice_tracking_URL |
alpha |
300 |
The URL to use when linking to shipment tracking information on the shipper’s web site. Built from the record in the TRACKVIA table with a matching ship via type: for example, if the ship via type is FX, the tracking URL should create a link to the Federal Express web site. All Parcel Post ship via types (PP, P1, P2, P3, and P4) use the TRACKVIA record whose ship via type is PP. Included only if there is a ship via type in the TRACKVIA table that matches the ship via used. Available in: 6.0 (release 3.5 of Order Management System). |
SpecialHandlingFormat The SpecialHandlingFormat element includes standard and custom special handling information for the items on the order that have a valid personalization_id defined and special handling instructions in the personalization_line element. Note: The SpecialHandlingFormat element is included only if the response_type in the Inbound Order XML Message (CWORDERIN) is set to D (detail) or E (errors). This element is also included when the send_detail flag in the Customer History Request XML Message (CWCustHistIn) is set to Y. See personalization_id for more information on adding special handling to an item using the Inbound Order XML Message (CWORDERIN). Available in: 8.0 (release 4.7 of Order Management System). |
|||
custom special handling: |
|||
special_format_seq_number |
numeric |
5 |
The sequence number assigned to the order line associated with custom special handling. From the Seq # field in the Order Special Format table. Available in: 8.0 (release 4.7 of Order Management System). |
special_handling_code |
alpha |
2 |
The type of special handling that applies to the item. Special handling refers to any type of item personalization, such as monogramming, alterations, and emblems. Special handling codes are defined in and validated against the Additional Charge Code table. See Special Handling Overview for more information. From the OSF SHF Code field in the Order Special Format table. Available in: 8.0 (release 4.7 of Order Management System). |
special_handling_format_seq_number |
numeric |
3 |
The special handling format sequence number assigned to the order special format. From the OSF Seq # field in the Order Special Format table. Available in: 8.0 (release 4.7 of Order Management System). |
special_format_label |
alpha |
15 |
The special handling option defined for the custom special handling format; for example: thread color. From the OSF Label field in the Order Special Format table. Available in: 8.0 (release 4.7 of Order Management System). |
special_format_text |
alpha |
45 |
The response selected for the special handling option in the custom special handling format; for example: black. From the OSF Input field in the Order Special Format table. Available in: 8.0 (release 4.7 of Order Management System). |
special_format_charge |
numeric |
7.2 |
The charge associated with the special handling option in the custom special handling format. This charge is added to the Handling bucket of the order totals. From the OSF Charge field in the Order Special Format table. Available in: 8.0 (release 4.7 of Order Management System). |
standard special handling: |
|||
special_handling_seq_number |
numeric |
2 |
The special handling sequence number assigned to the order special handling. This is populated only for standard special handling. From the Osh Seq # field in the Order Special Handling table. Available in: 8.0 (release 4.7 of Order Management System). |
special_handling_information |
alpha |
30 |
Input for the special handling. This is populated only for standard special handling. From the Osh S/H Info field in the Order Special Handling table. Available in: 8.0 (release 4.7 of Order Management System). |
The Promotion element lists the type of order audit discounts and promotions that were applied to the order. You can use this information on the web storefront to display to the customer the type of discounts and promotions for which the order qualifies, such as a ship via upgrade, reduced or free freight, or free items. Note: • The Promotion element is included only if the response_type in the Inbound Order XML Message (CWORDERIN) is set to D (detail) or E (errors). • Not all promotions are listed here. For example, if an order promotion uses an additional charge code to apply a discount, it is listed; otherwise, if it decreases the prices of the items on the order, the discounted prices are included in the response message, but the promotion applied is not listed here. See Discounted and Added Items in the CWOrderOut Response Message for more information. Available in: 3.0 (release 2.0 of Order Management System). |
|||
alpha |
2 |
A code used to identify the type of promotion applied to the order. Valid values: AA = additional charge on additional freight promotion AV = ship via override on additional freight promotion FA = additional charge on freight promotion FB = free gift for BOGO (Buy One/Get One Free) promotion FF = free freight FO = freight override FV = ship via override on freight promotion OA = additional charge on order promotion OV = ship via override on order promotion PI = package insert PT = premium RA = additional charge on offer promotion RG = free gift on offer promotion SA = additional charge on source promotion SG = free gift on source promotion TA = additional charge on tiered promotion TG = free gift on tiered promotion See Discounted and Added Items in the CWOrderOut Response Message for more information about each promotion type. From the Type field in the Order Discount Audit table. |
|
promotion_type_code_desc |
alpha |
25 |
A description of the type of promotion applied to the order. See the promotion_type_code, above, for a listing. See Discounted and Added Items in the CWOrderOut Response Message for more information about each promotion type. |
promotion_original_freight_amt |
numeric |
7.2 |
The freight amount for the order ship to before it was discounted by a freight promotion. This value is populated only for the FF (free freight) or FO (freight override) promotion types. From the Original freight amt field in the Order Discount Audit table. |
promotion_freight_amt |
numeric |
7.2 |
The freight amount for the order ship to after the freight promotion has been applied to the order. If freight is not being charged for the order ship to (the freight amount is 0.00), this tag does not display in the message. This value is populated only for the FO (freight override) promotion type. From the Promotion freight amt field in the Order Discount Audit table. |
promotion_addl_charge_code |
numeric |
2 |
The additional charge code that was added to the order as a result of the promotion. This value is populated only for the following promotion types: • AA (additional charge on additional freight promotion) • FA (additional charge on freight promotion) • OA (additional charge on order promotion) • RA (additional charge on offer promotion) • SA (additional charge on source promotion) • TA (additional charge on tiered promotion) From the Add’l chg code field in the Additional Charge table. Based on the Additional chg seq # field in the Order Discount Audit table. |
promotion_addl_charge_code_desc |
alpha |
30 |
The description of the additional charge code that was added to the order as a result of the promotion. From the Description field in the Additional Charge table. |
promotion_addl_charge_amt |
numeric |
7.2 |
The amount of the additional charge that was applied to the order as a result of the promotion. Typically, this amount is a negative amount. This value is populated only for the following promotion types: • AA (additional charge on additional freight promotion) • FA (additional charge on freight promotion) • OA (additional charge on order promotion) • RA (additional charge on offer promotion) • SA (additional charge on source promotion) • TA (additional charge on tiered promotion) From the Additional chg amt field in the Order Discount Audit table. |
promotion_original_shipping_method |
numeric |
2 |
The ship via for the order ship to before it was overridden by the promotion. This value is populated only for the following promotion types: • AV (ship via override on additional freight promotion) • FV (ship via override on freight promotion) • OV (ship via override on order promotion) From the Original ship via field in the Order Discount Audit table. |
promotion_original_shipping_method_desc |
alpha |
30 |
The description of the ship via that was assigned to the order before it was overridden by the promotion. From the Shipper name field in the Ship Via table. |
promotion_shipping_method |
numeric |
2 |
The ship via for the order ship to after the promotion has been applied to the order. This value is populated only for the following promotion types: • AV (ship via override on additional freight promotion) • FV (ship via override on freight promotion) • OV (ship via override on order promotion) From the Promotion ship via field in the Order Discount Audit table. |
promotion_shipping_method_desc |
alpha |
30 |
The description of the ship via that was assigned to the order as a result of the promotion. From the Shipper name field in the Ship Via table. |
promotion_item_id |
alpha |
12 |
A code for the item that was added to the order as a result of a free gift, premium, or package insert. This value is populated only for the following promotion types: • FB (free gift on BOGO promotion) • PI (package insert) • PT (premium) • RG (free gift on offer promotion) • SG (free gift on source promotion) • TG (free gift on tiered promotion) From the ITM number field in the Order Detail table. Based on the ODT seq # field in the Order Discount Audit table. |
promotion_item_desc |
alpha |
40 |
A description of the item that was added to the order as a result of a free gift, premium, or package insert. From the Description field in the Item table. |
promotion_sku |
alpha |
14 |
A code for the SKU of the item that was added to the order as a result of a free gift, premium, or package insert. This value is populated only for the following promotion types: • FB (free gift on BOGO promotion) • PI (package insert) • PT (premium) • RG (free gift on offer promotion) • SG (free gift on source promotion) • TG (free gift on tiered promotion) From the SKU code field in the Order Detail table. Based on the ODT seq # field in the Order Discount Audit table. |
promotion_sku_desc |
alpha |
40 |
A description of the SKU that was added to the order as a result of a free gift, premium, or package insert. From the Description field in the SKU table. |
promotion_offer_price |
numeric |
7.2 |
The offer price for the order detail line associated with the promotion, if one exists. This value is populated only for the following promotion types: • FB (free gift on BOGO promotion) • PI (package insert) • PT (premium) • RG (free gift on offer promotion) • SG (free gift on source promotion) • TG (free gift on tiered promotion) From the Offer price field in the Order Detail table. |
promotion_price |
numeric |
7.2 |
The selling price of the order detail line associated with the promotion. If the item is free of charge (the selling price is 0.00), this tag does not display in the message. This value is populated only for the following promotion types: • PI (package insert) • PT (premium) • RG (free gift on offer promotion) • SG (free gift on source promotion) • TG (free gift on tiered promotion) From the ODT price field in the Order Detail table. |
promotion_line_seq_nbr |
numeric |
5 |
The sequence number of the order line associated with the promotion. From the ODT seq # field in the Order Discount Audit table. |
The Ord_Msg element lists order messages whose Print flag is G Gift Message. Note: The Ord_Msg element is included only if the response_type in the Inbound Order XML Message (CWORDERIN) is set to D (detail) or E (errors). Available in: 7.0 (release 4.0 of Order Management System). |
|||
ord_msg_text |
alpha |
60 |
The text for an order message whose Print flag is G Gift Message. From the Message field in the Order Message table. Available in: 7.0 (release 4.0 of Order Management System). |
ord_msg_code |
alpha |
1 |
Defines where the order message prints. The system includes only messages whose Print flag is G Gift Message. From the Print? field in the Order Message table. Available in: 7.0 (release 4.0 of Order Management System). |
The response message includes any errors on the order if the response_type sent in the CWOrderIn message is E. Available in: 2.0 (release 1.1 of Order Management System). |
|||
error_type |
alpha |
4 |
Indicates whether the error is related to header or detail information: HDR = The error is related to the header, ship-to, or payment method DTLS = The error is related to an item on the order |
error_code |
alpha |
2 |
A code identifying the error. See Order Creation Errors for a listing. |
error_ship_to |
numeric |
3 |
Identifies order ship-to related to the error. |
error_odt_seq |
numeric |
5 |
Identifies the detail line related to the error. Included only for detail errors. |
error_text |
alpha |
80 |
The description of the error. See Order Creation Errors for a listing and more information. |
Detailed Order Response Message: Sample XML
A sample of the Detailed Order XML Response (CWORDEROUT) that does not include errors is presented below. The ORDER_IN job produces this response format if the response_type for the Inbound Order XML Message (CWORDERIN) is set to E. The response generated when the response_type is set to D is similar except that no errors are included.
<Message source="RDC" target="IDC" type="CWORDEROUT">
<Header company_code="6" order_id="4787" reference_order_number="081908AT" customer_number="13164" alternate_sold_to_id="000000105" bill_to_number="320" order_date="08192008" order_channel="I" bill_me_later_ind="N" order_status="E" order_type="W" order_type_description="WEB ORDER" entered_date="08192008" entered_time="140152" source_code="SOURCE" offer_id="OFR" sold_to_fname="MARY" sold_to_lname="JOHNSON" sold_to_busres="R" sold_to_address1="257 APPLE STREET" sold_to_city="WORCESTER" sold_to_state="MA" sold_to_state_description="MASSACHUSETTS" sold_to_zip="01602" sold_to_country="USA" sold_to_day_phone="5085550100" sold_to_opt_in="O1" allow_rent="Y" allow_mail="Y" bill_to_fname="MARY" bill_to_lname="JOHNSON" bill_to_busres="R" bill_to_address1="257 APPLE STREET" bill_to_city="WORCESTER" bill_to_state="MA" bill_to_state_description="MASSACHUSETTS" bill_to_zip="01602" bill_to_country="USA">
<Payments>
<Payment payment_seq_number="1" payment_type="5" pay_type_desc="MASTERCARD" credit_card_nbr="********1111" credit_card_auth_dt="1080815" credit_card_auth_nbr="AUTH"/>
</Payments>
<ShipTos>
<ShipTo ship_to_number="1" sub_total="27.50" discount_total="3.75" shipping="2.75" tax="1.82" additional_charges="4.29" order_total="36.36" ship_to_status="S" gift_order="N" ship_via_code="4" ship_via_description="BEST WAY" shipping_override="N" ship_to_fname="MARY" ship_to_lname="JOHNSON" ship_to_busres="R" ship_to_address1="257 APPLE STREET" ship_to_city="WORCESTER" ship_to_state="MA" ship_to_state_description="MASSACHUSETTS" ship_to_zip="01602" ship_to_country="USA">
<Details>
<Detail line_seq_number="1" short_sku_number="605" item_id="BELT" item_description="STYLISH LEATHER-LOOK MEN'S BELT" actual_price="20.00" offer_price="20.00" drop_ship="N" order_quantity="1" tax="1.20" set_main_item="N" set_component_item="N"/>
<Detail line_seq_number="2" short_sku_number="542" item_id="PEN" item_description="GEL WRITER 10/16/07" sku="BLUE" sku_description="BLUE PEN" actual_price="1.50" offer_price="2.25" drop_ship="N" order_quantity="5" reserve_quantity="5" tax="0.45" set_main_item="N" set_component_item="N" />
</Details>
<Errors>
<Error error_type="HDR" error_code="Z4" error_text="CC Expiration/Start Date"/>
</Errors>
</ShipTo>
</ShipTos>
</Header>
</Message>
Order Acknowledgement XML Message (CWORDEROUT)
The system generates this response to the Inbound Order XML Message (CWORDERIN) if the response_type is A (acknowledge).
Note:
• All numeric values with decimal positions are passed as explicit decimals. For example, a dollar value of $10.00 is passed as 10.00.
• Attributes are included in the response only if they contain a value. Blank attributes are not passed.
See Order Acknowledgement Message: Sample XML for a sample message.
Message Attribute |
Type |
Length |
Comments |
source |
alpha |
|
Identifies the source of the XML message. RDC indicates the XML message originates from Order Management System. |
target |
alpha |
|
Identifies the target of the XML message. |
type |
alpha |
|
Identifies the type of information in the XML message. |
company_code |
numeric |
3 |
The company_code from the Inbound Order Message. |
numeric |
8 |
The order number assigned by the system. |
|
reference_ |
alpha |
30 |
The order_number from the Inbound Order Message. |
customer_number |
numeric |
9 |
The number identifying the customer specified in the Inbound Order Message, or created by the system. See Customer Sold To Selection, Creation and Update. |
alternate_sold_to_id |
alpha |
15 |
The Alt cust # field at the Second Create Customer Sold To Screen. |
bill_to_number |
numeric |
7 |
The number identifying the bill-to customer specified in the Inbound Order Message, created by the system, or assigned to the sold-to customer. See Customer Bill To Selection and Creation. Passed only if the customer or order has a bill-to account. |
order_date |
numeric |
8 |
The order_date from the Inbound Order Message. |
order_channel |
alpha |
2 |
The order_channel from the Inbound Order Message |
bill_me_later_ind |
alpha |
1 |
Not currently implemented. |
Order Acknowledgement Message: Sample XML
A sample of the Order Acknowledgement XML Message (CWORDEROUT) is presented below.
<Message source="RDC" target="IDC" type="CWORDEROUT">
<Header company_code="6" order_id="5219" reference_order_number="093008B" customer_number="13164" alternate_sold_to_id="000000105" bill_to_number="320" order_date="09302008" order_channel="I" bill_me_later_ind="N"/>
</Message>
Order Reject Request Message (CWORDERREJECT)
Message structure: There is not a separate DTD or schema for the reject message. This message is based on the same structure as the Inbound Order XML Message (CWORDERIN); however, it is not necessary to include any tags besides those listed below. See the Order Reject Request Message: Sample below for an example.
When the message does include additional tags beyond those listed below, the order API returns an Invalid XML Message error if any of the additional information is invalid.
For more information: See Rejecting the Order (Order API) for background.
Message Attribute |
Type |
Length |
Comments |
Message |
|||
source |
alpha |
|
Identifies the source of the XML message. |
target |
alpha |
|
Identifies the target of the XML message. |
type |
alpha |
|
Must be set to CWORDERREJECT. Note: Not case-sensitive. For example, a setting of CWOrderReject is also acceptable. |
Header |
|||
company_code |
numeric |
3 |
Identifies the company for the order. Validated against the Company table. Padding with zeroes (for example, 005) is optional. Required. |
Identifying the Order: The reject message must specify either an order_number or rdc_order_nbr identifying an existing order in the company indicated. The order must be in error and not have a payment method. If the message includes both the order_number and the rdc_order_nbr, they should both point to the same order. Multi-recipient order? If the reject message specifies a multi-recipient order, the system cancels all recipients. |
|||
order_number |
alpha |
30 |
The E-commerce order number in the Order Header Extended table and in the E-Commerce Order Reference table. From the order_number passed in the Inbound Order XML Message (CWORDERIN). |
rdc_order_nbr |
numeric |
9 |
The order number assigned by Order Management System. |
Order Reject Request Message: Sample
The following sample includes all of the tags that could potentially be used to identify an order for rejection. The message can specify the order_number, rdc_order_nbr, or both, in addition to the company number.
<Message source="String" target="String" type="CWORDERREJECT" >
<Header company_code="6" order_number="1010mu123" rdc_order_nbr="10851" >
</Header>
</Message>
Order Reject Response Message: Samples
The order API returns a response such as one of the following examples provided the Order Reject Request Message (CWORDERREJECT) if the reject request message was valid, such as the sample above.
If the order rejection is successful, the response passed is:
<Message>PASS</Message>
Otherwise, if the order rejection is unsuccessful, the response passed is:
<Message>FAIL</Message>
A rejection is unsuccessful if the request message did not specify an existing order that is currently in error status without a payment method.
Generic Order Interface (Order API) | Contents | SCVs | Search | Glossary | Reports | Solutions | XML | Index | Order Creation Errors |
GO01_01x OMSCS 18.1 April 2019 OTN