Chapter 77: E-Commerce Order Creation

Overview: The EC_ORDERS job, started through Working with E-Commerce Job Control (EJCT) creates new orders through the e-commerce interface. The main purposes of this job:

• create the order (using the order type specified in the E-Commerce Order Type (G42) system control value)

• create the customer, if needed

• reserve inventory (exploding set items, although this is not visible on the web storefront)

• send the new order number to the web storefront

• possibly, delete an order and create a new one if the customer changes key information on the web storefront

Checking for errors: Orders you receive through the e-commerce interface go through an edit process that is similar to phone order edit or the business-to-business order edit. Any orders that fail this edit are placed in error (E) status, and assigned to the batch number you specify with the Default Batch for E-Commerce Orders in Error (G41) system control value. Additionally, the system generates the Order Error Listing, so you can review the errors on a particular order. This report is generated for the person who started the e-commerce jobs; see Working with E-Commerce Job Control (EJCT).

Once the edit flags an order for an error, it might not continue to flag all applicable errors for the same type of information on the order. For example, if a payment method on the order is in error, the system might stop performing additional checks against the payment method, even if other data required for the payment method is invalid or incomplete.

You should use batch order entry periodically to check whether any orders are in error, and to correct the errors. You can resubmit the batch for editing to collect all errors on the Print Phone Errors report, or accept the batch once you have corrected all errors. See Entering Batched Orders for more information.

Order transaction history: When you press F9 to accept an order that is part of the Default Batch for E-Commerce Orders in Error (G41), the system writes an order transaction history message indicating the user that accepted the order. The system writes an order transaction history message each time a user accepts the order so that you can track the users that changed an order in the e-commerce order batch. You can review order transaction history messages on the Display Order History Screen.

An example of the order transaction history message the system creates when a user accepts an order that is part of the e-commerce order batch is displayed below. The system includes an amount regardless of whether the change updated the order total.

Date	Type	Transaction Note	Amount	User
8/4/14	4	Batch order changed - Ecomm.	20.75	SFLYE

System control values: The Perform Order Edit Interactively (I56) system control value controls whether to perform the edit interactively when you create and apply payment to an e-commerce order, while the Send Order Response After E-Commerce Payment Message (I57) system control value controls whether to generate a response message after applying the payment. See these two system control values for more information on the steps the system takes in creating orders and generating response messages.

Order API or e-commerce message? You can use either the CWOrderIn message through the Generic Order Interface (Order API) or the CWCreateOrder message (e-commerce) to create orders in CWDirect. The CWOrderIn message includes additional information that is not part of the CWCreateOrder message. To determine which message best suits your business requirements, compare the information included in each.

Reserving e-commerce orders against a non-allocatable warehouse: If the Retail warehouse field for the E-Commerce Order Type (G42) contains a non-allocatable warehouse and the Reserve from Non-Allocatable Warehouse (J25) system control value is set to Y, the system allows you to reserve inventory against the non-allocatable warehouse defined for the e-commerce order type. If the item is not in stock, the system backorders the item against the non-allocatable warehouse. However, if a warehouse override is defined for the remote order, the system uses the override warehouse instead of the warehouse defined for the e-commerce order type.

Important: The logic and features described below apply to e-commerce order creation when you are using XML messages. Features added from version 7.0 of CWDirect forward are not supported for name/value pair messages.

In this chapter:

• Information You Can Receive through E-Commerce Orders

• Identifying the Item

• Payment Information

• Pricing and Price Overrides

• Discounts and Promotions

• Ship To Customer Ship Via

• Customer Ownership Information

• Other Order Information and Options

• Customer Selection/Creation Logic in E-Commerce Orders

• Selecting or Creating Sold-to Customers in E-Commerce Orders

• Selecting or Creating Bill-to Customers in E-Commerce Orders

• Selecting or Creating Individual Customers in E-Commerce Orders

• Selecting or Creating Recipient or Ship-to Customers in E-Commerce Orders

• User-Defined Fields in the New Order Message

• E-Commerce New Order Message (CWCreateOrder)

• E-Commerce Payment Message (CWPayment)

• E-Commerce New Order Response Message (CWOrderResponse)

Information You Can Receive through E-Commerce Orders

Identifying the Item

For each order detail line, the system determines the item and SKU first by checking the item_id. If this attribute identifies a valid item/SKU, the system adds this item/SKU to the order. Otherwise, the system checks the sku. If attribute specifies a short SKU for an existing item, the system adds this item/SKU to the order. Otherwise, the order is suspended with the error Base item does not exist.

