Chapter 34: Loading Remote Orders (LPHO)
Purpose: Use this option to process the remote order file and:
• create orders that can be inquired against, maintained, or reserved, picked, and shipped
• identify orders with errors
See Chapter 25: Introducing Batch Order Entry for more information on entering batched orders
Clear file after transfer? The Clear Phone Interface Files (J14) system control value controls whether the system clears each record in the Phone Order file (PHORDS) for your company when you load remote orders.
In this chapter:
• Submit Phone Order Load Screen
• Custom Special Handling Error Listing
• Checks Against the Sold-to Customer
• Checks Against the Payment Information
• Checks Against the Shipping Address
• Check the Individual Customers
• Additional Checking for Retail Orders
• Check Custom Special Handling Instructions
• Checks Against Catalog Request
• Correcting Errors in Supporting Files
• Re-run the Phone Order Edit (EPHO)
• Reprint the Phone Errors Report (PPHO)
Submit Phone Order Load Screen
Purpose: Use this screen to specify whether to perform the edit after the load and to submit the load.
How to display this screen: Enter LPHO in the Fast path field at the top of any menu screen or select Load Phone Orders from a menu.
PHR0050 ENTER Submit Phone Order Load 9/01/99 11:43:17 KAL Co.
Perform edit after load . . Y (Y/N)
F3=Exit F12=Cancel CONFIRM: N (Y/N) |
Completing this screen:
1. Press Enter to process the load with edits; otherwise, enter N.
1. The CONFIRM prompt displays in the bottom right. Enter Y to begin the load; otherwise, press Enter, then press F3 or F12 to cancel.
The system submits the PHONE_LOAD job, which runs program PHR0004. This program produces the:
• Phone Errors Report (PHR0019$), which you can use to confirm that you received the correct file
• Custom Special Handling Error Listing (PHR0103$), which you can use to identify items included in the phone order load whose special handling information was incorrect.
Phone edit: If you entered Y to perform the edit, this program also generates the PHONE_EDIT job. This job produces the:
• Phone Errors Report (PHR0003$), which identifies what you need to do to correct each remote order with errors.
• Print Catalog Request Interface Errors Report, which identifies the catalog requests that you need to correct using the Work with Catalog Request Interface menu option; see Customer Service Chapter 112: Working with the Catalog Request Interface (WCRU). If a catalog request does not contain errors, CWDirect creates a record in the Catalog Request file.
Normally, you will want to perform the edit at the same time as you load the orders, so that you can identify any errors in the phone load; however, you can also perform the edit as a separate step. See Re-run the Phone Order Edit (EPHO).
The system creates an order batch for the orders in the Phone Order file and updates the Batch number fields in the Used Phone Batch file with the order batch number assigned by the outside system and the order batch number assigned by CWDirect. If you entered Y to perform the edit, error-free orders are added immediately to the CWDirect order files in a suspended status. You must accept the batch of orders through the Batch Order Entry function. Then these orders can continue on the order cycle (pick slip generation, billing, allocation, shipping, etc.).
Orders with errors remain in the batch in an E (error) status (if you did not enter Y to perform the edit, all orders will remain in E status until you run the edit as a separate step). Again, you must use the Work with Order Batches option (Batch Order Entry) to correct each order.
List of errors: For a listing of possible errors, see Order Creation and Maintenance Errors.
Credit card encryption: If you Use Credit Card Encryption (I97), the credit card number in the Phone Orders file will not be encrypted because it comes from an external system. Once a CWDirect order is created from information in the Phone Orders file, the system encrypts the credit card number in the CWDirect database to provide additional security of credit card data.
Purpose: This chapter describes how the system edits remote orders, and discusses what type of order information the system checks to ensure that each order is complete. This step separates “good” orders from orders that contain errors you need to fix.
During the edit, the system performs the same order edits as in Order Entry, such as validating the source code, item number, and shipper assigned to the order.
Each phase of the editing process is described, along with the errors the system may find at each step.
• Checks Against the Sold-to Customer
• Checks Against the Order Header Information
• Checks Against the Payment Information
• Checks Against the Shipping Address
• Check the Individual Customers
• Additional Checking for Retail Orders
• Check Custom Special Handling Instructions
• Checks Against Catalog Request
For more information: See Order Creation and Maintenance Errors for a listing of various errors that might occur and their descriptions.
Checks Against the Sold-to Customer
Check the Customer Number: If a customer sold-to number appears on the order, the system validates it against the Customer file.
Note: If the number is not valid, you cannot correct the order, as the sold-to customer number is not an enterable field. You must reenter the entire order.
If the sold-to customer number is valid, the system ignores the name and address information on the order header and uses the current address in the Customer file. You cannot process name or address updates to existing sold-to customers through the phone interface.
The system performs the following checks on the customer address if there is no sold-to customer number on the order.
Check the buyer's address: If you do not use the customer number to fill in the name and address, the system performs the following check on the buyer's (sold-to customer) name and address to ensure that it is a deliverable, valid address: the system verifies that the order contains the address of the customer who placed the order. If the address was not entered, the system assigns an E status to the order and prints an error message on the Phone Errors Report.
Check for duplicate address: If you entered customer name and address information but no customer number, the system next checks the Sold To Customer file to see if this is a duplicate customer. If the customer's name and address are found (based on the customer's match code, which is made up of parts of the customer's name and address), the system uses the address already on the system.
If the customer information is not found in the Sold To Customer file, the system creates a customer record for the new customer.
Checks Against the Order Header Information
Check for valid source code: The system checks that the source code used on the order is valid. If an invalid source code is used on the order, the system assigns an E status to the order and prints an error message on the Phone Errors Report.
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; see Default Unknown Source Code Logic.
Check for a valid ship via: The system checks that the ship via used on the order is valid, an SCF/ship via record exists for the postal code on the shipping address, and the ship via is an eligible shipper for the items on the order. If an invalid ship via is used on the order, the system assigns an E to the order and prints an error message on the Phone Errors Report.
Check for non-allocatable warehouse: If the Retail warehouse field for the order type on the order 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 for the order against the non-allocatable warehouse defined for the order type. If the item is not in stock, the system backorders the item against the non-allocatable warehouse.
Checks Against the Payment Information
Next, the system checks the payment information on the order. If no payment information was entered, the system assigns an E status to the order and prints an error message on the Phone Errors Report.
Check for valid pay type: Next, the system checks that the payment method used on the order is valid. If an invalid payment type is used on the order or a payment type is not defined, the system assigns an E status to the order and prints an error message on the Phone Errors Report.
If the Allow Auto-Assign field for a pay category 2 pay type is set to Y, you do not have to define a payment type for the order; the system defaults the pay category 2 pay type to the order whose leading digits match the leading digits you enter in the Credit card number field for an order. See Allow Auto-Assignment of Pay Category 2 Pay Type for additional processing information.
Check coupon information: If the customer redeemed a coupon on the order, the system checks the coupon number to ensure that it is valid and verifies that the coupon has not been previously redeemed. If the coupon information is invalid, the system assigns an E status to the order and prints the appropriate message on the Phone Errors Report. (If a coupon or gift certificate number comes in for a payment type that is not a coupon or gift certificate (payment category 5), the system clears the information from the field.)
The system uses the coupon amount specified in the Coupon Redemption file in CWDirect, not the amount that comes through the phone order load.
Check credit card information: If the order contains a credit card, the system checks the credit card number and expiration date. If the credit card information is invalid, the system assigns an E status to the order and prints the appropriate message on the Phone Errors Report.
You can perform credit card security identification for orders passed through the phone interface by defining values in the Card security value and Card security 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.
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.
If you Use Credit Card Encryption (I97), the credit card number in the Phone Orders file will not be encrypted because it comes from an external system. Once a CWDirect order is created from information in the Phone Orders file, the system encrypts the credit card number in the CWDirect database to provide additional security of credit card data.
Checks Against the Shipping Address
An order can come through the phone interface with a separate shipping address (in addition to the address of the sold-to customer). The system performs the same checks as for the sold-to customer to make sure that the address is deliverable. In addition, when evaluating how to interpret and validate this information, the system uses the following criteria:
1. If the shipping address comes through with a 9-position customer number, this tells the system to validate this number against the Customer file as an independent customer name and address, not a dependent ship-to record. See Checks Against the Sold-to Customer.
2. If the shipping address comes through with a C in the Create ship-to flag field, this tells the system to create a new permanent ship-to record for the sold-to customer. The system will go through its standard matching routine to see if the shipping address matches an existing permanent ship-to record for this sold-to customer only. If the system considers this address to be a match, it will use the existing name and address on the system without updating it. (You can display the customer's ship-to records in Order Entry by pressing F7 at the order header screen.)
3. If the shipping address comes through with a 3-position ship-to customer number (which normally appears as a suffix to the 9-position sold-to customer number, separated by a hyphen) this tells the system to validate the name and address against the existing shipping addresses for this sold-to customer only. The system will go through its standard matching and validation routine and return an error message if the address is invalid. If the system considers this address to be a match, it will use the existing name and address on the system without updating it.
4. If the shipping address comes through with the 9-position customer number, Create ship-to flag, and 3-position ship-to customer number all blank, this tells the system that this is a temporary, order-level shipping address only, and does not update the customer file. (You can display an order-level shipping address in Order Entry by pressing F14 at the order header screen.)
Check the Individual Customers
If you track individuals within an organization who place or authorize orders, you can include individual records in orders you process through the phone interface (record type 8); you can also include individual customer numbers as part of the sold-to customer record (record type 1). The system handles individual information differently depending on how the Individuals Required in Order Entry (E01) system control value is set. If this field is set to Y, when you process phone orders, the system:
• validates the position and department codes against the Individual Position and Individual Department files
• adds individuals to the order if valid individual customer numbers are included in record type 1, regardless of whether the individual records on the order match
• adds individuals to the order if no individual customer numbers are included in record type 1, after going through the standard matching process, creating new individual customer records if no match is found
• puts the order in error status if invalid individual customer numbers are included in record type 1
If the Individuals Required in Order Entry (E01) system control value is set to N, when you process phone orders, the system:
• does not validate position and department codes
• adds individuals to the order if any individual customer numbers are included in record type 1, valid or not; creates new individual customer records if no match is found
• ignores any individual records included with the phone order if there are no individual customer numbers included in record type 1
See Customer Service Chapter 26: Understanding Customer Types for more information on individual customers.
The system then checks the items on each order to ensure that the items are defined in the Item file and that other item information is correct.
First, the system verifies that items have actually been ordered. If not, the system assigns an E status to the order and prints an error message on the Phone Errors Report.
Item information: The system then checks for an order quantity, whether an item is eligible for special handling, etc. If this information is invalid, the system assigns an E status to the order and prints the appropriate error message on the Phone Errors Report. Item errors include:
• no quantity entered
• invalid or missing price override reason code
• item does not exist
• item not valid for warehouse
• invalid special handling code
• SKU does not exist
• invalid page/letter
• item/city restriction
• invalid price for continuity item
• price is zero
• invalid line freight override
• restricted item/SKU
• item/customer class restriction
• special handling code not valid for item/SKU/offer
• warehouse not found
• invalid no charge flag
• invalid return reason code
• item/SKU not gift certificate. See Chapter 37: Working with Gift Certificate Errors (MDGC).
• duplicate gift certificate number. See Chapter 37: Working with Gift Certificate Errors (MDGC)
• item country/state restriction (see Merchandising Chapter 29: Entering Additional Item Information)
• ship via invalid for item. See Chapter 35: Working with Item Ship Via Overrides.
• Invalid email/opt in flag for stored value card item. See Stored Value Card Email Hierarchy.
Additional Checking for Retail Orders
In addition to the checking described above, the system performs the following checking on retail orders:
• missing Affect inventory value; you must enter Y (affect inventory) or N (do not affect inventory)
• missing warehouse and location (if Affect inventory = Y)
• negative on-hand for warehouse
Note: If you try to process an order with a batch date within a closed accounting period, the following error message displays:
Invalid date. This record will be in error.
Check Custom Special Handling Instructions
Finally, the system checks the custom special handling instructions, if any, passed for individual items. Custom special handling errors include:
• exceeds maximum character: The information passed in the phone order load exceeds the maximum number of characters allowed for the custom special handling format detail. For example, the maximum number of characters allowable for a monogram is set to 3, and the phone order specified 5 initials.
• input not valid response: The information passed in the phone order load does not match any of the valid responses defined for the custom special handling format detail. For example, the custom special handling format detail is color, with valid responses set up for various colors, but the phone order passed style information instead.
• required input missing: A special handling format detail flagged as "required" was not included in the information passed in the phone order load. For example, the custom special handling format is for personalization, but no name information was passed in the phone order load.
• S/H code is invalid: The phone order load passed an inactive special handling format.
• item/SpclH restriction: The item for which the special handling information was passed is assigned to an item class restricted from the special handling format.
See Customer Service Chapter 9: Establishing Custom Special Handling Formats (WSHF).
Checks Against Catalog Request
The following conditions place a catalog request in an error status:
• delivery code is invalid or blank
• both offer and source code are blank
• both last name and company name are blank
• no street address
• invalid postal code or SCF
• postal code does not match state
• state is invalid
• state does not match country
• country code is invalid
• offer is invalid
• source is invalid
If the catalog request passes validation, a Catalog Request record is created. You can review and change the catalog request using the Work with Catalog Requests menu option; see Customer Service Chapter 109: Entering Catalog Requests (WCAT). You can process the catalog request using the Process Catalog Requests menu option; see Customer Service Chapter 110: Processing Catalog Requests (PCAT).
If the catalog request does not pass validation, CWDirect prints the Print Catalog Request Interface Errors Report and creates a Catalog Request Interface record. You can review and correct the catalog request using the Work with Catalog Request Interface menu option; see Customer Service Chapter 112: Working with the Catalog Request Interface (WCRU).
See Catalog Request Related System Control Values for more information on default values you can define in system control values to help prevent catalog request errors.
Correcting Errors in Supporting Files
Purpose: If the Phone Errors Report indicates an error based on information that was deleted from or changed in a supporting file, you must:
Reenter the missing or changed information in the appropriate supporting file, reprocess the order batch using the Rerun Phone Order Edit option, then accept the batch through Batch Order Entry, or Use Batch Order Entry, select the order that contains the error, and enter a different (valid) value on the order itself.
Continue reading to find out how to correct errors by recreating codes in the supporting files. Otherwise, see Chapter 35: Using Batch Order Entry to Accept, Reject, or Correct Phone Orders, for more information about fixing the actual orders. Also, see Chapter 37: Working with Gift Certificate Errors (MDGC).
Errors are commonly found if information is deleted from or changed in any of the following supporting files:
• Source code
• Sales representative
• Item number
• SKU
• Ship via for SCF
• Warehouse
• Location
• Return reason code
• No charge code
• Individual department
• Individual position
• Item Ship Via Override
Example: The edit identifies an error on a remote order because the order uses source code 100 and this code has been deleted from the Source Code file.
You can reenter source code 100 in the Source Code file or you can change the source code on the order to another, valid source code. After updating the file or the order itself, reprocess the order, then accept the batch.
When an error cannot be corrected: You might choose not to correct an error on an order line. For example, an order line which shows an error status because the item is restricted from shipment to the country or state of the ship to address should not be corrected, since you cannot ship the item.
You can delete the order line using the batch order entry menu option. See Chapter 35: Using Batch Order Entry to Accept, Reject, or Correct Phone Orders.
Re-run the Phone Order Edit (EPHO)
Purpose: Use this option to re-edit the remote orders file after you correct the errors listed on the Phone Errors Report. You can also use this option to perform an initial edit if you entered N when you loaded the phone orders.
Step-by-step instructions:
1. Enter EPHO in the Fast path field at the top of any menu screen or select the Rerun Phone Order Edit option from the menu.
2. The PHONE_EDIT job runs and prints an updated Phone Errors Report (PHR0003$) that lists any orders that still contain errors.
3. Use Batch Order Entry and the Phone Errors Report to correct any outstanding errors and accept these orders on the system.
You can run the Phone Order Edit as many times as needed to reprocess remote orders.
Note: If you load a new batch of phone orders while you still have orders with errors, the Rerun Phone Order Edit will pick up the new orders.
Reprint the Phone Errors Report (PPHO)
Purpose: Use this option to print an updated copy of the Phone Errors Report, which identifies the remote orders that still contain errors.
Step-by-step instructions: Follow these steps to reprint the Phone Errors Report:
1. Enter PPHO in the Fast path field at the top of any menu screen or select the Reprint Phone Order Edit Listing option from the menu.
2. The PHONE_PRNT job runs and prints the Phone Errors report (PHR0003$) that identifies any outstanding errors.
3. Use Batch Order Entry and the current Phone Errors report to fix the errors so that you can accept these orders on the system.
You can reprint the Phone Errors report as many times as necessary to correct the remote orders.
Note: If you load a new batch of phone orders while you still have orders with errors, the Phone Errors report will pick up errors for the new and old orders.
| Chapter 33: Transferring Remote Orders (TPHO) | Contents | SCVs | Search | Glossary | Reports | XML | Index | Phone Errors Report |
OE03_04 CWDirect 18.0 August 2015 OTN