Zone reservation items: If an item is subject to zone reservation, the system applies the Standard Zone Reservation Rules or Alternate Zone Reservation Rules based on your setup. However, if the zone reservation rules that apply to the item would normally display the Select Order Line Option Window in order entry, the system always adds the item as a future order. See Shipping Zone Reservation Overview for a complete discussion.

Pre-billing items: If you pre-bill items, the system adds the Pre Billed Amount Item (J72) to the order when it receives a new order that includes a pre-billable item. The Pre Billed Amount Item (J72) is included in the response message with a status of In stock and reserved. The actual pre-billable amount is not indicated in the response message.

See Pre Billed Amount Item (J72) for a discussion.

For more information:

• item and SKU codes: Create Item Screen and Create SKU 1 of 2 (With Overrides) Screen

• short SKU number: Short SKU

Payment Information

How is payment information passed? Payment information can be included as part of the New Order message, depending on the design of your web storefront; otherwise, the Order Payment/Accept job handles payment information.

An order can include the following payments:

• pay category 1 (cash/check)

• pay category 2 (credit card), including:

• Bill Me Later (card type B)

• credit card (card type C)

• debit card (card type D)

• stored value card (card type S)

• pay category 3 (A/R)

• pay category 5 (coupon/credit), including gift certificates

Multiple payment methods: The order can include a single payment method or a combination of payment methods. As in regular order entry, the system requires that a “catch-all” payment method be specified if there are multiple credit cards, or one or more credit cards with an A/R payment method. See Order Error Listing for additional errors.

Auto-assign pay type: The Allow auto-assign field for a pay type indicates whether the system automatically assigns a pay category 2 (credit card) pay type to an order, based on the leading digits defined for the credit card number in the cc_number tag in the E-Commerce New Order Message (CWCreateOrder) or E-Commerce Payment Message (CWPayment).

• If the Allow auto-assign field for a pay type is set to Y, the system automatically assigns this pay type to the order when the leading digits entered in the cc_number tag match the leading digits defined for the pay type code. Additionally, if you define a pay type code in the cc_type tag, the system will override this pay type code if the leading digits entered in the cc_number tag match the leading digits for another pay type code whose Allow auto-assign field is set to Y.

• If the Allow auto-assign field for a pay type is set to N, the system does not automatically assign this pay type to an order when the leading digits entered in the cc_number tag match the leading digits defined for the pay type code. Additionally, if you define a pay type code in the cc_type tag, the system will not override this pay type code if the leading digits entered in the cc_number tag match the leading digits for another pay type code whose Allow auto-assign field is set to Y.

Note: Pay category 2 pay types include credit cards, stored value cards, Bill Me Later, Debit cards, and Direct Bank Disbursement. If you do not want the system to auto-assign a certain card type to an order, enter N the Allow auto-assign field for the pay type.

Example: The following pay category 2 pay types exist:

Pay Type	Card Type	Leading Digits	Allow Auto-Assign
21	stored value card	3333	Y
22	credit card VISA	478	N

You enter the following leading digits for the credit card number in the cc_number tag for the order:

Leading Digits	Results
3333	The system auto-assigns pay type 21 to the order.
478	The system does not auto-assign a pay type to the order since it cannot find a pay category 2 pay type with Allow auto-assign selected that has 478 defined as its leading digits. The system places the order in an error status for the error Invalid Pay Type, requiring you to enter a pay type code for the order in batch order entry to correct and reprocess the order.

See Allow Auto-Assignment of Pay Category 2 Pay Type for additional processing information.

Accounts receivable orders: A new order can use an accounts receivable payment method. The system uses the value in the ar_type field to create the accounts receivable payment method on the order.

Note: The ar_type field must specify a valid accounts receivable pay type (payment category 3).

See Selecting or Creating Bill-to Customers in E-Commerce Orders for information on how a bill-to customer is added to an accounts receivable order.

Gift certificates as payment: A new order can include a gift certificate and/or coupon. The gc_type field in the new order message indicates which pay type to use when creating the payment method on the order; if this field is blank, the system uses the value in the Default Pay Type for Gift Certificates/Coupons (G48) system control value. If there is a valid, unredeemed gift certificate/coupon number in the gift_certificate_number field on the order message, the system uses the amount specified for this number in the Coupon Redemption file and does not check the value of the gift_certificate_amount field.

Note: The gc_type field and/or Default Pay Type for Gift Certificates/Coupons (G48) must specify a valid coupon/credit pay type (payment category 5).

Pre-paid orders: A new order can use a pre-paid payment method (pay category 1 cash/check). The system uses the following fields to create the pre-paid payment method on the order. At minimum, you must enter the pre-paid pay type code in the check_type field and the amount in the check_amount field.

• check_type: A valid cash/check pay type (payment category 1). Identifies the Pay type field in the Order Payment Method file.

• check_number: The number of the check. Updates the Check number field in the Order Payment Method file.

• check_amount: The amount of the check. If an amount is not defined, the system places the order on balance due hold.

• checking_account: The checking account number. Updates the Checking account field in the Order Payment Method file.

• routing_number: The routing number defined for the check. Updates the Routing number field in the Order Payment Method file.

• cash_control_number: The cash control number assigned to the check. Updates the Cash control number field in the Order Payment Method file.

• pin_id: Informational-only. Updates the Pin storage field in the Order Payment Method file.

To include prepaid (cash/check payment category 1) payment types in the e-commerce pay type extraction, the Download Prepaid Payment Types to E-Commerce (I69) system control value must be set to Y.

Error-checking related to payment methods: The system also checks for other errors related to payment method, such as:

• For gift certificates:

• If there is a gift certificate number, there must be a gift certificate type

• The gift certificate number must exist in the Coupon Redemption file

• For credit card pay types:

• The pay type must have an issue number if required, based on the Require issue # flag

• The pay type must have a start date if required, based on the Require start date flag

• The pay type must have an expiration date if required, based on the Require expiration date flag

• If the pay type is Bill Me Later, the total order value cannot exceed the BML trans limit. Also, if the customer does not already have an account number established, the customer’s date of birth and last four digits of the social security number are required. See Bill Me Later Processing for an overview.

Credit card security identification: You can also perform credit card security identification for e-commerce orders by defining values in the card_sec_value and card_sec_presence fields. If the card security value and card security presence are passed for a credit card paytype, the system:

• updates the Card security value and Card security presence fields on the order in the Order Payment Method file.

• if a card security value exists and the card security presence is blank, the system updates the Card security value field with the passed value and the Card security presence field to 1 (card security value is present on card).

• if the card security value is blank and the card security presence is 2 (card security value is present on card, but is illegible) or 9 (card security value is not present on card), the system leaves the Card security value field blank and updates the Card security presence field with the 2 or 9.

• If the card security presence is 2 or 9, but a card security value exists, the system updates the Card security value field with the passed value and updates the Card security presence field to 1 (card security value is present on card).

• If the card security presence is not a valid value (1, 2, or 9), the system does not update the Card security value field or Card security presence field.

If the card security value and card security presence are passed for a non-credit card pay type, the system clears the values and does not pass them to the order.

Note: The system removes the card security value from an order when the order is accepted, even if an approved online authorization has not been received on the order. Card security processing is not available during batch authorization or deposit processing.

See Credit Card Security Service (CID, CVV2, CVC2) for more information on credit card security processing.

Credit card authentication: Credit card authentication helps to reduce fraud and chargeback volume on card not present transactions by requiring a cardholder to enter a card authentication password on the web storefront to verify that the card is present at the point of sale and belongs to the customer placing the order.

The web storefront sends the card authentication password to an authentication service, such as Visa’s Verified by Visa program or MasterCard’s SecureCode program, for validation.

The authentication service validates the password and sends back an electronic commerce indicator (ECI) and an authentication verification value to the web storefront.

• The electronic commerce indicator (ECI) indicates the level of security provided for a credit card transaction placed over the internet.

• The authentication verification value indicates whether the password the cardholder provided was approved for the credit card.

The web storefront sends the order to CWDirect and includes:

• the authentication verification value in the authentication_value field. This value updates the Authentication value field in the Order Payment Method file.

• the electronic commerce indicator (ECI) value in the ecommerce_indicator field. This value updates the Ecomm Indic field in the Order Payment Method file.

See Credit Card Authentication Service for more information.

Credit card encryption: Credit card encryption allows you to encrypt the credit card number in the CWDirect database to provide additional security of credit card data. If you use credit card encryption, the credit card number in the E-Commerce New Order Message (CWCreateOrder) and E-Commerce Payment Message (CWPayment) will not be encrypted; however, once the CWDirect order is created, the system encrypts the credit card number in the CWDirect database.

PO numbers: The new order message can include a PO number in the ship_to_po_number field (ship-to level) or the po_number field (order level). For each ship-to on the order, the system checks the ship-to level PO number first; if there is no PO number specified, the system uses the order-level PO number. The PO Required for A/R Orders (D79) and Verify Duplicate PO Numbers for A/R Orders (D80) system control values determine whether a PO number is required for accounts receivable orders, and whether the sold-to customer can submit the same PO number more than once.

Pricing and Price Overrides

Item price hierarchy: The system uses the following hierarchy to determine the price of the item on the order detail line:

• item is added to the order at no charge if the no_charge field (available for XML, not name/value pair messages) in the e-commerce order message is 1. The system adds the price override reason to the order detail line based on price override reason hierarchy. Note: The list_price field in the new order response message is 0000000, indicating the item is priced at no charge.

• item price defaults from the list_price field in the e-commerce order message. The system adds a price override reason to the order detail line based on price override reason hierarchy. Note: If you define a list_price, you must also enter 1 in the price_override field. If the price_override field is blank or a value other than 1, the system defaults the price from the offer associated with the order detail line.

• item price defaults from the offer associated with the order detail line.

If a price cannot be found, the e-commerce order is placed in an error status: Price cannot be zero for item.

Price override reason hierarchy: If you enter a price override for the item (a price is defined in the list_price field) or you add the item at no charge (1 in the no_charge field), you must also define a price override reason. The price override reason on the order detail line defaults from the:

• prc_ovr_rsn attribute (available for XML, not name/value pair messages) in the e-commerce order message; otherwise,

• Price Override Reason for E-Commerce (G73) system control value; otherwise,

• Default Price Override Reason (B35) system control value

If a price override reason is not defined in any of the above places, the system does not price the item at the override price and instead defaults the item price from the offer associated with the order detail line.

Price override reason and order response: The CWOrderResponse message (see below) includes details depending on if a price override is defined for the item (a price is defined in the list_price field or 1 is defined in the no_charge field) and, if defined, the price override reason defined for the order detail line.

The order response message includes details (ship_to_number, sku, item_id, list_price, status, reserved_warehouse, and reserved_quantity) if:

• a price override is not defined for the item.

• a price override is defined for the item and the price override reason for the order line equals the value in the Price Override Reason for E-Commerce (G73) system control value.

• a price override is defined for the item and the price override reason for the order line does not equal the value in the Default Price Override Reason (B35) or Price Override Code for Promotional Priced Lines (B61) system control values.

The CWOrderResponse message does not include details if:

• a price override is defined for the item and the price override reason for the order line equals the value in the Default Price Override Reason (B35) system control value.

• a price override is defined for the item and the price override reason for the order line equals the value in the Price Override Code for Promotional Priced Lines (B61) system control value.

• additionally, if the item is priced at no charge, the system includes a gift response (free_giftr field) in the order response message: Item added as a free gift.

When are response message(s) sent? There are two different points when the system might send response messages to the web storefront:

• The e-commerce ORDER PROCESSING function sends the CWOrderResponse message when it receives a new order message that does not include payment information.

• The e-commerce ORDER PAYMENT/ACCEPT function also sends the CWOrderResponse message after adding payment information to the order, regardless of whether this message was sent previously, if the Send Order Response After E-Commerce Payment Message (I57) system control value is selected.

Includes final order totals? The Perform Order Edit Interactively (I56) system control value controls whether the Detailed Order XML Response (CWORDEROUT) includes final order totals determined during the order edit process. See that system control value for more information.

Discounts and Promotions

Which discounts and promotions apply to web orders? See Discounting and Added Items in the Response Message to review a table that summarizes which discounts and promotions apply to web orders and when the response message reflects repricing and free or accompanying items, based on the settings of the Perform Order Edit Interactively (I56) and Apply End of Order Discounts during Repricing (J37) system control values.

Apply end of order discounting during repricing: When order information is passed back to the customer in the E-Commerce New Order Response Message (CWOrderResponse) and the Apply End of Order Discounts during Repricing (J37) system control value is set to Y, the system includes any non-pay type related discounts and promotions that have been applied to the order in the response message.

You can use this information to display to the customer on the web storefront the types of promotions for which the order qualifies, such as a ship via upgrade, reduced or free freight, or free items. You can use this information to simulate the promotion and free gift windows that display during interactive order entry.

Note: In order to include end of order promotions in the E-Commerce New Order Response Message (CWOrderResponse), you must enter Y in the Write Promotional Information to the Order Response Message (J38) system control value. The name/value pair version of the E-Commerce New Order Response Message (CWOrderResponse) has not been modified to include the Promotion element.

See End of Order Discounting for Remote Orders for more information.

Promotion discount: If the Promotion Code Entry Required for Discount (I63) system control value is:

• set to Y: the promotion code passed in the order message is applied against the order, provided the order qualifies. The system does not automatically apply any other promotions against the order, and only one promotion can apply for each order shipping address. 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 the promotion code specified in the message does not actually exist, the order will be in error with a reason of Invalid Promotion Code.

• set to N: the system ignores any promotion code passed and instead applies one promotion of each type (O order, F freight, T tiered discount, and A additional freight) to an order if the order qualifies for each type.

See the Promotion Code Entry Required for Discount (I63) system control value for a complete discussion.

Ship To Customer Ship Via

The system verifies that the ship via defined in the Shipping_method field is a valid shipper for the ship to customer.

In addition, the ship via must already be set up with the SCF on the shipping address as a valid SCF/ship via combination.

SCF ship via override: The Use SCF Ship Via in E-Commerce (J30) system control value controls whether the system overrides the ship via code on the order to the Preferred ship via defined for the ship to customer’s SCF (the first 3 digits of the destination postal code). See Ship Via Defaults for Remote Orders for more information on the ship via that defaults to a remote order.

Item ship via override: If using item ship via overrides, the ship via must exist as an eligible shipper for the item in the Item Ship Via Override file. If records do not exist in the Item Ship Via Override file for the item, all shippers are eligible to deliver the item. See Working with Item Ship Via Overrides.

Customer Ownership Information

You can create or update customer ownership records for the sold to customer on the order using the CustOwnership element. Customer ownership allows you to capture and confirm information about the products a customer currently owns or previously owned. The system uses the following fields to create or update a customer ownership record for the sold to customer on the order. At minimum, you must enter the ownership ID in the cust_own_ID field.

• cust_own_ID: A code that represents a product the customer owns or previously owned.

• cust_own_desc: A description of the product.

• cust_own_active: Indicates if the customer currently owns the product.

• cust_own_entry_date: The date the customer ownership record was created, in MMDDYY format.

• cust_own_confirm_date: The most recent date when the customer confirmed ownership of the product, in MMDDYY format.

The system looks at the Company, Customer #, and Ownership ID fields in the Customer Ownership file to determine if the customer ownership record passed on the order is a new record or updated record.

• If the company, customer number, and ownership ID values on the order match a record in the Customer Ownership file, the system updates the Active flag, Entry date, Confirm date, and Description fields for the existing customer ownership record.

• If the company, customer number, and ownership ID values on the order do not match a record in the Customer Ownership file, the system creates a new customer ownership record for the sold to customer.

Customer ownership errors: If a value is not defined for the cust_own_ID field, the system creates a customer note indicating the customer ownership record was not created/updated: Missing Ownership ID: Ownership Description. The system does not place the e-commerce order in an error status because of customer ownership errors.

See Working with Customer Ownership for more information on creating and updating customer ownership records for a sold to customer.

Other Order Information and Options

Dollar amount hold: If the order amount exceeds the dollar amount defined in the Maximum Order Amount for E-Commerce Orders (H54) system control value, CWDirect places the e-commerce order on e-commerce dollar hold (EH). If this system control value is blank, CWDirect uses the dollar amount defined in the Maximum Order Amount (A92) system control value to determine if the order should go on hold automatically.

Hold reason code: If this information is received by CWDirect, the system checks that the order hold reason code is valid. If the code is valid, the system puts the order on hold; otherwise, the order goes into error status. See Customer Service Chapter 4: Establishing Order Hold Reason Codes (WOHR). The order hold reason code is passed into CWDirect through the Order Payment/Accept process; see Chapter 76: Working with E-Commerce Job Control (EJCT).

Special handling: You can sell items with special handling through the e-commerce interface. The item must be eligible for special handling in the offer defined. See Establishing Custom Special Handling Formats (WSHF), the Create Item Offer Screen, and the E-Commerce New Order Message (CWCreateOrder) for more information.

Gift wrap: You can sell items with gift wrap through the e-commerce interface. However, the item must be eligible for gift wrap in the offer defined.

Set and continuity items: To include a set or continuity item on an order created through the e-commerce interface, the new order message should include the master set or continuity item only, and none of its components. The set or continuity item is “exploded” once the order is created, adding all of the components to the order. If any of the components of the set are eligible for special handling, the Copy Set Master Special Handling to Set Components (J39) system control value controls whether to copy the special handling instructions and handling charges to each eligible set component. See the Copy Set Master Special Handling to Set Components (J39) system control value and Setting Up Special Handing for Sets for more information.

Order messages: The New Order message can also include order-level and/or detail-level order messages, like the ones you can enter through Adding Order Messages.

Order line messages: Order lines on the New Order Message can include one or more order line messages. If the lin_msg_code is not valid, the system creates the order line message with a print value of blank (print nowhere). See Work with Order Line Messages Screen for more information.

Purchase order numbers: You can use the ship_to_po_number or the po_number fields in the new order message to specify the PO number to assign to an order. The system checks the ship_to_po_number first; if it is blank, it uses the po_number. If Verify Duplicate PO Numbers for A/R Orders (D80) is set to Y, the system verifies that the PO number has not already been used on any of the sold-to customer’s orders; otherwise, the order goes into error status and appears on the Order Error Listing.

Selling gift certificates: You can sell a gift certificate on an order. The item must be flagged as a gift certificate using the Gift cert (Gift certificate) field. The system assigns a gift certificate number if a gc_number is not specified in the message, or if the gift certificate number specified in the message is already assigned. The Create Random Gift Certificate/Coupon Numbers (H09) system control value controls whether the assigned number is random or sequential. See Working with Gift Certificates for an overview of the gift certificate process.

Note: Do not specify a gift certificate number in the message if the quantity ordered is greater than one; if a gift certificate number is specified, the system creates only one gift certificate.

Processing a return: You can use the new order message to process a return by specifying a negative order line quantity. The order line(s) bill immediately and do(es) not affect inventory.

IP address: The new order message can include an ip_addr, indicating the IP address where the order originated. The IP address updates the IP address in the Order Header Extended file, displayed at the Display Order Properties Screen. If the IP address received 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, 12.34.234.8). Each number between the periods must be from 1 to 255. The IP address must:

• not include any non-numeric characters besides the periods

• 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 file, the system puts the order on IP (IP address) hold and writes a message such as SYS HLD---IP ADDRESS HOLD to the Order Transaction History file. See Working with Miscellaneous Frauds (WMFF) for more information on IP addresses and fraud checking.

Source code and offer: You can define a source code at the header level and an offer at the header level or detail line level.

• You must enter a valid source code in the source_code field at the header level. The pricing method and freight, and any applicable promotions and discounts, are applied to the order based on the source code on the order header.

• Optionally, you can define a valid offer code in the offer_id field at the header level. However, you can override this offer by defining a valid offer for an order detail line in the line_offer field.

• If the order header source code matches the source code in the Default Unknown Source Code (I58) system control value, the system updates the source code on the order header to the source code associated with the offer on the first order detail line. The pricing method and freight, and any applicable promotions and discounts, are applied to the order based on the new source code on the order header. See Default Unknown Source Code Logic.

Selecting the order-level email address: The system uses the following hierarchy in updating the order-level email address when processing e-commerce orders:

• If there is an email address specified for the individual placer (either specified in the message, or an existing email address for the individual), and the Default Individual Email Address (J17) system control value is set to Y, use that email address; otherwise,

• If there is an email address specified for the sold-to customer (either specified in the message, or an existing email address for the customer), use that email address; otherwise,

• Leave the order-level email address blank.

You cannot specify an originator through the e-commerce order interface.

Customer Selection/Creation Logic in E-Commerce Orders

Selecting or Creating Sold-to Customers in E-Commerce Orders

The system uses the following basic logic in selecting a sold-to customer for the order (see below for exceptions and examples):

1. Customer number: If a valid customer_number is specified in the message, use that customer; otherwise,

2. Evening phone: If the Include Telephone Number in Customer Search (I20) system control value is set to Y, and a bill_to_evening_phone is specified in the message (but no valid customer_number):

• If there is just one customer whose Evening phone number matches the bill_to_evening_phone, use that customer; otherwise,

• Of the customers with matching Evening phone numbers whose name and address information matches the information in the message (using the matching rules specified through the Phone Interface Values (F70) system control value), use the matching customer with the lowest customer number (customer created first); otherwise,

3. Daytime phone: If the Include Telephone Number in Customer Search (I20) system control value is set to Y, and a bill_to_day_phone is specified in the message (but no valid customer_number or bill_to_evening_phone):

• If there is just one customer whose Day phone number matches the bill_to_day_phone, use that customer; otherwise,

• Of the customers with matching Day phone numbers whose name and address information matches the information in the message (using the matching rules specified through the Phone Interface Values (F70) system control value), use the matching customer with the lowest customer number (customer created first); otherwise,

4. Name and address match: If none of the above matches work, use the matching rules specified through the Phone Interface Values (F70) system control value to search for a customer who matches the name and address information specified in the message:

• If there is just one customer who matches the name and address information, use that customer; otherwise,

• If there are multiple customers who match the name and address information, use the customer with the highest customer number (most recently created customer); otherwise,

5. Create customer: If there is no matching customer, create a new customer for the order. Additionally, if a country is not passed, the system defaults the country defined in the Default Country for Customer Address (B17) system control value to the address.

Ghost customer: If the customer selected through the process described above is flagged as a Ghost, the system creates the order using the target customer with whom the ghost customer was merged (identified through the Customer number cross-reference field in the Customer Sold To file). For example, if the above process selects customer 123, and customer 123 has been merged with customer 456, the order is created for customer 456. In making this assignment, the system does not check that the name or address information for customer 456 matches the information in the message.

Note: The system uses the same search logic as described above when searching for an existing customer as part of the phone order interface; see Using the Phone Interface.

If using President’s Club: If the Use President’s Club Membership (H94) system control value is set to Y, the alternate customer number is used to identify an existing or prospective President’s Club membership. See Alternate Customer Number Matching through the Order API with President’s Club for a discussion.

Selecting or Creating Bill-to Customers in E-Commerce Orders

The system uses the following hierarchy to select or create a bill-to customer for the new order:

Note: The bill-to customer is identified as the ar customer in the new order message, while the sold-to customer is identified as the bill_to customer.

The system uses the following logic in selecting a bill-to customer for an order that uses an A/R payment method:

1. If a valid ar_number is specified in the message, use that bill-to customer on the order; otherwise,

2. If there is bill-to (A/R) name and address information specified in the message:

• If that information matches an existing bill-to customer exactly, use that bill-to; or,

• If that information does not match an existing bill-to customer, create a new bill-to using the information in the message; otherwise,

3. If there is an A/R payment method on the order use the Bill to number assigned to the sold-to customer, if any; otherwise,

4. Search the Customer Bill To file for a bill-to customer that matches the name and address of the sold-to customer; if there is more than one match, use the bill-to with the highest number (bill-to created last); otherwise,

5. Create a new bill-to customer based on the sold-to customer information. In this situation, the new bill-to number is also assigned to the customer sold-to as well as to the order. Additionally, if a country is not passed, the system defaults the country defined in the Default Country for Customer Address (B17) system control value to the address.

 

Note:

• The system does not update an existing bill-to customer when creating a new order.

• The bill-to information, if any, provided in the message 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, regardless of the setting of the Update Customer Sold to with Bill to Account Number for New E-Commerce Orders (H87) system control value.

Selecting or Creating Individual Customers in E-Commerce Orders

1. The system uses the valid individual number, if any, provided in the new order message.

2. If a valid individual number is not specified, but the individual in the new order matches an existing individual for the sold-to customer, the system uses the existing individual.

3. Otherwise, the system creates a new individual using the information provided in the new order message. To be considered a match to an existing customer, the first three characters of the first name and the first four characters of the last name must be the same.

Note:

• If the Individuals Required in Order Entry (E01) system control value is set to N, incomplete or invalid individual information does not put the order in error status.

• If the Individuals Required in Order Entry (E01) system control value is set to Y, or if there is an existing individual for the sold-to customer, an individual is required on the e-commerce order. See the system control value for a complete discussion.

 

Selecting or Creating Recipient or Ship-to Customers in E-Commerce Orders

Multiple ship-tos: You can enable the customer to create multiple shipping addresses for an order through the e-commerce interface.

Alternate shipping address: You can enable the customer to enter an alternate shipping address. Alternate shipping addresses can be created as any of the following recipient order types, as specified by the retailer:

• an order ship-to address (the same as pressing F14 in order entry or order maintenance). This type of ship-to address is indicated in the New Order Message sent from CWDirect to the web storefront by a ship_to_type of 1.

• a sold-to recipient address (the same as the pressing F2(Sold To or Gift Recipient) in order entry or order maintenance). This type of ship-to address is indicated in the New Order Message sent from CWDirect to the web storefront by a ship_to_type of 2.

• a permanent ship-to address for the customer (the same as the function F7(Customer Ship To) in order entry or order maintenance. This type of ship-to address is indicated in the New Order Message sent from CWDirect to the web storefront by a ship_to_type of 3.

Ship-to customer email address: If this information is received by CWDirect, the email address is stored in one of the following files, depending on which type of alternate shipping address is specified in the web order message:

• the Order Ship To Address file (OEORST), for an Order Ship-to customer, ship to type = 1 in the New Order message.

• the Customer Sold To file (OECSSL), for a Sold-to/Recipient customer, ship to type = 2 in the New Order message.

• the Customer Ship To file (CSSHIP), for a Customer Ship-to, permanent alternate shipping address, ship to type = 3 in the New Order message.

You can review ship-to information by pressing F9 at the Order Inquiry screen (OIOM).

If you have not set up your storefront to specify which type of alternate shipping address to create when a web customer selects an alternate shipping address, CWDirect uses the value specified in system control value Default Recipient Type for E-Commerce Orders (H33).

Matching and creation: The system uses the following logic to determine whether to create a new recipient or permanent ship-to customer:

• customer sold-to (recipient customer): If the ship_to_type is 2 and if the ship_to name and address information do not match an existing sold-to customer based on the fields specified with the Phone Interface Values (F70), the system uses the information to create a new sold-to customer for the order recipient.

• permanent ship-to: If the ship_to_type is 3 and the ship_to name and address information in the message are not an exact match to an existing permanent ship-to for the sold-to customer based on the fields specified with the Phone Interface Values (F70), the system uses the name and address information to create a new permanent ship-to for the order. Additionally, if a country is not passed, the system defaults the country defined in the Default Country for Customer Address (B17) system control value to the address.

User-Defined Fields in the New Order Message

Overview: The Order Header User Field file is available to store information about the order that does not belong in any of the system-defined files or fields. Although this file is not accessible from a screen, you can create order-related records in this file by passing the information from the web storefront in the new order message.

Setup: Before you can process user-defined fields in the new order message, you must first create user-defined detail to identify the type of information you expect to receive. For example, in order to use the Order Header User Field file to store an additional external source code for the order, you would use the Create User Defined Field Screen to create a user field record such as:

• File code = OHD

• File description = Order header (or similar description)

You would then use the Create User Defined Field Detail Screen to create a user-defined detail record such as:

• Field label = source (or similar label)

• Field type = T (text)

• Field usage = I (input)

The Display sequence field is required, but the setting does not matter in this case, because the user-defined fields will not display on a screen. However, you will need to check the User Defined Field Detail file and determine the Sequence number, because the system uses this number for processing. The Sequence number does not display on any screen.

In order to receive user-defined fields through the e-commerce interface, you will also need to set up your web storefront to pass the new information.

Note: You can set up and use as many user-defined field types as you want for the Order Header User Field file, although you can receive and store only one field of each type for an order. For example, you could not receive and store two external Source fields for the same order.

Processing: When the system receives a new order message, it compares the user_field_det_seq_number in the message with the Sequence number in the User Defined Field Detail file to determine the format of the user field information received in the message. If there is no sequence number, or the sequence number is invalid, the system compares the user_field_Label in the message with the Field label in the User Defined Field Detail file.

If the system finds a match based on sequence number or label, it creates a record in the Order Header User Field file for the order. If the system does not find a match, or if it finds a duplicate message type, it ignores the information. The system creates no more than one record in the Order Header User Field file for each record type.

Example: You have created a user-defined detail record such as the one described above. The Sequence number is 1. You receive the following information in the new order message:
User Field Information	Matches?
user_field_det_seq_number = 9 user_field_Label = SOURCE	yes, based on label
user_field_det_seq_number = blank user_field_Label = SOURCE	yes, based on label
user_field_det_seq_number = 1 user_field_Label = SRC	yes, based on sequence number
user_field_det_seq_number = 9 user_field_Label = SRC	no (neither sequence number or label match)