12 System Operations

Operating the Background Jobs

Running Period End Processing

Using the System Utilities

Setting Up Authorization Services

Purging Tables

Flexible Payment Options

Processing Deposits

E-Commerce Interface

Workflow Management

Point of Sale Integration

Stored Value Card Integration

Importing Item/SKU and Set Data

Integration Layer Processes and Web Services

Merchandise Locator API

Brokered Backorders

Tracking User, Authority, and Password Updates

Translating Special Characters

Operating Background Jobs

Topics in this part: The following topics describe the functions available to operate the background ASYNC jobs.

• Using the ASYNC Jobs (MBJC) describes the purpose of the background jobs, provides a brief overview of the each background ASYNC job, explains the steps to use to start and end the background ASYNC jobs, and shows you how to location the function.

• Working with the CNTL_ASYNC Job shows you how to start and end the background ASYNC jobs, how to reorganize the data queues associated with the background ASYNC jobs, and how to change the status of the background ASYNC jobs.

• Working with the BILL_ASYNC Job shows you how to display the Billing Header Data Queue, how to correct Billing ASYNC errors, how to change the status of the Billing ASYNC job, and describes the table updates that occur when records are processed by the BILL_ASYNC job.

• Working with the EBO_ASYNC Job shows you how to display the Evaluate B/O Data Queue, how to correct EBO_ASYNC errors, how to change the status of the EBO_ASYNC job, and describes the table updates that occur when records are processed by the EBO_ASYNC job.

• Working with the ORDR_ASYNC Job shows you how to display the Order Ship To Data Queue, how to correct ORDR_ASYNC errors, how to change the status of the ORDR_ASYNC job, and describes the table updates that occur when records are processed by the ORDR_ASYNC job.

• Working with the OTHR_ASYNC Job shows you how to display the PO Header Data Queue, how to correct OTHR_ASYNC errors, how to change the status of the OTHR_ASYNC job, and describes the table updates that occur when records are processed by the OTHR_ASYNC job.

• Purging Active Procedures (MACP)shows you how to display the Active Procedures for a user and how to delete stranded Active Procedure records for a user.

• Working with Integration Layer Processes (IJCT) shows you how to work with the integration layer processes used for transmitting data between Order Administration and an external system.

Using the ASYNC Jobs (MBJC)

ASYNC (background) jobs process the non-time sensitive table updates, such as analysis and reporting updates, associated with transactions that are processed throughout the day in the following modules: Order Entry, Order Maintenance, Purchase Order Maintenance, Purchase Order Receiving, and Billing.

ASYNC jobs are used to process these updates for the following reasons:

• System response time would be affected if all table updates associated with each system transaction were processed interactively.

• Table updates can occur more quickly by dynamically updating the tables through out the day rather than running an end of day batch process.

• Analysis information can be viewed and reported more quickly.

Example: When new orders are entered onto the system, the order records are created interactively, and if desired, inventory can be reserved for the order. The order can be maintained, viewed, and is eligible for shipment as soon as it is entered.

The marketing information associated with the order is updated via the Order Processing ASYNC function. These table updates occur throughout the day as the records are sent to the data queue associated with the Order Processing ASYNC function.

ASYNC processing allows you to quickly update the tables necessary to create and ship the order, and eliminates the need to run a batch process at the end of the day to update all of the system tables associated with recording the order.

The following ASYNC jobs are used:

ASYNC Job	Function
CNTL_ASYNC	Starts and ends all of the ASYNC jobs. See Starting the ASYNC Jobs and Ending the ASYNC Jobs.
BILL_ASYNC	Updates system tables as orders are billed.
EBO_ASYNC	Performs reservation for backordered items when inventory levels for an item change.
ORDR_ASYNC	Updates system tables as orders are entered and maintained.
OTHR_ASYNC	Updates system tables as purchase orders are entered, maintained, and received.

In this topic:

• Running the ASYNC (Background) Jobs

• Starting the ASYNC Jobs

• Processing Transactions

• Ending the ASYNC Jobs

• ASYNC Job Status Codes

Running the ASYNC (Background) Jobs

Purpose: The ASYNC jobs, or background jobs, are used to process system table updates throughout the day. These jobs run in the background and process transactions in sequence as they are sent to the data queues. These jobs are placed in a Wait (DEQW) status when there are no records to process.

Starting the ASYNC Jobs

The following ASYNC jobs must be running to process the records in the data queue tables. The controlling ASYNC job (CNTL_ASYNC) is used to start the ASYNC jobs.

• BILL_ASYNC

• EBO_ASYNC

• OTHR_ASYNC

Note:

The ORDR_ASYNC job updates system tables with order and demand information as orders are entered and maintained. As you enter or maintain orders, the system sends the records to the Order Processing data queue for processing. As soon as the Order Processing Data queue receives a record to process, the record is processed immediately, regardless of the status of the Order Processing ASYNC (ORDR_ASYNC) job. The ORDR_ASYNC job processes multiple orders simultaneously. While the Order Async job does not need to be active to process records, you should set the Order Async job to active to handle reorganization and cleanup of any transactions that did not process correctly.

If you start the ASYNC jobs and the ASYNC subsystem is not running, the status of the CNTL_ASYNC job will be *JOBQ. The status will change to *ACTIVE as soon as the ASYNC subsystem is up.

Scheduling when the Async Jobs Start: You can create a schedule for a periodic process that contains the STRASYN periodic function to start asyncs.

Function	Description	Program	Summary
STRASYN	Start asyncs	MSSTRASYNC	If the asyncs are currently Inactive, this periodic function calls the Controlling Data Queue (CNTL_ASYNC) in Background Job Control (MBJC) and starts the background jobs. This periodic function performs the same updates as selecting Start for the CNTL_ASYNC to start the background jobs. See Starting the Background ASYNC Jobs.

For more information:

• See Working with Periodic Processes (WPPR) for information on how to assign each function to a periodic process.

• See Executing Periodic Processes (EPRO) for more information on scheduling a periodic process to run at a specified time.

Processing Transactions

As transactions are processed on the system, records are sent to the data queues. The records are processed one-by-one in the sequence in which they were sent to the data queue. A separate data queue is used for each ASYNC job.

The status of each data queue record can be viewed at any point by displaying the data queue associated with the ASYNC job.

Errors: If an error occurs as a record is being processed, the system stops processing the record at the error point, and moves on to the next record in sequence for processing.  

The records in error remain on the system until the error is corrected and processing can be fully completed. The errors are listed on the error reports that print when the ASYNC jobs are ended. A separate error report is printed for each ASYNC job.

Processing errors occur when a table associated with the transaction cannot be updated. This usually occurs because the system is attempting to update a record that no longer exists.

Example: If the Source Code record associated with an order is deleted before the order is billed, an error will occur during BILL_ASYNC.

Status of async jobs: When the Async jobs are active, the system checks the status of each async job under Job Management (My Jobs). If the async job is active and the job status is not RUN, the next time the system checks the status of the async jobs, the system automatically updates the job status to RUN. For example, if the Order Async is Active and you change the ORDR_ASYNC job to END, the system will automatically change the status of the ORDR_ASYNC job back to RUN. To start or stop the Async jobs, you need to start or stop the Controlling Async job in the Background Job Control (MBJC) menu option.

Ending the ASYNC Jobs

The ASYNC jobs must be ended to clear the completed records from the data queue tables and to print the error reports. The controlling ASYNC job (CNTL_ASYNC) is used to end all of the ASYNC jobs. You can use the ENDASYN periodic function to end them.

The ASYNC jobs should be ended once per day so that the data queues can be deleted and any errors can be corrected in a timely manner. If you do not bring these jobs down regularly:

• Completed records in the data queues will not be deleted and the data queue tables will become quite large.

• The 'shut down' process will take longer.

• Errors will be more difficult to correct.

For more information: See Troubleshooting the Async Jobs for more information.

Scheduling when the Async Jobs End: You can create a schedule for a periodic process that contains the ENDASYN periodic function to end asyncs.

Function	Description	Program	Summary
ENDASYN	End asyncs	MSENDASYNC	If the asyncs are currently Active, this periodic function calls the Controlling Data Queue (CNTL_ASYNC) in Background Job Control (MBJC) and ends the background jobs. This periodic function performs the same updates as selecting End for the controlling data queue to end the background jobs; however, any records in the data queue will be processed when the background ASYNC jobs are restarted. See Ending the Background ASYNC Jobs for more information on the updates that are performed.

For more information:

• See Working with Periodic Processes (WPPR) for information on how to assign each function to a periodic process.

• See Executing Periodic Processes (EPRO) for more information on scheduling a periodic process to run at a specified time.

When the ASYNC jobs are ended:

• If you manually end asyncs, a terminator record is sent to each data queue to identify the last record to be processed. Records sent to the data queue before the terminator record will be processed; records sent to the data queue after the terminator record was sent will be processed when the background ASYNC jobs are restarted.

• If you use the ENDASYN periodic function to end asyncs, any records in the data queue will be processed when the background ASYNC jobs are restarted.

• The data queue will be reorganized. All completed records will be deleted from the data queue tables.

• An error report listing all of the records that could not be processed, and the reason for the error, will be printed. A separate error report will print for each ASYNC job.

• The status of the ASYNC jobs will change to *INACTIVE.

If someone reboots the server: If someone restarts Order Management System while an asynchronous job is active, the system updates the job on the Job Management Screen (under My Jobs) to MSG status. In this situation, you will need to run the JOBCLN periodic function. See Running the JOBCLN Periodic Function to Correct the Async Jobs for more information.

ASYNC Job Status Codes

Status	Description
*ACTIVE	The ASYNC job is up and running.
*INACTIVE	The ASYNC job is not running.
*JOBQ	The ASYNC job has been submitted to the job queue for start-up.  The ASYNC jobs are in a *JOBQ status only when the ASYNC subsystem has not been started.
*ENDPEND	The ASYNC job is in the process of ending.
*REORG	Completed records processed by the ASYNC job are being deleted from the tables.

Working With the CNTL_ASYNC Job

The controlling ASYNC job (CNTL_ASYNC) is used to start and end each of the background ASYNC jobs. When you start the CNTL_ASYNC job, all of the background ASYNC jobs start; when you end the CNTL_ASYNC job, all of the background ASYNC jobs end. You cannot start or end an individual background ASYNC job.

You should end the CNTL_ASYNC job each day, when your operations for the day are complete. When you end the CNTL_ASYNC job:

• Records that were processed successfully for each background ASYNC job are deleted from the data queue tables.

• An error list is produced for each background ASYNC job.

Ending the background ASYNC jobs allows you to delete unnecessary records from the system, and enables you to correct any processing errors in a timely manner.

In this topic:

• Work with Background Jobs Screen

• Display Asynchronous Job Screen (Displaying the CNTL_ASYNC Job)

• Starting the Background ASYNC Jobs

  • Starting the Background ASYNC jobs

• Ending the Background ASYNC Jobs

  • Display Active Procedure Window

• Reorganizing the ASYNC Job Data Queues

• Troubleshooting the Async Jobs

  • Determining the Status of the Async Jobs

  • Verifying the Status of the Async Jobs

  • Running the JOBCLN Periodic Function to Correct the Async Jobs

  • Reviewing the Async Job Log

Work with Background Jobs Screen

Purpose: This screen displays the current status of each background ASYNC job. This screen is used to start or end the ASYNC jobs, to display the records in the data queue associated with each job, or to reorganize the data queues.

All of the options on this screen can be used with the Controlling ASYNC (CNTL_ASYNC) job.

How to display this screen: Enter MBJC in the Fast path field at the top of any menu or select Background Job Control from a menu.

Field	Description
Job name	The name of the ASYNC job. The ASYNC jobs are: BILL_ASYNC = Billing background job CNTL_ASYNC = Controlling background job EBO_ASYNC = Evaluate backorders background job ORDR_ASYNC = Order processing background job OTHR_ASYNC = Other background job purchase orders) Alphanumeric, 10 positions; optional.
Description	The description of the data queue associated with the ASYNC function. Alphanumeric, 40 positions; optional.
Status	The status of the ASYNC job. Valid status codes are: *ACTIVE = the ASYNC function is running *INACTIVE = the ASYNC function has ended *JOBQ = the ASYNC function has been submitted to the job queue for startup *Endpend = the ASYNC function is in the process of ending *Reorg = the data queue associated with the ASYNC function is being reorganized Alphanumeric, 10 positions; display-only.
Control	A code indicating whether the ASYNC function is a controlling function.  The controlling function is used to start, end, and reorganize the data queues for the ASYNC functions it controls.  Currently, the CNTL_ASYNC function is the only controlling function.   Valid codes are: Y = the ASYNC function is a controlling function N = the ASYNC function is not a controlling function.

Note:

In order to perform certain options at the Work with Background Jobs screen, you need to have the Security administrator flag for the user selected. See User Configuration in the Administration Guide for more information.

Screen Option	Procedure
Display the attributes of an ASYNC job	Select Display for an ASYNC job to advance to the Display Asynchronous Job Screen (Displaying the CNTL_ASYNC Job).
Start the background ASYNC jobs	Select Start for the CNTL_ ASYNC job to start all of the ASYNC jobs.   See Starting the Background ASYNC Jobs.
End the background ASYNC jobs	Select End for the CNTL_ ASYNC job to end all of the ASYNC jobs. See Ending the Background ASYNC Jobs.
Reorganize the data queue for a background ASYNC job	Select Reorganize queue for the CNTL_ ASYNC job to reorganize the data queues associated with each   ASYNC job. See Reorganizing the ASYNC Job Data Queues.
Display the data queue for an ASYNC job	Select Display Data queue for an ASYNC job. Display Data queue cannot be used with the CNTL_ASYNC.
Work with Drop Ship background jobs	Select Drop Ship Jobs to advance to the Work with Drop Ship Background Jobs Screen.
Work with integration layer jobs	Select Integration Layer to advance to the Work with Integration Layer Process Screen.

Display Asynchronous Job Screen (Displaying the CNTL_ASYNC Job)

Purpose: Use this screen to display descriptive information about an ASYNC job such as the CNTL_ASYNC job.

How to display this screen: Select Display for a job at the Work with Background Jobs Screen.

Field	Description
Process name	The name of the process for this ASYNC job. Listed as the Workstation for the ASYNC job at the screen in Purge Active Procedures Across Users (MACX). The data queues are: CNTL_ASYNC = CNTRLDATAQ BILL_ASYNC = BILLDATAQ EBO_ASYNC = EVLBODATAQ ORDR_ASYNC = ORDERDATAQ OTHR_ASYNC = OTHERDATAQ Alphanumeric, 10 positions; display-only.
Job name	The name of the ASYNC job. The ASYNC jobs are: BILL_ASYNC = Billing background job CNTL_ASYNC = Controlling background job EBO_ASYNC = Evaluate backorders background job ORDR_ASYNC = Order processing background job OTHR_ASYNC = Other background job purchase orders) Each ASYNC job is discussed separately in this part. Alphanumeric, 10 positions; optional.
Description	The description of the ASYNC job. Alphanumeric, 40 positions; display-only
Start	The date and time the ASYNC job was last started and the User ID of the person who started it. (Date):  Numeric, 6 positions; display-only. (Time):  Numeric, 6 positions; display-only. (User ID):  Alphanumeric, 10 positions; display-only.
End	The date and time the ASYNC job was last ended and the User ID of the person who ended  it. (Date):  Numeric, 6 positions; display-only. (Time):  Numeric, 6 positions; display-only. (User ID):  Alphanumeric, 10 positions; display-only.
Controlling job	A flag indicating whether this function controls other ASYNC functions. The controlling ASYNC function starts and ends other ASYNC functions. Valid values are: Selected = This is a controlling ASYNC function. Unselected = This is not a controlling ASYNC function. The CNTL_ASYNC job is the only controlling ASYNC job.
System Option	A flag indicating whether this function is a system function that cannot be deleted by the user. Valid values are: Selected = This function cannot be deleted by the user. Unselected = This function can be deleted by the user.
Status	The current status of the function. Valid status codes are: *ACTIVE *INACTIVE *ENDPEND *JOBQ *REORG Display-only.

Starting the Background ASYNC Jobs

Purpose: The CNTL_ASYNC job is used to start and end all of the other background ASYNC jobs.

The following background jobs must be active for the records in the data queues to be processed. If the background ASYNC job is not active, records will be held in the data queue until you start the background ASYNC jobs.

• BILL_ASYNC

• EBO_ASYNC

• OTHR_ASYNC

Note:

The ORDR_ASYNC job updates system tables with order and demand information as orders are entered and maintained. As you enter or maintain orders, the system sends the records to the Order Processing data queue for processing. As soon as the Order Processing Data queue receives a record to process, the record is processed immediately, regardless of the status of the Order Processing ASYNC (ORDR_ASYNC) job. The ORDR_ASYNC job processes multiple orders simultaneously. While the Order Async job does not need to be active to process records, you should set the Order Async job to active to handle reorganization and cleanup of any transactions that did not process correctly.

Starting the Background ASYNC jobs

You can start the background ASYNC jobs manually at the Work with Background Jobs Screen, or create a periodic process to schedule the ASYNC jobs to start at a specified time.

When you start the background ASYNC jobs, the system removes any terminator records that may exist in the data queues. The system creates a terminator record in the data queues when you end the background async jobs to determine which records to process before the asyncs are brought down and which records to process when the asyncs are restarted. Multiple terminator records may exist in the data queues if you run the ENDASYN periodic function to end the asyncs when the asyncs are already inactive. Because you are now starting the background async jobs, the system no longer needs the terminator records to determine when to reprocess the records in the data queue and instead will process all records that may exist in the data queues.

Before you start the background ASYNC jobs: To start the background ASYNC jobs, the status of each job must be *INACTIVE and each job must not be running. You can use the Display Active Batch Jobs Screen menu option to verify that the jobs are not running.

To manually start the ASYNC jobs:

1. At the Work with Background Jobs Screen, review the status of the background jobs. The jobs must be started if the status is *INACTIVE.

2. Select Start for the CNTL_ASYNC job.

3. The status of the ASYNC jobs should be *ACTIVE.

Unable to start? The system verifies that the job is not currently in active status and is not actually running on any server. If the job is already in active status, or is actually running on a server, the screen displays an error message.

To resolve issues with the job’s status, use the JOBCLN periodic function.

To schedule the ASYNC jobs to start at a specified time: 

Create a schedule for a periodic process that contains the STRASYN periodic function to start asyncs.

Function	Description	Program	Summary
STRASYN	Start asyncs	MSSTRASYNC	If the asyncs are currently Inactive, this periodic function calls the Controlling Data Queue (CNTL_ASYNC) in Background Job Control (MBJC) and starts the background jobs.    This periodic function performs the same updates as selecting Start for the CNTL_ASYNC to start the background jobs.

For more information:

• See Working with Periodic Processes (WPPR) for information on how to assign each function to a periodic process.

• See Executing Periodic Processes (EPRO) for more information on scheduling a periodic process to run at a specified time.

• See Using the JOBCLN Function to Resolve Job Status Across Servers for more information on how to reset the async jobs when they are out of sync.

Ending the Background ASYNC Jobs

Purpose: You can end the background ASYNC jobs manually at the Work with Background Jobs Screen, or create a periodic process to schedule the ASYNC jobs to end at a specified time.

Use the CNTL_ASYNC job to end all of the other background ASYNC jobs. You should bring down the background jobs at the end of your processing day.   

When you bring down the background ASYNC jobs:

• If you manually end asyncs, a terminator record is sent to each data queue to identify the last record to be processed. Records sent to the data queue before the terminator record will be processed; records sent to the data queue after the terminator record was sent will be processed when the background ASYNC jobs are restarted.

• If you use the ENDASYN periodic function to end asyncs, any records in the data queue will be processed when the background ASYNC jobs are restarted.

• The data queues are reorganized. All completed records are deleted from the data queue tables. Records that have not been fully processed will be reloaded to the data queue when the background ASYNC jobs are restarted.

• An error list prints for each background ASYNC job, listing the records that could not be fully processed and the reason for the error.

When the jobs end: The status of each background job will change from *ACTIVE to *INACTIVE. (You may see *ENDPEND or *REORG before you see *INACTIVE, depending upon how long it takes to end each job.)

Note:

You must end the background ASYNC jobs before the ASYNC subsystem is brought down. If you bring down the ASYNC subsystem while the background ASYNC jobs are running, the jobs will be ended but will remain in an *ACTIVE status. You will then need to run the JOBCLN periodic function to reset the status correctly. See Using the JOBCLN Function to Resolve Job Status Across Servers.

To manually end the ASYNC jobs:

1. Select End for the CNTL_ASYNC job at the Work with Background Jobs Screen.

2. The status of the ASYNC jobs changes to ENDING and then to INACTIVE.

3. When you end the ASYNC jobs, the Display Active Procedure window displays if there are any active procedures for the Order Entry/Maintenance, Purchase Order Maintenance, Receiving, or Confirmation functions. The system creates these records to prevent possible conflicts when users are engaged in these activities. See Display Active Procedure Window.

Unable to end? The system verifies that the job is not currently in inactive status and is actually running server. If the job is already in inactive status, or is not actually running on a server, the screen displays an error message.

To resolve issues with the job’s status, use the JOBCLN periodic function.

Display Active Procedure Window

This window opens when you end the ASYNC jobs if there are any active procedures for the Order Entry/Maintenance, Purchase Order Maintenance, Receiving, or Confirmation functions. The system creates these records to prevent possible conflicts when users are engaged in these activities.

If a user is active in a function:

• the user can exit the function before the ASYNC jobs end. Depending on the activity, the user might need to exit Order Administration and then reenter, if needed, to clear the active procedure record.

• you can select Delete next to each active procedure record to delete the active procedure, or select Delete all to delete them all. Deleting the active procedure does not force the user out of the activity; there is no signal of the deletion to the user and the user can continue entering updates to the record. However, this allows more than one user to access the same record, such as an order or a customer and possibly overwrite each other’s updates.

If neither of these steps clears the active procedure record, you will need to purge the Active Procedures table. See Purging Active Procedures (MACP).

Field	Description
Job #	The system job number assigned to the active procedure. Numeric, 6 positions; display-only
Program description	The description of the program associated with the Active Procedures record. Alphanumeric, 3 positions; display-only.
User	The User ID of the person engaged in the activity that created the Active Procedures record.   Alphanumeric, 10 positions; display-only.
Workstation	The Workstation ID where the user is working. Alphanumeric, 10 positions, display-only.
Start date	The date when the Active Procedures record was created.  This is the date the user entered the application. Numeric, 6 positions; display-only.
Time	The time when the Active Procedure record was created.  This is the time the user entered the application. Numeric, 6 positions; display-only.

To remove active procedures:

1. Have each person whose name appears in the window exit the application so that you can end the ASYNC jobs. It may be necessary to exit Order Administration temporarily to delete the active procedure record, or

2. Select Delete next to each active procedure record to delete the active procedure. Deleting the active procedure does not force the user out of the activity; there is no signal of the deletion to the user and the user can continue entering updates to the record. However, this allows more than one user to access the same record, such as an order or a customer and possibly overwrite each other’s updates.

3. Use Purging Active Procedures (MACP) to delete any stranded Active Procedure records, if necessary. You can also purge active procedures for interactive jobs that are older than a specified number of hours using the Delete Stranded Active Procedures (PFR0121) periodic function.

4. Select Refresh to refresh the Active Procedure Window to monitor whether the users have exited.

5. Select Exit to exit the window and return to the Work with Background Jobs Screen.

Deleting active procedure records: You can delete the Active Procedure records at this window by selecting Delete for each record in the window. Deleting the active procedure does not force the user out of the activity, such as order entry; there is no signal of the deletion to the user and the user can continue entering updates to the record. However, it is not recommended to delete Active Procedure records in this way, because it removes the safeguard against two users potentially accessing the same record, such as an order or customer, at the same time.

To schedule the ASYNC jobs to end at a specified time:

Create a schedule for a periodic process that contains the ENDASYN periodic function to end asyncs.

Function	Description	Program	Summary
ENDASYN	End asyncs	MSENDASYNC	If the asyncs are currently Active, this periodic function calls the Controlling Data Queue (CNTL_ASYNC) in Background Job Control (MBJC) and ends the background jobs. This periodic function performs the same updates as selecting End for the controlling data queue to end the background jobs; however, any records in the data queue will be processed when the background ASYNC jobs are restarted.

Note:

When you end the ASYNC jobs using the job scheduler, the system does not look for active procedures, and instead, ends the asyncs immediately.

For more information:

• See Working with Periodic Processes (WPPR) for information on how to assign each function to a periodic process.

• See Executing Periodic Processes (EPRO) for more information on scheduling a periodic process to run at a specified time.

Reorganizing the ASYNC Job Data Queues

Purpose: The data queues associated with the ASYNC jobs are reorganized when the ASYNC jobs are ended. Use the Reorganize queue option as a recovery tool only when the ASYNC jobs end abnormally before the data queues have been reorganized. This option allows you to reorganize the data queues before the next ASYNC job end is processed.

To determine if the data queues were reorganized: Display the data queue for an ASYNC job. If the entry date for a record is earlier than the date you last ended the ASYNC jobs, or if records are in a *BLANK status, the data queues were not reorganized. If you do not use the Reorganize queue option, the data queues will be reorganized the next time you end the ASYNC jobs.

When you use the Reorganize queue option, the system deletes completed records from the data queue tables associated with the ASYNC jobs. Records that have not been fully processed will be reloaded to the data queues when the background ASYNC jobs are restarted.

The Reorganize queue option is available only with the CNTL_ASYNC job. All of the ASYNC jobs must be in a *INACTIVE status, and there can be no Active Procedures records for Order Entry, Order Maintenance, Purchase Order Maintenance, Receiving, and Confirmation functions.

Before you reorganize the data queues: Before you attempt to reorganize the data queues, you should make sure that the status of each ASYNC job is *INACTIVE.

How to reorganize the data queues: Select Reorganize queue for the CNTL_ASYNC job at the Work with Background Jobs Screen.

Active procedures window: A pop-up window opens if there are any users in the Order Entry/Maintenance, Purchase Order Maintenance, Receiving, or Confirmation functions. The data queues cannot be reorganized if there are any users in these functions. See Ending the Background ASYNC Jobs

For more information: See Troubleshooting the Async Jobs for more information on the steps you should take if you suspect the async jobs are not running correctly.

Troubleshooting the Async Jobs

Use the following steps if you suspect that the async jobs are not running correctly.

• Determining the Status of the Async Jobs

• Verifying the Status of the Async Jobs

• Running the JOBCLN Periodic Function to Correct the Async Jobs

• Reviewing the Async Job Log

Determining the Status of the Async Jobs

Use the Display Active Batch Jobs Screen to determine if the async jobs are running across all Order Administration application servers.

• If the async job is listed on the Display Active Batch Jobs Screen, the job is running. Review the My Jobs field for the async job to determine if the status of the async job on the Job Management Screen is accurate. See Verifying the Status of the Async Jobs.

• If the async job is not listed on the Display Active Batch Jobs screen, the job is not running, regardless of the status of the job on the Job Management Screen or the status of each async job on the Work with Background Jobs Screen. See Running the JOBCLN Periodic Function to Correct the Async Jobs for background on resetting the asyncs. Once the JOBCLN completes, you can restart the background async jobs; see Starting the Background ASYNC Jobs.

Verifying the Status of the Async Jobs

The batch jobs displayed on the Display Active Batch Jobs Screen are the jobs that are currently running across all Order Administration application servers. The My Jobs field on this screen indicates if the status of the batch job on the Job Management Screen is accurate. The table below indicates the action to take, based on the status of the async job on the Display Active Batch Jobs screen.

Async Status in My Jobs Field:	Indicates:	Action to Take:
RUN	The async job is running and the status of the job on the Job Management Screen is accurate.	Verify that the status of each of the async jobs that is running displays as *ACTIVE on the Work with Background Jobs Screen. What if the async job is active but no records are being processed? If this situation occurs, it is possible that the controlling async data queue table has been cleared. To correct, use the JOBCLN periodic function.
MSG	The async job is running, but the status on the Job Management Screen is not accurate.	When the Async jobs in the Background Job Control (MBJC) menu option are active, the system checks the status of each async job on the Job Management screen. If the async job is active and the job status is not RUN, the next time the system checks the status of the async jobs, the system automatically updates the job status to RUN. 1. If an async job is listed on the Display Active Batch Jobs Screen and its My Jobs status is not RUN, wait a few minutes to see if the system will automatically update the status to RUN. 2. Once the status updates to RUN, verify that the status of the async jobs displays as *ACTIVE on the Work with Background Jobs Screen. If the async job does not auto-update to a RUN status, you will need to determine if an error occurred. See Reviewing the Async Job Log. Use the JOBCLN periodic function to correct the async jobs. See Running the JOBCLN Periodic Function to Correct the Async Jobs for more information. Note:  Never try to end an actively running async job by manually ending it on the Job Management Screen. This does not actually end the async job.
ERR	The async job is running, but a user has manually ended the job on the Job Management Screen while its status was MSG.
END	The async job is running, but a user has manually ended the job on the Job Management Screen.
*RMV*	The async job is running, but a user has removed the job from the Job Management Screen.	End the CNTL_ASYNC that submitted the job. See Ending the Background ASYNC Jobs for instructions. Once you end the CNTL_ASYNC, the system ends the async job and removes the async job from the Display Active Batch Jobs Screen since it is no longer running. You will need to restart the CNTL_ASYNC in order to resubmit the job and run it again. Note: Never remove an actively running async job from the Job Management Screen. If you do this, the system removes all traces of the job from the system, even though the job is still actively running.

Running the JOBCLN Periodic Function to Correct the Async Jobs

Running the JOBCLN Periodic Function to Correct the Async Jobs

The JOBCLN periodic function corrects the status of ASYNC jobs across all servers as follows.

Correcting the status of the BILL_ASYNC, EBO_ASYNC, OTHR_ASYNC, and ORDR_ASYNC:

• Currently running? If one of these ASYNC jobs is currently running, the JOBCLN function does the following:

  • If the status is INACTIVE, change the status to ACTIVE; otherwise, do not change the status. Also, for the BILL_ASYNC job, make sure that there is an active procedure if the job is running.

  • If there are multiple Ending records for an async job, delete all but one.

  • If the job is in END, FIN, or MSG at Job Management (My Jobs) screen, change the status to RUN and update Job History (Display Job History (DJHY)).

• Not currently running? Otherwise, if the ASYNC job is not currently running, the JOBCLN function does the following:

  • If the status is ACTIVE, change it to INACTIVE.

  • If there is an active procedure for the BILL_ASYNC job, delete it.

  • If the job is in RUN or MSG status, or any status except END at the Job Management screen, change the status to END and update Job History.

Correcting the status of the CNTL_ASYNC job:

• Currently running? If the job is running, the JOBCLN periodic function does the following:

  • If the status is INACTIVE, update it to ACTIVE; otherwise, do not change status.

  • If the status is not in ENDING or REORG status, delete any Ending records for each of the ASYNC jobs.

  • If the status is END, FIN, or MSG at the Job Management screen, update the status to RUN and update Job History.

  • If the EBO_ASYNC or ORDR_ASYNC jobs are INACTIVE, start them.

  • If the BILL_ASYNC or OTHR_ASYNC are INACTIVE, do not change the status because each will start up automatically when data arrives in its queue.

• Not currently running? If the CNTL_ASYNC is not currently running, the JOBCLN periodic function does the following:

  • If any other ASYNC job is ACTIVE, create an Ending record if one does not exist.

  • If any of the other ASYNC jobs are INACTIVE, delete any Ending records for those jobs.

  • If the CNTL_ASYNC status is ACTIVE or ENDING or JOBQ, change to INACTIVE.

  • If the status is REORG and the REORG Job is not currently running, change the status to INACTIVE.

  • If the status is RUN, FIN, MSG, or any other status at the Job Management screen, update the status to END and update Job History.

Reviewing the Async Job Log

If the async job remains in a MSG status without being auto-corrected by the system, you can also review the async job log to determine if an error occurred.

Async Job Log

To review the async job log: Click the logFile link for the async job on the Job Management Screen to advance to the Log file screen. Note: If the logFile is not a link, the async job was submitted from a different application server; you must log on to the other application server to review the async job log.

If an error occurred during async processing, the system writes an entry similar to the following in the async job log:

2009-04-18 22:09:10,161 ERROR [ JENASYS] execute(): status change to [MSG]:334547java.lang.RuntimeException: java.lang.RuntimeException: com.microsoft.sqlserver.jdbc.SQLServerException: The result set has no current row. (JenasysJob.java:297)

2009-04-18 22:09:10,177 ERROR [ JENASYS] run(): Job status change to [MSG]. In 'invokeHandler' EXCEPTION occured while calling processServiceRequest. java.lang.RuntimeException: com.microsoft.sqlserver.jdbc.SQLServerException: The result set has no current row. (JenasysJob.java:701)

If an error exists in the async job log, copy the error and the log so that the problem can be researched if needed.

If an error occurred for one async job: Use the JOBCLN periodic function. See Using the JOBCLN Function to Resolve Job Status Across Servers for more information.

Working With the BILL_ASYNC Jobs

Purpose: The BILLING ASYNC job updates system tables with sales and shipment information as orders are billed.

As orders are confirmed, items returned, or records are uploaded from the PC Manifest system, the system sends records to the Billing data queue for processing. If the Billing ASYNC (BILL_ASYNC) job is active, it processes the records immediately. If the job is inactive when the records arrive, the BILL_ASYNC job processes them when it becomes active again. Records for virtual stored value cards are given priority for processing, and all other records are processed afterward in the sequence in which they arrive at the data queue.

If there are any errors, processing for that order stops at the error point. The system begins processing for the next order record in sequence. You should correct any errors that exist as soon as possible so that your system tables update properly. See Working with BILL_ASYNC Status Messages.

You can review the status of each record in the data queue at any point at the Display Billing Header Data Queue Screen 

To generate a shipment or return confirmation: Order Administration generates a shipment or return confirmation email or Outbound Email XML Message (CWEmailOut) when you:

• process a shipment or return through billing if the Send Shipment Confirmation from Billing (L98) system control value is selected.

• generate shipment confirmations or return confirmations using the Send Internet Order Ship Confirmations menu option; see Sending Internet Order Ship Confirmation (ESCF).

• execute the ECSHCNF periodic function; see Working with Periodic Functions (WPER).

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

For more information: See Troubleshooting the Async Jobs for more information on the steps you should take if you suspect the async jobs are not running correctly.

In this topic:

• Related System Control Values

• Display Asynchronous Job Screen (Displaying the Billing ASYNC Job)

• Display Billing Header Data Queue Screen

• Working with BILL_ASYNC Status Messages

• Updates During Background Processing.

Related System Control Values

The following system control values affect the function of the BILL_ASYNC job.

System Control Value	Description
Use Async Start Date for Billing Transactions (E95)	If this system control value is selected, the Override Async Start Date pop-up window opens when you start the CNTL_ASYNC job. In this window you can specify a date other than the system date to update billing transaction records and ensure a clean cutoff for billing. You must confirm your entry after completing the pop-up window. See Working with the CNTL_ASYNC Job. If this system control value is unselected, the system date is used for all billing transactions. Because Order Administration can be set up with multiple companies each with different settings, if any company has the system control value selected, the pop-up window is displayed. The override date that you enter at the window is used only for those companies that have the system control value selected; the system date is used for any company where the system control value is unselected.
Number of Billing Async Jobs to Start (F08)	This system control value indicates how many instances of the BILL_ASYNC job to run when you start the CNTL_ASYNC job. You can choose to run more than one BILL_ASYNC job to increase the rate at which you process billing transactions. Because the background jobs run for all companies in Order Administration, the system checks the setting for this system control value in all companies, and uses the highest value (up to 9). A setting of 0 or 1 will cause the system to run one BILL_ASYNC job only. See Note: For better system performance, if you run more than one Billing Async job, you should also select Delay Billing Updates (K85) to defer updates. Unique job names: If the Number of Billing Async Jobs to Start (F08) is set to more than 1 and Delay Billing Updates (K85) is selected, each submitted BILL_ASYNC job is assigned a unique name. The first is always named BILL_ASYNC, the second is named BILL_ASYNC_02, and so on.
Delay Billing Updates (K85)	If this system control value is selected, the Billing Async defers certain updates until you run the Delay Billing Update Process. If this system control value is unselected, the Billing Async completes all updates immediately. See Updates During Background Processing for more information on the billing updates that occur immediately and the updates that are processed by the Delay Billing Update Process.
Hold Invoices for Multi-Recipient Orders (G07)	This system control value defines whether the system holds invoices for multi-recipient orders until all of the pick slips for the order are confirmed. If this system control value is selected, the system determines if the pick slip being confirmed is the last pick slip that needs to be confirmed for the multi-recipient order. If the pick slip is the last pick slip that needs to be confirmed for the order, the system: submits all of the pick slips associated with the order to the BILL_ASYNC places the order in a closed status creates an invoice for all of the pick slips associated with order If the pick slip is not the last pick slip that needs to be confirmed for the order, the system: places the pick slip in a B (billing pending) status until all of the pick slips for the order have been confirmed does not create an invoice keeps the order in an open status writes an order transaction history message indicating that the pick slip has been confirmed
Capture Addresses for Invoice (J24)	If this system control value is selected, the system saves the billing and shipping addresses for each invoice during billing. The shipping address is used to calculate tax.
Preload Deposits (L78)	If selected, billing creates records in the CC Deposit Transaction table and CC Deposit History table immediately after creating records in the Invoice Payment Method table.

Display Asynchronous Job Screen (Displaying the Billing ASYNC Job)

Purpose: Use this screen to display the job attributes for each background ASYNC job, including the Billing ASYNC job.

How to display this screen: Select Display for the BILL_ASYNC job at the Work with Background Jobs Screen.

Field	Description
Process name	The name of the process for this ASYNC job. The name of the billing data queue is BILLDATAQ. Alphanumeric, 10 positions; display-only.
Job name	The name of the ASYNC job. Alphanumeric, 10 positions; display-only.
Description	The description of the ASYNC job. Alphanumeric, 40 positions; display-only.
Start	The date and time the ASYNC job was last started and the User ID of the person who started it. (Date): Numeric, 6 positions; display-only. (Time): Numeric, 6 positions; display-only. (User ID): Alphanumeric, 10 positions; display-only.
End	The date and time the ASYNC job was last ended and the User ID of the person who ended it. (Date): Numeric, 6 positions; display-only. (Time): Numeric, 6 positions; display-only. (User ID): Alphanumeric; 10 positions; display-only.
Controlling job?	A flag indicating whether this job controls other ASYNC functions. The controlling ASYNC job starts and ends other ASYNC functions. Valid values are: Selected = This is a controlling ASYNC job. Unselected = This is not a controlling ASYNC job. The CNTL_ASYNC job is the only controlling ASYNC job.
System Option?	A flag indicating whether this job is a system function that cannot be deleted by the user. Valid values are: Selected = This job cannot be deleted by the user. Unselected = This job can be deleted by the user.
Status	The current status of the job. Valid status codes are: *ACTIVE *INACTIVE *ENDPEND *JOBQ *REORG Display-only.

Display Billing Header Data Queue Screen

Purpose: This screen displays the records that were sent to the data queue for processing since the last time the ASYNC job was ended. Records are sent to the data queue when orders are confirmed or items are returned.

Records for virtual stored value cards are given priority for processing, and all other records are processed afterward in the sequence in which they arrive at the data queue.

The status of each record, indicating if the record was processed or if any errors exist, displays.

How to display this screen: Select Display Data Queue for the BILL_ASYNC job at the Work with Background Jobs Screen.

Field	Description
Cmp (Company)	The number of the company for which the transaction was processed. If you are running operations for more than one company, transactions for all companies are submitted to the same data queue. Numeric, 3 positions; display-only.
Date	The date when the transaction was submitted to the data queue for processing. Numeric, 6 positions (in user date format); display-only.
Time	The time when the transaction was submitted to the data queue for processing. Note:  The number of seconds might exceed 59 if the ASYNC job processed 60 or more records in a minute. Numeric, 6 position (HH:MM:SS format); display-only.
Job #	The job number assigned to the transaction when it was submitted to the data queue. Numeric, 6 positions; display-only.
B/A	A code indicating whether the record represents a before image or an after image for the transaction. After records are written for all transactions; before records are written for orders that have been maintained. Valid codes are: B = The record represents the order information before the transaction was processed. A = The record represents the order information after the transaction was processed. Alphanumeric, 1 position; display-only.
Processed	The status of the record. The record is either not processed, in process, in error, or processed. A status message displays for each step. Alphanumeric, 30 positions; display-only.
Ordr ship to	The order ship-to number for which the record is being processed. (Order #): Numeric, 8 positions; display-only. (Ship-to): Numeric, 3 positions; display-only.
Trans	A code identifying the function from which the transaction originated. Valid status codes are: CF = Confirmation DS = Drop Ship EB = Evaluate Backorders OE = Order Entry OM = Order Maintenance PM = Purchase Order Maintenance PR = Receiving RA = Return Authorization US = Unspecified Alphanumeric, 2 positions, display-only.

Working with BILL_ASYNC Status Messages

Purpose:You can review the status of each data queue record by displaying the data queue. You must correct the error before the billing transaction can be fully processed.

BILL_ASYNC status messages: This table lists the status messages that you may see when displaying the Billing Header Data Queue

Message	Message ID	Error Reason/Action Required
Processing has begun	-----	None.
All updates complete	-----	None. The record was fully processed.
Cust Bill To Change	OA20931	A Bill To record does not exist for the customer in the Customer Bill To table. This error cannot be corrected by the user.
Cust Ship To Change	OA20937	A Ship To record does not exist for the customer in the Customer Ship To table. This error cannot be corrected by the user.
Cust Sold To Change	OA20939	A Sold To record does not exist for the customer in the Customer Sold To table. This error cannot be corrected by the user.
Division Change	OA22980	A Division record does not exist for the division under which the order was entered, and must be created. See Working with Divisions (WDIV).
OHD in Use	OA21782	The order is currently being maintained (the Order Header record is in use). The system will process the record when the Order Header record is no longer in use.
OHD# Error	OA21153	The Order Header record does not exist. This error cannot be corrected by the user.
OST# Error	OA21170	The Order Ship To record does not exist. This error cannot be corrected by the user.
PCH in Use	OA22373	The Pick Control record is in use. The system will process the record when the Pick Control record is no longer in use.
Salesman Change	OA21795	A Salesman record does not exist for the sales representative assigned to the order, and must be created. See Working with Sales Representatives (WSLS).
Ship Via Change	OA21696	A Ship Via record does not exist for the carrier being used to ship the order, and must be created. See Working with Ship Via Codes (WVIA).
Source Change	OA21695	A Division record does not exist for the division under which the order was entered, and must be created. See Working with Source Codes (WSRC).

Updates During Background Processing

Purpose: The following tables list the field and table updates during the BILL_ASYNC procedure.

• Immediate Billing Updates

• Batch Billing Updates

Immediate Billing Updates

The following billing updates occur immediately during the BILL_ASYNC procedure.

Table	Updates
CC Deposit Transaction	Creates records if the Preload Deposits (L78) system control value is selected
CC Deposit History	Creates records if the Preload Deposits (L78) system control value is selected
IL Outbound Trigger (MSILOU)	Creates a record with a File/Key type of CAS for each shipment on an order whose order type matches the ChannelAdvisor Order Type (L90). See ChannelAdvisor Integration Overview, especially Sending Shipment Confirmations to ChannelAdvisor.
Invoice Address (OEINAD)	Creates a record for the shipping and billing address for each invoice if the Capture Addresses for Invoice (J24) system control value was selected
Invoice Currency (MSINCU)	Creates/updates records if the Multi Currency by Offer (E03) system control value or Track Invoice Currency (D68) system control value is selected
Invoice Detail (OEINDT)	Creates/updates records Note:  The system bypasses the creation of an Invoice Detail record for a drop ship line when the order line status is X Closed OR the quantity shipped is equal to or greater than the quantity ordered. If this situation occurs, the system writes a message similar to the following in the Application Log: Drop ship line skipped/already billed: 555/00039520/001/00001.
Invoice Detail Charge (INIDCP)	Creates/updates records
Invoice Detail Pay Method (CSINVP)	Creates/updates records
Invoice Header (OEINHD)	Creates/updates records
Invoice Pay Method (CSINVP)	Creates/updates records
Invoice Ship To (OEINSH)	Creates/updates records
Item Location (INILOC)	Reduce quantity on-hand Reduce printed quantity
Item Transaction History	Creates/updates records
Item Warehouse (INIWRE)	Units sold, $ Sold Units returned, $ returned Reduce quantity on-hand
Item Warehouse History (INIWRH)	Units sold, $ sold Units returned, $ returned
Order Orchestration Note: The system also sends a status update with a status of Fulfilled for a delivery order, or In transit for a ship-for-pickup order. See Order Orchestration Integration for an overview.	Updates the Status to Complete. If no response is received, updates the Status to Resend Fulfilled (delivery order) or Resend Intransit (ship-for-pickup order).
Order Detail (OEORDT)	Updates status Adjusts quantities
Order Line History	Creates/updates records
Order Payment Method (OEPAYM)	Updates amounts billed and credit For a retail pickup or delivery order from the Order Orchestration, deactivates the payment method
Order Ship To (OEORST)	Updates order balance amounts
Order Shipment Details	Creates a record for a shipment if a tracking number is specified, and generates the order request message to Narvar if the Narvar Integration is enabled
Refunds (CSRFND)	Creates/updates records
Reserved Order Line (FLRSOL)	Updates/deletes records
Stored Value Card (OESVCD)	Create a record for each unit of a stored value card item billed on the order; see Billing a Stored Value Card
Tickler (MSTKLR)	Creates/updates records if the Use Workflow Management (H96) system control value is selected and billing activates a tickler rule

Batch Billing Updates

If the Delay Billing Updates (K85) system control value is selected, the system delays the following billing updates until you run the Delay Billing Update Process; otherwise, these updates also occur immediately.

Table	Updates
Carton Contents	Create carton contents records
Customer Bill To (CSCBIL)	# of invoices # of sales Sales LTD Sales YTD $ on order # of Credits
Customer Membership (OECSMP)	Create or deactivate customer loyalty memberships based on total sales dollars or customer class. See Loyalty Memberships for an overview.
Customer Ship To Entity (OECHEP)	Units and $ Sales LTD Units and $ Exchanges LTD Units and $ Returns LTD On Order $
Customer Ship To Item Class Entity (OEICEP)	Units and $ Sales LTD Units and $ Exchanges LTD Units and $ Returns LTD
Customer Ship To Order History (CSORH)	# Sales LTD, $ Sales LTD # Exchanges LTD, $ Exchanges LTD # Returns LTD, $ Returns LTD On Order $
Customer Shipment History (FLCSHP)	# of shipments, $ value Last shipment date
Customer Sold To Entity (OECSEP) Foot 1	Units and $ Sales LTD Units and $ Exchanges LTD Units and $ Returns LTD On Order $
Customer Sold To Item Class (OECSIC)	Units and $ Sales LTD Units and $ Returns LTD Units and $ Exchanges LTD
Customer Sold To Order History (CSTOOH)	# Sales LTD, $ Sales LTD, incremented for each recipient # Exchanges LTD, $ Exchanges LTD # Returns LTD, $ Returns LTD On Order $ $ Warranty Shipped $ Warranty Returned
Division (MSDIV)	# Sales Today, # Sales LTD, incremented for each recipient $ Sales Today, $ Sales LTD # Returns Today, # Returns LTD $ Returns Today, $ Returns LTD
Division History (ACDIVH)	# Sales, $ Sales # Returns, $ Returns
Exchange Reason/Offer (CSXROF)	# Exchange, $ Exchange
Exchange Reason/Offer/Item (INEROI)	# Exchange, $ Exchange
Flexible Payment Option (FLFPOP)	# of shipments, $ shipped # of returns, and $ returned
Order Control Summary (MSORSU)	# orders shipped, $ orders shipped, quantity shipped # invoices credited, $ invoices credited, quantity credited # orders exchanged, $ orders exchanged, quantity exchanged Note:  The Order Async updates the orders entered, orders canceled, and orders soldout fields in the Order Control Summary table. The batch order control job updates the operation and merchandising fields in the Order Control Summary table; see Reviewing Operations Control Summary (FLSH).
Order/Billing History (OEBHST)	Qty Sold, $ Sold Total, # Sales Qty Exchanged, $ Exchanged Total, # Exchanged Qty Returned, $ Returned Total, # Returns
Return Reason/Offer (CSRTNO)	# Returns, $ Returns
Return Reason/Offer/Item (INRROI)	# Returns, $ Returns
Salesman (MSSLMN)	# Sales LTD, $ Sales LTD, incremented for each recipient # Exchanges LTD, $ Exchanges LTD # Returns LTD, $ Returns LTD
Ship Via (MSSHPV)	# of Packages TD, # of Packages LTD Freight Collected TD, Freight Collected LTD
Ship Via History (VIAHST)	# of Packages, Freight Collected
SKU Price History (SKUPHT)	# Sales, $ Sales
Source (MSSRC)	$ Sales, # Sales, incremented for each shipment $ Exchanges, # Exchanges $ Returns, # Returns Requests mailed (if the order type on the order matches the order type in the Order Type to Process as Catalog Request/Item Samples (E08) system control value)
Tax Jurisdiction History (MSTXJH)	Amount charged Amount credited
User Define Exit Point	Execute any user defined exit points that are called during Billing

^Footnote 1 Entity-level updates take place only if the Track Customer History at Entity Level (F89) system control value is selected.

Working With the EBO ASYNC Job

Purpose: The Evaluate Backorders ASYNC function updates the system tables with reservation and backorder information whenever the inventory level for a backordered item increases. Inventory levels for an item increase when you process inventory transactions, receive purchase orders, or transfer merchandise from suspense.

When the inventory transactions program runs, it sends records to the Evaluate Backorders data queue for processing if the inventory level for a backordered item is increased.

• If the Evaluate Backorders ASYNC (EBO_ASYNC) function is active, it processes the records immediately.

• If the EBO_ASYNC is not active when it receives the records, it processes them as soon as it becomes active again.

All records are processed in the sequence in which they arrive in the data queue.

Pick slip preparation: During the Evaluate Backorders process, the system performs pick slip preparation for each order updated:

1. The system REMOVES any pick slip preparation from the order.

2. Once the Evaluate Backorders async reserves stock for an order, the system EVALUATES the order to determine if it is eligible for pick slip preparation.

3. If the order is eligible for pick slip preparation after the changes to the order have been made, the system RE-APPLIES pick slip preparation to the order.

See Preparing Orders for Pick Slip Generation for processing details.

Errors: If any errors occur in processing a data queue record, the function stops processing at the error point and starts the next record in sequence. The records in error are listed on the Evaluate Backorders ASYNC Error Report, which prints when the ASYNC jobs end. EBO_ASYNC continues processing any record in error once the error is corrected.

You can view the status of each record in the data queue at the Display Evaluate B/O Data Queue Screen.

For more information: See Troubleshooting the Async Jobs for more information on the steps you should take if you suspect the async jobs are not running correctly.

In this topic:

• Display Asynchronous Job Screen (Displaying the Evaluate Backorders ASYNC Job) 

• Display Evaluate B/O Data Queue Screen

• Evaluate B/O Background Job Error Listing

• Updates During Background Processing.

Display Asynchronous Job Screen (Displaying the Evaluate Backorders ASYNC Job)

Purpose: Use this screen to display the job attributes for each background ASYNC job. This screen displays descriptive information about the ASYNC job.

How to display this screen: Select Display for the EBO_ ASYNC job at the Work with Background Jobs Screen.

Field	Description
Process name	The name of the process for this ASYNC job. The name of the evaluate backorders data queue is EVLBODATAQ. Alphanumeric, 10 positions; display-only.
Job name	The name of the ASYNC job. Alphanumeric, 10 positions; display-only.
Description	The description of the ASYNC job. Alphanumeric, 40 positions; display-only.
Start	The date and time the ASYNC job was last started and the User ID of the person who started it. (Date): Numeric, 6 positions; display-only. (Time): Numeric, 6 positions; display-only. User ID): Alphanumeric, 10 positions; display-only.
End	The date and time the ASYNC job was last ended and the User ID of the person who ended it. (Date): Numeric, 6 positions; display-only. (Time): Numeric, 6 positions; display-only. (User ID): Alphanumeric, 10 positions; display-only.
Controlling job?	A flag indicating whether this function controls other ASYNC functions. The controlling ASYNC function starts and ends other ASYNC functions. Valid values are: Selected - This is a controlling ASYNC function. Unselected - This is not a controlling ASYNC function. The CNTL_ASYNC job is the only controlling ASYNC job.
System Option?	A flag indicating whether this function is a system function that cannot be deleted by the user. Valid values are: Selected - This function cannot be deleted by the user. Unselected - This function can be deleted by the user.
Status	The current status of the job. Valid status codes are: *ACTIVE *INACTIVE *ENDPEND *JOBQ *REORG Display-only.

Display Evaluate B/O Data Queue Screen

Purpose: This screen displays the records that have been sent to the data queue for processing since the last time the ASYNC function was ended. Records are sent to the data queue when the inventory level for an item is increased.

The status of each record indicates if the record has been processed or if any errors exist.

Note:

If the Use Inventory Sharing Backorder Evaluation (I80) system control value is selected, there is a data queue record only for the shared company (the company where you actually track the inventory). See Inventory Sharing (A69) for an overview.

How to display this screen: Select Display Data Queue for the EBO_ASYNC job on the Work with Background Jobs Screen.

Field	Description
Cmp (Company)	The number of the company for which the transaction was processed. If you are running operations for more than one company, transactions for all companies are submitted to the same data queue. Note: If the Use Inventory Sharing Backorder Evaluation (I80) system control value is selected, there is a data queue record only for the shared company (the company where you actually track the inventory). See Inventory Sharing (A69) for an overview. Numeric, 3 positions; display-only.
Date	The date when the transaction was submitted to the data queue for processing. Numeric, 6 positions (in user date format); display-only.
Time	The time at which the transaction was submitted to the data queue for processing. Note:  The number of seconds might exceed 59 if the ASYNC job processed 60 or more records in a minute. Numeric, 6 position (HH:MM:SS format); display-only.
Job #	The job number assigned to the transaction when it was submitted to the data queue. Numeric, 6 positions; display-only.
Processed	The status of the record. The record is either not processed, in process, in error, or processed. A status message displays for each step. Alphanumeric, 30 positions; display-only.
Item	The item number/SKU of the backordered item that can now be reserved. (Item#): Alphanumeric, 12 positions; display-only. (SKU): Alphanumeric, three 4-position fields; display-only.
Whs	The code of the warehouse where the backordered item can be reserved. Numeric, 3 positions; display-only.

Evaluate B/O Background Job Error Listing

Purpose: This listing prints when the background ASYNC jobs are ended. The report lists the records that could not be processed and the reason for the error. The record will be processed when the error is corrected.

• Order #: The order number for which the error occurred.

• Ship to: The ship-to suffix of the order for which the error occurred.

• Order date: The date when the order was entered.

• User: The User ID of the operator who entered the order.

• Update area: The message describing the reason for the error.

• Error ID: The ID number assigned to the error.

Updates During Background Processing

Updates: Evaluate Backorders:

• Updates backorder quantity, reserved quantity, and available quantity in item warehouse

• Creates reserved order lines

Pick slip preparation: During the Evaluate Backorders process, the system performs pick slip preparation for each order updated:

1. The system REMOVES any pick slip preparation from the order.

2. Once the Evaluate Backorders async reserves stock for an order, the system EVALUATES the order to determine if it is eligible for pick slip preparation.

3. If the order is eligible for pick slip preparation after the changes to the order have been made, the system RE-APPLIES pick slip preparation to the order.

See Preparing Orders for Pick Slip Generation for processing details.

Working With the ORDR_ASYNC Job

Purpose: The Order Processing ASYNC job updates system tables with order and demand information as orders are entered and maintained.

As you enter or maintain orders, the system sends the records to the Order Processing data queue for processing. As soon as the Order Processing Data queue receives a record to process, the record is processed immediately, regardless of the status of the Order Processing ASYNC (ORDR_ASYNC) job. The ORDR_ASYNC job processes multiple orders simultaneously.

If there are any records that the job cannot update, it skips that record and continues.

You can review the status of each record in the data queue at any point by displaying the Display Order Ship To Data Queue Screen.

Quotes: The system does not send quotes to the Order Async until the quote is converted to an order; see Entering Pre-Order Quotes for an overview.

Related system control value: The Update Demand for Order Maintenance Transactions (C72) controls how this job processes updates.

Note:

While the Order Async job does not need to be active to process records, you should set the Order Async job to active to handle reorganization and cleanup of any transactions that did not process correctly.

For more information: See Troubleshooting the Async Jobs for more information on the steps you should take if you suspect the async jobs are not running correctly.

In this topic:

• Display Asynchronous Job Screen (Displaying the Order Processing ASYNC Job)

• Display Order Ship To Data Queue Screen

• Updates During Background Processing

Display Asynchronous Job Screen (Displaying the Order Processing ASYNC Job)

Purpose:  Use this screen to display the job attributes for each background ASYNC job, including the Order Processing ASYNC job.

How to display this screen: Select Display for an ASYNC job at the Work with Background Jobs Screen.

Field	Description
Process name	The name of the process for this ASYNC job. The name of the order data queue is ORDERDATAQ. Alphanumeric, 10 positions; display-only.
Job name	The name of the ASYNC job. Alphanumeric, 10 positions; display-only.
Description	The description of the ASYNC job. Alphanumeric, 40 positions; display-only.
Start	The date and time the ASYNC job was last started and the User ID of the person who started it. (Date): Numeric, 6 positions; display-only. (Time): Numeric, 6 positions; display-only. (User ID): Alphanumeric; 10 positions; display-only.
End	The date and time the ASYNC job was last ended and the User ID of the person who ended it. (Date): Numeric, 6 positions; display-only. (Time): Numeric, 6 positions; display-only. (User ID): Alphanumeric; 10 positions; display-only.
Controlling job	A flag indicating whether this job controls other ASYNC functions. The controlling ASYNC job starts and ends other ASYNC functions. Valid values are: Selected - This is a controlling ASYNC job. Unselected - This is not a controlling ASYNC job. The CNTL_ASYNC job is the only controlling ASYNC job.
System Option	A flag indicating whether this is a system job that cannot be deleted by the user. Valid values are: Selected - This job cannot be deleted by the user. Unselected - This job can be deleted by the user.
Status	The current status of the job. Valid status codes are: *ACTIVE *INACTIVE *ENDPEND *JOBQ *REORG Display-only.

Display Order Ship To Data Queue Screen

Purpose: Use this screen to review the records that have arrived in the data queue for processing since the last time you ended the ASYNC jobs. Records arrive in the data queue for new orders that are entered and for existing orders that are maintained. The status of each record, indicating if the record has been processed or if any errors exist, displays.

How to display this screen: Select Display Data Queue for the ORDR_ASYNC job at the Work with Background Jobs Screen.

Field	Description
Cmp (Company)	The number of the company for which the transaction was processed. If you are running operations for more than one company, transactions for all companies are submitted to the same data queue. Numeric, 3 positions; display-only.
Date	The date when the transaction was submitted to the data queue for processing. Numeric, 6 positions (in user date format); display-only.
Time	The time when the transaction was submitted to the data queue for processing. Note:  The number of seconds might exceed 59 if the ASYNC job processed 60 or more records in a minute. Numeric, 6 position (HH:MM:SS format); display-only.
User	The user ID of the user associated with the order transaction. Alphanumeric, 10 positions; display-only.
B/A	A code indicating whether the record represents a before image or an after image for the transaction. After records are written for all transactions; before records are written for orders that have been maintained. Valid codes are: B = The record represents the order information before the transaction was processed. A = The record represents the order information after the transaction was processed. Alphanumeric, 1 position; display-only.
Processed	The status of the record. The record is either not processed, in process, in error, or processed. A status message displays for each step. Alphanumeric, 30 positions; display-only.
Ordr #	The order number of the record. (Order #): Numeric, 8 positions; display-only.
Ordr ship to	The order ship-to number of the record. (Ship to): Numeric, 3 positions, display-only.
Trn	A code identifying the job from which the transaction originated. Valid status codes are: CF = Confirmation DS = Drop Ship EB = Evaluate Backorders OE = Order Entry OM = Order Maintenance PM = Purchase Order Maintenance PR = Receiving RA = Return Authorization US = Unspecified Alphanumeric, 2 positions, display-only.

Updates During Background Processing

Purpose: The ORDR_ASYNC job updates system tables with order and demand information as orders are entered and maintained. As you enter or maintain orders, the system sends the records to the Order Processing data queue for processing. As soon as the Order Processing Data queue receives a record to process, the record is processed immediately, regardless of the status of the Order Processing ASYNC (ORDR_ASYNC) job. The ORDR_ASYNC job processes multiple orders simultaneously. While the Order Async job does not need to be active to process records, you should set the Order Async job to active to handle reorganization and cleanup of any transactions that did not process correctly.

Related system control value: The Update Demand for Order Maintenance Transactions (C72) system control value controls whether totals update as a result of order maintenance as well as order entry.

Order count and demand updates for retail pickup and delivery orders: If the originating location on a retail pickup or delivery order is Order Administration, the system does not increase the order count that is displayed on the About Application Screen or perform any demand updates for the order. 

Note:

The system identifies the originating location as Order Administration if the request_system_cd in the fulfillment response message matches the system code in the OROB System (K50) system control value and the request_location_cd in the fulfillment response message matches the location in the Originating Location to Pass to OROB (M32) system control value. In this situation, the system prefaces the E-commerce order number in the Order Header Extended table with ORIG#: 9999-001, where ORIG#: indicates the order was created as a result of OROB fulfillment assignment, 9999 is the order number, and 001 is the ship to number. See Retail Pickup (including Ship-for-Pickup) or Delivery Orders for more information.

Table	Updates
Cancel Reason/Offer (CNCNRO)	Date # canceled qty canceled units canceled Creates a record only if the cancel reason code is flagged not to reduce demand.
CC Authorization Backorder (CCATBO)	Create a record for authorization of a fully backordered order if the Preauthorize Backorders (D32) system control value is selected.
Correspondence History (MSCOHS)	Creates a record for each order confirmation email Outbound Email XML Message (CWEmailOut) generated if the Write Outbound Email to Email Repository (H99) system control value is selected. See the Suppress Order Confirmations for Orders in Error (K09) system control value for a discussion of when the ORDR_ASYNC background job generates order confirmations. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1)
Customer Membership (OECSMP)	Create or deactivate customer loyalty memberships based on total order dollars or customer class. See Loyalty Memberships for an overview.
Customer Sold To (OECSSL)	Original and current mail type Original source Current source (if Update of Current Source Code in Customer File (D08) system control value is selected)
Customer Sold To Entity (OECSEP)	Last order date On order $ # orders LTD, $ orders LTD # cancels LTD, $ cancels LTD # soldouts LTD, $ soldouts LTD Last source Current mail type Original mail type Active since date Original source code Last source code Updated if the Track Customer History at Entity Level (F89) system control value is selected.
Customer Sold to Item Class (OECSIC)	# orders LTD, $ ordered LTD # units ordered LTD # units canceled LTD, $ canceled LTD # units soldout LTD, $ soldout LTD Last order date
Customer Sold To Item Class Entity (OEICEP)	Creates records and updates: # orders (not units) # orders LTD, $ orders LTD # cancels LTD, $ cancels LTD # soldouts LTD, $ soldouts LTD Last order date
Customer Sold To Order History (CSTOOH)	On order $ # orders LTD, $ orders LTD # soldouts LTD, $ soldouts LTD # canceled LTD, $ canceled LTD Last CC# Last expiration date Active since date Last order date Last order type Pay type Current source code Last order amount
Flash Report (FLFLSH)	See Reviewing Operations Control Summary (FLSH) for information on order totals tracked.
Item/Sku/Offer (FCISOF)	Start and end dates Quantity ordered, $ ordered
Offer (MSOFFR)	Date of first order
Order Control Summary (MSORSU)	# orders entered, $ orders entered, quantity ordered # orders cancelled, $ orders cancelled, quantity cancelled # orders soldout/closed, $ orders soldout, quantity soldout Note:  The Billing Async updates the orders shipped, orders exchanged, and invoices credited fields. The batch order control job updates the operation and merchandising fields in the Order Control Summary table; see Reviewing Operations Control Summary (FLSH).
Order Type/ User (OEOTYU)	# Orders TD, LTD $ Value - TD, LTD # Receipts TD, LTD # Lines TD, LTD
Order/Billing History (OEBHST)	# orders, $ order total, qty ordered # soldout, $ soldout total, qty soldout # canceled, $ canceled, qty canceled
Price override reason (OEPROR)	# of overrides Total discount
SKU (INSKU)	Date of first order Date of last order
SKU Price History (SKUPHT)	# orders (actually updated with the total ordered quantity) $ orders
Soldout Notifications (SONTFY)	Creates records
Source Code (MSSRC)	$ ordered, soldout, canceled # of orders, soldouts, cancels Date of first order Date of last order Response percent
Tickler	Records created based on related configuration. See Workflow Management Overview and Setup for background.

Note:

• Entity-level updates take place only if the Track Customer History at Entity Level (F89)system control value is selected.

• Order maintenance activity updates demand only if the Update Demand for Order Maintenance Transactions (C72) system control value is selected.

Working With the OTHR_ASYNC Job

The Other ASYNC function updates the system tables with purchase order information when purchase orders are entered, maintained, or received.

When purchase orders are entered, maintained, or received, records are sent to the Other data queue for processing. If the Other ASYNC (OTHR_ASYNC) function is active, the records will be processed immediately. If the function is not active when the records are sent, they will be processed as soon as the OTHR_ASYNC function becomes active again. All records are processed in the sequence in which they were sent to the data queue.

If any errors exist, processing for that record stops at the error point. The system begins processing the next record in sequence. The records in error are listed on the P/O Background Job Error Listing, which is printed when the ASYNC jobs are ended. OTHR_ASYNC will continue processing the record when the error has been corrected. You should correct any errors that exist as soon as possible so that your system tables are updated properly. See Working with OTHR_ASYNC Status Messages.

The status of each record in the data queue can be viewed at any point by displaying the Display PO Header Data Queue Screen.

For more information: See Troubleshooting the Async Jobs for more information on the steps you should take if you suspect the async jobs are not running correctly.

In this topic:

• Display Asynchronous Job Screen (Displaying the Other ASYNC Job)

• Display PO Header Data Queue Screen

• Working with OTHR_ASYNC Status Messages

• P/O Background Job Error Listing

• Updates During Background Processing.

Display Asynchronous Job Screen (Displaying the Other ASYNC Job)

Purpose: Use this screen to display the job attributes for each background ASYNC job, including the OTHR_ASYNC job. This screen displays descriptive information about the ASYNC job.

How to display this screen: Select Display for the OTHR_ASYNC job at the Work with Background Jobs Screen

Field	Description
Process name	The name of the process for this ASYNC job. The name of the OTHR_ASYNC data queue is OTHERDATAQ. Alphanumeric, 10 positions; display-only
Job name	The name of the ASYNC job. Alphanumeric, 10 positions; display-only
Description	The description of the ASYNC job. Alphanumeric, 40 positions; display-only.
Start	The date and time the ASYNC job was last started and the User ID of the person who started it. (Date): Numeric, 6 positions; display-only. (Time): Numeric, 6 positions; display-only. (User ID): Alphanumeric; 10 positions; display-only.
End	The date and time the ASYNC job was last ended and the User ID of the person who ended it. (Date): Numeric, 6 positions; display-only. (Time): Numeric, 6 positions; display-only. (User ID): Alphanumeric, 10 positions; display-only.
Controlling job?	A flag indicating whether this function controls other ASYNC functions. The controlling ASYNC function starts and ends other ASYNC functions. Valid values are: Selected = This is a controlling ASYNC function. Unselected = This is not a controlling ASYNC function. The CNTL_ASYNC job is the only controlling ASYNC job.
System Option?	A flag indicating whether this function is a system function that cannot be deleted by the user. Valid values are: Selected - This function cannot be deleted by the user. Unselected - This function can be deleted by the user.
Status	The current status of the function. Valid status codes are: *ACTIVE *INACTIVE *ENDPEND *JOBQ *REORG Display-only

Display PO Header Data Queue Screen

Purpose: This screen displays the records that have been sent to the data queue for processing since the last time the ASYNC function was ended. Records are sent to the data queue when the inventory level for an item is increased.

The status of each record, which indicates if the record has been processed or if any errors exist, displays.

How to display this screen: Select Display Data Queue for the OTHR_ASYNC job on the Display Asynchronous Job Screen (Displaying the Other ASYNC Job)

Field	Description
Cmp (Company)	The number of the company for which the transaction was processed. If you are running operations for more than one company, transactions for all companies are submitted to the same data queue. Numeric, 3 positions; display-only.
Date	The date on which the transaction was submitted to the data queue for processing. Numeric, 6 positions (in user date format); display-only.
Time	The time at which the transaction was submitted to the data queue for processing. Note:  The number of seconds might exceed 59 if the ASYNC job processed 60 or more records in a minute. Numeric, 6 position (HH:MM:SS format); display-only.
User	The User ID of the person who entered the transaction. Alphanumeric, 10 positions; display-only.
B/A	A code indicating whether the record represents a before image or an after image for the transaction. After records are written for all transactions; before records are written for order maintenance transactions. Valid codes are: Before = The record represents the order information before the transaction was processed. After = The record represents the order information after the transaction was processed. Alphanumeric, 1 position; display-only.
Processed	The status of the record. The record is either not processed, in process, in error, or processed. A status message displays for each step. Alphanumeric, 30 positions; display-only.
PO#	The number of the purchase order for which the record is being processed. Numeric, 7 positions; display-only.
Trans	A code that identifies the function where the transaction originated. Valid status codes are: CF = Confirmation DS = Drop Ship EB = Evaluate Backorders OE = Order Entry OM = Order Maintenance PM = Purchase Order Maintenance PR = Receiving RA = Return Authorization US = Unspecified Alphanumeric, 2 positions, display-only.

Working with OTHR_ASYNC Status Messages

Purpose: The status of each data queue record can be viewed by displaying the data queue. If an error exists, the message will print on the P/O Background Jobs Error Listing that is printed when the ASYNC jobs are ended. The error must be corrected before the transaction can be fully processed.

OTHR_ASYNC status messages: This table lists the status messages that you may see when displaying the PO Header Data Queue, or when reviewing the P/O Background Job Error Listing. The Error Reason/Action Required section of the table below is incomplete as of this writing.

Message	Message ID	Error Reason/Action Required
Processing has begun		None.
All updates complete		None. The record was fully processed.
Error updating buyers	OA21759
Error updating Item/Warehouse	OA21760
Error updating PO Dtl audit	OA21915
Error updating PO Hdr audit	OA21916
Error creating PO layering	OA21897
Error changing PO layering	OA21920
Error creating PO layering	OA21918
Error deleting PO layering	OA21919
Error updating SKU Offer	OA21758
Error updating threshold value	OA22968
Error updating vendor	OA21732
Error updating vendor history	OA21733
Error updating vendor items	OA21766

P/O Background Job Error Listing

Purpose: This report prints when the background ASYNC jobs are ended. The report lists the records that could not be processed and the reason for the error. The record will be processed when the error is corrected.

See Working with OTHR_ASYNC Status Messages for a complete description of the error messages you may encounter and the steps necessary to correct the error.

  Order #: The order number for which the error occurred.

• Ship to: The ship-to suffix of the order for which the error occurred.

• Order date: The date on which the order was entered.

• User: The User ID of the operator who entered the order.

• Update area: The message describing the reason for the error. See Working with OTHR_ASYNC Status Messages.

• Error ID: The ID number assigned to the error. See Working with OTHR_ASYNC Status Messages.

Updates During Background Processing

Purpose: The system performs the following field and table updates during the OTHR_ASYNC procedure:

Function	Field
Update the SKU/Offer table
---	SKU CWI work field SKU on order for PO Threshold values include: Number and dollar value for Held POs Number and dollar value for Units of Suspense Inventory Number and dollar value for PO Receipts in Suspense
Update the Item/Warehouse table
---	On order quantity
Update PO Layering table
PO Maintenance + PO Receipts	Creates the record Open quantity
PO Receipts	Status Note:  If you receive inventory into a pending putaway warehouse, the system keeps the PO layering record in an open status until the inventory is moved out of the pending putaway warehouse. See Pending Putaway Overview.
---	Warehouse
---	Due date
Update the Vendor/Item table
PO Receipts	Shipments - LTD
---	Elapsed days - LTD
---	Late days - LTD
---	Number of late shipments
---	Defects - LTD
---	Underships
---	Overships
---	Units received - LTD
PO Maintenance	Dollar value purchased - LTD
---	Units purchased - LTD
Update Vendor table
---	Dollar value cancelled
---	Dollar value held
---	Dollar value open
---	Number of POs - LTD
---	Number of open POs
Update Vendor History table
---	Dollar value purchase orders
---	Number of purchase orders
Update the Buyer table
---	Dollar value POs - LTD
---	Number of purchase orders - LTD
Update Vendor Extended table
---	Dollar value on order
Update IL Outbound Trigger Table
PO Maintenance	Creates ITW outbound trigger records when you create a purchase order or maintain an open purchase if the Include PO Updates (J93) system control value is selected. See Generic Inventory Download API for an overview and details. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1)

Running Period End Processing

Topics in this part:

• Working with Periodic Functions (WPER) describes working with the functions you can include in your periodic processing.

• Working with Periodic Processes (WPPR) describes how to create, change, delete or display a periodic process.

• Executing Periodic Processes (EPRO) describes how to set up and execute a periodic process.

• Working with Periodic Process History (WPHS) presents the screens you use to review periodic process history.

• Purge Periodic Process History (MPPR) describes how to purge periodic process history in a completed status for all Order Administration companies prior to a specified date.

• Printing the Tax Jurisdiction Report (PTXJ) describes how to run this report and presents a sample.

• Releasing Orders from Time Hold describes the RLSTIME periodic function.

• Working with the Marketing Download Extract describes how to download order, customer, source code, and vendor information from Order Administration to the DMT system.

• Using the Financial Data Interface describes how to extract information to the Financial Sales Download table.

Releasing Orders from Time Hold

Purpose: Use the Release Orders on Time Hold (RSLTME) function to release prepaid orders from hold automatically when the number of days to hold the order (in the Hold days field in the Pay Type table) has passed, and to release orders held for credit card authorization.

Prepaid orders: When this job runs, the system checks all open prepaid orders (pay category Cash/Check) to see if the hold days have expired. The system holds prepaid orders automatically for a certain number of days to ensure that the checks clear (you define the hold days in the Pay Type table). The system places these orders on TM hold (Time Hold), which is a system-level hold. Once the checks have cleared, these orders are eligible for pick slip preparation, unless they are on hold for some other reason. By running this program, you have the system release the eligible orders automatically, so you do not have to release them one-by-one.

See Working with Pay Types (WPAY) for information on setting up the Pay Type table.

Credit card orders: This job also evaluates orders placed on hold because of a declined credit card.  You can specify a number of days to hold an order based on the response you receive from an authorization service; for example, if a credit card is declined because the customer is over a credit limit, it is unlikely that the customer's credit situation will change significantly in a single day. In this situation, you might set up this vendor response to hold such orders for five days before making these orders eligible for pick slip preparation and attempting authorization again.   

Orders that are on hold because of a declined credit card have an order hold reason of AT (failed authorization). See Working with Credit Card Cancellations (WCCC) for a discussion on managing declined authorizations using Order Administration.

Pick slip preparation: When you release an order from hold, the system removes any pick slip preparation that has been applied to the order and then reevaluates the order for pick slip preparation; see Preparing Orders for Pick Slip Generation.

In this topic:

• Orders Released from Time Hold Report

Define as periodic function: You must define RSLTME as a periodic function with Working with Periodic Functions (WPER).

Sample setup: Enter the following at the Create Periodic Function Screen:

• Function: RLSTIME

• Description: Release Orders on Time Hold

• Company parameter: Y

• Appl area: C/S

• Program name: CSR0557

Add to DAILY periodic process: Next, at the Work with Periodic Functions Screen, select Functions to add this periodic function to your daily periodic process.

Released orders report: The system prints the Orders Released from Time Hold Report automatically when you execute the Daily Periodic Process, which includes the Release Orders from Time Hold job. If the order is still on user hold, the system displays the user hold reason on the report.

Order history for release: The system logs messages to the Order History table automatically for orders placed on and released from time hold. Select Order History in standard Order Inquiry to advance to the Display Order History screen. This information is also available in streamlined Order Inquiry by selecting History.

History messages: Two messages are logged for orders placed on Time Hold (TM type hold) or credit card hold (AT).  The first message is logged automatically when the system places the order on hold.

The second message is logged automatically when the system releases the order after the hold days expire.  This message contains:

• the date the order was released from TM or AT hold (although it may remain on hold for other reasons)

• the type of transaction, which is R for "release"

• a transaction note, which identifies the type of activity performed

• the dollar amount of the order

• the user ID of the person who started the periodic process

Using the System Utilities

Topics in this part: The following topics describe the utilities available in the system that are typically used only by the System Administrator.

• Working with Default Options (WDFT) describes how to work with predefined field or program defaults.

• Consolidating Order Billing History (MOBH) describes how to consolidate order billing history.

• Working with Inventory Resets describes the options available to reset inventory levels when they become out of synch.

• Reset Allocation Quantities (MRPC) describes how to reset the printed quantities for orders.

• Reset Reserve Quantity (MRQR) describes how to reset the reserved quantity of items in inventory.

• Reset Back Order Quantity (MRBO) describes how to reset the backorder quantity of items in inventory.

• Reset Item Warehouse Quantity On Hand (MRIW) describes how to reset the quantity on-hand for each Item Warehouse record based on the total quantities on-hand.

• Reset SKU Open Order Quantity (MRSO) describes how to  reset the fields in the SKU table based on the current open orders for the SKU.

• Unlocking a Stranded Order or Batch (MULO) describes how to unlock an order or batch that became locked during processing or maintenance.

• Resetting the Order Billing History Table (ROBH) describes how to reset the Order Billing History table based on the records in the Order Detail table.

• Resetting Customer Sold To Amount On Order (RONO) describes how to reset the On order amount field in the Customer Sold To Order History file so that it matches the amount of any existing open orders for the customer.

• Unlock Purchase Order (MUPO) describes how to reset locked purchase orders and reset the on-order quantities for Item Warehouse records.

• Work with File Uploads (WUPL) describes how to upload a file to a specified table in the Order Administration database.

Working with Inventory Resets

Purpose: Use the following inventory options to reset quantities when inventory levels become out-of-sync due to system problems:

• Reset Allocation Quantities (MRPC)

• Reset Reserve Quantity (MRQR)

• Reset Back Order Quantity (MRBO)

• Reset Item Warehouse Quantity On Hand (MRIW)

• Reset SKU Open Order Quantity (MRSO)

Note:

Do not run these resets when the Billing Async is active, or when you are running pick slip generation or performing inventory transaction processing. Also, do not run the Reserve Quantity Reset or Backorder Quantity Reset while creating or updating orders.

Working with File Imports

Purpose: Your options for uploading file data to Order Administration are:

• File storage API: Use the file storage API to import files for most types of imports, as well as deleting files that are no longer needed. See the Available File Uploads for details.

• The file storage API stages uploaded file data in the FILE_STORAGE database table. Upload processes point to the FILE_STORAGE table when retrieving data to update target database tables. See File Storage API.

• The file storage API also supports exporting files. See File Storage API.

• Work with File Uploads (WUPL): You can use this menu option to upload files. When you upload a file through this menu option, if the file contents need to first be placed in a staging database table before processing, the upload process populates the staging table with the file data.

Regardless of how the upload file contents are retrieved or staged, you then need to update the destination table in the Order Administration database with the uploaded data. The file layouts, edits, and periodic processes are the same, regardless of the method you use to upload the data.

In this topic:

• File Upload Setup

• File Upload Process

• Populating the Upload File

• Processing File Uploads through Work with File Uploads (WUPL)

• Available File Uploads

• Purging Upload History

• Sample Upload Data

File Upload Setup

Before you can use the file upload process, you must complete the required setup.

• File Upload Properties

• Available File Uploads

File Upload Properties

Order Administration uses the following properties to process a file upload.

Property Name	Description
FILE_STORAGE_MAX_SIZE Located in Working with Customer Properties (PROP).	The maximum size, in bytes, of a file that can be uploaded to the FILE_STORAGE table. If a file’s size exceeds this maximum, the API returns a 403 error and the upload fails. Uploaded files should be less than 1G in size, so this property should be set to 1073741824 or less.
CWDIRECTCP_UPLOAD_ BATCH_SIZE Located in Working with Admin Properties (CPRP).	Defines the number of records to process in an upload file at a time. The default setting is 2500, indicating the system inserts records from the upload file into the Order Administration database in batches of 2500. If a record in a batch contains an error, the system does not insert any of the records in the batch into the Order Administration database and places the upload file in an error status. For troubleshooting purposes, you can decrease the UPLOAD_BATCH_SIZE and reprocess the file upload to help you determine which record contains the error. Example:  In this example, the CWDIRECTCP_UPLOAD_BATCH_SIZE is 10. You process an upload file containing 30 records. In this situation, the system processes the upload file in 3 batches: the first batch contains records 1-10; the second batch contains records 11-20; and the third batch contains records 21-30. If a record in the second batch fails, the system does not process any of the records in the second batch, but does process all of the records in the first batch and third batch.
CWDIRECTCP_ USPS_UPLOAD_ FILE Located in Working with Customer Properties (PROP).	Defines the location of the USPS Zip Codes upload file.
STORE_FILE_PATH Located in Working with Customer Properties (PROP).	Defines the path used for the Stores upload file. Note: This property is defined by Oracle and cannot be changed.

File Upload Process

The file upload process includes the following steps:

• Populating the Upload File

• Using the File Storage API or Processing File Uploads through Work with File Uploads (WUPL)

• Processing staged data: Some uploads, such as Catalog Requests, initially populate an intermediate table in the database. For these uploads, you need to run an additional process to use the contents of the intermediate table to populate the destination table. Uploads that require the use of a staging table are described under Available File Uploads.

Populating the Upload File

The file upload requires you to identify the file containing the data to upload to the Order Administration database. You can create an upload file by:

• creating your own text file, using a text editor or spreadsheet application, or

• copying the sample file upload data, pasting the data into a text editor, and saving it with the file extension .txt, unless otherwise indicated. See Sample Upload Data.

Important:

In order to leave any field in an upload file blank, pass a space in an alphanumeric field and a 0 in a numeric field so that the file can be processed without errors. Leaving a field with no space or 0 is interpreted as null in the database and causes errors.

Processing File Uploads through Work with File Uploads (WUPL)

Run or schedule a file upload periodic function (see Available File Uploads) or use the Work with File Upload Screen to upload a file to a specified table in the Order Administration database.

Completing the Work with File Upload Screen

1. Use the File Name field to select the file to upload.

2. Use the File Type field to specify the type of upload to perform.

3. Select Submit File Upload.

File Upload Process

The system:

• Clears all records from the target table in the Order Administration database. Note: The system performs this step for each file type except Retail Integration Items.

• Moves the upload file to the directory defined in the CWDIRECTCP_UPLOAD_DIRECTORY property (CPRP); however, the USPS Zip Code Upload uses the CWDIRECTCP_ USPS_UPLOAD_ FILE directory, and the Sales Rep Upload uses the ASSOCIATE_FILE_PATH (CPRP).

  Note:

  When you use Work with File Upload (WUPL), the upload file remains in this folder until you run the periodic function to populate the destination table, as described in the next step.

• Uses a bulk insert to load the records in the upload file into the specified table in the Order Administration database. The CWDIRECTCP_UPLOAD_BATCH_SIZE property defines the batch size used to process the records in the upload file. For example, if this setting is set to 2500, the system inserts records from the upload file into the Order Administration database in batches of 2500.

  The Work with File Upload Screen displays the upload history record in the lower portion of the screen.

  A Completed Status indicates all records in the file were processed successfully.

• An Error status indicates a record in the upload batch failed to upload to the database successfully. In this situation, the system does not insert any record in the batch into the Order Administration database. The system places the file upload in an Error status and a description of the first error encountered is assigned to the upload history record so that you can correct the error. Select View Error to display a description of the error that occurred during processing. The error description provides the upload batch number that failed to process.

Important:

If you run the file upload process and an upload file does not exist to process, or if an error occurs during processing, the system will still clear the records in the associated Order Administration upload table. You must correct any errors and run the file upload process again the populate the associated Order Administration upload table.

Processing example: To import Catalog Requests through the file storage API:

1. Create or obtain the Catalog Request file named IXCRIN.txt. See the Sample Catalog Requests Upload Data for sample contents.

2. Use the Work with File Upload Screen to upload the IXCRIN.txt file.

3. This clears populates the Catalog Request Interface table (IXCRIN). Also, the system creates a file upload record, viewable at the Work with File Upload Screen.

4. Use the Work with Catalog Request Interface (WCRU) menu option to process the records in the Catalog Request Interface table; see Working with the Catalog Request Interface (WCRU).

Troubleshooting the File Upload

Logging: During the file upload process, the system writes messages to the Trace log if its logging level is set to Debug or lower.

Example of log entries for successful file upload: 

11:39:18,270 DEBUG TRACE - Upload started for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:39:18,293 DEBUG TRACE - Upload completed for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:39:18,293 DEBUG TRACE - Upload file processing started for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:39:18,316 DEBUG TRACE - Upload file is RIItemUpload50Records.txt
11:39:18,434 DEBUG TRACE - Upload file processing ended for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:39:48,814 DEBUG TRACE - Upload started for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:39:48,826 DEBUG TRACE - Upload completed for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:39:48,826 DEBUG TRACE - Upload file processing started for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:39:48,840 DEBUG TRACE - Upload file is RIItemUpload50Records.txt
11:39:48,853 DEBUG TRACE - Upload path and file is /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:39:48,865 DEBUG TRACE - 10 RIItemUpload50Records.txt upload records have been processed so far.
11:39:48,897 DEBUG TRACE - 20 RIItemUpload50Records.txt upload records have been processed so far.
11:39:48,905 DEBUG TRACE - 30 RIItemUpload50Records.txt upload records have been processed so far.
11:39:48,912 DEBUG TRACE - 40 RIItemUpload50Records.txt upload records have been processed so far.
11:39:48,916 DEBUG TRACE - 49 RIItemUpload50Records.txt total upload records were processed.
11:39:48,923 DEBUG TRACE - Upload file processing ended for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt

Example of log entries for failed file upload: If an error occurs during processing, the log indicates which batch did not process successfully. Notice in this example, the third batch of records did not process.

11:41:17,811 DEBUG TRACE - Upload started for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:41:17,820 DEBUG TRACE - Upload completed for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:41:17,820 DEBUG TRACE - Upload file processing started for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:41:17,833 DEBUG TRACE - Upload file is RIItemUpload50Records.txt
11:41:17,861 DEBUG TRACE - Upload file processing ended for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:41:44,814 DEBUG TRACE - Upload started for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:41:44,824 DEBUG TRACE - Upload completed for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:41:44,824 DEBUG TRACE - Upload file processing started for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:41:44,837 DEBUG TRACE - Upload file is RIItemUpload50Records.txt
11:41:44,847 DEBUG TRACE - Upload path and file is /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt
11:41:44,863 DEBUG TRACE - 10 RIItemUpload50Records.txt upload records have been processed so far.
11:41:44,871 DEBUG TRACE - 20 RIItemUpload50Records.txt upload records have been processed so far.
11:41:44,957 DEBUG TRACE - 49 RIItemUpload50Records.txt total upload records were processed.
11:41:44,977 DEBUG TRACE - Upload file processing ended for /domain/OMSFiles/File/Uploads/RIItemUpload50Records.txt

Error processing: If any record in an upload batch is in error, the system does not insert any record in the batch into the Order Administration database. The system places the upload batch in an error status and a description of the first error encountered is assigned to the associated upload history record so that you can correct the error. You can select View Error to display a description of the error that occurred during processing.

If you are unable to determine which record in the upload batch is in error, you can decrease the batch size defined for the CWDIRECTCP_UPLOAD_BATCH_SIZE setting in the CWDirectCP Properties file and reprocess the records in the batch to narrow down the record that is in error. For example, if you normally process a batch size of 2500 records, for troubleshooting purposes, you can temporarily change the batch size to 10 and reprocess. The system will process the records in the upload file in batches of 10 records and fail the upload batch that contains the error. In this example, only 10 records will exist in the batch to help you determine where the error occurred.

Note:

The system places the upload batch in an error status for the first error encountered. When you reprocess the upload file after correcting the error, the file may be placed in an error status again if another error is found during processing.

Error related to large batch size: An upload file is placed in an error status with the error message Stopped waiting for file to upload when a large file does not transfer from a user’s local machine to the Order Administration application server within 20 minutes. To correct this issue, upload the file in smaller sections to accommodate the slow upload speed or get a faster internet connection.

Other possible errors: A file upload might also fail because:

• There is a blank line at the end of the file.

• The file is not UTF-8 encoded.

Available File Uploads

Upload steps: You can upload records to the following tables in the Order Administration database. Use the processing steps listed below to upload the data in a text file and then process the file data to populate the target table.

Using file storage API: The steps listed below under To Process for each upload assume that you have used the putFile web service method to upload the file. The file content is staged in the OMS-IMPORT container of the FILE_STORAGE table. See File Storage API for background. You will need to then run the periodic functions listed below for each upload in order to use the record in the FILE_STORAGE table to update to the target table.

Example: After you upload the PO Layering file record to the FILE_STORAGE table, run the UPPOLAY Upload PO Layering File (Program name PFR0134, Parameter POLAYR) periodic function to upload a PO Layering file named POLAYR.txt to the PO Layering table (POLAYR).

Staging table? Some of the uploads listed below initially update a staging table, and require an additional step to use the staged data to update the target table. Others can update the target table directly from the contents of the uploaded file without the use of a staging table.

Periodic processes: Some of file uploads listed below require the use of two periodic functions for processing. For example, to run the Customer Price Group Exclusions upload, you need to first run the CPGIXUP periodic function, and then the CPGIXUP periodic function. You can set up a periodic process to run these two functions.

File Upload screen: Regardless of whether the file storage API is enabled for imports, you can accomplish file uploads from the Work with File Upload Screen for each of the uploads listed below, with the exception of the batch inventory overlay import. In most cases, the upload from this screen also executes the required periodic function to process the uploaded data.

See File Upload Process for instructions on using the File Storage process or the upload from the CWDIRECTCP_UPLOAD_ DIRECTORY.

File Type	Order Administration Upload Table	To Process	Sample Upload Data
ACS Tape	ACS Tape table (CSACST)	After using the putFile method to upload the file (File Storage API), run the UPACSTP Upload ACS Tape File (Program name PFR0134, Parameter CSACST) periodic function to upload an ACS Tape file named CSACST to the ACS Tape table (CSACST). Note:  This step is not necessary if you use the Work with File Upload Screen to upload the ACS Tape file. Update target table: After populating the ACS Tape table, you must use the Process Address Changes (PACS) menu option, selecting an Input File Type of ACS, to process the records in the ACS Tape table; see Loading Address Updates.	Sample ACS Tape Upload Data
Batch Inventory Overlay Upload	N/A: updates the Item Location table directly	After using the putFile method to upload the file (File Storage API), run the INVOVRL periodic function. Processing File Uploads through Work with File Uploads (WUPL) is not supported for the batch inventory overlay upload.	See Batch Inventory Overlay Upload For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
Catalog Requests	Catalog Request Interface table (IXCRIN)	After using the putFile method to upload the file (File Storage API) or placing the file in the CWDIRECTCP_UPLOAD_ DIRECTORY, run the UPCATRQ Upload Catalog Request File (Program name PFR0134, Parameter IXCRIN) periodic function to upload a Catalog Request file named IXCRIN to the Catalog Request Interface table (IXCRIN). Note:  This step is not necessary if you use the Work with File Upload Screen to upload the Catalog Request file. Update target table: After populating the Catalog Request Interface table, you must use the Work with Catalog Request Interface (WCRU) menu option to process the records in the Catalog Request Interface table; see Working with the Catalog Request Interface (WCRU).	Sample Catalog Requests Upload Data
Cust Price Group Exclusions	Customer Price Group SKU Exclusion Upload Table (CUSTPGEUP)	After using the putFile method to upload the file (File Storage API) or placing the file in the CWDIRECTCP_UPLOAD_ DIRECTORY, run the UPCSTPG Upload Customer Price Group Exclusion File (Program name PFR0134, Parameter CUSTPGEUP) periodic function to upload a Customer Price Group Exclusion file named CUSTPGEUP to the Customer Price Group SKU Exclusion Upload table (CUSTPGEUP). Note:  This step is not necessary if you use the Work with File Upload Screen to upload the Customer Price Group Exclusion file. Update target table: After populating the Customer Price Group SKU Exclusion Upload table, use the CPGIXUP Customer Price Group SKU Exclusion Upload periodic function (Program name PFRCPGEXUP) to process the records in the upload table; see Customer Price Group SKU Exclusion Upload.	Sample Customer Price Group Exclusions Upload Data
MBS Tape	MBS Tape table (CSMBST)	After using the putFile method to upload the file (File Storage API) or placing the file in the CWDIRECTCP_UPLOAD_ DIRECTORY, run the UPMBSTP Upload MBS Tape file (Program name PFR0134, Parameter CSMBST) periodic function to upload an MBS Tape file named CSMBST to the MBS Tape table (CSMBST). Note:  This step is not necessary if you use the Work with File Upload Screen to upload the MBS Tape file. Update target table: After populating the MBS Tape file table, use the Process Address Changes (PACS) menu option to process the records in the MBS Tape table; see Loading Address Updates.	Sample MBS Tape Upload Data
PO Layering	PO Layering Table (POLAYR)	After using the putFile method to upload the file (File Storage API) or placing the file in the CWDIRECTCP_UPLOAD_ DIRECTORY, run the UPPOLAY Upload PO Layering File (Program name PFR0134, Parameter POLAYR) periodic function to upload a PO Layering file named POLAYR.txt to the PO Layering table (POLAYR). Once the records are uploaded to the PO Layering table, the process uses the newly uploaded records to update the due date and backorder quantity for order lines on backorder. Note:  When you run purchase order layering, the system clears the PO Layering table and rebuilds it based on the purchase order records that are uploaded to the table. In order to ensure accurate updates, you must upload the PO Layering table with ALL open purchase orders every time you perform an upload. Note:  This step is not necessary if you use the Work with File Upload Screen to upload the PO Layering file. See Purchase Order Layering.	Sample PO Layering Upload Data
Price Codes	Price Code Upload Table (PriceCdUpload)	After using the putFile method to upload the file (File Storage API) or placing the file in the CWDIRECTCP_UPLOAD_ DIRECTORY, run the UPPRCCD Upload Price Code File (Program name PFR0134, Parameter PRICECDUPLOAD) periodic function to upload a Price Code file named PRICECDUPLOAD to the Price Code Upload Table (PriceCdUpload). Note:  This step is not necessary if you use the Work with File Upload Screen to upload the Price Code upload file. Update target table: You must run the PCUPLD Price Code Upload periodic function (Program name PFPRCCODUP) to process the records in the Price Code Upload table; see Price Code Upload.	Sample Price Codes Upload Data
Promotions	Promotion Upload Table (PRMUPLD)	After using the putFile method to upload the file (File Storage API) or placing the file in the CWDIRECTCP_UPLOAD_ DIRECTORY, run the UPPROMO Upload Promotion Code File (Program name PFR0134, Parameter PRMUPLD) periodic function to upload a Promotion file named PRMUPLD to the Promotion Upload Table (PRMUPLD). Note:  This step is not necessary if you use the Work with File Upload Screen to upload the Promotion upload file. Update target table: You must run the PRMOUPL Create or Delete Promotions periodic function (Program name PRMOUPL) or use the Work with Promotion Values (WPRO) menu option to process the records in the Promotion Upload table; see Promotion Upload.	Sample Promotions Upload Data
Retail Integration Items	RI Item Upload Table (RIIUPP) Note:  You cannot use the UPRITEM Upload Retail Item File (Program name PFR0134, Parameter RIIUPP) periodic function or the Work with File Upload Screen to process imports from RMFCS, although completed RMFCS imports are listed at the Work with File Upload screen.	After using the putFile method to upload the file (File Storage API) or placing the file in the CWDIRECTCP_UPLOAD_ DIRECTORY, run the UPRITEM Upload Retail Item File (Program name PFR0134, Parameter RIIUPP) periodic function to upload a Retail Integration Item file named RIIUPP to the RI Item Upload Table (RIIUPP). Note:  This step is not necessary if you use the Work with File Upload Screen to upload the Retail Integration Item file. Update target table: After uploading the file, run the RIUPLD Retail Integration Item Upload periodic function (Program name PFR0084) or use the Work with Retail Integration Item Upload (RIIU) menu option to process the records in the RI Item Upload table; see Working with Retail Integration Item Upload (RIIU).	Sample Retail Integration Items Upload Data
Sales Associates	Salesman Associate File	After using the putFile method to upload the file, run the SLSUPLD (Program name PFR0109) periodic function to update the target table; see Salesman Associate Upload. This step is not necessary if you use the Work with File Upload Screen to upload the Salesman Associate file to the ASSOCIATE_FILE_PATH (CPRP). File name: The name of the file must start with SR and have a .TXT file extension; for example: SR00001.TXT and SR00002.TXT. If there are multiple eligible files, they are processed sequentially based on file name; SR00001 processes before SR00002. If you use the file storage API for imports, you can upload a zip file that contains a single text file with the same name, for example: SR00001.ZIP containing a text file named SR00001.TXT. See Salesman Associate Upload for more information. Note:  The SLSUPLD periodic function uses the folder defined in the ASSOCIATE_FILE_PATH (CPRP) rather than the CWDIRECTCP_UPLOAD_ DIRECTORY.	Sample Sales Associates Upload Data
Source Codes	Source Upload Table (IXSRCE)	After using the putFile method to upload the file (File Storage API) or placing the file in the CWDIRECTCP_UPLOAD_ DIRECTORY, run the UPSRCCD Upload Source Code File (Program name PFR0134, Parameter IXSRCE) periodic function to upload a Source Code file named IXSRCE to the Source Upload Table (IXSRCE). Note:  This step is not necessary if you use the Work with File Upload Screen to upload the Source Code file. Update target table: You must use the Work with Source Code Upload (WSRW) menu option to process the records in the Source Code Work table; see Generating Source Codes Using the Source Upload Table (WSRW).	Sample Source Codes Upload Data
Stores	Store File	File upload: Use the Work with File Upload Screen to upload the Store file to the STORE_FILE_PATH. The file name must begin with ST and have a .TXT file extension; see Store Upload. Update target table: Run the STRUPLD periodic function. This function uses the folder defined in the STORE_FILE_PATH rather than the CWDIRECTCP_UPLOAD_ DIRECTORY. Note:  Uploading the Store file through the file storage API is not currently supported.	Sample Stores Upload Data
USPS Zip Codes	USPS Zip Codes Upload	Use the putFile method to upload the file if you are using the File Storage API; otherwise, place the file in the CWDIRECTCP_ USPS_UPLOAD_ FILE and use the Work with File Upload Screen to upload the USPS Zip Codes file. Update target table: After uploading the file, use the Load USPS Zip Code File (LZPS) menu option to process the uploaded file. The file name must be ctystate.txt, and file name matching is case-sensitive. See Fields in the USPS Zip/City/State Table and Fields in the USPS Zip/City/State Table for background.	Sample USPS Zip Codes Upload Data
Vendors	Vendor Upload Table (VNDUPL)	After using the putFile method to upload the file (File Storage API), or placing the file in the CWDIRECTCP_UPLOAD_ DIRECTORY, run the UPVENDR Upload Vendor File (Program name PFR0134, Parameter VNDUPL) periodic function to upload a Vendor file named VNDUPL to the Vendor Upload Table (VNDUPL). Note:  This step is not necessary if you use the Work with File Upload Screen to upload the Vendor Upload file. Update target table: After uploading the file, run the VNDUPLD Vendor Upload periodic function (Program name PFR0086) or use Working with Vendor Upload (LVUP) to process the records in the Vendor Upload table.	Sample Vendors Upload Data

Purging Upload History

PURGEUP: Run the PURGEUH Purge Upload History Table (program name PFR0126) periodic function to purge Upload History records that are older than the number of days specified in the Parameter field. If the Parameter field is blank or 0, records must be 21 days old to be eligible for purge.

Sample Upload Data

You can use the sample upload data below as a starting point to creating your own upload file by copying the sample file upload data, pasting the data into a text editor, and saving it with the file extension .TXT, unless otherwise indicated.

Important:

In order to leave any field in an upload file blank, pass a space in the field so that the file can be processed without errors. Leaving a field with no space is interpreted as null in the database and causes errors.

• Sample ACS Tape Upload Data

• Sample Catalog Requests Upload Data

• Sample Customer Price Group Exclusions Upload Data

• Sample MBS Tape Upload Data

• Sample PO Layering Upload Data

• Sample Price Codes Upload Data

• Sample Promotions Upload Data

• Sample Retail Integration Items Upload Data

• Sample Sales Associates Upload Data

• Sample Set Components Upload Data

• Sample Source Codes Upload Data

• Sample Stores Upload Data

• Sample USPS Zip Codes Upload Data

• Sample Vendors Upload Data

Sample ACS Tape Upload Data

Use the sample data below to create an ACS Tape upload file. See ACS Tape for a setup summary, and Loading Address Updates for processing information.

200000145BXBKCCJ21263204414     200206F 038ANDERSON            JEN                        S                            1234        EXAMPLE                     CIR                 HALETHORPE                  MD21227S                            123         MARY WAY                    CT                  LINTHICUM HEIGHTS           MD21090-1754533453 MARY WAY CT                                                   XX0000        C             

Sample Catalog Requests Upload Data

Use the sample data below to create a Catalog Requests upload file. See Catalog Requests for a setup summary, and Working with the Catalog Request Interface (WCRU) for processing information.

34 SAMPLE STREET|APT123|ADDRESS LINE 2|ADDRESS LINE 3|ADDRESS LINE 4|WESTBOROUGH|01581||MA|US|5085550100||[e-mail]|O1|R|COMPANY NAME|SOURCE7|7|1150417|207|5085550101||5085550102||MS.|MARY|M|JOHNSON||[e-mail]||5085550104|5085550105|5085550106|1|1|O1

Sample Customer Price Group Exclusions Upload Data

Use the sample data below to create a Customer Price Group Exclusions upload file. See Cust Price Group Exclusions for a setup summary, and ../marketing/c_customer_price_group_sku_exclusion_upload.dita#customerpricegroupskuexclusionupload for processing information.

7|1|CPG|RF123SKU4567|ROSE XSML WMNS||

Sample MBS Tape Upload Data

Use the sample data below to create an MBS Tape upload file. See MBS Tape for a setup summary, and Loading Address Updates for processing information.

JOHN                SMITH                 1 TEST DRIVE                                                WESTBORO                MA01581                B                                            I                                      01581                                     B                                                                                                           1 TEST DRIVE                                                WESTBORO     MA                                1 TEST DRIVE APT 2                                             WESTBORO       MA01581        B           12879000|

Sample PO Layering Upload Data

Use the sample data below to create a PO Layering upload file. See PO Layering for a setup summary, and Purchase Order Layering for processing information.

7|RF123SKU4567|ROSE XSML WMNS|4|53|1|1080915|20| |Ref#

Sample PCO Price Code Upload Record Type

Use the sample data below to create a Price Codes upload file. See Price Codes for a setup summary, and Price Code Upload for processing information.

• Sample PCO Price Code Upload Record Type

• Sample PCC Price Code Customer Upload Record Type

• Sample PCD Price Code Detail Upload Record Type

Sample PCO Price Code Upload Record Type

7|1|PCO|U|1150416|1234567|PRICE CODE UPLOAD|1|1|5.00|0.00|0.00|0.00|0.00|0.00|ITEM|Y|1150401|1150501|||||0||||

Sample PCC Price Code Customer Upload Record Type

7|2|PCC|U|1150416|1234567||0|0|.00|.00|.00|.00|.00|.00|||0|0|||||55||||

Sample PCD Price Code Detail Upload Record Type

7|3|PCD|U|1150416|1234567||0|0|.00|.00|.00|.00|.00|.00|||0|0|SKU|RED||SOURCE7|0||||

Sample Promotions Upload Data

Use the sample data below to create a Promotions upload file. See Promotions for a setup summary, and Promotion Upload for processing information.

• Sample PRM Order Promotion Upload Record

• Sample PRM Freight Promotion Upload Record

• Sample PRM Additional Freight Promotion Upload Record

• Sample PRM Item Category Promotion Upload Record

• Sample PRM Tiered Promotion Upload Record

• Sample PRM BOGO Promotion Upload Record

• Sample PRM Delete Promotion Upload Record

• Sample PRB BOGO Promotion Upload Record

• Sample PBP BOGO by Price Code Promotion Upload Record

• Sample PMD Discount Promotion Upload Record

• Sample PRS Source Promotion Upload Record

• Sample PRC Customer Promotion Upload Record

• Sample PIC Item Category Promotion Upload Record

• Sample PIE Item Exclusion Promotion Upload Record

Sample PRM Order Promotion Upload Record

7|PRM|A|1|1150414||PUORDER|PUORDER PROMOTION DESCRIPTION|1150401|1150601|POPUP WINDOW MESSAGE 1|POPUP WINDOW MESSAGE 2|POPUP WINDOW MESSAGE 3|POPUP WINDOW MESSAGE 4|1|O|PROMOID|5.95||.00|||||1||OA|WEB|4|4|US||N|O||1|.00|10||||0|0|.00|.00|.00|||0|||.00|0|0|0|.00|.00|.00||||||.00|.00||||0||||||0|.00|5.00|.00

Sample PRM Freight Promotion Upload Record

7|PRM|A|2|1150414||PUFRT|PUFRT PROMOTION DESCRIPTION|1150401|1150601|POPUP WINDOW MESSAGE 1|POPUP WINDOW MESSAGE 2|POPUP WINDOW MESSAGE 3|POPUP WINDOW MESSAGE 4|2|F|PROMOID|6.95|Y|.00|||||1|Y||WEB|4|4|US||N|O||1|.00|10||||0|0|.00|.00|.00|||0|||.00|0|0|0|.00|.00|.00||||||.00|.00||||0||||||0|.00|.00|.00

Sample PRM Additional Freight Promotion Upload Record

7|PRM|A|3|1150414||PUADLFR|PUADLFR PROMOTION DESCRIPTION|1150401|1150601|POPUP WINDOW MESSAGE 1|POPUP WINDOW MESSAGE 2|POPUP WINDOW MESSAGE 3|POPUP WINDOW MESSAGE 4|3|A|PROMOID|5.00||.00|||||1|Y|A|WEB|4|4|US||N|O||1|.00|10||||0|0|.00|.00|.00|||0|||.00|0|0|0|.00|.00|.00||||||.00|.00||||0||||||0|.00|.00|.00

Sample PRM Item Category Promotion Upload Record

7|PRM|A|4|1150414||PUITMCT|PUITMCT PROMOTION DESCRIPTION|1150401|1150601|POPUP WINDOW MESSAGE 1|POPUP WINDOW MESSAGE 2|POPUP WINDOW MESSAGE 3|POPUP WINDOW MESSAGE 4|4|C|PROMOID|5.95||.00|||||1|||WEB|4|0|||N|O|O|1|10.00|10||||0|0|.00|.00|.00|||0|||.00|0|0|0|.00|.00|.00||||||.00|.00||||0||||||0|.00|.00|.00

Sample PRM Tiered Promotion Upload Record

7|PRM|A|5|1150414||PUTIERD|PUTIERD PROMOTION DESCRIPTION|1150401|1150601|POPUP WINDOW MESSAGE 1|POPUP WINDOW MESSAGE 2|POPUP WINDOW MESSAGE 3|POPUP WINDOW MESSAGE 4|5|T|PROMOID|0||.00|||||0||||0|0||||||1|.00|0||||0|0|.00|.00|.00|||0|||.00|0|0|0|.00|.00|.00||||||.00|.00||||0||||||0|.00|.00|.00

Sample PRM BOGO Promotion Upload Record

7|PRM|A|6|1150414||PUBOGO|PUBOGO PROMOTION DESCRIPTION|1150401|1150601|POPUP WINDOW MESSAGE 1|POPUP WINDOW MESSAGE 2|POPUP WINDOW MESSAGE 3|POPUP WINDOW MESSAGE 4|6|B|PROMOID|0.00||.00|||||0|||WEB|4|0|||N|O||1|.00|10||||0|0|.00|.00|.00|||0|||.00|0|0|0|.00|.00|.00||||||.00|.00||||0||||||0|.00|.00|.00

Sample PRM Delete Promotion Upload Record

7|PRM|D|7|1150414||PUDELTE|PUDELTE PROMOTION DESCRIPTION|1150401|1150601|POPUP WINDOW MESSAGE 1|POPUP WINDOW MESSAGE 2|POPUP WINDOW MESSAGE 3|POPUP WINDOW MESSAGE 4|7||PROMOID|5.00||.00|||||1|Y|N|WEB|4|4|US|SOURCE7|N|O|O|1|.00|10||||0|0|.00|.00|.00|||0|||.00|0|0|0|.00|.00|.00||||||.00|.00||||0||||||0|.00|.00|.00

Sample PRB BOGO Promotion Upload Record

7|PRB|A|8|1150414||BOGO1|PUBOGOB PROMOTION DESCRIPTION|0|0|||||0|||0.00||.00|||||0||||0|0||||||0|.00|0||SKU|RED|1|1|5.00|.00|.00|Y|N|0|||.00|0|0|0|.00|.00|.00||||||.00|.00||||0||||||0|.00|.00|.00

Sample PBP BOGO by Price Code Promotion Upload Record

7|PBP|A|9|1150414||BOGO1|PUBOGOP PROMOTION DESCRIPTION|0|0|||||0|||0.00||.00|||||0||||0|0||||||0|.00|0||||0|0|.00|.00|.00|||101|||50.00|1|101|1|5.00|.00|.00|N|Y|N|||.00|.00||||0||||||0|.00|.00|.00

Sample PMD Discount Promotion Upload Record

7|PMD|A|10|1150414||TG|TG TIER PROMOTION DESCRIPTION|0|0|||||0|||0.00||.00|||||0||||0|0||||||0|.00|0||||0|0|.00|.00|.00|||0|||.00|0|0|0|.00|.00|.00||||||0.00|.00|SKU|PINK||0||||||25.00|.00|.00|.00

Sample PRS Source Promotion Upload Record

7|PRS|A|11|1150414||OP|OPSORCS PROMOTION DESCRIPTION|0|0|||||0|||0.00||.00|||||0||||0|0||||||0|.00|0||||0|0|.00|.00|.00|||0|||.00|0|0|0|.00|.00|.00||||||0.00|.00|||SOURCE7|0||||||0|.00|.00|.00

Sample PRC Customer Promotion Upload Record

7|PRC|A|12|1150414||OP|OPCUSTC PROMOTION DESCRIPTION|0|0|||||0|||0.00||.00|||||0||||0|0||||||0|.00|0||||0|0|.00|.00|.00|||0|||.00|0|0|0|.00|.00|.00||||||0.00|.00||||55||||||0|.00|.00|.00

Sample PIC Item Category Promotion Upload Record

7|PIC|A|13|1150414||ITMCATP|PUITMC PROMO DESCRIPTION|0|0|||||0|||0.00||.00|||||0||||0|0||||||0|.00|0||||0|0|.00|.00|.00|||0|||.00|0|0|0|.00|.00|.00||||||0.00|.00||||0||DFLT||||0|.00|.00|.00

Sample PIE Item Exclusion Promotion Upload Record

7|PIE|A|14|1150414||ITMCATP|PUITMX PROMO DESCRIPTION|0|0|||||0|||0.00||.00|||||0||||0|0||||||0|.00|0||||0|0|.00|.00|.00|||0|||.00|0|0|0|.00|.00|.00||||||0.00|.00||||0||0||DFLT||0|.00|.00|.00

Sample Retail Integration Items Upload Data

Use the sample data below to create a Retail Integration Items upload file (RIIUPP or RIIUPP.TXT). See Retail Integration Items for a setup summary, and RI Item Upload Process for processing information.

• Sample 01 Item/SKU Item Upload Record

• Sample 03 Item Offer Upload Record

• Sample 04 SKU Offer Upload Record

• Sample 05 Item Price Upload Record

• Sample 06 SKU Price Upload Record

• Sample 07 Vendor Item Upload Record

• Sample 08 Item UPC Upload Record

• Sample 09 Item Coordinate Upload Record

Sample 01 Item/SKU Item Upload Record

6|1150304|110000|01|A|1|IT|3009|RED  S        |U|0|0|Y|0|N|0| |0|                    |                    |       |0|N|0|0|0|N| |0|          |          |          |          |0|Y|N|Mens Patterned Long-Sleeve|                                        |N|N|N|0| |   |0|11500|0|CLT|  |0| |  |0|0|   |EA|1234|0|0|0|   |0|   |0|0|Red Small|N|0|0|29.99|0|0|0|0|0|0|0|0|N|0|N|100101|0|100101|          |          |          |0|0|N|                |0|0|0|0|0|                                        |N|   |0|0|N|0|     |     |N|0|                    |       |N|29.99|0|0| |0| |1|S010101|02|   |    |    |    | |    |  |   |0|    | |0|0|N|0|0|0|0|N|0|0|0|N  |N|0|0| | |                              |                              |                              |                              |N|N|0|  |   |   |0|0| |0|0|0| |0|0|0|0|0|0| |   | | | | |0|  |   |   |0|0|0|0|0|0|0| |   |0|0|0|0|0|0|0| |0|                    |0|                              |0|                              |                              |                              |0|0|0|0|0|   |   |   |              |0|            |  |                                                                      |              |Y|https://example.com/is/image/Fry/1001|https://example.com/is/image/Fry/1001|https://example.com/is/image/Fry/1001|https://example.com/is/image/Fry/1001|0

Sample 03 Item Offer Upload Record

7|1150421|84600|03|A|1|IT|RITEST1| | |0|0|0|0.0|0|0|0|0|0|0|0|0.0000|0|0|0|0.000|0|0|0.000|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0.0000|0.0|0|0|0|0|0.00|0|0|0|0.00|0|0|0|0|0|0|0|0|0.000|0|0|0|0|0.000|0|0|0|0|0.0000|0.0000|0.0000|0.0000|0|0|0|0.00|0.00|0|0|0|0|0|0|0|0|0|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|7|16.99|15.00|Y|5.00|2|100|0.00|N|36.00|3.00|1.50|N|N|0.00|0|F|P|||||N|N|207|||0|0.00|0.00|0|0|0|0.00|0|0.00|0.00|0.00|0.00|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0.00|0.00|0|0|0|0|0.00|0.00|0|0.00|0.00|0|0|0|0|0|0|0|0|0|0|0.0000|0.000|0|0|0|0|0|0|0|0|0|0|0|0|||||0

Sample 04 SKU Offer Upload Record

7|1150421|84600|04|A|1|IT|RITEST2|AQUA LRGE BABY||0|0|0|0.0|0|0|0|0|0|0|0|0.0000|0|0|0|0.000|0|0|0.000|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0.0000|0.0|0|0|0|0|0.00|0|0|0|0.00|0|0|0|0|0|0|0|0|0.000|0|0|0|0|0.000|0|0|0|0|0.0000|0.0000|0.0000|0.0000|0|0|0|0.00|0.00|0|0|0|0|0|0|0|0|0|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0.00|0|0|0.00|0|0.00|0.00|0.00|0|0|0.00|0|0|0|0|0|0|0|0|0|0|0|0|7|0.00|0.00|N|0|0|0.00|Y|0.00|0.00|0.00|0.00|0.00|0|N|N|||N|N|0|MO||0|0|0|0.00|0.00|0|0.00|0.00|0|0|0|0|0.00|0.00|0|0.00|0.00|0|0|0|0|0|0|0|0|0|0|0.0000|0.000|0|0|0|0|0|0|0|0|0|0|0|0|||||0

Sample 05 Item Price Upload Record

7|1150421|84600|05|A|1|IT|RITEST2| | |0|0|0|0.0|0|0|0|0|0|0|0|0.0000|0|0|0|0.000|0|0|0.000|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0.0000|0.0|0|0|0|0|0.00|0|0|0|0.00|0|0|0|0|0|0|0|0|0.000|0|0|0|0|0.000|0|0|0|0|0.0000|0.0000|0.0000|0.0000|0|0|0|0.00|0.00|0|0|0|0|0|0|0|0|0|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0.00|0|0|0.00|0|0.00|0.00|0.00|0|0|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0|0|0.00|0|0.00|0.00|0.00|0.00|0.00|0|0|0|0|0|0|0|0|0|0|7|1150401|1|0.00|50.00|0|0.00|0.00| |0|0|0|0.00|0.00|0|0.00|0.00|0|0|0|0|0|0|0|0|0|0|0.0000|0.000|0|0|0|0|0|0|0|0|0|0|0|0|||||0

Sample 06 SKU Price Upload Record

7|1150421|84600|06|A|1|IT|RITEST2|AQUA LRGE BABY||0|0|0|0.0|0|0|0|0|0|0|0|0.0000|0|0|0|0.000|0|0|0.000|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0.0000|0.0|0|0|0|0|0.00|0|0|0|0.00|0|0|0|0|0|0|0|0|0.000|0|0|0|0|0.000|0|0|0|0|0.0000|0.0000|0.0000|0.0000|0|0|0|0.00|0.00|0|0|0|0|0|0|0|0|0|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0.00|0|0|0.00|0|0.00|0.00|0.00|0|0|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0|0|0.00|0|0.00|0.00|0.00|0.00|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0.00|0.00|0|7|1150401|1|0.00|45.00|0|0.00|0.00||0|0|0|0|0|0|0|0|0|0.0000|0.000|0|0|0|0|0|0|0|0|0|0|0|0|||||0

Sample 07 Vendor Item Upload Record

7|1150421|84600|07|A|1|IT|RITEST2|||0|0|0|0.0|0|0|0|0|0|0|0|0.0000|0|0|0|0.000|0|0|0.000|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0.0000|0.0|0|0|0|0|0.00|0|0|0|0.00|0|0|0|0|0|0|0|0|0.000|0|0|0|0|0.000|0|0|0|0|0.0000|0.0000|0.0000|0.0000|0|0|0|0.00|0.00|0|0|0|0|0|0|0|0|0|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0.00|0|0|0.00|0|0.00|0.00|0.00|0|0|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0|0|0.00|0|0.00|0.00|0.00|0.00|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0.00|0.00|0|0|0|0|0.00|0.00|0|0.00|0.00|0|7|7RIITEM1VI|10|7ITEM VENDOR ITEM|2|VENDOR ITEM MESSAGE 1|VENDOR ITEM MESSAGE 2|VENDOR ITEM MESSAGE 3|10|10.0000|1.350|10|45|10||0|0|0|0|0|0|0|0|||||0

Sample 08 Item UPC Upload Record

7|1150421|84600|08|A|1|IT|RITEST2|||0|0|0|0.0|0|0|0|0|0|0|0|0.0000|0|0|0|0.000|0|0|0.000|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0.0000|0.0|0|0|0|0|0.00|0|0|0|0.00|0|0|0|0|0|0|0|0|0.000|0|0|0|0|0.000|0|0|0|0|0.0000|0.0000|0.0000|0.0000|0|0|0|0.00|0.00|0|0|0|0|0|0|0|0|0|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0.00|0|0|0.00|0|0.00|0.00|0.00|0|0|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0|0|0.00|0|0.00|0.00|0.00|0.00|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0.00|0.00|0|0|0|0|0.00|0.00|0|0.00|0.00|0|0|0|0|0|0|0|0|0|0|0.0000|0.000|0|0|0|0|E8|65656565|7|0|0|0|0|0|||||0

Sample 09 Item Coordinate Upload Record

7|1150421|84600|09|A|1|IT|RITEST2| | |0|0|0|0.0|0|0|0|0|0|0|0|0.0000|0|0|0|0.000|0|0|0.000|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0.0000|0.0|0|0|0|0|0.00|0|0|0|0.00|0|0|0|0|0|0|0|0|0.000|0|0|0|0|0.000|0|0|0|0|0.0000|0.0000|0.0000|0.0000|0|0|0|0.00|0.00|0|0|0|0|0|0|0|0|0|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0.00|0|0|0.00|0|0.00|0.00|0.00|0|0|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0|0|0.00|0|0.00|0.00|0.00|0.00|0.00|0|0|0|0|0|0|0|0|0|0|0|0|0|0.00|0.00|0|0.00|0.00|0|0|0|0|0.00|0.00|0|0.00|0.00|0|0|0|0|0|0|0|0|0|0|0.0000|0.000|0|0|0|0|0|0|0|COORDINATE1|O|coordinate1 message|AQUA LRGE BABY|0|||||0

Sample Sales Associates Upload Data

Use the sample data below to create a Sales Associates upload file. See Sales Associates for a setup summary, and Salesman Associate Upload for processing information.

5555555SALESMAN ASSOCIATE UPLOAD NAMENHOMESTORE [e-mail]  

Sample Set Components Upload Data

Use the sample data below to create a Set Components upload file. See Importing Set Components (WCUP) for processing information.

• Sample Type S: Set and Set Detail Upload Record

• Sample Type VG: Variable Set and Variable Set Group Upload Record

• Sample Type VI: Variable Set Detail Upload Record

Sample Type S: Set and Set Detail Upload Record

7|S|SET||||SETCOMP1||||1|50.00|1|0|0||0|

Sample Type VG: Variable Set and Variable Set Group Upload Record

7|VG|VARIABLE||||VARIABLECMP1||||0|0|0|0|1|VARIABLE GROUP 1|2|

Sample Type VI: Variable Set Detail Upload Record

7|VI|VARIABLE||||VARIABLECMP2||||0|0|0|0|1||0|

Sample Source Codes Upload Data

Use the sample data below to create a Source Codes upload file. See Source Codes for a setup summary, and Generating Source Codes Using the Source Upload Table (WSRW) for processing information.

7|SOURCECD7|C|$O|H|D|K|SOURCECD7 SOURCE CODE DESCRIPT|500.00|.00|.00|CD|5.00|DR|N|12.00|5.00|25.00|5.00|1|10000|1150401|5000|7000|POP UP WINDOW MESSAGE 1       |POP UP WINDOW MESSAGE 2       |POP UP WINDOW MESSAGE 3       |POP UP WINDOW MESSAGE 4       |12345|1234567|12.00|12345|123|Y|N|Y|12.00|12.00|150.00|55.00|ALPHANUMERIC 30 POSITIONSUSER1|ALPHANUMERIC 30 POSITIONSUSER2|ALPHANUMERIC 30 POSITIONSUSER3|ALPHANUMERIC 30 POSITIONSUSER4|ALPHANUMERIC 30 POSITIONSUSER5|ALPHANUMERIC 30 POSITIONSUSER6|N|N|07|       |007|01|01|123|RCCD|LSTSOURCE|FPOCD|N|CAT|CL|1150601| |     |123.00|N|N|

Sample Stores Upload Data

Use the sample data below to create a Stores upload file. See Stores for a setup summary, and Store Upload for processing information.

STORE#777 THIS IS STORE#777 NAME/DESCRIPTION      YSTORE#777 STREET ADDRESS LINE 1 STORE#777 STREET ADDRESS LINE 2 STORE#777 STREET ADDRESS LINE 3  STORE#777 STREET ADDRESS LINE 4CITY                     MA01468     USATELEPHONENUMBR

Sample USPS Zip Codes Upload Data

Use the sample data below to create a USPS Zip Codes upload file. See USPS Zip Codes for a setup summary, and Load USPS Zip Code File (LZPS) for processing information.

D00501V13916UHOLTSVILLE                               PYV13916HOLTSVILLE                  NA 353910NY103SUFFOLK                  

D00544V13916UHOLTSVILLE

Sample Vendors Upload Data

Use the sample data below to create a Vendors Upload file (VNDUPL). See Vendors for a setup summary, and Working with Vendor Upload (LVUP) for processing information.

007|7|A|EXAMPLE VENDOR                |1234 SAMPLE STREET              |SECOND ADDRESS LINE             |THIRD ADDRESS LINE              |FOURTH ADDRESS LINE             |WESTBOROUGH              |MA|01581     |US |JOHN SMITH                    |5085550100|    |0|ROBERT JONES                  |1234 REMIT SAMPLE ST            |SECOND ADDRESS LINE             |THIRD ADDRESS LINE              |FOURTH ADDRESS LINE             |SPRINGFIELD              |MA|01119     |US |Y|N|Y|P|0|0|N|N|N|N|N         |0|.00|.00|.00|          |0|   |S|                    |V|                    |[e-mail]                                |[e-mail]                                 |USR1      |USR2      |USR3      |                                                            |Y

Setting Up Authorization Services

Topics in this part: The following topics describe the functions available to define the payment authorization services that your company uses.

• Reprocess Authorizations Screen (RPAA)

•  Reprocess Drop Ship Authorizations Screen (RPDS)

•  Working with Required Responses (WREQ)

• Reset Authorizations (RSAA) describes how to reset records in the Credit Card Authorization Transaction table from a *SENT status to a *RDY status so that they can be resent to the authorization service.

• Defining Authorization Services (WASV) shows you how to define the authorization services that your company uses.

• Defining Authorization Service Countries shows you how to cross-reference your country codes to the country codes used by the account provider. You can also indicate whether the account provider performs address verification for the country.

• Defining Vendor Paytype Codes shows you how to cross-reference your payment codes to the payment codes used by the account provider.

• Defining Vendor Response Codes shows you how to define the codes your account provider uses to identify whether a credit card is approved or declined, and how to have the system place orders on hold based upon the vendor response code.

• Defining Merchant ID Overrides describes how to set up merchant ID overrides for different entities within your company.

• Defining Authorization Service Currencies describes how to set up cross references for your company's currency codes and the codes used by a account provider.

• Performing Online Credit Card Authorizations provides an overview on online credit card authorization and required setup.

• Performing Batch Authorization (SATH) describes how to send credit cards up for batch authorization by the associated ship via.

• Printing the Online Credit Card Authorization List (PATL) describes how to print the Online Authorization Listing.

Defining Authorization Services (WASV)

Purpose: Use the Work with Authorization Services menu option to:

• define the account providers that you use, such as:

  • Authorization services, to authorize charges against a credit card or stored value card.

  • Authorization/Deposit services, to authorize card charges and receive deposit amounts.

  • Deposit services, to provide settlement for card payments.

• identify the type of service the account provider performs

• define the parameters that identify your company to the account provider

• define the information necessary to connect, transmit, and receive data to and from the service, such as:

  • country codes

  • valid pay types

  • response codes (vendor responses, AVS responses, and CID responses)

  • currency codes

  • merchant IDs for individual entities within your company

  • whether the order originated as an internet order

Some of the information required to establish a account provider service provider on your system must be acquired from the account provider. For example, each account provider will assign you a unique merchant id and password.

You can use the same account provider service provider to process your authorizations and deposits, or you can use one service for authorizations and another for deposits.

Important:

You would use Work with Authorization Services in Classic View to create and manage payment processing for Customer Engagement Stored Value Card, PayPal and External Payment Service Stored Value Cards and Credit Cards.

You cannot create, change, or delete an authorization service that uses EFTConnect through the Work with Authorization Services option in Classic View, instead, use the Payment Configurations option in Modern View to create and manage any payment processing through EFTConnect. Once the merchant account is created, configure additional settings for the EFTConnect authorization service within Work with Authorization Services such as Response Code hold reasons or country and currency mappings.

In this topic:

• Deferred/Installment Pay Plans

• Identifying Internet Orders

• Work with Authorization Services Screen

• First Create Authorization Services Screen

• Second Create Authorization Service Screen

• Work with External Authorization Service Screen

Deferred/Installment Pay Plans

Deferred or installment pay plans allow you to process deposits against orders at various intervals after you bill the order shipment. For example, you could offer “no payment for 60 days” or “four easy payments” to your customers.

In order to set up deferred or installment pay plans, you must have the Deferred and Installment Billing (F51) system control value must be selected. See Deferred/Installment Billing Overview for more information on deferred and installment pay plans and how to set them up in Order Administration.

Identifying Internet Orders

An internet order is determined in one of two ways:

• If using the E-Commerce Interface the system loads an I in the Internet field on the order header when the order is created in Order Administration.

• An order is considered an internet order if the order type on the order matches the E-Commerce Order Type (G42) system control value.

• Mail = Mail order.

• Phone = Telephone order.

• Internet = Web order.

To determine where the order originated, the system:

• looks at the value in the Internet order field in the Order Header table. If this field is set to I, the order is a web order.

• determines if the order type for the order matches the E-Commerce Order Type (G42) system control value. If the order type matches, the order is a web order.

• looks at the Forecasting order category field in the Order Type table. If this value is 1, the order is a mail order. If this value is 2, the order is a phone order.

Work with Authorization Services Screen

How to display this screen: Enter WASV in the Fast path field at the top of any menu screen or select Work with Authorization Services from a menu.

You can create only PayPal (PPL), Customer Engagement Stored Value Card (RLT) and External Payment Credit Card and Stored Value Card records through this screen. Use the Payment Configurations option in Modern View to create EFTConnect merchant accounts. Details about the EFTConnect merchant accounts will be available for display only.

Field	Description
Code	The code to identify the account provider. Enter a full or partial code and select OK to display service codes in alphanumeric order, starting with your entry. Alphanumeric, 3 positions; optional.
Application	The type of activity performed by the account provider. Valid values are: Auth/Deposit = The account provider authorizes card charges and deposits dollar amounts billed to cards Authorization = The account provider only authorizes card charges. Deposit = The account provider only deposits dollar amounts billed to cards. Optional.
Description	The name of the account provider. Alphanumeric, 30 positions; optional.
Merchant	The account number assigned by the account provider to identify transmissions to/from your company.  This is the default ID number; you can also specify separate ID numbers for each entity in your company, and/or to use for orders using deferred or installment billing. Alphanumeric, 20 positions; optional.

Screen Option	Procedure
Change an authorization service record	Select Change for a service to advance to the Change Authorization Services Screen. At this screen you can change any information except the Service code. See the First Create Authorization Services Screen for field descriptions. Important: You cannot use this option to change an existing authorization service using EFTConnect. Use the Payment Configurations option in Modern View instead.
Delete an authorization service record	Select Delete for a service to delete it. Important: You cannot use this option to delete an existing authorization service using EFTConnect. Use the Payment Configurations option in Modern View instead.
Display an authorization service record	Select Display for a service to advance to the Display Authorization Services Screen. You cannot change any information at this screen. See the First Create Authorization Services Screen for field descriptions. Settings configured through the Payment Configurations options in Modern View for EFTConnect will be displayed here.
Work with country codes	Select Country for a service to add, change or delete the country codes recognized by the account provider; see Defining Authorization Service Countries.
Work with vendor paytype codes	Select Paytypes for a service to add, change, delete or display the pay type codes recognized by the authorization service. See Defining Vendor Paytype Codes.
Work with vendor responses	Select Responses for a service to add, change, display or delete the response codes you receive from the service and the actions to take for each. See Defining Vendor Response Codes.
Work with merchant ID overrides based on entity	Select Merchant ID Override for a service to add, change, or delete merchant ID overrides by entity. See Defining Merchant ID Overrides.
Work with currency codes	Select Currency for a service to add, change, or delete cross-references between the currency codes used in your company and by the authorization service. See Defining Authorization Service Currencies.
Work with external authorization service settings	Select External Service to advance to the Work with External Authorization Service Screen. External Authorization Service Access (B25) authority is required.
Create an authorization service	Select Create to advance to the First Create Authorization Services Screen. Important: You cannot use this option to create an EFTConnect. Use the Payment Configurations option in Modern View instead.

First Create Authorization Services Screen

Purpose: Use this screen to define a account provider on your system. The Authorization Service record contains information that identifies your company to the account provider and the parameters that you must include in the transmission to the account provider.

Each account providerrequires its own information. Not all fields are applicable for each service.

Important:

You cannot use this screen to create a new authorization service using EFTConnect. Use the Payment Configurations option in Modern View instead.

How to display this screen: Select Create at the Work with Authorization Services Screen.

Field	Description
Service Code	The code to identify the account provider. Point-to-Point communication: If you are using point-to-point communication, the Service code must be a specific value for the integration: PayPal: To use the PayPal Integration, enter PPL. Oracle Retail Customer Engagement integration: To use the Customer Engagement Stored Value Card Integration, enter RLT. EFTConnect: Generated by the system when a merchant account is created through the Payment Configuration option in Modern View. The code is created sequentially always starting with an ‘E’ (i.e. E01, E02, E03). External Payment Service: Enter a unique code for the service that is different from the other system required codes. Alphanumeric, 3 positions. Create screen: required. Change screen: display-only.
Application	The type of activity performed by the account provider. Valid values are: Auth/Deposit = The account provider authorizes card charges and deposits dollar amounts billed to the cards. Authorization = The account provider only authorizes card charges. Deposit = The account provider only deposits dollar amounts billed to cards. Note:  PayPal should have the Application type set to Auth/Deposit. Required.
Merchant ID	The account number assigned by the account provider to identify transmissions to/from your company. This ID is a default. You can also identify merchant IDs to use for depositing deferred or installment pay plans (as opposed to regular deposits) below. Similarly, you can set up overrides for different entities in your company, including deferred or installment overrides. See Defining Merchant ID Overrides. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 20 positions; optional.
Charge description	A description that identifies your company's product line or the type of service performed. Alphanumeric, 20 positions; optional.
Deferred merchant ID	The account number assigned by the service to identify transmission of deferred pay plan transactions for deposit. See Deferred/Installment Billing Overview for more information on deferred and installment billing, and see Processing Auto Deposits (SDEP) for more information on processing deposits. You can also set up overrides for different entities in your company, including deferred or installment overrides. See Defining Merchant ID Overrides. Alphanumeric, 20 positions; optional.
Installment merchant ID	The account number assigned by the service to identify transmission of installment pay plan transactions for deposit. See Deferred/Installment Billing Overview, and see Processing Auto Deposits (SDEP). You can also set up overrides for different entities in your company, including deferred or installment overrides. See Defining Merchant ID Overrides. Alphanumeric, 20 positions; optional.
	The account provider assigns values to the following fields:
Signon	A code required to sign on to the account provider. Case-sensitive. Alphanumeric, 10 positions; optional.
Receiving code	A code that identifies your company to the account provider. Alphanumeric, 10 positions; optional.
Password	A password required by the account provider. Case-sensitive. Alphanumeric, 10 positions; optional.
Start up information	Startup text that identifies your company to the account provider. Alphanumeric, 10 positions; optional.
Presenter's ID Auth / Deposit	A code required to sign on to the account provider. Separate fields allow you to define a presenter’s ID for both batch authorization and deposit transactions; if you use the same port number for both batch authorization and deposit transactions, define the presenter’s ID in the first field. Alphanumeric, 10 positions; optional.
PID password Auth / Deposit	A password required to sign on to the account provider. Separate fields allow you to define a PID password for both batch authorization and deposit transactions; if you use the same port number for both batch authorization and deposit transactions, define the PID password in the first field. Alphanumeric, 10 positions; optional.
Submitter's ID Auth / Deposit	A code required to sign on to the account provider. Separate fields allow you to define a submitter’s ID for both batch authorization and deposit transactions; if you use the same port number for both batch authorization and deposit transactions, define the submitter’s ID in the first field. Alphanumeric, 10 positions; optional.
SID password Auth / Deposit	A password required to sign on to the account provider. Separate fields allow you to define a SID password for both batch authorization and deposit transactions; if you use the same port number for both batch authorization and deposit transactions, define the SID password in the first field. Alphanumeric, 10 positions; optional.
Sub code	A code required to sign on to the account provider. Alphanumeric, 10 positions; optional.
Exclude from FPO (Exclude from flexible payment option)	Indicates whether to exclude orders associated with this account provider from a deferred or installment pay plan. If an order includes any pay type whose authorization service has this field selected, the order is not eligible for a pay plan. Valid values are: Selected = exclude from pay plan Unselected = do not exclude from pay plan See Deferred/Installment Billing Overview for information on how the system determines whether an order is eligible for a pay plan in order entry.
Void auth at deposit	Defines whether any unused portion of an authorization should be voided at deposit time for: A credit card pay type, or A stored value card, when the External Payment Service is used. Valid values are: Selected = The system voids any unused portion of an authorization for a credit card pay type at deposit time. Order Administration will need to obtain an additional authorization for any subsequent deposits for the order. Unselected = The system retains any unused portion of an authorization for a credit card pay type at deposit time. See Void Unused Authorization After Initial Deposit for processing details. Important: Your end account provider must support split shipments for you to set this flag to N.  Stored value card pay types when not using the External Payment Service: The setting of the Retain Unused Stored Value Card Authorization After Deposit (J21) system control value defines whether the system automatically voids a partially deposited stored value card authorization when the External Payment Service is not in use. See Stored Value Card Deposits for processing details.
Send reversal	Defines whether the account provider supports authorization reversals for credit card and stored value card payments. Valid values are: Selected = The account provider supports authorization reversal processing for credit card and stored value card pay types. The REVERSE (Send Reversals for Expired Authorizations) periodic function processes all open Authorization History records for pay types associated to this service that are eligible for authorization reversal. Unselected = The account provider does not support authorization reversal processing for credit card or stored value card pay types. The REVERSE periodic function does not process eligible authorization reversals for pay types associated to this service. Regardless of the setting of this field, you can still perform stored value card authorization reversals when the card is deactivated; see Stored Value Card Authorization Reversal.
Supports Auth Resubmission	Indicates whether to resubmit failed authorization and deposit requests for credit cards through the External Payment Service. When the request is for authorization and deposit of a failed deposit request: CyberSource: The subsequentAuthReason in the authorization and deposit request is set to 1 if the Supports Auth Resubmission flag is selected; otherwise it is set to 3. Note:  If the credit card number changes since the initial deposit request, then the subsequentAuthReason is set to 3, since it is not considered a subsequent authorization and deposit request. External Payment Service: The subsequentAuthReason is set to RESUBMIT; otherwise, if the Supports Auth Resubmission flag is not selected, the subsequentAuthReason is set to REAUTH. Important: Select this flag only if your account provider supports merchant-initiated resubmission of failed deposits.

Second Create Authorization Service Screen

Important:

You cannot use this screen to create or change and EFTConnect service. Use the Payment Configurations option in Modern View instead.

How to display this screen: Select OK at the First Create Authorization Services Screen.

Field	Description
Media type	The method by which the data is transmitted to the account provider. Valid value is Communication. Optional.
Batch/Online	A code that indicates whether transactions are transmitted to/received from the account provider immediately (online) as each order is entered, or whether groups of transactions are transmitted to/received from the account provider at predefined times during the day (in batch). Valid values are: Batch = Transactions are grouped and transmitted to/received from the account provider at predefined times throughout the day. On-line = Transactions are transmitted to/received from the account provider immediately for each order. On-line or Batch = Transactions are transmitted to/received from the account provider immediately if the order is eligible for online authorization. Any order that does not receive an authorization immediately is grouped and transmitted to/received from the account provider at predefined times. Optional.
Active production system	This field is ONLY used for PayPal. Indicates whether you are processing in a live environment (production) or in a testing environment.    Valid values are: Selected = Transactions are being processed in a live environment. Unselected = Transactions are being processed in a testing environment.
Installment billing?	Indicates if the account provider supports installment billing of credit cards. Installment billing plans are typically established for high cost items. Note:  This field is informational only and is not used to set up an installment pay plan in Order Administration. Valid values are: Selected = The account provider supports installment billing. Unselected = The account provider does not support installment billing.
Immediate response	Indicates whether a response from the account provider is received immediately for each authorization transaction. Valid values are: Selected = Responses from the account provider are received immediately for each transaction. Unselected = Responses from the account provider are not received immediately (delayed turnaround).
Immediate deposit	Indicates whether the account provider sends a detailed response to Order Administration. Valid values are: Selected = The account provider does not send a detailed response to Order Administration; Order Administration marks the transaction as received and subsequently confirmed. Unselected = The account provider sends a detailed response to Order Administration; Order Administration waits for the response based on the Wait time defined for the associated integration layer job.
Keep history information?	Indicates whether transactions sent to the account provider will be kept online. Typically, this feature is used in test environments. Valid values are: Selected = Keep the transaction records on-line. Unselected = Do not keep the transaction records on-line.
Selected for deposit	Indicates whether the account provider is included in the next deposit run. By default, all account providers are selected for deposit; however, you can remove a account provider from the next deposit run at the Select Auth Service for Deposit Screen in Processing Auto Deposits (SDEP). Once you submit the deposit run, the system reselects all account providers for the next deposit run. Valid values are: Selected (default) = The system includes the account provider in the next deposit run. Unselected = The system does not include the account provider in the next deposit run. This field displays as unselected only if you are reviewing this screen at the same time a deposit run is submitted that does not include this account provider. Display-only.
Address verification	Indicates whether you will be using the Address Verification Service provided by the account provider to verify the customer's address and credit card number. Valid values are: Selected = Perform address verification Unselected = Do not perform address verification
Decline days	The number of days to hold a declined credit card charge on the system before sending it for an authorization again. This field is not implemented. See Defining Vendor Response Codes for setup information. Numeric, 3 positions; optional.
Industry format code	A code that is assigned by the account provider to identify your company type. Use this field to enter your DBA number. Alphanumeric, 5 positions; optional.
Primary authorization service	The primary account provider that the account provider uses for its transmission setup. Orders sent to this account provider are redirected to the primary account provider defined in this field. If this field is left blank, the data created for this account provider will be used. Alphanumeric, 3 positions; optional.
Deposit phone #	The telephone number associated with the deposit account provider. Informational only. Numeric, 11 positions; optional.
Authorization phone #	The telephone number associated with the authorization account provider. Informational only. Numeric, 11 positions; optional.
Communication type	Indicates the method of communication used to transmit transactions between Order Administration and the account provider. The only valid value is Payment Link, in which the system sends transactions to the account provider using a point-to-point integration. You must define communication settings in Working with Customer Properties (PROP). The system also uses the Activation and Authorization Reversal integration layer jobs to process stored value card triggers. Optional.
Response check frequency	Indicates the multiple to apply to the Response time to determine how long to wait for a response after a connection when you are using an external payment service. For example, if the Response check frequency is 6 and the Response time is 10,000, the system waits 60,000 milliseconds (60 seconds or 1 minute) for a response after connection. Note:  If the total response interval is exceeded for an authorization record, the record goes into *RCVD status with a response type of SU, and is then removed from the Credit Card Authorization Transaction table (CCAT00). To avoid potential timeout issues, Oracle recommends that you set the Response Time high enough for the authorization service to prevent issues that could potentially occur if the authorization process times out while processing multiple authorizations for an order. Numeric, 3 positions; optional.
Test mode?	This field is used for both PayPal and EFTConnect. Indicates whether you are transmitting in test mode. Valid values are: Selected = Test mode. The system inserts the word TEST in the transmission. Unselected (default) = Live mode. For PayPal, if selected, the environment key is set to "sandbox" and if unselected, the environment key is set to "live". For EFTConnect, see Payment Configurations. The Environment field can be set to Test or Live.
Response time	Indicates the number of milliseconds to wait for a connection to the account provider when you are using an external payment service. For example, set this field to 10,000 milliseconds to wait 10 seconds for a connection. Numeric, 5 positions; optional.
Merchant division	Assigned by the authorization service. Numeric, 5 positions; optional.
Authorization service provider	This field is not implemented. Alphanumeric, 10 positions; optional.
API User name	The user name, provided by the account provider, used to establish a direct connection to the account provider. Alphanumeric, 64 positions; optional.
API Password	The password, provided by the account provider, used to establish a direct connection to the account provider. Alphanumeric, 64 positions; optional.
API Signature	The encrypted signature, provided by the account provider, used to establish a direct connection to the account provider. You can also define API credential information at the entity level using the Create Merchant ID by Entity Screen. Alphanumeric, 128 positions; optional.
Override Reconciliation Id	Indicates the value to pass as the reconciliationID in a debit deposit, credit deposit, or authorization and deposit request to EFTConnect. Available settings are: blank (default) = Do not send the invoice number or the alternate order number as the reconciliation ID. Invoice Number = Send the invoice number as the reconciliation ID. The invoice number is assigned at billing. Alternate Order Number = Send the alternate order number, if it exists, as the reconciliationID. For an e-commerce order, the alternate order number is the order_number passed in the Inbound Order XML Message (CWORDERIN) message to identify the order in the originating system or on the web storefront. The alternate order number is labeled the Alt ord at the Display Order Properties Screen. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1). If the reconciliationID in the request message does not specify an invoice number or alternate order number, then when using EFTConnect CyberSource, the reconciliationID is assigned as a reference number for the transaction, and passes it in the response message. If the e-commerce is configured as a reconciliation ID for deposits, the deposit could fail if the e-commerce ID is longer than allowed by the payment processor. See Alternate Order Number Prefix for Order Creation (M76) for more information. Note:   If the Alternate Order Number is passed as the reconciliationID, it must be alphanumeric. If the reconciliationID includes any special characters, depending on the rules or requirements of the back-end processor, CyberSource may ignore the ID provided in the request and assign its own reconciliationID, to be passed in the response. Only the debit deposit, credit deposit, and authorization and deposit messages support sending the reconciliationID. CyberSource generates a reconciliationID during authorization, so as a result, there can be more than one reconciliationID associated with the deposit. The supported size of the reconciliationID varies based on the credit card processor. You need to confirm that the credit card processor used supports the length and attributes of the invoice number or alternate order number. It is possible that the reconciliationID from Order Administration may not be unique in CyberSource if, for example, you have multiple companies. In the case of an authorization + deposit request, the reconciliationID is included in both the ccAuthService node as well as the ccCaptureService node. Otherwise, it is included only in the ccCaptureService node.

Instructions:

1. At the First Create Authorization Services Screen, enter the Service Code, Application, Merchant ID, Charge description and any other information required by the account provider.

2. Select OK to advance to the Second Create Authorization Service Screen.

3. Continue entering all necessary information to set up the account provider on your system.

Work with External Authorization Service Screen

Purpose: The purpose of the external authorization service screen is to configure the communication to an external Payment Service Provider (PSP) for card-based payment processing when you want to create a direct integration as part of your implementation project.

Use EFTConnect to integrate with Account Providers, such as CyberSource and Adyen. See the Payment Configurations option in Modern View for more information.

If your payment service provider would like a published offering with Order Management Suite Cloud Service leveraging the EFTConnect OPI integration, submit an enhancement request to Oracle for next steps.

For more information: See the External Payment Service section of the Order Administration Cloud Service Web Services Guide on My Oracle Support for more information on this interface.  

EFTConnect required: The EFTConnect Payment Form is required for adding or replacing an external service payment method through Modern View Order Entry, Order Edit, Customer Membership and Rejected Deposits.  This Payment Form will collect the required payment card data, and EFTConnect will return a Form Token to Order Administration for subsequent authorizations, deposits and refunds with the external payment service.  See the EFTConnect Custom Core Implementation Reference Paper on My Oracle Support for more information on this implementation.

Required settings before you begin: Before you use the External Payment Service, the following configuration is required for communicating to the EFTConnect Payment Form:

• Properties: Configure the following properties in Work with Admin Properties (CPRP):

  • ELO_CONFIG_URL: Used to establish a connection with EFTConnect.

  • ELO_PAYMENT_URL: Defines the URL to use for any transactional communication with EFTConnect Payment Form.

  • ELO_THRESHOLD_TIME: Used for logging purposes. Compares the elapsed time of the web service with the ELO_THRESHOLD_TIME. If the elapsed time exceeds the threshold, a message is logged.

  • ELO_TIMEOUT: Defines the number of milliseconds to wait before requests from Order Administration to EFTConnect time out.

Note:

All fields are required, with the exception of the External Service flag.

Field	Description
External Service	Select this field to have request messages generated for the External Payment Service.
External URL Prefix	The prefix that forms the beginning of the URL where messages are sent. Must begin with HTTPS. The message type defines the suffix that is appended to the prefix to create the entire URL. For example, for a credit card authorization request, the entire URL might be https://remote.auth.com:1234/authorization, where remote.auth.com is the remote server, 1234 is the port, and authorization identifies an authorization request. The following endpoints are supported: balanceInquiry authorization reversal getToken generateGift activateGift rechargeGift deposit return Alphanumeric, 600 positions; required if the External Service flag is selected.
Message Version	Indicates which message version is used when integrating with an external payment service provider. Defaults to the latest version when creating a new service.
Authentication User	The user ID for authentication of the messages to the external service. Alphanumeric, 256 positions; required if the External Service flag is selected.
Authentication Password	The password for authentication of the messages to the external service. Must be at least 6 positions long, include both numbers and letters, include a special character, and cannot end with a number. Alphanumeric, 256 positions; required if the External Service flag is selected.

Defining Authorization Service Countries

Purpose: Each account provider that your company uses may assign its own country codes to the various credit card payment methods. These country codes may differ from the country codes your company uses.

The Authorization Service Country function is used to cross reference the country codes your company uses with the country codes the authorization and deposit service uses. By cross referencing the country codes:

• You can use your country codes when entering orders.

• The country code the account provider uses can be included in the Authorization and Deposit transactions that are transmitted to the account provider.

• When you create the country cross-reference, you can also indicate whether the account provider performs address verification for the country.

Note:

Use this option if you are sending transactions to the account provider using a point-to-point integration.

Authorization service country required for double-byte customer address: If the customer’s address uses a double-byte language, such as Chinese, you need to set up an authorization service country record to support address verification.

In this topic:

• Work with Authorization Service Country Screen

• Create Authorization Service Country Screen

Work with Authorization Service Country Screen

Purpose: This screen displays the country cross references currently defined for the account provider. Use this screen to create, change, or delete the country cross reference information for an External Payment Service or EFTConnect account provider

The country codes your company uses are defined in the Country table; the country codes the account provider uses are provided by the account provider.

How to display this screen: At the Work with Authorization Service Country Screen, select Country for the account provider.

Field	Description
Authorization service	The code and description of the account provider for which you are defining a country cross reference. Code: Alphanumeric, 3 positions; display-only. Description: Alphanumeric, 30 positions; display-only.
Country	A code you use to identify a country. Country codes are defined in and validated against the Country table; see Setting Up the Country Table (WCTY). Alphanumeric, 3 positions; optional.
Authorization Service Country	The code the account provider uses to identify a country. Vendor country codes are provided by the account provider. Alphanumeric, 3 positions; optional.
AVS	Defines whether the account provider performs address verification for the country. N = The account provider does not perform address verification for the country. Y = The account provider performs address verification for the country. Alphanumeric, 1 position; display-only.

Option	Procedure
Create a country cross reference	Select Create to advance to the Create Authorization Service Country Screen.
Change a country cross reference	Select Change for the country cross reference to advance to the Change Authorization Service Country screen. At this screen you can change the Authorization service country and the Address verification setting. See the Create Authorization Service Country Screen for field descriptions.
Delete a country cross reference	Select Delete for the country cross reference to delete it.

Create Authorization Service Country Screen

Purpose: Use this screen to cross reference the country codes your company uses with the codes the account provider uses. For example, your company may use country code USA to identify the United States of America, whereas the account provider may use country code US.

The country codes your company uses are defined in the Country table; the country codes the account provider uses are provided by the account provider.

How to display this screen: Select Create at the Work with Authorization Service Country Screen.

Field	Description
Authorization service	The code and description of the account provider for which you are defining a country cross reference. Code: Alphanumeric, 3 positions; display-only. Description: Alphanumeric, 30 positions; display-only.
Country	A code you use to identify a country. Country codes are defined in and validated against the Country table; see Setting Up the Country Table (WCTY). Alphanumeric, 3 positions. Create screen: required. Change screen: display-only.
Authorization service country	The code the account provider uses to identify a country. Vendor country codes are provided by the account provider. Note: EFTConnect requires a 2-character ISO country code. Alphanumeric, 3 positions; required.
Address verification	Defines whether the account provider performs address verification for the country. Not used by EFTConnect. Unselected = The account provider does not perform address verification for the country. Selected = The account provider performs address verification for the country.

Defining Vendor Paytype Codes

Purpose: Each account provider that your company uses may assign its own paytype codes to the various credit card payment methods. These paytype codes may differ from the paytype codes your company uses. For example, the account provider may use paytype code 01 to represent payment by Visa, whereas, your company may use paytype code 04 to identify payment by Visa.

The Vendor Paytype Codes function is used to cross reference the paytype codes your company uses with the paytype codes the authorization service uses. By cross referencing the paytype codes:

• you can use your paytype codes when entering orders

• the paytype code the account provider uses can be included in the Authorization and Deposit transactions that are transmitted to the account provider.

In this topic:

• Work with Paytype Cross Reference Screen

• Create CC Paytype Cross Reference Screen

Work with Paytype Cross Reference Screen

Purpose: This screen displays the pay type cross references currently defined for the account provider. Use this screen to create, change, delete, or display the pay type cross reference information.

The pay type codes your company uses are defined in the Pay Type table; the pay type codes the account provider uses are provided by the account provider.

How to display this screen: At the Work with Authorization Services Screen, select Paytypes for the account provider.

Field	Description
Pay type	A code you use to identify a method of payment on an order. Pay type codes are defined in the Pay Type table; see Working with Pay Types (WPAY). Numeric, 2 positions; optional.
Vendor pay code	The code the authorization service uses to identify a method of payment.  Vendor pay type codes are provided by the account provider.   Alphanumeric, 5 positions; optional.
Authorization Merchant #	The merchant number to use when sending authorization requests for this pay type code to the account provider for approval.  The merchant number is assigned to your company by the account provider.    Alphanumeric, 10 positions; optional.
Deposit merchant # (Deposit merchant number)	The merchant number to use when sending deposit requests for this pay type code to the account provider for settlement.  The merchant number is assigned to your company by the account provider.    Alphanumeric, 10 positions; optional.

Option	Procedure
Create a paytype cross reference	Select Create to advance to the Create CC Paytype Cross Reference Screen for the account provider.
Change a paytype cross reference	Select Change for the pay type cross reference you want to change to advance to the Change Paytype Cross Reference Screen. At this screen you can change any information except the Authorization service and the Pay type code. See the Create CC Paytype Cross Reference Screen for field descriptions.
Delete a paytype cross reference	Select Delete for the pay type cross reference you want to delete.
Display a paytype cross reference	Select Display for the pay type cross reference you want to display to advance to the Display CC Paytype Cross Reference Screen. You cannot change any information at this screen. See the Create CC Paytype Cross Reference Screen for field descriptions.

Create CC Paytype Cross Reference Screen

Purpose: Use this screen to cross reference the pay type codes your company uses with the codes the account provider uses.  For example, your company may use pay type code 4 to identify payment by Visa, whereas the account provider may use pay type code 1.

The pay type codes your company uses are defined in the Pay Type table; the pay type codes the account provider uses are provided by the account provider.

How to display this screen: Select Create at the Work with Paytype Cross Reference Screen.

Field	Description
Pay type	The code you use to identify a method of payment on an order. Pay type codes are defined in the Pay Type table; see Working with Pay Types (WPAY). Numeric, 2 positions. Create screen: required. Change screen: display-only.
Vendor paytype/code	The code the account provider uses to identify a method of payment.  Vendor pay type codes are provided by the account provider. Alphanumeric, 5 positions; required.
Authorization merchant #	The merchant number to use when sending authorization requests for this pay type code to the account provider for approval.  The merchant number is assigned to your company by the account provider. Alphanumeric, 10 positions; optional.
Deposit merchant #	The merchant number to use when sending deposit requests for this pay type code to the account provider for settlement.  The merchant number is assigned to your company by the account provider. Alphanumeric, 10 positions; optional.

Instructions:

1. Enter the pay type code you company uses to identify the payment method in the Pay type field.

2. Enter the corresponding pay type code the account provider uses to identify the payment method in the Vendor pay code.

3. Optionally, enter the authorization and deposit merchant numbers assigned to your company by the account provider in the Authorization Merchant # and the Deposit merchant # (Deposit merchant number) fields.

4. Your entries are cleared from the screen and a message similar to the following displays: CC Vendor Paytype Cross Reference (NAB - 5) created.

Defining Vendor Response Codes

Vendor response codes identify the reasons that the account provider approves (authorizes) or declines a credit card charge or deposit. The codes are assigned to each transaction by the account provider when approving or declining the request.

You should define each code for each account provider you work with.

The system allows you to set up the following instructions for vendor response codes:

• how many times to attempt authorization for this response

• whether to put the order on hold and, if so, for how long

• whether to flag the order for cancellation

EFTConnect generic response code: EFTConnect generic message response and AVS reason codes are automatically created when setting up a new EFTConnect Merchant Account through the Payment Configurations option in Modern View. Additional details, such as hold codes and messaging, will need to be configured. See EFTConnect Response Code Table for a full list.

Online credit card authorizations: If you are sending store value card or card tokens for authorization during order entry and edit (the On-line Authorizations (B89) system control value is selected), the system displays additional fields where you can enter a message indicating whether the card was approved or declined and if any action should be taken, such as asking the customer to repeat the card number or requesting a different card for authorization. If you define a message, the system displays the message when a response is received from the account provider. This window displays the pop up window messages you defined for this vendor response. See Performing Online Credit Card Authorizations for an overview on online authorizations and the required setup.

Credit card decline email: If you specify a program in the Credit Card Decline Email Program (K53) system control value, the batch authorization process in pick slip generation generates an email to the customer when an order is placed on hold due to a credit card decline. See that system control value for more information.

In this topic:

• Entity Setup

• Vendor Response Setup Examples

• About Deposits

• Work with Vendor Response Screen

  • Create Vendor Response Screen

• Select Entity for Vendor Response Details Screen

• Work with Ship Via $ Limit to Hold Screen

  • Create Ship Via $ Limit to Hold Screen

• Work with Pay Type $ Limit to Force Authorization Screen

  • Create Pay Type $ Limit to Force Authorization Screen

• Work with Item Class $ Limit to Hold Screen

• Create Item Class $ Limit to Hold Screen

• Change Item Class $ Limit to Hold Screen

• Display Item Class $ Limit to Hold Screen

• Work with Postal Code $ Limit to Hold Screen

• Create Postal Code $ Limit to Hold Screen

• Change Postal Code $ Limit to Hold Screen

• Display Postal Code $ Limit to Hold Screen

Defining Vendor Response Codes

Entity Setup

Additionally, you can set up the following instructions for a vendor response code for each entity in your company:

• Whether a dollar limit is applied to the ship via on the order. If the authorization amount is less than the ship via dollar limit, the system releases the order from any AVS hold. If the authorization amount is greater than the ship via dollar limit, the system places the order on hold using the hold reason defined for the ship via dollar limit. See Entity ship via dollar limits.

• Whether a dollar limit to force an authorization is applied to a specific pay type. See Entity pay type dollar limits.

• Whether a dollar limit is applied to the item class associated with an item on the order that requires authorization. If the authorization amount is less than the item class dollar limit, the system releases the order from any AVS hold. If the authorization is greater than the item class dollar limit, the system places the order on hold using the hold reason defined for the item class dollar limit. See Entity item class dollar limits.

• Whether a dollar limit is applied to the postal code for the bill to or sold to customer on the order. If the authorization amount is less than the postal code dollar limit, the system releases the order from any AVS hold. If the authorization amount is greater than the postal code dollar limit, the system places the order on hold using the hold reason defined for the postal code dollar limit. See Entity postal code dollar limits.

Online authorization: If you are performing online authorization, the system does not evaluate the order for entity pay type dollar limit or entity ship via dollar limit; however, the system will evaluate the order for item class dollar limit and postal code dollar limit.

Entity dollar limit hierarchy: The system uses the following hierarchy when evaluating whether the order meets an entity dollar limit.

1. Evaluate the order for Entity pay type dollar limits.

2. If the order does not qualify for entity pay type dollar limits, evaluate the order for Entity ship via dollar limits.

3. If the order does not qualify for entity ship via dollar limits, evaluate the order for Entity item class dollar limits.

4. If the order does not qualify for entity item class dollar limits, evaluate the order for Entity postal code dollar limits.

If an order qualifies for more than one of the entity dollar limits, the system holds/releases the order using the last entity dollar limit that qualifies. For example, if the order qualifies for both entity ship via dollar limit and entity postal code dollar limit, the system holds or releases the order based on the entity postal code dollar limit setup.

Entity ship via dollar limits

You can set up a ship via dollar limit for an AVS response for each entity in your company. You can use the ship via dollar limit to reduce the amount of fraud. For example, a credit card may receive an AVS response of “all address matching,” but you may want to perform an additional check against the ship via assigned to the order and the dollar amount that requires authorization.

• If the authorization amount is less than the ship via dollar limit, the system releases the order from any AVS hold.

• If the authorization amount is greater than the ship via dollar limit and the sold to customer and ship to customer are different, the system places the order on hold using the hold reason defined for the ship via dollar limit.

The system checks the following information to determine if an order should go on hold due to a ship via dollar limit:

• the account provider code

• the AVS response code received from the account provider

• the Entity associated with the order

• the Ship via code on the order header

• the $ limit to hold on the order

• the sold to customer and ship to customer are different

• The Use Credit Card Vendor Response Entity Ship Via Dollar Limits (F94) system control value is selected. If this system control value is not selected, the system does not perform an edit against the ship via dollar limit for an AVS response to determine if an order should go on hold.

The system does not evaluate the order for ship via dollar limit if:

• The order does not pass authorization, regardless of whether the ship to customer is different than the sold to customer.

• You are performing online authorization.

Entity ship via dollar limit summary: 

AVS response	Entity $ limit	Auth amount less than entity $ limit	Auth amount greater than or equal to entity $ limit
hold reason	no hold reason	The system releases the order from AVS hold. Order transaction history message: AVS HLD Release - Entity Via $Limit.	The system places the order on hold, using the hold reason defined for the AVS response. Order transaction history message: SYS HLD - Declined Credit Card.
no hold reason	hold reason	The system does not place the order on hold.	The system places the order on hold, using the hold reason defined for the entity ship via dollar limit. Order transaction history message: SYS HLD - Declined Credit Card.
no hold reason	no hold reason	The system does not place the order on hold.	The system does not place the order on hold.
hold reason	hold reason	The system releases the order from AVS hold. Order transaction history message: AVS HLD Release - Entity Via $Limit.	The system places the order on hold, using the hold reason defined for the entity ship via dollar limit. Order transaction history message: SYS HLD - Declined Credit Card.

Ship via dollar limit example: The following is an example of how to set up a ship via dollar limit for an AVS response code.

AVS Response	Description	Hold Reason Code
I3	All Address Matching	None

The following is an example of how to set up ship via dollar limit hold values:

AVS Response	Entity	Ship Via	$ Limit	Hold Reason Code
I3	555	1	$50.00	J3
I3	555	2	$75.00	J4
I3	555	3	$150.00	J5

Using the example, if an order passed AVS because it received an AVS response of I3, all address matching, the system would then perform an edit against the ship via dollar limit defined for the response.

If a ship via dollar limit was defined for the entity associated with the order, the ship via defined on the order, and the dollar amount on the order that required authorization was greater than the dollar limit defined for the AVS response, the order would then be placed on hold, using the hold reason code defined for the ship via dollar limit.

Using the example, the system would assign the hold reason code J3 to an order if the order was associated with entity 555, ship via code 1, and the dollar amount that required authorization was greater than $50.00.

Entity pay type dollar limits

You can set up a pay type dollar limit for a vendor response for each entity in your company. You can use the pay type dollar limit to force authorizations that have been declined.

Example: If a credit card received a vendor response of "credit card exceeds limit", you may want to force the authorization through anyway if the dollar amount that requires authorization is less than $50.00.

If you set up a pay type dollar limit, the order receives a forced authorization if:

• the credit card on the order is declined, and

• the dollar amount that requires authorization is greater than $1.00 and is less than the pay type dollar limit you have set up for the credit card pay type on the order. Note: If you wish to force authorizations for credit cards requiring authorizations less than $1.00, enter an authorization number in the Authorization Number for Authorizations Under $1.00 (I08) system control value.

In this situation, the order receives a forced authorization, and the system writes the Default Credit Card Authorization Number for Soft Declines (F93) to the Authorization number field on the Authorization History record. The system processes the authorization through Order Administration, as if the number that defaulted from the system control value was an actual authorization number. The order will be processed through pick slip generation and the system will produce pick slips for the order. The system also writes an order transaction history message indicating the authorization was forced.

If the Default Credit Card Authorization Number for Soft Declines (F93) system control value is blank, the order is placed on hold, using the vendor response hold reason code. If the hold reason code for the vendor response is blank, or a hold reason code has not been defined for the vendor response, the order is not placed on hold, and is processed through pick slip generation.

Note:

The system may still place the order on hold if it fails AVS authorization.

The system checks the following information to determine if an order should receive a forced authorization after it has been declined:

• the account provider code

• the Vendor response code received from the account provider

• the Entity associated with the order

• the credit card Pay type on the order that requires authorization

The system does not evaluate the order for pay type dollar limit if you are performing online authorization.

Note:

The system performs an edit against the pay type dollar limit defined for a vendor response before the number of authorization attempts logic. If the order passes the pay type dollar limit edit, the system does not perform the number of attempts edit against the order. 

Entity pay type dollar limit summary: 

Vendor response	Auth amount less than entity $ limit to force auth	Auth amount greater than or equal to entity $ limit to force auth
hold reason	The system does not place the order on hold. Order transaction history message: System Forced CC Auth - Auth# 999999.	The system places the order on hold, using the hold reason defined for the vendor response. Order transaction history message: SYS HLD - Declined Credit Card.

Pay type dollar limit example: This example shows how to set up a pay type dollar limit for a vendor response code.

Vendor Response	Description	Hold Reason Code
Vendor Response Value:
42	Declined, card over limit	H4

Vendor Response	Entity	Pay Type	Dollar Limit
Pay Type Dollar Limit Values:
42	555	4 VISA	$50.00
42	555	5 MASTERCARD	$75.00

Using the example, if an order did not pass authorization because it received a vendor response of 42, declined card over limit, the system would then perform an edit against the pay type dollar limit defined for the response.

If a pay type dollar limit was defined for the entity associated with the order, the pay type defined on the order, and the dollar amount on the order that required authorization was less than the dollar limit defined for the vendor response, the order would receive a forced authorization, using the Default Credit Card Authorization Number for Soft Declines (F93).

Using the example, an order would receive a forced authorization if the pay type on the order was VISA and the dollar amount for the VISA card was under $50.00.

Entity item class dollar limits

You can set up an item class dollar limit for an AVS response for each entity in your company. You can use the item class dollar limit to reduce the amount of fraud. For example, a credit card may receive an AVS response of “all address matching”, but you may want to perform an additional check against the item class (such as high-theft items) assigned to one or more of the items on the order and the dollar amount that requires authorization.

• If the authorization amount is less than the item class dollar limit, the system releases the order from any AVS hold.

• If the authorization is greater than the item class dollar limit, the system places the order on hold using the hold reason defined for the item class dollar limit.

The system checks the following information to determine if an order should go on hold due to an item class dollar limit:

• the account provider code

• the AVS response code received from the account provider

• the Entity associated with the order

• the $ limit to hold on the order

• the item class assigned to one or more of the items on the order requesting authorization

Note:

• The item(s) assigned to the item class must be requesting authorization. For example, if the item assigned to the item class is on backorder, the other items on the order requesting authorization will not qualify for the item class dollar limit.

• If more than one item class on the order qualifies for an item class dollar limit, the system uses the item class associated with the lowest order number. For example, if order line 1 is associated with item class PNT and order line 3 is associated with item class ELC and both qualify, the system uses the item class dollar limit defined for item class PNT.

The system does not evaluate the order for item class dollar limit if the order does not pass authorization.

Entity item class dollar limit summary: 

AVS response	Entity $ limit	Auth amount less than entity $ limit	Auth amount greater than or equal to entity $ limit
hold reason	no hold reason	The system releases the order from AVS hold. Order transaction history message: AVS HLD Release - Item Class $Limit.	The system places the order on hold, using the hold reason defined for the AVS response. Order transaction history message: SYS HLD - Declined Credit Card.
no hold reason	hold reason	The system does not place the order on hold.	The system places the order on hold, using the hold reason defined for the entity item class dollar limit. Order transaction history message: SYS HLD - Declined Credit Card.
no hold reason	no hold reason	The system does not place the order on hold.	The system does not place the order on hold.
hold reason	hold reason	The system releases the order from AVS hold. Order transaction history message: AVS HLD Release - Item Class $Limit.	The system places the order on hold, using the hold reason defined for the entity item class dollar limit. Order transaction history message: SYS HLD - Declined Credit Card.

Item class dollar limit example: The following is an example of how to set up an item class dollar limit for an AVS response code.

AVS Response	Description	Hold Reason Code
I3	All Address Matching	None

Item class dollar limit to hold example:

AVS Response	Entity	Item Class	Dollar Limit	Hold Reason Code
I3	555	ELC	$50.00	C1
I3	555	PNT	$75.00	C2
I3	555	ZBA	$150.00	C3

Using the example, if an order passed AVS because it received an AVS response of I3, all address matching, the system would then perform an edit against the item class dollar limit defined for the response.

If an item class dollar limit was defined for the entity associated with the order, the item class assigned to at least one of the items on the order requiring authorization, and the dollar amount on the order that required authorization is equal to or greater than the dollar limit defined for the AVS response, the order would then be placed on hold, using the hold reason code defined for the item class dollar limit.

Using the example, the system would assign the hold reason code C1 to an order if the order was associated with entity 555, item class ELC, and the dollar amount that required authorization was equal to or greater than $50.00.

Entity postal code dollar limits

You can set up a postal code dollar limit for an AVS response for each entity in your company. You can use the postal code dollar limit to reduce the amount of fraud. For example, a credit card may receive an AVS response of “All Address Match”, but you may want to perform an additional check against the postal code assigned to the bill to or sold to customer on the order and the dollar amount that requires authorization.

• If the authorization amount is less than the postal code dollar limit, the system releases the order from any AVS hold.

• If the authorization amount is greater than the postal code dollar limit, the system places the order on hold using the hold reason defined for the postal code dollar limit.

The system checks the following information to determine if an order should go on hold due to a postal code dollar limit:

• the account provider code

• the AVS response code received from the account provider

• the Entity associated with the order

• the postal code for the bill to customer on the order; if a bill to customer is not defined, the system validates the postal code for the sold to customer on the order

• the $ limit to hold on the order

The system does not place the order on postal code dollar limit hold if the order does not pass authorization.

Entity postal code dollar limit summary: 

AVS response	Entity $ limit	Auth amount less than entity $ limit	Auth amount greater than or equal to entity $ limit
hold reason	no hold reason	The system releases the order from AVS hold. Order transaction history message: AVS HLD Release - Postal Code $Limit.	The system places the order on hold, using the hold reason defined for the AVS response. Order transaction history message: SYS HLD - Declined Credit Card.
no hold reason	hold reason	The system does not place the order on hold.	The system places the order on hold, using the hold reason defined for the entity postal code dollar limit. Order transaction history message: SYS HLD - Declined Credit Card.
no hold reason	no hold reason	The system does not place the order on hold.	The system does not place the order on hold.
hold reason	hold reason	The system releases the order from AVS hold. Order transaction history message: AVS HLD Release - Postal Code $Limit.	The system places the order on hold, using the hold reason defined for the entity postal code dollar limit. Order transaction history message: SYS HLD - Declined Credit Card.

Postal code dollar limit example: The following is an example of how to set up a postal code dollar limit for an AVS response code.

AVS Response	Description	Hold Reason Code
I3	All Address Matching	None

Postal code dollar limit to hold example:

AVS Response	Entity	Postal code	Dollar Limit	Hold Reason Code
I3	555	01468	$50.00	P1
I3	555	01701	$75.00	P2
I3	555	02053	$150.00	P3

Using the example, if an order passed AVS because it received an AVS response of I3, all address matching, the system would then perform an edit against the postal code dollar limit defined for the response.

If a postal code dollar limit was defined for the entity associated with the order, the postal code assigned to the sold to, and the dollar amount on the order that required authorization is equal to or greater than the dollar limit defined for the AVS response, the order would then be placed on hold, using the hold reason code defined for the postal code dollar limit.

Using the example, the system would assign the hold reason code P1 to an order if the order was associated with entity 555, postal code 01468, and the dollar amount that required authorization was equal to or greater than $50.00.

Vendor Response Setup Examples

Examples of different vendor responses, and how you might set them up on the system for credit card authorization before shipment, are:

Stolen credit card:

• do not reattempt authorization

• put the order on CF (credit card fraud) hold

• flag the order for cancellation

Over credit limit:

• put the order on hold for 5 days before reattempting authorization

• flag the order for cancellation after a number of declined authorizations

Transmission error:

• do not put the order on hold; reattempt authorization immediately

Address verification failed:

• do not reattempt authorization

• put the order on AV (address verification) hold

Card security value should be on the credit card:

• do not reattempt authorization

• put the order on CF (credit card fraud) hold

Note:

A pick slip will not print if the authorization is declined or if the order is on hold.

Determining the maximum number of declines: The system counts the number of declines for each different vendor response code separately.  For example, if an authorization is declined twice for a transmission error, and is then declined for exceeding a credit limit, the counter starts again at 1 the first time you receive the new vendor response code.  

The Maximum Number of Retries on Credit Card Orders (E74) system control value specifies the maximum number of all declines (with any vendor response that represents a decline) an order can accumulate before being flagged for cancellation.   This value overrides the limit you specify for an individual vendor response. Be sure to set this system control value high enough that you do not inadvertently flag on order for cancellation when it still might be eligible for authorization.

Releasing held orders: The Release Orders on Time Hold periodic function evaluates held credit card orders for release based on their hold dates. See Releasing Orders from Time Hold.

You can also use the Release Held Orders menu option to release orders one at a time. See Manage Held Orders in Modern View online help.

Canceling orders: You can use the Working with Credit Card Cancellations (WCCC) menu option to cancel all orders flagged for cancellation automatically.   You can also set up this function as part of your periodic process.

About Deposits

Response codes may be used both for credit card authorizations and deposit authorizations.  Typically, you would need to authorize a deposit because the order is using deferred or installment billing, and so you would not have a current authorization for the amount of the deposit you are processing.

The system does not perform the same types of actions against the order for a deposit authorization as it does for other authorizations. Specifically, the system does not reference the following fields (defined at the Create Vendor Response Screen) when processing an authorization for a deposit:

• Hold reason

• of authorization attempts

• of days between attempts

• Cancel reason

• Letter type

Similarly, the Maximum Number of Retries on Credit Card Orders (E74) system control value does not play a role in authorizing deposits.

Force deposit: You can set a vendor response code to “force deposit” in your company when you receive this response code from the deposit service. To do so, select the Force deposit for FPO flag for the response code. Forcing deposit means that you process all of the same updates in your company as if you had received an approval for the authorization.

Regular (non-payment plan) deposits are always forced.

Note:

You must make your own arrangements with the account provider regarding how to deal with unconfirmed or rejected deposit transactions.

The system checks the setting of this "force deposit" flag only when:

• you process a deposit for a deferred or installment pay plan

• the account provider supports force deposit

• the authorization is declined (that is, the response code is not 100)

• the system submitted the transaction with an action code of B (obtain both an authorization and deposit) rather than D (deposit only)

If you don't force: When a payment plan deposit fails authorization and is not forced, the deposit appears on the Unconfirmed Deposits Listing Report. You can use Manage Rejected Deposits in Modern view to work with these deposits. Additionally, the order is placed on hold, and any orders that match the sold to customer and/or the credit card number are placed on hold as well.

More information:

• Deferred/Installment Billing Overview 

• Processing Auto Deposits (SDEP) 

Work with Vendor Response Screen

Purpose: This screen displays the response codes currently defined for the account provider. Use this screen to add, delete, or change a response code for the account provider.

You must create a vendor response code for each code used by the account provider. If the system receives a vendor response code it does not recognize, it puts the order on AVS hold.

EFTConnect: When creating an EFTConnect Merchant Account in the Payment Configuration option in Modern View, the EFTConnect response codes will created automatically by the system. CyberSource and Adyen are mapped to each of the EFTConnect response codes. Navigate to the Vendor Responses screen in Work with Authorization Services to configure the fields. It is recommended to not delete these response codes, however they can be re-added if needed. See the EFTConnect xxxx for a list of response codes.

PayPal: See the PayPal Direct Connection Integration for required response codes.

Customer Engagement Stored Value Card: See Stored Value Card Integration for a list of response codes.

How to display this screen: Select Responses for the account provider at the Work with Authorization Services Screen 

Field	Description
Response code	The code assigned by the account provider that identifies whether the credit card was authorized or declined, and the reason for the authorization or decline. Alphanumeric, 10 positions; optional.
Description	The description of the response code.   Alphanumeric, up to 40 positions; optional.

Option	Procedure
Change a vendor response code	Select Change for a response code to advance to the Change Vendor Response Screen. At this screen you can change any information except the Authorization service code and the Response code. See the Create Vendor Response Screen for field descriptions.
Delete a vendor response code	Select Delete for a response code to delete it.
Display a vendor response code	Select Display for a response code to advance to the Display Vendor Response Screen. You cannot change any information at this screen. See the Create Vendor Response Screen for field descriptions.
Work with ship via dollar limits and pay type dollar limits for a vendor response code	Select Response/Entity Details for a response code to advance to the Work with Ship Via $ Limit to Hold Screen.
Create a vendor response code	Select Create to advance to the Create Vendor Response Screen.

Create Vendor Response Screen

Purpose: Use this screen to define the response codes that the account provider uses to indicate the disposition of the authorization, and how the system should then handle the order.

How to display this screen: Select Create at the Work with Vendor Response Screen 

Field	Description
Response code	The code assigned by the account provider to identify whether the credit card was authorized or declined, and the reason for the authorization or decline. You should define each code used by the account provider on the system. If the account provider returns a response that the system does not recognize, the order appears on the Credit Card Authorization Listing as DECLINED (no description will appear) and is put on AVS hold; you must release the order through the Release Held Orders menu option, described in Manage Held Orders in Modern View online help. Deposits: See About Deposits for an example of how response codes may be used during deposits processing. Note:  The INSUFFICIENT_FUNDS response code for the RLT authorization service (WASV) must be assigned a hold reason code of SV. Alphanumeric, 10 positions. Create screen: required. Change screen: display-only.
ORCE response	The code assigned by the Oracle Retail Customer Engagement account provider to identify whether the stored value card transaction was approved or declined. Use this field to map a response from Oracle Retail Customer Engagement to a vendor response code. This field displays only if the Authorization service code for the account provider is RLT. See Customer Engagement Stored Value Card Integration. Alphanumeric, 60 positions. Create screen: optional. Change screen: display-only.
Description 1	The description of the response code. You can use the description provided by the account provider or you can use your own description.    Both lines of the description appear on the Credit Card Authorization Listing. You can also review it in standard order inquiry at the Authorization History Details Window. Deposits:  The first line only of the response code description displays on the Display Deposit History Detail Screen in standard order inquiry when the account provider uses this response code for a deposit authorization. Alphanumeric, 100 positions; required.
Description 2	An additional description for the response code.   Alphanumeric, 100 positions; optional.
Hold reason	The hold code to use for orders receiving this response. This a paytype-level hold; the order will be put on AT hold. The hold reason you enter here displays on the Credit Card Order Cancellation List when you process cancellations, so you can use this field as a description of the vendor response for that report. No pick slip prints if the order is placed on hold.   If you assign a Hold date to the order (by completing the # of days between attempts field) you can release the order through the Release Orders on Time Hold periodic function. If not, you must use the Release Held Orders or Manual Credit Card Authorization function to release the order. Leave the Hold field blank if orders with this response code should not be placed on hold. Hold reason codes are defined in and validated against the Order Hold Reason table; see Establishing Order Hold Reason Codes (WOHR). Deposits: The system does not reference this field when processing an authorization for a deposit. See About Deposits. Alphanumeric, 2 positions; optional.
# authorization attempts (Number of authorization attempts)	The number of times to attempt to authorize an order before flagging it for cancellation.  This field defines the number of attempts for this response code only; if the vendor returns a different response code, the count begins again at one. Enter 1 in this field if you want to flag an order for cancellation immediately.  If this value is set to more than one, the system will continue to resubmit the order for authorization until the value is reached, provided the order is not held. The Maximum Number of Retries on Credit Card Orders (E74) system control value overrides this limit if it is lower than the maximum specified for a given response code. This system control value will also override the limit for a response code if the combined total authorization attempts for all responses on an order meets the maximum defined in the System Control table. Leave this field blank if you want to the system to continue to attempt authorization indefinitely (however, the system control value described above will override a blank value). Deposits: The system does not reference this field when processing an authorization for a deposit. See About Deposits. Online credit card authorization: The system does not reference this field when processing an online credit card authorizations. Numeric, 2 positions; optional.
# of days between attempts	The number of days to add to the current date when calculating a Hold until date for an order.   Example:  If the current date is 7/15, and this field is set to 5, the system assigns a Hold until date of 7/20. If you leave this field blank and: if the Hold reason field is also blank, the system will repeatedly submit the order for reauthorization until the Number of authorization attempts is reached; if you have defined a Hold reason, the system will never submit the order for reauthorization repeatedly (for example, if the order is flagged for cancellation; see Cancel reason). The Release Orders on Time Hold periodic function releases an order from hold once the Hold date is reached. See Releasing Orders from Time Hold. Deposits:  The system does not reference this field when processing an authorization for a deposit. See About Deposits. Online credit card authorization: The system does not reference this field when processing an online credit card authorization. Numeric, 2 positions; optional.
Cancel reason	The cancel reason to use when an order has reached the # authorization attempts (Number of authorization attempts), or in the number in the system control value (whichever is lower). As part of this process, the order is flagged for cancellation; you use the Working with Credit Card Cancellations (WCCC) option to cancel such orders. You can also set this function up as part of your periodic processing. If an order becomes eligible for cancellation because its total number of authorization attempts meet the maximum defined in the System Control table, the system uses the cancellation code associated with the most recently received vendor response. Cancel reason codes are defined in and validated against the Cancel Reason Code table; see Establishing Cancel Reason Codes (WCNR). Deposits: The system does not reference this field when processing an authorization for a deposit. See About Deposits. Online credit card authorization: The system does not reference this field when processing an online credit card authorization. Numeric, 2 positions; optional (required if you enter a value in the # authorization attempts field).
Force deposit for FPO	Indicates whether to process all the usual updates for a deposit when you receive this response code from the account provider, even though this response code actually represents a decline. Selected = force deposit Unselected (default) = Do not force deposit About Deposits
Pop up window messages (online authorization messages)	Four additional fields where you can enter a message indicating whether the credit card is approved or declined and if any action should be taken, such as asking the customer to repeat the credit card number or requesting a different credit card for authorization. Note:  These fields only display if the On-line Authorizations (B89) system control value is selected and the Batch/online field for the account provider is set to I (online authorization only) or C (online and batch authorization). If you are sending credit cards for authorization during order entry (the On-line Authorizations (B89) system control value is selected), the system displays the  Select Authorization Response Option Window in order entry when a response is received from the account provider. This window displays the pop up window messages you defined for this vendor response. See Performing Online Credit Card Authorizations for an overview on online authorizations and the required setup. Alphanumeric, four 40-positions fields; optional.

Select Entity for Vendor Response Details Screen

Purpose: Use this screen to define more information for a vendor response for each entity in your company.  At this screen you can:

• define a ship via dollar limit for an AVS response code to perform an additional edit against the authorization amount if the ship via on the order matches a ship via dollar limit and the sold to customer and ship to customer are different.

• define a pay type dollar limit to force an authorization for a declined vendor response code.

• define an item class dollar limit for an AVS response code to perform an additional edit against the authorization amount if one or more item(s) on the order requiring authorization has an item class that matches an item class dollar limit.

• define a postal code dollar limit for an AVS response code to perform an additional edit against the authorization amount if the postal code for the sold to on the order matches a postal code dollar limit.

How to display this screen: On the Work with Vendor Response Screen, select Response/Entity Details for a vendor response

Field	Description
Authorization service	The code and description to identify the account provider for which you are working with vendor response details.   This is the account provider you selected at the Work with Authorization Services Screen. Authorization code:  Alphanumeric, 3 positions; display-only. Authorization description:  Alphanumeric, 30 positions; display-only.
Response code	The code and description assigned by the account provider that identifies whether the credit card was authorized or declined, and the reason for the authorization or decline. This is the vendor response you selected on the Work with Vendor Response Screen. For ship via dollar limit, postal code dollar limit, and item class dollar limit, this must be an AVS response code. Pay type dollar limit applies to a vendor response code. Vendor response code:  Alphanumeric, 10 positions; display-only. Vendor response description:  Alphanumeric, 40 positions; display-only.
Entity	A code for the entity for which you wish to create vendor response details.  An entity is a component of the sales reporting hierarchy.  An entity can represent the business units in your company, for example, mail order, retail, wholesale).  A list of all the valid entity records set up for the company you are currently in displays. Entity codes are defined in and validated against the Entity table. See Working with Entities (WENT). Numeric, 3 positions; optional.
Description	A description of the entity. Alphanumeric, 25 positions; optional.

Screen Option	Procedure
Define ship via dollar limits for a specific entity	Select Ship Via $ Limit for an entity to advance to the Work with Ship Via $ Limit to Hold Screen.
Define pay type dollar limits for a specific entity	Select Pay Type $ Limit for an entity to advance to the Work with Pay Type $ Limit to Force Authorization Screen.
Define item class dollar limits for a specific entity	Select Item Class $ Limit for an entity to advance to the Work with Item Class $ Limit to Hold Screen.
Define postal code dollar limits for a specific entity	Select Postal Code $ Limit for an entity to advance to the Work with Postal Code $ Limit to Hold Screen.

Work with Ship Via $ Limit to Hold Screen

Purpose: Use this screen to create and maintain ship via dollar limits for a specific entity, AVS response, and account provider.

Ship via dollar limit defines whether a dollar limit is applied to the ship via on the order.

• If the authorization amount is less than the ship via dollar limit, the system releases the order from any AVS hold.

• If the authorization amount is greater than the ship via dollar limit, the system places the order on hold using the hold reason defined for the ship via dollar limit.

You might use this if you want to keep a careful check for stolen credit cards. For example, you can place an order on hold if the order is associated with a Federal Express ship via and the dollar amount required for authorization is greater than $200.00.

See Entity ship via dollar limits for more information on the processing the system performs.

Note:

If you are performing online authorization, the system does not validate entity ship via dollar limit.

How to display this screen:  Select Ship Via $ Limit for an entity on the Work with Vendor Response Screen

Field	Description
Authorization service	The code and description of the account provider for which you are working with ship via dollar limits. This is the account provider you selected on the Work with Authorization Services Screen. Authorization code:  Alphanumeric, 3 positions; display-only. Authorization description:  Alphanumeric, 30 positions; display-only.
Response code	The code and description assigned by the account provider that identifies whether the credit card passed address verification. This is the AVS response you selected on the Work with Vendor Response Screen. Response code:  Alphanumeric, 10 positions; display-only. Response description:  Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected on the Select Entity for Vendor Response Details Screen. Entity code:  Numeric, 3 positions; display-only. Entity description:  Alphanumeric, 25 positions; display-only.
Ship Via	A code for the carrier you use to ship merchandise.   Ship via codes are defined in and validated against the Ship Via table using Working with Ship Via Codes (WVIA). Numeric, 2 positions; optional.
$ Limit to Hold	The dollar limit that defines when the system places the order on hold. The system places an order on hold when the order meets the account provider/AVS response code/entity/ship via code combination and the dollar amount the requires authorization is greater than the amount defined for the ship via dollar limit. The system assigns the hold reason code defined for the ship via dollar limit to the order. Conversely, if you do not define a hold reason, the system does not place an order on hold if the order does not pass AVS authorization, but is under the ship via dollar amount specified. Numeric, 13 positions with a 2-place decimal; optional.
Hold Reason	The hold reason code to assign to orders whose authorization amount is greater than the ship via dollar limit. Alphanumeric, 2 positions; optional.
Description	A description of the hold reason code. Alphanumeric, 50 positions; optional.

Screen Option	Procedure
Change a ship via dollar limit	Select Change for a ship via dollar limit to hold to advance to the Change Ship Via $ Limit to Hold Screen. At this screen you can change the ship via, dollar limit, and hold reason code. See the Create Ship Via $ Limit to Hold Screen for field descriptions.
Delete a ship via dollar limit	Select Delete for a ship via dollar limit to hold to delete it.
Display a ship via dollar limit	Select Display for a ship via dollar limit to hold to advance to the Display Ship Via $ Limit to Hold Screen. You cannot change any information at this screen. See the Create Ship Via $ Limit to Hold Screen for field descriptions.
Create a ship via dollar limit	Select Create to advance to Create Ship Via $ Limit to Hold Screen.

Create Ship Via $ Limit to Hold Screen

Purpose: Use this screen to create a ship via dollar limit.

How to display this screen: Select Create on the Work with Ship Via $ Limit to Hold Screen.

Field	Description
Authorization service	The code and description of the account provider for which you are creating a ship via dollar limit. This is the account provider you selected on the Work with Authorization Services Screen. Authorization code:  Alphanumeric, 3 positions; display-only. Authorization description:  Alphanumeric, 30 positions; display-only.
Response code	The code and description of the AVS response code assigned by the account provider that identifies whether the credit card pass address verification. This is the AVS response you selected on the Work with Vendor Response Screen. Response code:  Alphanumeric, 10 positions; display-only. Response description:  Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected on the Work with Vendor Response Screen. Entity code:  Numeric, 3 positions; display-only. Entity description:  Alphanumeric, 25 positions; display-only.
Ship via	A code for the carrier you use to ship merchandise.   An error message indicates if you try to create a ship via dollar limit for a ship via that already has a dollar limit defined for this AVS response code and entity: Duplicate record exists. Ship via codes are defined in and validated against the Ship Via table using Working with Ship Via Codes (WVIA). Numeric, 2 positions; optional.
$ limit to hold	The dollar limit that defines when the system places the order on hold. The system places an order on hold when the order meets the account provider/AVS response code/entity/ship via code combination and the dollar amount that requires authorization is greater than the amount defined for the ship via dollar limit. The system assigns the hold reason code defined for the ship via dollar limit to the order. Conversely, if you do not define a dollar limit, the system does not place an order on hold if the order does not pass AVS authorization, but is under the ship via dollar amount specified. An error message indicates if you try to enter a dollar limit that is less than $1.00: Ship Via $ Limit cannot be less than One. Numeric, 13 positions with a 2-place decimal; optional.
Hold reason	A code for the hold reason the system assigns to the order when the authorization amount is greater than the ship via dollar limit. This is a paytype level hold; the order will be put on AT hold.   The hold reason you enter here displays on the Credit Card Order Cancellation List when you process cancellations. No pick slip prints if the order is on hold. Hold reason codes are defined in and validated against the Order Hold Reason table; see Establishing Order Hold Reason Codes (WOHR). Alphanumeric, 2 positions; optional.

Work with Pay Type $ Limit to Force Authorization Screen

Purpose: Use this screen to create and maintain pay type dollar limits.

Pay type dollar limit defines whether a dollar limit to force an authorization is applied to a specific pay type.

See Entity pay type dollar limits for more information on the processing the system performs.

Note:

If you are performing online authorization, the system does not validate entity pay type dollar limit.

How to display this screen: On the Work with Vendor Response Screen, select Pay Type $ Limit for an entity.

Field	Description
Authorization service	The code and description of the account provider for which you are working with pay type dollar limits for a vendor response. This is the account provider you selected on the Work with Authorization Services Screen. Authorization code:  Alphanumeric, 3 positions; display-only. Authorization description:  Alphanumeric, 30 positions; display-only.
Response code	The code and description of the vendor response assigned by the account provider that identifies whether the credit card was authorized or declined, and the reason for the authorization or decline. This is the vendor response you selected on the Work with Vendor Response Screen. Response code:  Alphanumeric, 10 positions; display-only. Response description:  Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected on the Select Entity for Vendor Response Details Screen. Entity code:  Numeric, 3 positions; display-only. Entity description:  Alphanumeric, 25 positions; display-only.
Pay type	A code used to identify a method of payment on an order. Pay type codes are defined in and validated against the Pay Type table. Numeric, 2 positions; optional.
Description	A description of the pay type. Alphanumeric, 30 positions; display-only.
Dollar limit to force authorization	The dollar limit that indicates whether the order is eligible for a forced authorization. If the dollar amount for the credit card is greater than $1.00 but less than the dollar amount defined, the system forces an authorization. Note:  If you wish to force authorizations for credit cards requiring authorizations less than $1.00, enter an authorization number in the Authorization Number for Authorizations Under $1.00 (I08) system control value. Numeric, 13 positions with a 2-place decimal; optional.

Screen Option	Procedure
Change a pay type dollar limit	Select Change for a pay type dollar limit to advance to the Change Pay Type $ Limit to Force Authorization Screen. You can change the pay type code or dollar amount on this screen. See the Create Pay Type $ Limit to Force Authorization Screen for field descriptions.
Delete a pay type dollar limit	Select Delete for a pay type dollar limit to delete it.
Display a pay type dollar limit	Select Display for a pay type dollar limit to advance to the Display Pay Type $ Limit to Force Authorization Screen. You cannot change any information at this screen. See the Create Pay Type $ Limit to Force Authorization Screen for field descriptions.
Create a pay type dollar limit	Select Create to advance to the Create Pay Type $ Limit to Force Authorization Screen.

Create Pay Type $ Limit to Force Authorization Screen

Purpose: Use this screen to create a pay type dollar limit.

How to display this screen: Select Create on the Work with Pay Type $ Limit to Force Authorization Screen.

Field	Description
Authorization service	The code and description of the account provider for which you are creating a pay type dollar limit for a vendor response. This is the account provider you selected on the Work with Authorization Services Screen. Authorization code:  Alphanumeric, 3 positions; display-only. Authorization description:  Alphanumeric, 30 positions; display-only.
Response code	The code and description of the response assigned by the account provider that identifies whether the credit card was authorized or declined, and the reason for the authorization or decline. This is the vendor response you selected on the Work with Vendor Response Screen. Response code:  Alphanumeric, 10 positions; display-only. Response description:  Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected on the Select Entity for Vendor Response Details Screen. Entity code:  Numeric, 3 positions; display-only. Entity description:  Alphanumeric, 25 positions; display-only.
Pay type	A code used to identify a method of payment on an order. Pay type codes are defined in and validated against the Pay Type table; see Working with Pay Types (WPAY). An error message indicates if you try to create a pay type dollar limit for a pay type that already has a pay type dollar limit defined for this vendor response and entity: Duplicate record exists. An error message indicates if you enter a pay type other than a credit card pay type: Pay Type entered must be a credit card. Numeric, 2 positions; required.
$ limit to authorization	The dollar amount that you wish to use to force a credit card authorization.   If the dollar amount defined for the credit card is greater than $1.00 but less than the amount you define, the system forces the credit card authorization. If the dollar amount defined for the credit card is equal to or greater than the amount you define, the system does not authorize the credit card. An error message indicates if you enter a dollar amount that is less than $1.00: Pay Type $ Limit cannot be less than One Dollar ($1.00). Note:  If you wish to force authorizations for credit cards requiring authorizations less than $1.00, enter an authorization number in the Authorization Number for Authorizations Under $1.00 (I08) system control value. Numeric, 13 positions with a 2-place decimal; required.

Work with Item Class $ Limit to Hold Screen

Purpose: Use this screen to create and maintain item class dollar limits.

Item class dollar limit defines whether a dollar limit is applied to the item class associated with an item on the order that requires authorization.

• If the authorization amount is less than the item class dollar limit, the system releases the order from any AVS hold.

• If the authorization is greater than the item class dollar limit, the system places the order on hold using the hold reason defined for the item class dollar limit.

You might use this if you want to keep a careful check for stolen credit cards. For example, you can place an order on hold if at least one of the items on the order requesting authorization is assigned to item class PNT (high-fraud items) and the dollar amount required for authorization is greater than $200.00.

See Entity item class dollar limits for more information on the processing the system performs.

How to display this screen: Select Item Class $ Limit for an entity on the Work with Vendor Response Screen.

Field	Description
Authorization service	The code and description to identify the account provider for which you are working with item class dollar limits. This is the account provider you selected on the Work with Authorization Services Screen. Authorization code: Alphanumeric, 3 positions; display-only. Authorization description: Alphanumeric, 30 positions; display-only.
Response code	The code and description assigned by the account provider that identifies whether the credit card passed address verification. This is the AVS response you selected at the Work with Vendor Response Screen. Response code: Alphanumeric, 10 positions; display-only. Response description: Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected on the Select Entity for Vendor Response Details Screen. Entity code: Numeric, 3 positions; display-only. Entity description: Alphanumeric, 25 positions; display-only.
Item class	A code for an item class used to group like items together. Item class codes are defined in and validated against the Item Class table. Alphanumeric, 3 positions; optional.
$ Limit To Hold	The dollar limit that defines when the system places the order on hold. The system places an order on hold when the order meets the account provider/AVS response code/entity/item class combination and the dollar amount that requires authorization is greater than the amount defined for the item class dollar limit. The system assigns the hold reason code defined for the item class dollar limit to the order. Conversely, if you do not define a hold reason, the system does not place an order on hold if the order does not pass AVS authorization, but is under the item class dollar amount specified. Numeric, 13 positions with a 2-place decimal; optional.
Hold Reason/Description	The code and description of the hold reason to assign to orders whose authorization amount is greater than the item class dollar limit. Code: Alphanumeric, 2 positions; optional. Description: Alphanumeric, 50 positions; display-only.

Screen Option	Procedure
Create an item class dollar limit	Select Create to advance to the Create Item Class $ Limit to Hold Screen.
Change an item class dollar limit	Select Change for an item class dollar limit to hold to advance to the Change Item Class $ Limit to Hold Screen.
Delete an item class dollar limit	Select Delete for an item class dollar limit to hold to delete it.
Display an item class dollar limit	Select Display for an item class dollar limit to hold to advance to the Display Item Class $ Limit to Hold Screen.

Create Item Class $ Limit to Hold Screen

Purpose: Use this screen to create an item class dollar limit.

How to display this screen: Select Create at the Work with Item Class $ Limit to Hold Screen.

Field	Description
Authorization service	The code and description of the account provider for which you are creating an AVS response item class dollar limit. This is the account provider you selected at the Work with Authorization Services Screen. Authorization code: Alphanumeric, 3 positions; display-only. Authorization description: Alphanumeric, 30 positions; display-only.
Response code	The code and description of the AVS response code assigned by the account provider that identifies whether the credit card passed address verification. This is the AVS response you selected at the Work with Vendor Response Screen. Response code: Alphanumeric, 10 positions; display-only. Response description: Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected at the Select Entity for Vendor Response Details Screen. Entity code: Numeric, 3 positions; display-only. Entity description: Alphanumeric, 25 positions; display-only.
Item class	A code for an item class used to group like items together. Item class codes are defined in and validated against the Item Class table. An error message indicates if you try to create an item class dollar limit for an item class that already has a dollar limit defined for the vendor response code and entity: Duplicate record exists. Alphanumeric, 3 positions. Create screen: required. Change screen: display-only.
$ limit to hold	The dollar limit that defines when the system places the order on hold. The system places an order on hold when the order meets the account provider/AVS response code/entity/item class combination and the dollar amount that requires authorization is greater than the amount defined for the item class dollar limit. The system assigns the hold reason code defined for the item class dollar limit to the order. Conversely, if you do not define a hold reason, the system does not place an order on hold if the order does not pass AVS authorization, but is under the item class dollar amount specified. An error message indicates if you try to enter a dollar limit that is less than $1.00: Item Class $ Limit cannot be less than $1.00. Numeric, 13 positions with a 2-place decimal; required.
Hold reason	A code for the hold reason the system assigns to the order when the order meets the item class dollar limit hold requirements. This is a paytype level hold; the order will be put on AT hold. The hold reason you enter here displays on the Credit Card Order Cancellation List when you process cancellations. No pick slip prints if the order is on hold. Hold reason codes are defined in and validated against the Order Hold Reason table; see Establishing Order Hold Reason Codes (WOHR). Alphanumeric, 2 positions; optional.

Change Item Class $ Limit to Hold Screen

To change: At the Work with Item Class $ Limit to Hold Screen, select Change for an item class dollar limit to hold to advance to the Change Item Class $ Limit to Hold screen. At this screen, you can change the $ limit to hold and hold reason code.

See Create Item Class $ Limit to Hold Screen for a description of the fields on this screen.

Display Item Class $ Limit to Hold Screen

To display: At the Work with Item Class $ Limit to Hold Screen, select Display for an item class dollar limit to hold to advance to the Display Item Class $ Limit to Hold screen. You cannot change any fields on this screen.

See Create Item Class $ Limit to Hold Screen for a description of the fields on this screen.

Work with Postal Code $ Limit to Hold Screen

Purpose: Use this screen to create and maintain postal code dollar limits.

Postal code dollar limit defines whether a dollar limit is applied to the postal code for the sold to customer on the order.

• If the authorization amount is less than the postal code dollar limit, the system releases the order from any AVS hold.

• If the authorization amount is greater than the postal code dollar limit, the system places the order on hold using the hold reason defined for the postal code dollar limit.

You might use this if you want to keep a careful check for stolen credit cards. For example, you can place an order on hold if the order is associated with a high-crime delivery area and the dollar amount required for authorization is greater than $200.00.

See Entity postal code dollar limits for an example and additional processing logic.

How to display this screen: Select Postal Code $ Limit for an entity at the Select Entity for Vendor Response Details Screen.

Field	Description
Authorization service	The code and description of the account provider for which you are working with postal code dollar limits. This is the account provider you selected on the Work with Authorization Services Screen. Authorization code: Alphanumeric, 3 positions; display-only. Authorization description: Alphanumeric, 30 positions; display-only.
Response code	The code and description assigned by the account provider that identifies whether the credit card passed address verification. This is the vendor response you selected at the Work with Vendor Response Screen. Response code: Alphanumeric, 10 positions; display-only. Response description: Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected on the Select Entity for Vendor Response Details Screen. Entity code: Numeric, 3 positions; display-only. Entity description: Alphanumeric, 25 positions; display-only.
Postal code	A code for a postal code or zip code representing a delivery area. Alphanumeric, 10 positions; optional.
$ Limit To Hold	The dollar limit that defines when the system places the order on hold. The system places an order on hold when the order meets the account provider/AVS response code/entity/postal code combination and the dollar amount that requires authorization is greater than the amount defined for the postal code dollar limit. The system assigns the hold reason code defined for the postal code dollar limit to the order. Conversely, if you do not define a hold reason, the system does not place an order on hold if the order does not pass AVS authorization, but is under the postal code dollar amount specified. Numeric, 13 positions with a 2-place decimal; optional.
Hold Reason/Description	The code and description of the hold reason to assign to orders whose authorization amount is greater than the postal code dollar limit. Code: Alphanumeric, 2 positions; optional. Description: Alphanumeric, 50 positions; display-only.

Screen Option	Procedure
Create a postal code dollar limit to hold	Select Create to advance to the Create Postal Code $ Limit to Hold Screen.
Change a postal code dollar limit to hold	Select Change for a postal code dollar limit to hold to advance to the Change Postal Code $ Limit to Hold Screen.
Delete a postal code dollar limit to hold	Select Delete for a postal code dollar limit to hold to delete it.
Display a postal code dollar limit to hold	Select Display for a postal code dollar limit to hold to advance to the Display Postal Code $ Limit to Hold Screen.

Create Postal Code $ Limit to Hold Screen

Purpose: Use this screen to create a postal code dollar limit.

How to display this screen: Select Create at the Work with Postal Code $ Limit to Hold Screen.

Field	Description
Authorization service	The code and description of the account provider for which you are creating an AVS response postal code dollar limit. This is the account provider you selected at the Work with Authorization Services Screen. Authorization code: Alphanumeric, 3 positions; display-only. Authorization description: Alphanumeric, 30 positions; display-only.
Response code	The code and description of the AVS response assigned by the account provider that identifies whether the credit card passed address verification. This is the AVS response you selected at the Work with Vendor Response Screen. Response code: Alphanumeric, 10 positions; display-only. Response description: Alphanumeric, 40 positions; display-only.
Entity	The code and description of the entity you selected at the Select Entity for Vendor Response Details Screen. Entity code: Numeric, 3 positions; display-only. Entity description: Alphanumeric, 25 positions; display-only.
Postal code	A code for a postal code or zip code representing a delivery area. Postal codes are defined in and validated against the Zip/City/State table. An error message indicates if you try to create a postal code dollar limit for a postal code that already has a dollar limit defined for the AVS response and entity: Duplicate record exists. Alphanumeric, 5 positions. Create screen: required. Change screen: display-only.
$ limit to hold	The dollar limit that defines when the system places the order on hold. The system places an order on hold when the order meets the account provider/AVS response code/entity/postal code combination and the dollar amount that requires authorization is greater than the amount defined for the postal code dollar limit. The system assigns the hold reason code defined for the postal code dollar limit to the order. Conversely, if you do not define a hold reason, the system does not place an order on hold if the order does not pass AVS authorization, but is under the postal code dollar amount specified. An error message indicates if you try to enter a dollar limit that is less than $1.00: Postal Code $ Limit cannot be less than $1.00. Numeric, 13 positions with a 2-place decimal; required.
Hold reason	A code for the hold reason the system assigns to the order when the authorization amount is greater than the postal code dollar limit. This is a paytype level hold; the order will be put on AT hold. The hold reason you enter here displays on the Credit Card Order Cancellation List when you process cancellations. No pick slip prints if the order is on hold. Hold reason codes are defined in and validated against the Order Hold Reason table; see Establishing Order Hold Reason Codes (WOHR). Alphanumeric, 2 positions; optional.

Change Postal Code $ Limit to Hold Screen

To change: At the Work with Postal Code $ Limit to Hold Screen, select Change for a postal code dollar limit to hold to advance to the Change Postal Code $ Limit to Hold screen. At this screen, you can change the $ limit to hold and hold reason code.

See Create Postal Code $ Limit to Hold Screen for a description of the fields on this screen.

Display Postal Code $ Limit to Hold Screen

To display: At the Work with Postal Code $ Limit to Hold Screen, select Display for a postal code dollar limit to hold to advance to the Display Item Class $ Limit to Hold screen. You cannot change any fields on this screen.

See Create Postal Code $ Limit to Hold Screen for a description of the fields on this screen.

Defining Merchant ID Overrides

Purpose: Use merchant ID overrides to set up overrides for the different entities in your company.   

When used: You use the merchant ID, which the account provider assigns, to identify your company when you transmit information to the account provider. Although you can set up a default ID for your company, you may need to set up overrides for each separate entity under which you perform authorizations and deposits. Not used for EFTConnect account providers.

Access to screens: The screens you use to work with merchant ID overrides are available through the Work with Authorization Services Screen.

Source code points to entity: The system determines the entity for a customer order based on the source code on the order header.  When you create a source code you must specify a division, and when you create a division you must specify an entity.  In this way, the source code on the order header indicates which merchant ID override to use for transactions related to the order.

Deferred/installment pay plans: If you use deferred or installment billing, you would also use these screens to set up merchant ID overrides for transactions related to these orders. See Deferred/Installment Billing Overview for more information on pay plans.

In this topic:

• Work with Merchant ID Overrides Screen

• Create Merchant ID by Entity Screen

For more information:

• Introducing Offer and Source Codes 

• Working with Entities (WENT)

• Working with Divisions (WDIV)

Work with Merchant ID Overrides Screen

How to display this screen: Select Merchant ID Override for an authorization service at the Work with Authorization Services Screen.

Field	Description
Authorization service	The service code representing the authorization service you selected at the Work with Authorization Services Screen. Alphanumeric, 3 positions; display-only.
Entity	The code representing an entity with a unique merchant ID. Numeric, 3 positions; optional.
Merchant ID	An account number assigned by the account provider to identify transmissions to/from a particular entity in your company. The default merchant ID, used for regular (as opposed to pay plan) transactions displays. To review the deferred or installment merchant IDs, select Change or Display for the entity. Alphanumeric, 20 positions; optional.

Screen Option	Procedure
Create a new merchant ID override	Select Create to advance to the Create Merchant ID by Entity Screen.
Change a merchant ID override	Select Change for a merchant ID override to advance to the Change Merchant ID Override Screen. At this screen, you can change the merchant ID fields and API fields. See the Create Merchant ID by Entity Screen for field descriptions.
Delete a merchant ID override	Select Delete for a merchant ID override to delete it.
Display a merchant ID override	Select Display for a merchant ID override to advance to the Display Merchant ID Override Screen. You cannot change any information at this screen. See the Create Merchant ID by Entity Screen for field descriptions.

Create Merchant ID by Entity Screen

Purpose: Use this screen to create a new merchant ID override for orders associated with a specific entity in your company.

How to display this screen: Select Create at the Work with Merchant ID Overrides Screen.

Field	Description
Entity	Enter the entity associated with the merchant ID. Entities are defined in and validated against the Entity table; see Working with Entities (WENT). Numeric, 3 positions. Create screen: required. Change screen: display-only.
Merchant ID	Enter the merchant ID to use when transmitting information to an authorization or deposit service for orders associated with this entity (based on the division associated with the source code on the order header).  This is the merchant ID to use for regular, as opposed to pay plan, transactions. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 20 positions; required.
Deferred merchant ID	Enter the merchant ID to use when transmitting transactions to a account provider for orders that are associated with this entity, and which are using a deferred billing pay plan.   Deferred and installment pay plans are available only if the Deferred and Installment Billing (F51) system control value is selected. See Deferred/Installment Billing Overview. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 20 position; optional.
Installment merchant ID	Enter the merchant ID to use when transmitting transactions to a account provider for orders that are associated with this entity, and which are using an installment plan. Deferred and installment pay plans are available only if the Deferred and Installment Billing (F51)Deferred and Installment Billing (F51) system control value is selected. See Deferred/Installment Billing Overview. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 20 positions; optional.
API User name	The user name, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 64 positions; optional.
API Password	The password, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 64 positions; optional.
API Signature	The encrypted signature, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing. Note:  You can enter upper and lower case letters in this field. Alphanumeric, 128 positions; optional.

Defining Authorization Service Currencies

Purpose: Use the Work with Authorization Currency function to set up cross references between the currency codes you use in Order Administration and the account provider's codes. The system uses these cross references to determine which currency code to pass to the account provider when authorizing credit cards and processing deposits. Use this screen to create, change, or delete the currency cross reference information for an External Payment Service or EFTConnect account provider.

In this topic:

• Work with Authorization Service Currency Screen

• Create Authorization Service Currency Screen

Work with Authorization Service Currency Screen

How to display this screen: Select Currency for the authorization service at the Work with Authorization Services Screen.

Field	Description
Authorization service	The service to use the cross references. The service you selected at the Work with Authorization Services Screen displays. Code:  alphanumeric, 3 positions; display-only. Description:  alphanumeric, 30 positions; display-only.
Currency	The code identifying a type of currency in Order Administration.    Currency codes are defined in and validated against the Currency table; see Working with Currency (WCUR). Alphanumeric, 3 positions; optional.
Authorization Service Currency	The related currency code used by the authorization service. Alphanumeric, 3 positions; optional.

Select Option	Procedure
Change an authorization service currency code  cross reference	Select Change for a currency code to advance to the Change Authorization Service Currency Screen. At this screen you can change only the authorization service currency code. See the Create Authorization Service Currency Screen for field descriptions.
Delete an authorization service currency code	Select Delete for a currency code to delete it.
Display an authorization service currency code cross reference	Select Display for a currency code to advance to the Display Authorization Service Currency Screen. You cannot change any information at this screen. See the Create Authorization Service Currency Screen for field descriptions.
Create an authorization service currency code cross reference	Select Create to advance to the Create Authorization Service Currency Screen.

Create Authorization Service Currency Screen

Purpose: Use this screen to define an equivalency between a currency code in your company and a currency code used by the account provider.

How to display this screen: Select Create at the Work with Authorization Service Currency Screen.

Field	Description
Authorization service	The account provider to use the cross references. The account provider you selected at the Work with Authorization Services Screen displays. Code:  alphanumeric, 3 positions; display-only. Description:  alphanumeric, 30 positions; display-only.
Currency	The code identifying a type of currency in your company.    Currency codes are defined in and validated against the Currency table; see Working with Currency (WCUR). Alphanumeric, 3 positions. Create screen: optional. Change screen: display-only.
Authorization service currency	The related currency code used by the account provider. Alphanumeric, 3 positions; optional.

Performing Online Credit Card Authorizations

Overview: Online credit card authorization allows you to send and receive the information required to authorize a credit card when the order is placed instead of when the pick slip is generated for the order.

Quotes: If the Online Authorization field for a quote order type is selected, the system performs online authorization during quote entry; see Entering Pre-Order Quotes for an overview.

In this topic: This topic provides an overview of the online credit card authorization process and the required setup.

• Receiving a Credit Card Authorization During Order Entry

  • What Credit Card Amount is Sent for Authorization?

  • Hierarchy for Placing the Credit Card On Hold

  • What Happens When a Credit Card is Approved?

  • What Happens When a Credit Card is Declined?

  • When Communication Failures Occur

  • What Happens When an Undefined Response is Returned?

  • Select Authorization Response Option Window

• Resending Credit Cards for Authorization

• Pick Slip Generation

• Credit Card Authorization List

• Transmitting and Receiving Deposits

• Online Authorization Process

• Online Credit Card Authorization Setup

  • System Control Values

  • Number Assignment Value

  • Account Provider Settings

  • Order Types

  • Pay Types

  • Pick Slip Generation

Receiving a Credit Card Authorization During Order Entry

The system performs online authorization when you select Accept to accept an order after determining if the order should go on hold due to the credit card payment method. Note that online authorization can still take place if the order is on hold for another reason, provided the order is eligible.

Generic order interface: If you receive orders through the Generic Order Interface (Order API), the system performs online authorization after determining if the order should go on hold and performing credit card tokenization; see Performing Online Credit Card Authorization on Web Orders.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Batch order entry: If you are using batch order entry, the system performs online authorization when you accept a batch at the Work with Error Orders Batches Screen or Select Customer Sold To For Order Screen.

Order maintenance: The system performs online authorization when you select Auth On-Line for a credit card payment on the Enter Payment Methods Screen.

When you convert a quote to an order in order maintenance, the system will perform online authorization for eligible payment methods only if the Authorize Full Amount During Order Entry (G99) system control value is selected; see Converting Quotes to Orders.

1. The system determines if the order is eligible for online authorization. In order to receive a credit card authorization during order entry:

• the On-line Authorizations (B89) system control value must be selected.

• the order type defined for the order must be eligible for online authorizations (the On-line authorization field is set to Window (on-line eligible and display window) or Without Window (on-line eligible and do not display window).

• the order must have a credit card, stored value card, or debit (Switch) card payment method.

• the order must be in an open or suspended status. Note: You can authorize a credit card payment during order maintenance when the order is on hold; regardless of whether the payment is authorized, the order remains on hold.

• the arrival date on the order cannot be greater than the current date.

  Express bill orders: When you enter a credit card payment method on an express bill order, you must manually authorize the card or the order must be eligible for online authorization. However, since you cannot enter the Authorization Request ID at this screen, Oracle recommends that you instead use the Add Authorization option from the Order Summary page in Modern View to apply a manual authorization.

  See Online Credit Card Authorization Setup for more information on setting up the required values for online authorization.

2. The system determines the amount to authorize.

What Credit Card Amount is Sent for Authorization?

• If the Online Auth Verification Only (I96) system control value is selected, the system processes online authorizations for $0.00 for the purpose of validating the card. During batch authorizations, the system authorizes the card for the shippable dollar amount and voids the online authorization for $0.00.

• If the Online Auth Verification Only (I96) system control value is unselected, the system looks at the setting of the Authorize Full Amount During Order Entry (G99) system control value to determine the amount sent for authorization.

The Authorize Full Amount During Order Entry (G99) system control value determines if the credit card is authorized for the full order amount or for the shippable amount on the order.

Authorize full amount...	Authorize shippable amount...
The system sends the entire dollar amount defined for the credit card for authorization. If the credit card is the only payment method... The amount to authorize is the order total. The order total is the sum of all charges on the order, including: merchandise, freight, additional freight, tax, handling, additional charges, GST and PST.	The system sends the dollar amount associated with what is shippable on the order, across all ship to customers, for authorization. If the credit card is the only payment method... This shippable dollar amount includes: shippable merchandise amount, including drop ship items tax associated with the shippable merchandise amount total freight total additional freight total order level additional charges Note:  The system sends the total freight and total additional freight for authorization, regardless of whether you are prorating freight charges (the Prorate Freight Charges (D39) system control value is selected).
If the credit card is the catch-all payment method... The amount to authorize is the remaining dollar amount not associated with another payment method on the order. The system subtracts the amount applied to any other payment methods from the order total. order total - dollar amount associated with other payment methods = amount to authorize for this credit card	If the credit card is the catch-all payment method... The amount to authorize is the remaining shippable dollar amount not associated with another payment method on the order. The system subtracts the amount applied to any other payment methods from the shippable dollar amount. shippable dollar amount - dollar amount associated with other payment methods = amount to authorize for this credit card Excluded from authorizations: order lines with a future arrival date order lines on backorder, canceled, closed, or sold out reserved order lines that are coordinate grouped with an order line on backorder or with an order line with a future arrival date

Excluded from authorizations:

• order lines with a future arrival date

• order lines on backorder, canceled, closed, or sold out

• reserved order lines that are coordinate grouped with an order line on backorder or with an order line with a future arrival date

Regardless of whether you are authorizing the full amount or the shippable amount...

Included in authorizations:

• express bill order lines

• drop ship order lines

• non-inventory order lines

Deferred Billing

If the credit card on the order is associated with a deferred pay plan, the system:

• sends an authorization for $1.00 if the Authorize full amount field for the pay plan is unselected.

• sends an authorization for the dollar amount available for authorization if the Authorize full amount field for the pay plan is selected.

Installment Billing

If the credit card on the order is associated with an installment pay plan, the system:

• sends an authorization for the first installment amount if the Authorize full amount field for the pay plan is unselected.

• sends an authorization for the dollar amount available for authorization if the Authorize full amount field for the pay plan is selected.

If more than one credit card is sent for authorization:

The system sends for authorization the credit card defined with a dollar amount, then sends the catch-all credit card for authorization.

Credit cards requiring authorizations less than $1.00: If the credit card amount to authorize is less than $1.00 and you have defined an authorization number in the Authorization Number for Authorizations Under $1.00 (I08) system control value, the system does not send the credit card to the account provider for authorization and instead assigns the authorization number from the system control value to the credit card. If an authorization number is not defined in this system control value, the system sends the credit card to the account provider for authorization, regardless of the amount that requires authorization.

3. The system sends the authorization amount to the account provider. If there is an amount to authorize for the credit card, the system sends an authorization request in online format to the account provider.

4. The account provider sends back a response. The account provider sends an authorization response to Order Administration.

There are 3 types of responses you can receive from the account provider.

• R = an authorization response is received, such as declined or approved

• T = the program timed out before an authorization response was received

• U = an undefined response

Additionally, if an authorization response is received, the account provider sends back an authorization response code, AVS response code (if performing address verification), CID response code (if performing credit card identification verification), authorization code, and date.

Vendor response settings: If a pop up window message has been defined for the vendor response received, the system displays the Select Authorization Response Option Window. Also, if a hold reason code has been defined for the vendor response received, the system places the order on hold.

Oracle Retail Customer Engagement stored value cards: When using the Customer Engagement Stored Value Card Integration, if the Oracle Retail Customer Engagement stored value card is the only payment on the order and the amount authorized for the card is less than the order total, Order Administration updates the amount for the card with the amount authorized and displays the message Insufficient balance on card - please add another payment. In order to accept the order, you must add another payment to the order to cover the amount of the order that is not covered by the Oracle Retail Customer Engagement stored value card. Example: If the order total is 500.00 and the amount authorized for the Oracle Retail Customer Engagement stored value card is 236.20, the system updates the amount for the card to 236.20 and requires another form of payment to cover the remaining 289.55 balance on the order.

Hierarchy for Placing the Credit Card On Hold

The credit card pay type may be placed on hold if the credit card is not approved, the AVS verification fails, or the CID verification fails.

The system uses this hierarchy to determine if the credit card pay type should go on hold:

• Authorization response has a hold reason defined: If the credit card charge is declined (not authorized), the credit card may be placed on hold (based on the value in the Hold reason field in the Vendor Response table). The order header is also placed on AT (declined credit card) hold. You must take the order header and credit card pay type off of hold through Manage Held Orders in Modern View and resend for authorization or cancel the order.

• AVS response has a hold reason defined: If the credit card charge is approved (authorized) but the credit card fails the address verification check, the authorization may be placed on hold (based on the value in the Hold reason field in the Vendor Response table). The order header is also placed on AT (declined credit card) hold. You must contact the customer and obtain correct address information, then take the order header and credit card pay type off of hold through Manage Held Orders in Modern View and resend for authorization or cancel the order.

• Card security identification response has a hold reason defined: If the credit card charge is approved (authorized) and passes the address verification check, but the credit card fails the credit card security identification check, the credit card pay type may be placed on hold (based on the value in the Hold reason field in the Vendor Response table). The order header is also placed on AT (declined credit card) hold. You must contact the customer to verify credit card ownership, then take the order header and credit card pay type off of hold through Manage Held Orders in Modern View and resend for authorization or cancel the order.

For more information: See Defining Vendor Response Codes and Establishing Cancel Reason Codes (WCNR).

What Happens When a Credit Card is Approved?

When a credit card is approved during order entry, the system:

• Select Authorization Response Option Window

• places the order on hold if a hold reason code has been defined for the vendor response. Typically, if an authorization is approved, the order is not placed on hold. However, if the credit card is approved but fails address verification or card identification verification, you may want to place the order on hold.

• once you accept the order, you return to the Select Customer Sold To For Order Screen, or the Customer Selection Screen if you are a CTI user.

• processes any end-of-order updates and sends the order to the Order Async.

• creates a record in the On-Line Authorization table indicating the order number, that the credit card has been approved, the dollar amount authorized, the transaction sequence number, and the authorization number. The status for this authorization is *UPDT, indicating the online authorization has completed.

• creates a record in the Authorization History table indicating the credit card has been approved, the authorization number, the date the credit card was authorized, and the dollar amount authorized. If you reject an order after the credit card has been approved, the system removes the record in the Authorization History table. You can review authorization history at the Display Authorization History Screen.

• creates a record in the Void Authorization table indicating the order number and the dollar amount eligible for void. If you reject an order after the credit card has been approved, the system removes the record from the Void Authorization table.

AVS response: If the credit card charge is approved (authorized) but the order fails the address verification check and receives an AVS response that has a hold reason code, the system:

• places the order on AT hold.

• places the credit card payment method on the order on AV (AVS) hold.

• creates an order transaction history message indicating the credit card was declined: SYS HLD - DECLINED CREDIT CARD.

• updates the record in the On-Line Authorization table indicating the credit card failed AVS. The OLA AVS result field is updated with the AVS response received from the account provider. You can review the response at the Authorization History Details Window.

• updates the record in the Authorization History table indicating the credit card failed AVS. The AUH status field is updated to O (authorized but not used) and the AVS response field is updated with the AVS response received from the account provider. You can review the status of the credit card and the AVS response at the Authorization History Details Window.

You must contact the customer and obtain correct address information, then take the order off of hold through the Release Held Orders function and resend for authorization.

If the authorization has not yet expired and the transaction passes AVS, the system updates the credit card authorization record from an O (authorized but not used) status to an A (approved) status. If the authorization has expired, the system updates the credit card authorization record from an O (authorized but not used) status to a D (declined) status and resends the credit card for authorization and address verification.

Card security identification response: If the credit card charge is approved (authorized) but the order fails the credit card security check and receives a card security identification response (CID, CVV2, CVC2) that has a hold reason code, the system:

• places the order on AT hold.

• places the credit card payment method on the order on CF (credit card fraud) hold.

• creates an order transaction history message indicating the credit card was declined: SYS HLD - DECLINED CREDIT CARD.

• updates the record in the On-Line Authorization table indicating the credit card failed card security. The OLA vendor response 2 field is updated with the card security response received from the account provider. You can review the response at the Authorization History Details Window.

• updates the record in the Authorization History table indicating the credit card failed card security. The AUH status field is updated to O (authorized but not used) and the Vendor response 2 field is updated with the card security response received from the account provider. You can review the status of the credit card and the card security response at the Authorization History Details Window.

You must contact the customer to verify credit card ownership, then take the order off of hold through  Manage Held Orders in Modern View and resend for authorization.

If the authorization has not yet expired and the transaction passes card security identification, the system updates the credit card authorization record from an O (authorized but not used) status to an A (approved) status. If the authorization has expired, the system updates the credit card authorization record from an O (authorized but not used) status to a D (declined) status and resends the credit card for authorization and card security identification.

Voiding an online authorization: After receiving an online authorization, if you change the price of an item in Order Maintenance, the stem voids the authorization. Because the authorization is voided, the system sends the order for batch authorization during pick slip generation.

What Happens When a Credit Card is Declined?

When a credit card is declined during order entry, the system:

• displays the Select Authorization Response Option Window if a vendor response pop up window message has been defined, the On-line authorization field for the order type is set to Window (on-line eligible and display window), and a Response time is defined for the account provider. The message should indicate the credit card has been declined and any action you should take to correct the decline or inform the customer. From this window, you can accept the order or return to the order to make any corrections.

• places the order on hold: If a hold reason code is defined for the vendor response, the system assigns this hold reason code to the order payment method and places the order header on AT (Declined Credit Card) hold. If the response received is not defined for the account provider, the system places the order payment method on AV (Invalid Response Code) hold.

• once you accept the order you return to the Select Customer Sold To For Order Screen, or the Customer Selection Screen if you are a CTI user.

• processes any end-of-order updates and sends the order to the Order Async.

• creates a record in the On-Line Authorization table indicating the order number, that the credit card has been declined, the dollar amount submitted for authorization, and the transaction sequence number. The status of this authorization is *UPDT, indicating the online authorization has been completed.

• creates a record in the Authorization History table indicating the credit card has been declined, the reason why the credit card was declined, the date the credit card was declined, and the dollar amount submitted for authorization. If you reject the order after the credit card has been declined, the system removes the record from the Authorization History table. You can review authorization history at the Display Authorization History Screen.

You can send the credit card up for authorization again during order maintenance, using the Performing Batch Authorization (SATH) menu option, or during pick slip generation if the Batch/on-line field for the account provider contains a C (on-line and batch authorizations).

When Communication Failures Occur

Communication failures can occur if the system times out before a response is received. If communication failures occur and you do not receive a response from the account provider, the system:

• does not display the Select Authorization Response Option Window since a vendor response was not received.

• accepts the order and returns you to the Select Customer Sold To For Order Screen, or the Customer Selection Screen if you are a CTI user.

• processes any end-of-order updates and sends the order to the Order Async.

• creates a record in the On-Line Authorization table. The status of this authorization is:

• RDY, indicating online authorization has not been performed.

• SENT, indicating the online authorization transmission failed after the credit card was sent to the account provider for authorization.

• RCVD, indicating the online authorization transmission failed after a response was received from the account provider, but final updates could not be completed. This may occur if the Online Authorization integration job became inactive. The authorization does not complete processing until the job is active. Once the Online Authorization integration job is active, the system updates the status of the authorization to *UPDT.

• creates a record in the Authorization History table indicating the credit card is waiting for authorization, the date the credit card was sent for authorization, and the dollar amount waiting for authorization.

The amount of time the system waits for an authorization is defined in the Response time field for the account provider.

Grace period: The system allows a 2 day grace period to receive a response from the account provider if the status of the authorization is *RDY, *SENT, or *RCVD. To determine the grace period, the system takes the current date - the authorization sent date to determine the number of days. Once the 2 day grace period is passed, the system declines the transmission. You will need to resend the credit card for authorization during order maintenance or pick slip generation.

What Happens When an Undefined Response is Returned?

When an undefined response is returned, the system:

• does not display the Select Authorization Response Option Window since this vendor response has not been defined for the account provider.

• places the order on AVS hold.

• accepts the order and returns you to the Select Customer Sold To For Order Screen, or the Customer Selection Screen if you are a CTI user.

• processes any end-of-order updates and sends the order to the Order Async.

• creates a record in the On-Line Authorization table indicating the order number, that the credit card is waiting for authorization, the dollar amount waiting for authorization, and the transaction sequence number. The status of this authorization is *RDY, indicating online authorization has not been performed.

• creates a record in the Authorization History table indicating the credit card is waiting for authorization, the date the credit card was sent for authorization, and the dollar amount waiting for authorization.

You can resend the order for authorization during order maintenance, using the Performing Batch Authorization (SATH) menu option, or during pick slip generation if the Batch/on-line field for the account provider contains a C (on-line and batch authorizations).

Select Authorization Response Option Window

Use this window to review the response received from the account provider and any messages defined for this vendor response.

Once you review the message, you can accept the order or return to the order to make any corrections or reject the order.

Typically, a vendor response pop up window message is defined for a vendor response indicating a declined authorization, declined address verification, or declined card identification verification.

How to display this screen: This window displays when you select Accept to accept an order in order entry if:

• the dollar amount defined for the credit card payment method on the order was sent up for authorization and received a response, and

• the On-line authorization field for the order type on the order is set to Window (on-line eligible and display window), and

• a Response time is defined for the account provider, and 

• the Pop up window messages field for the vendor response returned by the account provider contains text.

Note:

The Pop up window messages # 1 field must contain text in order to display this window. If you define text in the Pop up window messages # 2 - # 4 fields and not in the Pop up window messages # 1 field, this window will not display.

This window displays for each credit card payment method on the order that is sent up for authorization and meets the criteria above.

What message displays? You can receive a response from the account provider for the authorization, address verification (AVS), and credit card security identification (CID, CVV2, CVC2). If you receive a response for the authorization, AVS verification, and card security identification, the system uses the following hierarchy to determine the pop up window message that displays in the Select Authorization Response Option window:

• Authorization response has a message defined: the message associated with the authorization response displays in the Select Authorization Response Option window.

• AVS response has a message defined: if the authorization response does not have a message defined, the message associated with the AVS response displays in the Select Authorization Option window.

• Card security identification response has a message defined: if the authorization response and AVS response do not have a message defined, the message associated with the card security response displays in the Select Authorization Option window.

Batch order entry: This window does not display if you are performing online credit card authorization during batch order entry.

Order maintenance: The Select Authorization Response Option window displays if you are performing online credit card authorization during order maintenance. You can authorize a credit card during order maintenance by selecting On-line Auth for a credit card payment method.

Field	Description
Order #	The order number containing the credit card payment method that received this authorization response. Numeric, 8 positions; display-only.
Pay type	The description of the credit card payment method that received the authorization response containing this message text. Alphanumeric, 30 positions; display-only.
Credit card #	The credit card number defined for the credit card payment method used on the order. Information will be provided by Oracle at a later date. Alphanumeric, 20 positions; display-only.
Exp date (credit card expiration date)	The date this credit card is no longer valid. Numeric, 4 positions (MMYY format); display-only.
Auth amt	The amount sent for authorization for this credit card. If this credit card was the catch all payment method on the order or the only payment method on the order, this field is blank. Numeric, 13 positions with a 2-place decimal; display-only.
Vendor response pop up window messages # 1 - # 4	The message text from the Pop up window messages # 1 - # 4 fields for the vendor response you received from the account provider. This message text should indicate whether the credit card has been approved or declined and any action that you should take to correct any problems and inform the customer. Alphanumeric, four 40-position fields; display-only.

Screen Option	Procedure
Accept the order	Select Accept Order. The system returns you to the Select Customer Sold To For Order Screen or the Customer Selection Screen if the operator placing the order is a CTI user, and processes the order through the Order Async.
Return to the order to make any corrections or reject the order	Select Edit Order. The system returns you to the Work with Order/Recap Screen or the Enter Payment Method Screen where you can make any corrections or reject the order.

Resending Credit Cards for Authorization

If you did not receive a response from the account provider during order entry or the credit card was declined in order entry, you can resend the credit card for authorization:

• selecting On-line Auth for the credit card at the Enter Payment Methods Screen in Order Maintenance in order maintenance. The system sends the credit card for authorization, waits for a response as in order entry, and displays the Select Authorization Response Option Window if pop up window message text was defined for the vendor response.

• using the Performing Batch Authorization (SATH) menu option. This menu option allows you to send credit cards associated with a selected ship via for authorization.

• during pick slip generation if the Batch/on-line field for the account provider contains a C (on-line and batch authorizations).

Pick Slip Generation

You can generate pick slips for orders that contain pre-paid payment methods, such as cash or check, and/or credit cards that have received an approved authorization by selecting the Preauthorized orders only field in the pick generation template.

If you try to generate pick slips for orders that contain credit cards that have not been authorized with the Preauthorized orders only field selected and the Use Auto Authorization Interface (C14) system control value selected, the system will not send the credit cards up for authorization and will not generate pick slips.

Note:

If you generate pick slips for preauthorized orders only and records exist in the Authorization History table in an S (sent) status, the system updates the records to a D (decline) status. The next time you generate pick slips with the Preauthorized orders only field unselected, the system sends orders associated with records in the Authorization History table in a D status up for authorization.

Receiving authorizations during pick slip generation: If the credit card has not yet received an approved authorization, you can resend the credit card for authorization during pick slip generation if the Preauthorized orders only field in the pick generation template is unselected and the Batch/on-line field for the account provider is set to C (batch and on-line authorization). See Authorizations During Pick Slip Generation for more information on receiving authorizations during pick slip generation.

Authorization Listing Screen

Credit Card Authorization List

The Online Credit Card Authorization Listing is a report you can use to review credit cards that have been authorized, declined, or sent for authorization for a specific date range.

You can generate this report by:

• defining selection criteria at the  and selecting Accept.

• sending credit cards for authorization using the Performing Batch Authorization (SATH) menu option.

Note:

The system generates a similar report when you authorize credit cards during pick slip generation; see Online Credit Card Authorization Listing.

Transmitting and Receiving Deposits

After you obtain an authorization for a credit card charge, you can generate a pick slip for the order, ship the order to the customer, and charge the credit card for the shipment. At this point, you use Processing Auto Deposits (SDEP) to transmit the deposit information to a deposit service for settlement.

Online Authorization Process

Online Credit Card Authorization Setup

Purpose: Before you can receive online credit card authorizations in your company, you must perform the necessary setup. Information requiring creation and setup includes:

• System Control Values

• Number Assignment Value

• Account Provider Settings, including response codes and currency codes

• Order Types eligible for online credit card authorization

• credit card Pay Types

• Pick Slip Generation

System Control Values

System Control Value	Description
On-line Authorizations (B89)	Select this field to indicate you will be performing online credit card authorizations. If this field is unselected, you will not be able to authorize credit cards in order entry or order maintenance.
Authorize Full Amount During Order Entry (G99)	Select this field to indicate you will send an order up for authorization for the full order amount. Deselect this field to indicate you will send an order up for authorization for the shippable order amount.
Online Auth Verification Only (I96)	Select this field to indicate you want the system to process online authorizations for $0.00 for the purpose of validating the card. During batch authorizations, the system authorizes the card for the shippable dollar amount and voids the online authorization for $0.00. If this field is unselected, the system looks at the Authorize Full Amount During Order Entry (G99) system control value to determine the amount sent for authorization.

Number Assignment Value

The number assignment Transaction Sequence # assigns the next available number to the credit card authorization.

Account Provider Settings

• When you are setting up a account provider to support online authorization, please note these required settings:

• Industry code: enter your DBA number.

• Batch/on-line: set to I (on-line) to perform only online credit card authorizations; set to C (on-line or batch) to perform both online credit card authorizations and batch credit card authorizations.

• Response time: set the number of seconds the system waits to receive a response from the account provider before continuing to process the order.

• Pay type cross reference (Paytypes at the Work with Authorization Services Screen): Create a cross-reference for each pay type code for which you wish to receive online credit card authorization, using the vendor pay code information supplied by the account provider.

• Currency cross reference (Currency at the Work with Authorization Services Screen): Create a cross-reference for each currency code you will use on orders receiving online credit card authorizations, using the vendor currency code information supplied by the account provider.

• Vendor responses (Responses at the Work with Authorization Services Screen): Optionally, you can define Vendor response pop up window messages. The messages display in a pop up window in order entry when a credit card that was sent up for authorization is declined. You can enter up to four 40-position lines of message text. Set up vendor responses for authorizations, AVS (if you are performing address verification), and CID (if you are performing credit card identification).

Order Types

You define whether an order type is eligible for online authorizations and if the order type will display a window during order entry when a response is received from the account provider, based on the On-line authorization field:

• Window indicates the order type is eligible for online authorizations and the Select Authorization Response Option Window displays.

• Without Window indicates the order type is eligible for online authorization and the Select Authorization Response Option Window does not display.

• Not Eligible indicates the order type is not eligible for online authorization.

Online authorization for web orders: In order to perform online authorization when Order Administration receives the web order through the Generic Order Interface (Order API), the Online Authorization setting for the order type on the web order must be set to Without Window.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Pay Types

Each credit card pay type eligible for online authorization should have the account provider set up as its authorization and deposit service. See Working with Pay Types (WPAY) for more information on setting up pay types.

Pick Slip Generation

If you wish to generate pick slips only for orders that contain pre-paid payment methods and/or credit cards that have received an authorization, you can create a pick slip generation template with the Preauthorized orders only field selected.

Processing Authorizations and Deposits Using Point-to-Point Communication

Purpose: Processing authorizations and deposits using point-to-point communication, allows you to post transactions directly to the account provider in the format required by the account provider.

Available Point-to-Point Integrations

Integration	See:
Oracle Retail Customer Engagement Stored Value Card integration: Allows you to process the stored value card transactions between Order Administration and Oracle Retail Customer Engagement in Oracle Retail Customer Engagement’s message format.	Customer Engagement Stored Value Card Integration for an overview and more information on the Oracle Retail Customer Engagement messages used to process stored value card transactions between Order Administration and the Oracle Retail Customer Engagement system using point-to-point communication.

For more information: See:

• Stored Value Card Integration for more information on how to process stored value card transactions.

• Processing Auto Deposits (SDEP) for more information on deposit processing in Order Administration.

PayPal Direct Connection Integration

Purpose: The PayPal Direct Connection integration enables you to use PayPal as a method of payment on web orders.

• The web storefront sends the PayPal payment on the order directly to PayPal for authorization. The order must receive an approved authorization on the web storefront before it is sent to Order Administration for processing.

• During pick slip generation, Order Administration verifies that the amount required to generate the pick slip is covered by the authorization received for the PayPal payment during web storefront processing. If the amount is not covered, the system places the order on Credit Card Decline hold and the PayPal payment on PayPal Decline hold.

• During deposit processing, Order Administration sends the deposit transaction directly to PayPal for confirmation and settlement.

• When an order is canceled or the PayPal payment method deactivated, Order Administration sends an authorization reversal request to PayPal.

PayPal is an e-commerce business that allows you to perform payment and money transfers securely over the Internet. PayPal’s service builds on the existing financial infrastructure of bank accounts and credit cards and utilizes fraud prevention systems to create a safe, global, real-time payment solution.

Note:

PayPal is a registered trademark

The Order Administration PayPal Direct Connection integration allows you to use PayPal as a form of payment on web orders and send the deposit transactions directly to PayPal.

Note:

Because the PayPal Direct Connection Integration does not send authorization transactions between Order Administration and PayPal, web orders containing a PayPal payment must receive an approved authorization on the web storefront before being sent to Order Administration for processing. In addition, you can only use PayPal as a form of payment on web orders. The Order Administration PayPal Direct Connection integration does not support PayPal as a form of payment on non-web orders.

In this topic: This topic provides an overview of the PayPal Direct Connection integration and the required setup.

• PayPal Direct Connection Integration Process

• Processing Orders Containing a PayPal Payment

  • Validating a Web Order that Contains a PayPal Payment

  • Maintaining a PayPal Order

  • Applying Refunds Across Multiple Capture Transaction IDs

• Processing Authorizations for a PayPal Order

  • PayPal Authorization Processing

  • Approved PayPal Authorizations

  • Declined PayPal Authorizations

• Processing Deposits for a PayPal Order

  • PayPal Deposit Processing

  • Approved PayPal Deposits

  • Failed PayPal Deposits

• Purchase Deposit Transactions

  • PayPal DoCapture Request

  • PayPal DoCapture Response

• Return Deposit Transactions

  • PayPal RefundTransaction Request

  • PayPal RefundTransaction Response

• PayPal Authorization Reversals

  • PayPal DoVoid Transaction Request

  • PayPal DoVoid Transaction Response

• PayPal Direct Connection Integration Restrictions

• PayPal Direct Connection Integration Troubleshooting

  • PayPal Log

• PayPal Direct Connection Integration Setup

  • Creating the PayPal Decline Order Hold Reason

  • Creating the PPL (PayPal) Account Provider

  • Creating a PayPal Pay Type

PayPal Direct Connection Integration Process

• Processing Orders Containing a PayPal Payment

  • Validating a Web Order that Contains a PayPal Payment

  • Maintaining a PayPal Order

• Processing Authorizations for a PayPal Order

• Processing Deposits for a PayPal Order

PayPal Direct Connection integration illustration:

Processing Orders Containing a PayPal Payment

When a customer places an order on the web storefront and pays for the order using a PayPal account:

• The web storefront sends an authorization request for the PayPal payment directly to PayPal.

• PayPal validates the PayPal account number that is passed in the authorization request and sends PayPal confirmation information back to the web storefront.

• The web storefront completes the order and sends the order to Order Administration in the Inbound Order XML Message (CWORDERIN).

Web orders containing a PayPal payment that has been authorized by PayPal contain the following information in the Inbound Order XML Message (CWORDERIN). The authorization for the PayPal payment is sent to Order Administration as a manual authorization.

For more information see the Web Services Guide on My Oracle Support (ID 2953017.1).

• Regular order information

• PayPal pay type passed in the payment_type field

• PayPal transaction ID passed in the cc_number field

• Approved PayPal payment:

  • auth_amount

  • auth_number (this is the first 16 positions of the PayPal transaction ID)

  • auth_date (this is the date the PayPal payment was authorized with PayPal)

Validating a Web Order that Contains a PayPal Payment

Because the PayPal Direct Connection Integration does not send authorization transactions between Order Administration and PayPal, web orders containing a PayPal payment must receive an approved authorization on the web storefront before being sent to Order Administration for processing.

If Order Administration receives a web order that contains a PayPal payment that has not yet received an approved authorization, the system will accept the order; however, the PayPal payment will fail batch authorization and you will not be able to generate a pick slip for the order. See Processing Authorizations for a PayPal Order.

Maintaining a PayPal Order

When you advance to an order in order maintenance that contains a pay type with PPL (PayPal) defined as the authorization service and deposit service, the system displays the PayPal Warning Window indicating that you should not make any changes to the order that would increase the order total. When you generate a pick slip for an order that contains a PayPal payment, the system validates that the amount required to generate the pick slip does not exceed 15% or $75.00 of the initial authorization amount that was received from PayPal during web storefront processing.

Examples:

• If the authorization received from PayPal during web storefront processing is $100.00, you can increase the order total up to $115.00 ($100.00 + 15% = $115.00) and still process the order without any problems. However, once you exceed $115.00, the PayPal payment will fail batch authorization and the system will not generate a pick slip or perform drop ship processing for the order.

• If the authorization received from PayPal during web storefront processing is $600.00, you can increase the order total up to $675.00 and still process the order without any problems. However, once you exceed $675.00, the PayPal payment will fail batch authorization and the system will not generate a pick slip or perform drop ship processing for the order. Note: The system does not allow you to increase the order total by 15% ($600.00 + 15% = $690.00) because it would exceed $75.00 of the initial authorization amount that was received from PayPal during web storefront processing.

Reversals? The system submits a reversal to PayPal if:

• The entire order is canceled or sold out, or;

• The payment method is deactivated before any transactions are billed.

The system does not submit a reversal to PayPal for a partial amount, such as when:

• A single item on a multi-line order is canceled or sold out.

• A single unit on an order line is canceled or sold out.

• Any items remaining on the order are canceled after a shipment has taken place.

Also, the reversal is not submitted if any of the order lines have been submitted to Order Orchestration for fulfillment.

For more information: See Stored Value Card Authorization Reversal.

Applying Refunds Across Multiple Capture Transaction IDs

PayPal cannot process a refund that exceeds the amount of the initial deposit. For example, if an order includes two deposits of $25.00, PayPal requires that any single refund processed not exceed $25.00.

In order to be able to reconcile refunds against the initial deposits, Order Administration stores the TRANSACTIONID provided by PayPal for each deposit as the Capture Transaction ID in the Credit Card Deposit History table for each successful deposit with PayPal, so that each refund amount applies to a deposit amount.

Example: You process an order in two shipments:

• Shipment 1: $50.00

• Shipment 2: $40.00

During deposit processing, the capture transaction ID for each shipment is stored in the Credit Card Deposit History table. This ID is not displayed on any screen.

If you then need to process one or more refunds against the order, Order Administration uses the capture transaction IDs to reconcile the refund amounts. It uses the capture transaction ID that matches the refund amount, if any; otherwise, it uses the capture transaction ID for the lowest total shipment that exceeds the refund amount. For example:

• If the refund amount is $40.00: Use the capture transaction ID for shipment 2, because the amount matches this shipment.

• If the refund amount is $50:00: Use the capture transaction ID for shipment 1, because the amount matches this shipment.

• If the refund amount is $45:00: Use the capture transaction ID for shipment 1 (because $45.00 is more than the amount for shipment 2).

• If the refund amount is $25.00: Use the capture transaction ID for shipment 1 (because $25.00 does not match the amount of either deposit).

• If the refund amount is more than $50.00: Split the refund across both capture transaction IDs.

Sometimes multiple capture transaction ID are used for a refund deposit, because no single transaction is large enough to cover the refund. In these cases, the Display Order Payment History Screen indicates the number of deposits used for the total refund amount. For example, if you process a refund totaling $60.00 for an order with the two shipments, one for $50.00 and another for $25.00, the Display Order Payment History screen indicates:

• Partial Deposit confirmed $50.00-

• Partial Deposit confirmed $10.00-

• Deposit split into 2 separate deposits.

• Deposit confirmed $60.00-

Note:

These messages are not displayed at the Payment Method Details panel in Contact Center (Modern View Order Summary), although the purchase and deposit amounts are displayed.

In this situation, there is also an Order Transaction History message written, for example: Refund for inv# 1234 exceeds PayPal limit. Note that the message may be truncated based on the size of the invoice number.

Multiple refunds? Order Administration tracks the total returned amount for PayPal payment methods in order to ensure that subsequent refunds do not result in overusing any individual deposit amounts. For example, if there was a deposit for $50.00 and a deposit of $10.00, and there is already a refund amount of $40.00 applied to the first deposit, leaving $10.00 unrefunded, a subsequent refund of $15.00 would be split across the two deposits.

If the deposit fails: When the deposit is not initially processed successfully and you use Manage Rejected Deposits in Modern View instead, no capture transaction ID is recorded, so a refund cannot be applied to the deposit.

Note:

Deposits processed before update 20.0 will not have a capture transaction ID, so the process described above does not apply to these deposits.

Processing Authorizations for a PayPal Order

The system calls authorization processing when you generate a pick slip or perform drop ship processing for an order that contains a pay type with PPL (PayPal) defined as the authorization service. During authorization processing for an order that contains a PayPal pay type, the system validates that the required authorization amount is covered by the initial authorization received for the PayPal payment during web storefront processing.

• Approved PayPal Authorizations

  • Example: Approved PayPal Authorization

  • Example: Multiple Approved PayPal Authorizations

  • Example: Approved PayPal Authorization for Amount Within Allowed 15%

  • Example: Approved PayPal Authorization and Credit Card Authorization

• Declined PayPal Authorizations

  • Example: Declined PayPal Authorization for Amount Over 15%

  • Example: Declined PayPal Authorization for Amount Over $75.00

Note:

Orders containing a PayPal payment should have received an authorization from PayPal on the web storefront before the order was received into Order Administration. The system does not send a PayPal payment to PayPal for authorization during pick slip generation or drop ship processing.

PayPal Authorization Processing

The system performs the following steps during PayPal authorization processing.

#	Step
1.	The system determines if a manual authorization exists for the PayPal payment on the order.
	If a manual authorization does not exist for the PayPal payment on the order, the system declines the authorization. See Declined PayPal Authorizations for the updates that the system performs.
	If a manual authorization exists for the PayPal payment on the order, the system determines if this if the first time authorization processing was called for the PayPal payment on the order.
2.	If this is the first time authorization processing was called for the PayPal payment on the order, the system: Creates an order history record indicating the manual authorization was detected. This record indicates: The date when the order history record was created. The first 16 positions of the PayPal transaction ID. The amount that was manually authorized. This is the amount that was authorized by PayPal on the web storefront. Creates an authorization history record for the manual authorization. This record indicates: That the authorization was authorized. The first 16 positions of the PayPal transaction ID in the Authorization # field. The date the PayPal payment was authorized by PayPal on the web storefront. The date the authorization expires. The amount authorized for the PayPal payment. The amount available to apply towards other authorization requests. This amount equals the amount authorized until the system approves an authorization request.

Order history record for manual authorization: The system creates an order history record for the authorization that was received from PayPal on the web storefront. For example:

Date	Type	Transaction Note	Amount	User
7/28/09	AUTH	MANUAL AUTH# DETECTED - O-AUTH_CODE	100.00	AUTH

Authorization history record for manual authorization: The system creates an approved authorization history record for the authorization that was received from PayPal on the web storefront. For example:   

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	100.00

#	Step
3.	The system determines if the initial authorization has expired. The system uses the following calculation to determine the expiration date: authorization date from Authorization History table + Reauthorization days from Pay Type table = authorization expiration date For example, if the initial authorization date is 7/01/09 and the Reauthorization days is 29, the initial authorization expires on 7/29/09 (7/01/09 + 29 = 7/29/09). If the initial authorization has expired, the system declines the authorization. See Declined PayPal Authorizations for the updates that the system performs.
4.	The system determines if the amount of the authorization request exceeds the manual authorization. The system allows the authorization request amount to be 15%, or up to $75.00, over the initial authorization amount. For example: If the manual authorization is for $100.00, the authorization request cannot exceed $115.00 ($100.00 + 15% = $115.00). If the manual authorization is for $600.00, the authorization request cannot exceed $675.00. The system does not allow an increase of 15% to the $600.00 authorization because 15% of $600.00 exceeds $75.00 (600.00 + 15% = 690.00). If the authorization request amount exceeds the initial authorization by 15% or $75.00, the system declines the authorization. See Declined PayPal Authorizations for the updates that the system performs. Orders that Contain a Catch-All Credit Card Pay Type If the order contains a catch-all credit card pay type in addition to the PayPal pay type, instead of declining the PayPal authorization, the system adds the amount that exceeds the manual authorization to the catch-all credit card pay type on the order. In this situation, the system approves the PayPal authorization for the manual authorization amount and applies the amount not covered by the manual authorization to the catch-all credit card. For example, if the manual authorization for the PayPal pay type is $100.00 and the order total is $124.00, the system approves the PayPal authorization request for $100.00 and applies $24.00 towards the catch-all credit card on the order.
5.	If the amount of the authorization request is covered by the manual authorization or exceeds the manual authorization but is within the 15% or $75.00 allowance, the system approves the authorization. If the approved authorization amount exceeds the manual authorization, the system creates a new authorization history record for the extra amount. This record indicates: That the authorization was authorized. The first 16 positions of the PayPal transaction ID in the Authorization # field. The date the PayPal payment was authorized; this is the date the initial authorization was received from PayPal. The date the authorization expires. The extra amount authorized for the PayPal payment. See Approved PayPal Authorizations for the updates that the system performs.

Approved PayPal Authorizations

If the authorization received for the PayPal payment during web storefront processing covers the amount in the authorization request, the system:

• Generates a pick slip or performs drop ship processing for the order.

• Decreases the Amount available for the initial authorization history record by the authorization request amount. For example, if the initial authorization amount received on the web storefront is $100.00, and the authorization request amount is $28.00, the remaining amount available on the initial authorization is $72.00.

• If the authorization request amount exceeds the manual authorization received for the PayPal payment, but is within the 15% or $75.00 allowance, the system creates a new authorization history record for the extra amount.

Updated authorization history record for manual authorization:

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	72.00

New authorization history record for the amount not covered by the manual authorization but within the 15% or $75.00 allowance:

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	7/28/09	8/26/09	12.00	.00

Example: Approved PayPal Authorization

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00 and PayPal authorizes the payment for $100.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-CC_NUMBER (this is the PayPal transaction ID)

• auth_amount = 100.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the authorization date.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $100.00. Because the unused authorization amount of $100.00 covers the amount required to generate a pick slip for the order, the system:

• Generates the pick slip.

• Creates an order history record:

Date	Type	Transaction Note	Amount	User
6/26/09	AUTH	MANUAL AUTH# DETECTED - O-AUTH_CODE	100.00	AUTH

• Creates an authorization history record for the PayPal payment on the order.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	100.00	.00

Example: Multiple Approved PayPal Authorizations

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00 and PayPal approves the payment for $100.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

• auth_amount = 100.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the authorization date.

You generate a pick slip for part of the order. The authorization amount required to generate a pick slip for the order is $42.00. Because the unused authorization amount of $100.00 covers the amount required to generate a pick slip for the order, the system:

• Generates the pick slip.

• Creates an order history record:

Date	Type	Transaction Note	Amount	User
6/26/09	AUTH	MANUAL AUTH# DETECTED - O-AUTH_CODE	100.00	AUTH

Creates an authorization history record.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	100.00	58.00

You generate a pick slip for the remainder of the order. The authorization amount required to generate a pick slip for the order is $58.00. Because the unused authorization amount of $58.00 covers the amount required to generate a pick slip for the order, the system:

• Generates the pick slip.

• Updates the authorization history record.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	58.00	0.00

Example: Approved PayPal Authorization for Amount Within Allowed 15%

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00 and PayPal approves the payment for $100.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

• auth_amount = 100.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the authorization date.

You maintain the order and as a result the order total increases to $110.50.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $110.50. Because the required authorization amount is within 15% of the unused authorization amount of $100.00, the system:

• Generates the pick slip.

• Creates an order history record:

Date	Type	Transaction Note	Amount	User
6/27/09	AUTH	MANUAL AUTH# DETECTED - O-AUTH_CODE	100.00	AUTH

Creates authorization history records:

• One authorization history record for the original authorization amount received from PayPal on the web storefront.

• One authorization history record for the amount that was over the original authorization amount, but within 15% of the original authorization amount.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	100.00	0.00
Authorized	O-AUTH_CODE	6/26/09	7/25/09	10.50	0.00

Example: Approved PayPal Authorization and Credit Card Authorization

Declined PayPal Authorizations

If the authorization received for the PayPal payment during web storefront processing does not cover the authorization request amount, the system places the order on hold and does not generate a pick slip or perform drop ship processing for the order.

The system declines the PayPal authorization for the following reasons:

• A manual authorization does not exist for the PayPal payment, or

• The initial authorization received from PayPal on the web storefront has expired, or

• The authorization request amount exceeds 15% of the initial authorization amount received from PayPal on the web storefront, or

• The authorization request amount exceeds $75.00 of the initial authorization amount received from PayPal on the web storefront.

If the authorization received for the PayPal payment during web storefront processing cannot cover the authorization request amount, or a manual authorization for the PayPal payment does not exist, the system:

• Does not generate a pick slip or perform drop ship processing for the order.

• If the authorization was declined because the initial authorization has expired, the system updates the Amount available for the initial authorization history record to zero. For example:

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09 EXPIRED	100.00	.00

• If the authorization was declined because the initial authorization amount cannot cover the authorization request amount, the system does not update the initial authorization history record. For example:

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	7/27/09	8/25/09	100.00	100.00

• Creates an authorization history record for the declined authorization amount. For example:

Status	Vendor Response	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Declined	PPLDECLINE		7/27/09	8/25/09	39.00	.00

• Places the order on Declined Credit Card (AT) hold and the PayPal payment on the hold reason defined for the PPLDECLINE response code (typically PP PayPal Decline). Note:

• If the PPLDECLINE response code has not been set up for the PPL account provider, the system places the order on AV hold.

• If the PPLDECLINE response code exists, but a hold reason is not defined for the response code, the system does not place the order on hold, but does not generate a pick slip for the order since the initial authorization for the PayPal payment is not valid.

• Creates order history records indicating the authorization was declined and the order as put on hold. For example:

Date	Type	Transaction Note	Amount	User
7/27/09	PICKGEN	ORDER FLAGGED FOR CREDITCARD CANCELLATIO		USER
7/27/09	HOLD	SYS HLD - DECLINED CREDIT CARD	39.00	USER

Correcting PayPal authorization declines: If Order Administration declines the PayPal authorization request, you will need to correct the error by either:

• Maintaining the order and reducing the order total so that it does not exceed 15% or $75.00 of the initial authorization amount received from PayPal on the web storefront.

• Calling the customer on the order to ask for an additional form of payment to cover the amount that exceeds the initial authorization amount received from PayPal on the web storefront.

• Canceling the order.

Note:

Before you run pick slip generation or perform drop ship processing for the order again, make sure to remove the order from hold.

Example: Declined PayPal Authorization for Amount Over 15%

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00 and PayPal approves the payment for $100.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

• auth_amount = 100.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the current date.

You maintain the order and as a result the order total increases to $122.50.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $122.50. Because the unused authorization amount of $100.00 does not cover the amount required to generate a pick slip for the order, and the amount required exceeds 15% of the unused authorization, the system:

• Does not generate a pick slip.

• Declines the PayPal authorization.

• Places the order on Credit Card Decline (AT) hold and the PayPal payment on the hold reason defined for the PPLDECLINE response code.

• Creates order history records, indicating the PayPal authorization was declined:

Date	Type	Transaction Note	Amount	User
6/26/09	AUTH	MANUAL AUTH# DETECTED - O-42693038SP2401	100.00	AUTH
6/26/09	PICK GEN	ORDER FLAGGED FOR CREDITCARD CANCELLATIO		USER
6/26/09	HOLD	SYS HLD - DECLINED CREDIT CARD	22.50	USER

Creates authorization history records for the PayPal payment on the order, indicating the authorization was declined.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	100.00	100.00
Declined		6/26/09	7/25/09	22.50	0.00

The system allows you to generate a pick slip for the order if:

• You maintain the order and decrease the amount so that it does not exceed 15% of the unused PayPal authorization ($115.00), or

• You maintain the order and apply the amount that exceeds 15% of the unused PayPal authorization towards another form of payment.

Example: Declined PayPal Authorization for Amount Over $75.00

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $600.00 and PayPal approves the payment for $600.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

• auth_amount = 600.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the current date.

You maintain the order and as a result the order total increases to $680.00.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $680.00. While $680.00 is within 15% of the unused PayPal authorization, it is greater than $75.00 of the unused authorization. Because the authorization amount required to generate a pick slip for the order ($680.00) is greater than $75.00 of the unused PayPal authorization ($600.00), the system:

• Does not generate a pick slip.

• Declines the PayPal authorization.

• Places the order on Credit Card Decline (AT) hold and the PayPal payment on the hold reason defined for the PPLDECLINE response code.

• Creates order history records, indicating the PayPal authorization was declined:

Date	Type	Transaction Note	Amount	User
6/26/09	AUTH	MANUAL AUTH# DETECTED - O-42693038SP2401	600.00	AUTH
6/26/09	PICK GEN	ORDER FLAGGED FOR CREDITCARD CANCELLATIO		USER
6/26/09	HOLD	SYS HLD - DECLINED CREDIT CARD	80.00	USER

Creates authorization history records for the PayPal payment on the order, indicating the authorization was declined.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	600.00	600.00
Declined		6/26/09	7/25/09	80.00	0.00

The system allows you to generate a pick slip for the order if:

• You maintain the order and decrease the amount so that it does not exceed $75.00 of the unused PayPal authorization ($675.00), or

• You maintain the order and apply the amount that exceeds $75.00 of the unused PayPal authorization towards another form of payment.

Example: Initial PayPal Authorization Expired

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00. Due to communication problems, the web storefront cannot send the PayPal payment to PayPal for approval. The web storefront sends the order to Order Administration without a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

Order Administration receives and processes the order.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $100.00. Because a manual authorization does not exist for the PayPal payment on the order, the system:

• Does not generate a pick slip.

• Declines the PayPal authorization.

• Places the order on Credit Card Decline (AT) hold and the PayPal payment on the hold reason defined for the PPLDECLINE response code.

• Creates order history records, indicating the PayPal authorization was declined:

Date	Type	Transaction Note	Amount	User
6/26/09	PICK GEN	ORDER FLAGGED FOR CREDITCARD CANCELLATIO		USER
6/26/09	HOLD	SYS HLD - DECLINED CREDIT CARD	100.00	USER

Creates an authorization history record for the PayPal payment on the order, indicating the authorization was declined.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Declined		6/26/09	7/25/09	100.00	0.00

Processing Deposits for a PayPal Order

When you process deposits for an order that contains a pay type with PPL (PayPal) defined as the deposit service, the system sends the deposit transaction directly to PayPal via PayPal SOAP API architecture.

• PayPal Deposit Processing

  • Approved PayPal Deposits

  • Failed PayPal Deposits

• Purchase Deposit Transactions

  • PayPal DoCapture Request

  • PayPal DoCapture Response

• Return Deposit Transactions

  • PayPal RefundTransaction Request

  • PayPal RefundTransaction Response

PayPal Deposit Processing

The system performs the following steps during PayPal deposit processing.

#	Step
1.	Determines if the deposit is for a debit or credit transaction. If the deposit transaction is for a debit transaction, the system sends the PayPal DoCapture Request to PayPal. If the deposit transaction is for a credit transaction, the system sends the PayPal RefundTransaction Request to PayPal.
2.	PayPal processes the deposit and sends the response back to Order Administration. If the deposit transaction is for a debit transaction, PayPal sends the PayPal DoCapture Response to Order Administration. If the deposit transaction is for a credit transaction, PayPal sends the PayPal RefundTransaction Response to Order Administration.
3.	Order Administration receives the response and processes the deposit. See Approved PayPal Deposits and Failed PayPal Deposits.

Approved PayPal Deposits

If the deposit for the PayPal payment was approved, the system:

• For debit transactions, updates the authorization history record with the deposit amount. For example:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Dep
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	28.00

• Creates a deposit history record for the deposit transaction.

For debit transactions:

Inv#	Type	Date	Amt	Status	Response	Action
467	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit

For credit transactions:

Inv#	Type	Date	Amt	Status	Response	Action
479	*RETURN	7/30/09	20.00-	CONFIRMED	*PROCESSED	Return

• For debit transactions:

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response. However, if a transaction ID is already defined in the Authentication value field, the system replaces the transaction ID only if the deposit amount for the current deposit transaction is equal to or greater than the deposit amount for the previous deposit transaction. For example, If you process two deposit transactions for a PayPal order: the first deposit for $25.00 and the second deposit for $40.00, when you process the second deposit, the system updates the transaction ID defined in the Authentication value field with the transaction ID returned for the second deposit since the second deposit amount ($40.00) is greater than the first deposit amount ($25.00).

• During deposit processing, updates the Credit Card Deposit History table with the transaction ID for each successful deposit, storing it as the capture transaction ID. The system then uses this capture transaction ID to tie refunds, if generated, to individual deposits; see Applying Refunds Across Multiple Capture Transaction IDs for more information. This ID is not displayed on any screen.

Example: Approved PayPal Deposit Across Multiple Authorizations

The PayPal payment on an order has the following authorization history records:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	.00
Authorized	O-AUTH_CODE	7/28/09	8/26/09	12.00	.00	.00

You submit a debit deposit transaction for the PayPal payment for $112.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history records with the deposit amount of $112.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	100.00
Authorized	O-AUTH_CODE	7/28/09	8/26/09	12.00	.00	12.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
469	*PURCH	7/28/09	112.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response.

Example: Approved PayPal Deposit Across Multiple Deposits; Authentication Value Updated

The PayPal payment on an order has the following authorization history record:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	.00

You submit a debit deposit transaction for the PayPal payment for $28.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $28.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	28.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
469	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response.

• You submit a second debit deposit transaction for the PayPal payment for $28.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $28.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	56.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
469	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit
470	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response. The system performs this update because the deposit amount for the current deposit transaction ($28.00) is equal to the deposit amount for the previous deposit transaction.

• You submit a third debit deposit transaction for the PayPal payment for $44.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $44.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	44.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
469	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit
470	*PURCH	7/29/09	28.00	CONFIRMED	*PROCESSED	Deposit
471	*PURCH	7/30/09	44.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response. The system performs this update because the deposit amount for the current deposit transaction ($44.00) is greater than the deposit amount for the previous deposit transaction ($28.00).

Example: Approved PayPal Deposit Across Multiple Deposits; Authentication Value Not Updated

The PayPal payment on an order has the following authorization history record:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	.00

You submit a debit deposit transaction for the PayPal payment for $56.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $56.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	56.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
472	*PURCH	7/28/09	56.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response.

• You submit a second debit deposit transaction for the PayPal payment for $44.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $44.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	44.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
472	*PURCH	7/28/09	56.00	CONFIRMED	*PROCESSED	Deposit
473	*PURCH	7/28/09	44.00	CONFIRMED	*PROCESSED	Deposit

• Does not update the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response. The system does not update this field because the deposit amount for the current deposit transaction ($44.00) is less than the deposit amount for the previous deposit transaction ($56.00).

Example: Approved PayPal Deposit and Catch-All Credit Card Deposit

The PayPal pay type on an order has the following authorization history record:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	.00

The catch-all credit card pay type on the order has the following authorization history record:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	AUTH_#	7/28/09	8/26/09	24.00	.00	.00

You submit a debit deposit transaction for the order for $124.00. Order Administration:

• Sends the deposit transaction for the credit card to the account provider for deposit processing.

• Sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history records with the deposit amount of $124.00.

PayPal pay type:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	124.00

Catch-all Credit Card pay type:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	AUTH_#	7/28/09	8/26/09	24.00	.00	24.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action	Ser
475	*PURCH	7/28/09	100.00	CONFIRMED	*PROCESSED	Deposit	PPL
475	*PURCH	7/28/09	24.00	CONFIRMED	100	Deposit	PMT

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response.

Example: Approved PayPal Credit Deposit

The PayPal payment on an order has the following authorization history records:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/30/09	8/28/09	100.00	.00	100.00
Authorized	O-AUTH_CODE	7/30/09	8/28/09	14.19	.00	14.19

A debit deposit history record exists for the order:

Inv#	Type	Date	Amt	Status	Response	Action
480	*PURCH	7/30/09	114.20	CONFIRMED	*PROCESSED	Deposit

The customer returns part of the order for a credit of $22.00.

You submit a credit deposit transaction for the PayPal payment for $22.00. Order Administration sends the deposit transaction to PayPal in the PayPal RefundTransaction Request and receives the approved response in the PayPal RefundTransaction Response.

Order Administration creates a deposit history record for the credit deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
481	*PURCH	7/30/09	22.00-	CONFIRMED	*PROCESSED	Return

Failed PayPal Deposits

The deposit transaction will be rejected if:

• Communication failures occur between Order Administration and PayPal.

• A duplicate deposit transaction already exists on the PayPal system.

• For debit deposit transactions:

  • The debit amount is greater than the associated authorization amount.

  • The transaction ID defined for the deposit does not match the associated authorization transaction.

• For credit deposit transactions:

  • The transaction ID defined for the deposit does not match the associated debit deposit transaction.

  • The credit amount is greater than the deposit amount.

For example, the PayPal payment on an order receives an authorization for $100.00.

On 6/24, the system ships part of the order for $40.00.

On 6/30, the system ships the rest of the order for $60.00.

On 7/15, the system processes a return for the order for $75.00.

Because the return amount of $75.00 is greater than each deposit amount, PayPal fails the return deposit.

Correcting failed deposits: You can use the Submit Rejected Deposits (SRDP) menu option to cancel or resend failed deposits.

See PayPal Direct Connection Integration Troubleshooting.

Purchase Deposit Transactions

Deposits for a debit (*PURCH) transaction use the PayPal DoCapture method to process the settlement. The system uses the API credentials (API User name, API Password, and API Signature) defined for the PPL account provider as the credentials used to establish a direct connection to the PayPal system during deposit processing.

PayPal DoCapture Request

Order Administration sends the purchase deposit transaction to PayPal in the PayPal DoCapture Request transaction.

Parameter	Description
METHOD	DoCapture. Transactions sent to PayPal for a purchase deposit use the PayPal DoCapture API.
AUTHORIZATION ID	The transaction ID from the Credit card # field in the Order Payment Method table.
AMT	The amount of the deposit transaction. PayPal will accept an amount that is up to 15% or $75.00 more than the original authorization amount. Note:  This amount cannot exceed $10,000.
CURRENCYCODE	The PayPal currency code, from the ASC Currency code field in the Auth Service Currency table that corresponds to the Currency in the Order Header Extended table. If the Currency in the Order Header Extended table is blank, the system uses the currency code defined in the Local Currency Code (A55) system control value to determine which ASC Currency code in the Auth Service Currency table to use. If a cross reference is not defined in Authorization Service Currency for the selected currency code, the system leaves the CURRENCYCODE in the PayPal DoCapture Request blank; PayPal treats a blank CURRENCYCODE as USD currency. See the Work with Authorization Service Currency Screen to cross-reference the Order Administration currency code to the PayPal currency code.
COMPLETETYPE	NotComplete. This value indicates that there may be additional captures.
INVNUM	The company number and invoice number. Also includes the ecommerce order number if the Append Ecommerce Order # to PayPal Invoice ID (M40) system control value is selected. The company number and invoice number include leading zeros. Example:  006-0000467-EC12345, where 006 is the company number, 0000467 is the invoice number, and EC12345 is the ecommerce order number.
NOTE	The charge description from the Charge description field in the Authorization Service table, followed by the order number. A plus sign (+) displays for each space. Example:  PAYPAL+DIRECT+COMMUNICATION+1845, where PAYPAL DIRECT COMMUNICATION is the charge description and 1845 is the order number.

PayPal DoCapture Response

Order Administration receives the purchase deposit response transaction from PayPal in the PayPal DoCapture Response transaction.

Parameter	Description
AUTHORIZATION ID	The transaction ID from the card number field in the Order Payment Method table.
TRANSACTIONID	The unique transaction ID assigned by PayPal to the deposit confirmation. Updates the Authentication value field in the Order Payment Method table. However, if a transaction ID is already defined in the Authentication value field, the system replaces the transaction ID only if the deposit amount for the current deposit transaction is equal to or greater than the deposit amount for the previous deposit transaction. Example:  If you process two deposit transactions for a PayPal order: the first deposit for $25.00 and the second deposit for $40.00, when you process the second deposit, the system updates the transaction ID defined in the Authentication value field with the transaction ID returned for the second deposit since the second deposit amount ($40.00) is greater than the first deposit amount ($25.00). Capture transaction ID: During deposit processing, the system updates the Credit Card Deposit History table with this transaction ID for each successful deposit, storing it as the capture transaction ID. The system then uses this capture transaction ID to tie refunds, if generated, to individual deposits; see Applying Refunds Across Multiple Capture Transaction IDs for more information. This ID is not displayed on any screen.
PARENT TRANSACTIONID
PAYMENTTYPE	Indicates whether the payment is instant or delayed.
ORDERTIME	The date and time when the payment was processed by PayPal. Example:  2009-07-24T17:23:15Z
AMT	The final amount charged, including any shipping and taxes from the Merchant Profile.
FEEAMT	The PayPal fee amount charged for the transaction.
SETTLEAMT	The amount deposited in the merchant’s PayPal account if there is a currency conversion.
EXCHANGERATE	The exchange rate if a currency conversion occurred.
PAYMENTSTATUS	Order Administration considers a deposit successful if the following status is received: Completed = The payment was completed, and the funds were added successfully to the merchant’s account balance. Refunded = The merchant refunded the payment. Processed = A payment was accepted. The system considers any other response a rejected deposit. Updates the Response field in the Deposit History table.

Return Deposit Transactions

Deposits for a credit (*RETURN) transaction use the PayPal RefundTransaction method to process the settlement. The system uses the API credentials (API User name, API Password, and API Signature) defined for the PPL account provider as the credentials used to establish a direct connection to the PayPal system during deposit processing.

PayPal RefundTransaction Request

Order Administration sends the return deposit request transaction to PayPal in the PayPal RefundTransaction Request transaction.

Parameter	Description
METHOD	RefundTransaction. Transactions sent to PayPal for a return deposit use the PayPal RefundTransaction API.
TRANSACTIONID	The transaction ID from the Authentication value field in the Order Payment Method table for the record associated with the first non-deactivated PayPal pay type. This ID is also stored in the Credit Card Deposit History table as the capture transaction ID. The system uses this value to match a purchase deposit to the return deposit. When a refund is applied across multiple transactions, the system uses the capture transaction IDs to reconcile the refund amounts and submits each refund amount separately based on the originating capture transaction ID. See Applying Refunds Across Multiple Capture Transaction IDs for a discussion. If a transaction ID does not exist in the Authentication value, the system sends a blank Authorization ID field to PayPal. Because PayPal cannot match a purchase deposit to the return deposit, the system places the return deposit in a failed status.
REFUNDTYPE	The type of refund to make. Set to Partial.
AMT	The amount of the deposit (refund) transaction. Return Amount PayPal does not accept returns for an amount that is greater than the original deposit amount. For example, the PayPal payment on an order receives an authorization for $100.00. On 6/24, the system ships part of the order for $40.00. On 6/30, the system ships the rest of the order for $60.00. On 7/15, the system processes a return for the order for $75.00. Because the return amount of $75.00 is greater than each deposit amount, PayPal fails the return deposit.
NOTE	The charge description from the Charge description field in the Authorization Service table, followed by the order number. A plus sign (+) displays for each space. Example:  PAYPAL+DIRECT+COMMUNICATION+1845, where PAYPAL DIRECT COMMUNICATION is the charge description and 1845 is the order number.

PayPal RefundTransaction Response

Order Administration receives the return deposit response transaction from PayPal in the PayPal RefundTransaction Response transaction.

Parameter	Description
REFUND TRANSACTIONID	The unique transaction ID assigned by PayPal to the deposit confirmation.
NETREFUNDAMT	The amount subtracted from the PayPal balance of the original recipient of payment to make this refund.
FEEREFUNDAMT	The transaction fee refunded to the original recipient of payment.
GROSSREFUND AMT	The amount of money refunded to the original payer.

PayPal Authorization Reversals

Authorization reversals use the PayPal DoVoid method to request the reversal. The system uses the API credentials (API User name, API Password, and API Signature) defined for the PPL account provider as the credentials used to establish a direct connection to the PayPal system when processing a stored value card authorization trigger record (File/Key = AHR).

Sent when? The system creates authorization reversal triggers only if the Send reversal flag is selected for PayPal in Defining Authorization Services (WASV). Also, the system sends a DoVoid request for a reversal only if:

• The entire order is canceled or sold out, or;

• The payment method is deactivated before any transactions are billed.

The system does not submit a reversal to PayPal for a partial amount, such as when:

• A single item on a multi-line order is canceled or sold out.

• A single unit on an order line is canceled or sold out.

• Any items remaining on the order are canceled after a shipment has taken place.

For more information: See:

• Stored Value Card Authorization Reversal for background.

• Working with Outbound Interface Transactions (WOIT) for information on creating and processing outbound interface triggers.

• Defining Authorization Services (WASV) for information on setting up PayPal as an authorization service.

PayPal DoVoid Transaction Request

Order Administration sends the DoVoid request to PayPal to request an authorization reversal.

The DoVoid request specifies the stored value card number for the Order Payment Method as the AUTHORIZATIONID.

PayPal DoVoid Transaction Response

The DoVoid response confirms that the DoVoid request was successful and echoes the AUTHORIZATIONID.

PayPal Direct Connection Integration Restrictions

The Order Administration PayPal Direct Connection does not support the following.

• Online or batch authorization processing in Order Administration. Web orders containing a PayPal payment must receive an approved authorization from PayPal on the web storefront before being sent to Order Administration for processing.

• Additions to orders that contain a PayPal pay type in Order Maintenance that would exceed 15% or $75.00 of the initial authorization received for the PayPal payment. For example, if the authorization received for the PayPal payment is $100.00, you can apply up to $115.00 towards the PayPal authorization ($100.00 + 15% = $115.00).

• Orders that contain multiple ship to customers.

• Gift card payments.

• Alias items.

• Promotions applied to web orders in Order Administration. Final order amounts must be passed from the web storefront.

• Authorization reversals are supported only for the full amount of the authorization when the entire order is canceled or sold out, when the payment method is deactivated.

• Exchanges and returns performed through order entry are not recommended when the pay type on the order is PayPal; however, the system does not prevent either activity.

• Exchanges are not supported if there is a charge on the exchanged item. In this scenario, you must create a separate order for the new charge with a different customer payment.

• Returns/Refunds using the PayPal payment cannot be greater than the original deposit amount.

PayPal Direct Connection Integration Troubleshooting

If you have problems connecting to PayPal during deposit processing, use the following steps to help troubleshoot the issue.

PayPal service set up correctly? Verify that you have performed the required setup for the PayPal Direct Connection integration; see PayPal Direct Connection Integration Setup.

PayPal Log

When you process deposits for an order containing a PayPal pay type, the system sends the deposit transaction directly to PayPal and logs the transactional information in the PayPal log.

Information in log: The PayPal log includes a copy of the deposit information sent between Order Administration and PayPal. In addition, any errors that may occur during deposit transaction processing are captured in the log.

You can use this log to confirm that communication between Order Administration and PayPal is working correctly, to isolate communication problems, or the recover information.

Sample log information:

Successful deposit process generates IFO level messages, such as the following:

11:56:55,831 INFO PAYPAL - [Settlement] Transmitted deposit(*PURCH) Processed : AMT=20.94&INVNUM=I23-1754&NOTE=PAYPAL+1754&AUTHORIZATIONID=AUTH_ID&COMPLETETYPE=NotComplete&METHOD=DoCapture

Failure deposit process and errors during processing generates ERROR level messages, such as the following:

11:56:55,831 ERROR PAYPAL - [Settlement] Transmitted deposit(*PURCH) Failure : AMT=20.94=123-1234=PAYPAL+1754=AUTH_ID=NotComplete=DoCapture
11:57:06,581 ERROR PAYPAL - [Settlement] Timestamp      : 2009-05-08T15:52:55Z
11:57:08,737 ERROR PAYPAL - [Settlement] CorrelationId  : CORR_ID
11:57:10,284 ERROR PAYPAL - [Settlement] Error code     : 10002
11:57:11,972 ERROR PAYPAL - [Settlement] Short message  : Security error
11:57:15,018 ERROR PAYPAL - [Settlement] Long message   : Security header is not valid
11:57:17,300 ERROR PAYPAL - [Settlement] Severity code  : Error
11:57:20,297 INFO  PAYPAL - [Settlement] Transmitted deposit(*RETURN)Failure : AMT=68.00=123-123456=PAYPALID+7042982=AUTH_ID=NotComplete=RefundTransaction

The time elapsed to receive a response is indicated in a DEBUG level message, such as the following:

12:19:13,481 DEBUG PAYPAL - message: [Settlement] Got response, elapsed time = 2 seconds

Errors reading the authorization service or authorization service extended generates ERROR level messages, such as the following:

11:31:04,471 ERROR PAYPAL - [Settlement] Defaults set. Do not process in PayPal 'live' environment

11:31:31,841 ERROR PAYPAL - [Settlement] Exception(s) encountered during Initialization. No Deposit processing performed.

PayPal Direct Connection Integration Setup

Purpose: Before you can use the PayPal - Direct Connection integration, you must perform the necessary setup.

• Creating the PayPal Decline Order Hold Reason

• Creating the PPL (PayPal) Account Provider

• Creating a PayPal Pay Type

If you are upgrading from 5.0: In 5.0, the PayPal credentials are stored in the System Properties (PPOP) menu option. When you upgrade from version 5.0, the PayPal credentials are stored in the Work with Authentication Services (WASV) menu option in the API user name, API password, and API signature fields. You will need to redefine your PayPal credentials as part of the upgrade process.

Type of PayPal integration: The PayPal Direct Connection integration uses PayPal’s Express Checkout to send deposit transactions between PayPal and Order Administration. Communication protocol is provided through the PayPal SOAP API Architecture, which uses a signed SOAP request over HTTPS. The PayPal API jar file, provided by PayPal and included with Order Administration, handles communication between PayPal and Order Administration.

In order to use the PayPal Direct Connection integration, your web storefront must support a direct connection to PayPal to perform authorizations.

Related system control value: In addition to the setup described below, you can use the Append Ecommerce Order # to PayPal Invoice ID (M40) to define whether to include the ecommerce order number in the INVNUM set to PayPal.

Creating the PayPal Decline Order Hold Reason

Use the Establishing Order Hold Reason Codes (WOHR) menu option to create the PP (PayPal Decline) order hold reason code. The system assigns this reason to the PayPal pay type on the order when it is declined during PayPal authorization processing at pick slip generation time.

At the Create Order Hold Reason Screen, enter the following information:

Field	Description
Reason	Enter PP.
Description	Enter PAYPAL DECLINE.

Creating the PPL (PayPal) Account Provider

Use the Defining Authorization Services (WASV) menu option to create the PPL account provider.

Multiple PayPal accounts: If you use multiple PayPal accounts, for example, each of your entities uses an individual PayPal account, you can:

• Use the Work with Merchant ID Overrides Screen to set up overrides for the different entities in your company. In this situation, you can define unique API credentials to establish a connection to the PayPal system for each of your PayPal accounts at the Create Merchant ID by Entity Screen. You can create one PayPal pay type for all of your accounts; see Creating a PayPal Pay Type.

• Use the Work with Authorization Service Currency Screen to set up a cross-reference between the Order Administration currency code and the PayPal currency code. When sending the PayPal DoCapture Request to PayPal, the system populates the CURRENCYCODE in the request with the ASC Currency code in the Auth Service Currency table that corresponds to the Currency in the Order Header Extended table.

  • If the Currency in the Order Header Extended table is blank, the system uses the currency code defined in the Local Currency Code (A55) system control value to determine which ASC Currency code in the Auth Service Currency table to use.

  • If a cross reference is not defined in Authorization Service Currency for the selected currency code, the system leaves the CURRENCYCODE in the PayPal DoCapture Request blank; PayPal treats a blank CURRENCYCODE as USD currency.

At the First Create Authorization Services Screen, enter the following information:

Field	Description
Service code	Enter the name of the PayPal account; for example PPL.
Application	Select Auth/Deposit.
Charge description	Enter PAYPAL DIRECT CONNECTION.

At the Second Create Authorization Service Screen, enter the following information:

Field	Description
Media type	Select Communication.
Batch/Online	Select Batch.
Active production system?	Select this field to send transactions to PayPal.
Primary authorization service	Enter PPL.
Test mode?	Select this field if you are sending transactions to PayPal’s test “sandbox” environment. Deselect this field if you are sending transactions to PayPal’s production “live” environment.
	The following fields are used to establish a connection to the PayPal system when using the PayPal Direct Connection Integration. You can also define API credential information at the entity level using the Create Merchant ID by Entity Screen.
API User name	Enter the user name, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing.
API Password	Enter the password, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing.
API Signature	Enter the encrypted signature, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing.

At the Create Vendor Response Screen, enter the following information:

Field	Description
Response code	Enter PPLDECLINE.
Description 1	Enter PAYPAL DECLINE.
Hold reason	Enter PP. If you do not enter PP as the hold reason, the system places the PayPal payment on AV hold.

Creating a PayPal Pay Type

Use the Work with Pay Types (WPAY) menu option to create the PayPal pay type, making sure to define the following information.

Field	Description
Pay category	Enter Credit Card (pay category 2).
Card type	Enter Credit (card type C).
Authorization service	Enter the name of the PayPal Direct Connection account provider, for example, PPL.
Deposit service	Enter the name of the PayPal Direct Connection account provider, for example, PPL.
Reauthorization days	Enter the number of days before PayPal payments expire. Make sure the number of days you enter matches the number of days defined in the PayPal system. Typically, PayPal payments are good for 29 days.
Send reversal	Select this field to enable sending reversals to PayPal when the value of the entire authorization amount is canceled or deactivated. See Stored Value Card Authorization Reversal for background.

External Payment Service

External payment service is a RESTful web service that provides an interface from Order Administration for sending stored value card transactions and receiving responses. Using this service, you can build a custom payment processor that maps to your account provider.

This payment service needs to be configured to use the integration layer component of Order Administration, as this component controls payment service processing.

Supported stored value card transactions:

• activation request

• authorization request

• balance inquiry

• deposit request

• generation request

• recharge request

• return request

• reversal request

For more information: For background on stored value card authorization, see:

• Defining Authorization Services (WASV)

In this topic:

• External Payment Service Setup

  • Authorization Service Settings

  • Work with Pay Types (WPAY)

  • Work with Order Types (WOTY)

  • Stored Value Card Reversal Function

• Subsequent Authorization Requests through the External Payment Service

For sample messages see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

External Payment Service Setup

The required setup for the External Payment Service is described below, and includes:

• Secured Feature

• Authentication

• Authorization Service Settings

• Work with Pay Types (WPAY)

• Work with Order Types (WOTY)

Additional security requirements: For additional security-related setup requirements, including implementation of OAuth, see the External Payment Service Technical Reference Paper on My Oracle Support (2149144.1).

Secured Feature

The External Authorization Service Access (B25) secured feature controls access to the Work with External Authorization Service Screen, where you can work with required settings for the External Payment Service. These settings are described briefly below under External Service Settings

Authentication

Use OAuth to authenticate the External Payment Service. See the Oracle Retail Omnichannel Web Service Authentication Guide on My Oracle Support (2728265.1) for more information.

Authorization Service Settings

Use Defining Authorization Services (WASV) to create a account provider for the External Payment Service.

Settings for External Payment Service: The following table lists some of the required settings, in addition to the basic settings required for all account providers and any optional settings, to support the External Payment Service.

Fields at the first Create/Change/Display Authorization Services screen include:	Description
Service Code	Typically set to EXT or EXC, but can be set to anything.
Application	Select Auth/Deposit.
Void auth at deposit	Select this field to void any unused portion of a credit card or stored value card authorization at deposit time. Note:  The Retain Unused Stored Value Card Authorization After Deposit (J21) system control value does not control stored value card deposit updates for the External Payment Layer.
Send reversal	Select this field to perform a credit card authorization reversal when you process a cancellation associated with a credit card payment or deactivate a credit card payment.
Fields at the second Create/Change/Display Authorization Services screen:
Media type	Select Communication.
Batch/Online	Select Online or Batch.
Immediate response	Must be selected.
Primary authorization service	Should be blank
Communication type	Payment Link must be selected, to indicate messages sent the external payment layer are processed directly.
Response check frequency	Indicates the multiple to apply to the Response time to determine how long to wait for a response after a connection when you are using the External Payment Service. For example, if the Response check frequency is 6 and the Response time is 10,000, the system waits 60,000 milliseconds (60 seconds or 1 minute) for a response after connection. Note:  If the total response interval is exceeded for an authorization record, the record goes into *RCVD status with a response type of SU, and is then removed from the Credit Card Authorization Transaction table (CCAT00).
Response time	Indicates the number of milliseconds to wait for a connection to the account provider when you are using the External Payment Service. For example, set this field to 10,000 milliseconds to wait 10 seconds for a connection. Note: Order Management System does not wait the entire response time if it is not necessary. To avoid potential timeout issues, Oracle recommends that you set the Response Time high enough for the authorization service to prevent issues that could potentially occur if the authorization process times out while processing multiple authorizations for an order.
Country codes	If needed, define a cross reference between your country code and the country code used by the account provider. Note:  This option also indicates whether a account provider performs address verification processing for the country. See Defining Authorization Service Countries.
Currency codes	If needed, define a cross reference between your currency code and the currency code used by the account provider; see Defining Authorization Service Currencies.
Merchant ID Override	If needed, define a merchant ID override for the different entities in your company; see Defining Merchant ID Overrides.
Paytype codes	If needed, define a cross reference between your pay type code and the pay type code used by the account provider; see Defining Vendor Paytype Codes.
Response codes	Define the reasons that the account provider approves (authorizes) or declines a transaction. The codes are assigned to each transaction by the account provider when approving or declining the request; see Defining Vendor Response Codes. A response code of SU, indicating service unavailable, must be created. When there is a REJECT or ERROR response, the order goes on AT hold and the authorization is updated as declined when: The reason code passed is not defined as an authorization response code, or The reason code passed is defined as an authorization response code but also has a hold code defined, or No reason code is passed. If no reason code is passed, a response code of SU is applied.

External Service Settings

The additional External Service Settings at the Work with External Authorization Service Screen are accessible only to users with External Authorization Service Access (B25) authority.

All fields on the screen are required, with the exception of the External Service flag.

Tracking changes to external service settings: Changes that users make to external service settings are tracked in the User Audit table, and listed on the User Authority Change report. See Tracking User, Authority, and Password Updates for more information.

For more information: See the External Payment Layer RESTful Service technical reference on My Oracle Support for more information on updating these settings.

Setting	Notes
External Service	Select this field to have request messages generated for the External Payment Service.
External URL Prefix	The prefix that forms the beginning of the URL where messages are sent. Must begin with https. The message type defines the endpoint suffix that is appended to the prefix, creating the entire URL. For example, for a credit card authorization request, the entire URL might be https://remote.auth.com:1234/authorization, where remote.auth.com is the remote server, 1234 is the port, and authorization identifies an authorization request. The following endpoints are supported: balanceInquiry authorization reversal getAuthToken generateGift activateGift rechargeGift deposit return
Message Version	Indicates which message version is supported with version 3.0 being the default version when creating a new authorization service. Previous versions have been removed. Version 3.0 no longer includes tags that pass the credit card number for an order and instead includes tags that pass the card token. It also allows an external merchant application to call for both Credit Cards and Stored Value Cards supported through the External Payment Service and EFTConnect.
Authentication User	The user ID for authentication of the messages to the external service.
Authentication Password	The password for authentication of the messages to the external service. Must be at least 6 positions long, include both numbers and letters, include a special character, and cannot end with a number.

Work with Pay Types (WPAY)

Use Working with Pay Types (WPAY) to assign the authorization and deposit service to each credit card or stored value card pay type that uses the External Payment Service.

Work with Order Types (WOTY)

In order to perform online authorization on web orders, the Online Authorization setting for the order type on the web order must be set to Without Window. See Establishing Order Types (WOTY) for more information on setting up an order type.

Stored Value Card Reversal Function

You can use a periodic function, described below, to submit stored value card reversal requests for closed or canceled orders.

REVXAHP (Program name = PFREVXAHP): Reverse Partial Auth for External Payment Service: Generates SVC reversal request messages for the External Payment Service within the specified company, provided that:

• A company is specified.

• The parameter specified for the function is a valid stored value card pay type code for the company.

• The pay type is assigned to an authorization service configured as the External Payment Service.

• The pay type does not match the Default Auth Code for CC Netting (M25) system control value.

For more information: See Stored Value Card Authorization Reversal for an overview of the authorization reversal process.

Subsequent Authorization Requests through the External Payment Service

About subsequent authorizations: Order Administration sends information through the External Payment Service and EFTConnect indicating whether a transaction was initiated by the merchant, or by the customer. For example, when the customer initially places the order, this is a transaction initiated by the customer; an example of a merchant-initiated transaction is a subsequent authorization that is acquired by Order Administration when the initial authorization is expired.

Term definitions:

• Merchant-Initiated Transactions (MIT): An authorization that the system initiates without the customer’s active participation.

• Cardholder-Initiated Transactions (CIT): An authorization that uses payment information provided by the customer.

• Credentials on File (COF): The cardholder payment information that is stored by the system.

Types of subsequent authorizations: Brief descriptions of subsequent authorization types for credit cards include:

• Resubmission of a failed deposit: When the Supports Auth Resubmission flag is selected for the authorization service and a previous deposit request for the credit card failed. A subsequent authorization and deposit request is generated, with the subsequentAuth tag set to Y and the subsequentAuthReason set to RESUBMIT. However, if the Supports Auth Resubmission flag is not selected, the subsequentAuthReason is set to REAUTH.

• Split shipment: When the order is not fulfilled in a single shipment. In this case, the request for the subsequent authorization includes a subsequentAuthReason set to REAUTH and passes the existing ci_transaction_id as the subsequentAuthTransactionID.

• Deferred or installment billing: When the order uses deferred or installment billing. The pay type’s Notify of installments setting indicates whether to send the subsequentAuthReason set to INSTALLMENT or REAUTH. See Deferred/Installment Billing Overview for background.

• Customer membership orders: When you generate orders for a customer membership that has been authorized. Authorization can take place either through the order originating the customer membership, or through a generated membership order. The CIT Transaction ID (customer-initiated transaction ID) and the original authorization amount are stored on the customer membership, although this information is not displayed on any screen. For more information, see Subsequent Authorizations through the External Payment Service for Membership Orders.

For EFTConnect, see the Payment Configuration, Merchant Account option in Modern View for setting these flags. For External Payment Service, see the Defining Authorization Services (WASV) option for setting these flags.

Details on the External Payment Service tags supporting subsequent authorization requests: See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

External Payment Service Level 2 and 3 Discounting

External Payment Service supports the ability for a Retailer to leverage attributes within the request and response messages to qualify for Level 2 and Level 3 discounts. Certain Business-to-Business (B2B) and Business-to-Government (B2G) credit card types and their transactions can qualify for Level 2 or Level 3 discounts on processing fees, and when applied, can save the retailer a significant amount of money on the fees.

In order to qualify for Level 2 or Level 3 discounts, additional data must be sent on the authorization transactions to the Payment Service Provider.

For example, to qualify for Level 2 discounts, the following additional fields can be sent:

• Customer Reference, Sales Tax Amount, Requestor Name, Ship To Name, Ship To Address, Customer Tax Id

For Level 3 discounts, send the Level 2 fields and the following additional Order and Item fields:

• Order Number, Order Date, Invoice Number, Duty Amount, Freight Amount, Ship To Country, Discount Amount, Freight Tax Amount

• Item Id, Item Description, Item Quantity, Item Unit Of Measure, Item Price, Item Line Total, Item Commodity Code, Item Line Discount, Item Tax Amount, Item Class, Item Tax Rate

Additionally, some Payment Service Providers can return a Card Level Indicator on payment transaction responses. This indicator could be used by the Retailer when sending payment transactions to the payment provider, in order to determine whether to forward the Level 2/3 data fields, where the payment provider wants to be selective in what data is transmitted to the different issuers.

• Optionally, pass the Card Level Indicator with a Card Payment when available through External Payment Service or CWOrderIn.

• Blank or not set - It is not eligible for Level 2/3 discounts, or is unknown

• "2" - It is eligible for Level 2 discounts (generally commercial, corporate and government cards)

• "3" - It is eligible for Level 3 discounts (generally commercial, corporate and government cards)

• The Card Level Indicator will be updated if the card is replaced through Manage Rejected Deposits and Customer Membership based on the new card entered.

• The Card Level Indicator will be stored with Customer Memberships and included in the order payment method of generated child membership orders.

Purging Tables

Topics in this part:

• Purging Prestige Credit Card Deposits (MPSP) describes how to purge processed records from the Credit Card Deposit Prestige table.

• Purging Orders (MPOR) described how to purge closed and canceled orders based on the date of last activity.

• Purging Sold To Customers describes how to purge eligible sold to customers based on the customer’s last change date.

• Purging Suspended Orders (PSOR) describes how to remove orders in a suspended status from the system.

• Purging SKUs (MPSK) described how to remove item/SKUs based on item status from the system.

• Additional Purges summarizes the additional purges available.

Purging Sold To Customers

Purpose: Use the PURGECS Purge Sold To Customers periodic function (program name PFR0137) to purge eligible sold to customers.

Which customers are purged? For the customer to be eligible for purge, the system verifies that:

• the last change date for the customer is older than the number of days defined in the periodic function’s Parameter field. If the Parameter is blank or 0, records must be 365 days old to be eligible for purge.

• there are no unpurged orders for the customer.

• the customer does not exist in the Customer Fraud table.

• there are no open refunds for the customer.

• there are no open returns for the customer.

• there are no open ticklers for the customer.

• there are no catalog requests for the customer.

• there are no active or in-process memberships for the customer.

• there are no open purchase orders for the customer.

Once the purge completes, the system generates the Purged Customer List, listing the sold to customers that were removed.

The system writes processing details to the Trace log.

Purging an individual customer:

• To purge an individual sold to customer, use the Delete option in Creating and Updating Sold-to Customers (WCST).

• To purge an individual ship to customer, use the Delete option in Creating and Updating Sold-to Customers (WCST).

• To purge an individual bill to customer, use the Delete option in Creating and Updating Bill-to Customers (WCBT).

Updated tables: See the Tables Updated during Customer Purge for a listing of the tables purged through the PURGECS Purge Customers periodic function (program name PFR0137).

Before you purge customers:

• Use the Purge Catalog Request History (PCRH) menu option to delete outdated records from the Catalog Request History table.

• Use the PURGEOR Purge Orders periodic function (program name PFR0114) to purge orders that are closed or canceled. See Purging Orders (MPOR) for processing details.

In this topic:

• Tables Updated during Customer Purge 

For more information: See:

• How to Schedule a Job for information on scheduling a periodic process that includes the PURGECS periodic function

• Working with Periodic Functions (WPER) for information on setting up periodic functi

Tables Updated during Customer Purge

Purpose: The system purges records in the following customer-related and order-related tables when you use the PURGECS Purge Customers (program name PFR0137) periodic function.

• Contract Price (PRCNPR)

• Correspondence History (MSCOHS)

• Cust Mail/Rent Changes (OECMRC)

• Cust Sold To Item Class Entity (OEICEP)

• Customer Action (CSCSAC)

• Customer Action Note (OECACN)

• Customer Address Change (CSCACP)

• Customer Affinity (CSAFFY)

• Customer Individual (CSCIFP)

• Customer Individual Mail History (CSTIMH)

• Customer Individual Order History (CSTIOH)

• Customer Membership (OECSMP)

• Customer Membership Detail (OECSMD)

• Customer Note (CSCUNO)

• Customer Ownership (OECSOW)

• Customer Pay Type Exclusion (CSCPTX)

• Customer Profile (CSCPRO)

• Customer Ship To (CSSHIP)

• Customer Ship To Entity (OECHEP)

• Customer Ship To Extended (CSHXNA)

• Customer Ship To Mail History (CSHPMH)

• Customer Ship To Order History (CSHORH)

• Customer Ship To Phone # (CSCTP#)

• Customer Shipment History (FLCSHP)

• Customer Sold To (OECSSL)

• Customer Sold To BML (OECSBM)

• Customer Sold To Email (OECSEM)

• Customer Sold To Entity (OECSEP)

• Customer Sold To Extended (CSTXNA)

• Customer Sold To Item Class (OECSIC)

• Customer Individual (CSCIFP)

• Customer Sold To Item Class Entity (OEICEP)

• Customer Sold To Mail History (CUSTMH)

• Customer Sold To Order History (CSTOOH)

• Customer Sold To User Field (OECSUF)

• Customer Profile (CSCPRO)

• Customer Sold To Promotion (OECSPR)

• Customer Sold To Phone # (CSCSP#)

• Customer Sold To Xref (OECSXR)

• Customer Source Finder (CSSFND)

• Customer Subscription (OECSSB)

• Customer Tax (OECSTX)

• Customer Warehouse (CDCWFP)

• Customer Warranty Track (CSWTRP)

• DW Correspondence History (DWCSEM)

• EC CST Ext (EXCSTE)

• Marketing Download Customer Address Change (IXDTCA)

• Marketing Download Customer Inquiry (IXDTCI)

• Marketing Download Customer Ownership (IXDTCO)

• Marketing Download Customer Profile (IXDTCP)

• Marketing Download Customer Status Change (IXDTCS)

• Tickler (MSTKLR)

Additional Purges

Purpose: In addition to the purges described earlier under Purging Tables, you can use the purge options listed below to delete outdated or unneeded records in various tables. Purging unnecessary records can help save space and improve performance.

• For more information: See:

• Active Procedures: Purging Active Procedures (MACP).

• Correspondence History: Purging Email History (MPCH).

• Customer Subscriptions: Purging Subscriptions (MPCS).

• Orders: Purging Orders (MPOR) Note: You can also purge a single order through the Purge Orders by Order Number menu option, fast path = MORP.

• Prestige Credit Card Deposits: Purging Prestige Credit Card Deposits (MPSP).

• Refund Checks: Reconciling Checks (MREC).

• SKUs: Purging SKUs (MPSK).

• Suspended Orders: Purging Suspended Orders (PSOR).

• Purge Inventory Transaction History (MITH)

• Purge Purchase Order (MPOP)

• Purge Empty Item Locations (PITL)

• Purge Order Billing History (POBH)

• Purge Orders by Order Number (MORP)

Flexible Payment Options

Topics in this part:

• Deferred/Installment Billing Overview provides an overview of how flexible payment options work.

• Deferred/Installment Billing Setup describes the steps necessary to set up deferred or installment billing pay plans.

• Working with Flexible Payment Options (WFPO) describes the screens you use in the Work with Flexible Payment Options menu option.

• Credit Card Net Exchange Billing describes the process the system uses to net credit invoices with debit invoices before a deposit is sent to the service bureau for an invoice associated with an exchange.

Important:

There is a known issue with deferred/installment billing functionality when processing a return. If you plan to use deferred/installment billing, contact customer support to determine if your planned use of this functionality will be impacted by this issue.

Deferred/Installment Billing Overview

Pay plans are deferred payment or installment billing options you can offer to your customers.  Under a pay plan, you delay billing the customer's credit card for a prearranged interval.

There are two types of pay plans:

• Deferred billing: You bill the customer for the shipment after a specific number of days has passed, based on either the order date or the shipment date; or, you bill the customer on a given day of the month following the order or shipment.

• Installment billing: You bill the balance due for a shipment in a number of equal installment payments, which are due after specific intervals or on a given day of the month.

Different credit card types: Only credit cards (as opposed to different types such as stored value card or debit card) are eligible for deferred or installment billing. If you accept any other credit card type besides a regular credit card, you should make the Paytype one of the Qualification Values for each payment plan you create to prevent these other credit card types from being accepted. You can use the Copy option at the Work with Flexible Payment Option Screen to make a copy of the payment plan for each eligible credit card pay type.

EXC flexible payment option: The system delivers the EXC Net Billing for Exchanges flexible payment option in the Working with Flexible Payment Options (WFPO) menu option to use during Credit Card Net Exchange Billing (the Use CC Net Exchange Billing (M23) system control value is selected). You cannot change or delete this flexible payment option and you cannot use this flexible payment option for deferred/installment billing. See Credit Card Net Exchange Billing for processing details.

Important:

There is a known issue with deferred/installment billing functionality when processing a return. If you plan to use deferred/installment billing, contact customer support to determine if your planned use of this functionality will be impacted by this issue.

In this topic:

• Applying a Pay Plan in Order Entry

  • Selection Hierarchy

  • Demand Updates

• Pick Slip Generation

• Billing Updates

  • Deposit Release Date

• Processing Deposits

• Rejected Deposits

• Order Inquiry

• Returns

  • Netting Credits

• Reporting

• More Information

Not in this topic: This topic does not include general information on setting up your company to use deferred or installment billing, or on setting up the pay plans themselves; see Deferred/Installment Billing Setup. Also, see Manage Rejected Deposits in Modern View and Printing the Deposit History Summary (PDHS) for more information.

Examples

Pay Plan Setup	Result
Payment deferred 30 days based on invoice date	Order entered on 9/1 and shipment confirmed on 9/15.   Deposit eligible for processing on 10/15.
Payment deferred 30 days based on order date	Order entered on 9/1 and shipment confirmed on 9/15. Deposit eligible for processing on 10/1. Note:  If the shipment did not take place until 10/1 or after, the deposit would be eligible for processing immediately after shipment confirmation.
Payment deferred until the 25th of the month	Order entered on 9/1 and shipment confirmed on 9/15. Deposit eligible for processing on 9/25.

Pay Plan Setup	Result
Four installments, 30 day intervals	Order entered on 9/1 for $200.00 and shipment confirmed on 9/15. Four installments of $50.00, eligible for processing on 9/15, 10/15, 11/14, 12/14
Six installments, 1st of the month	Order entered on 9/1 for $300.00 and shipment confirmed on 9/15. Six installments of $50.00, eligible for processing on 10/1, 11/1, 12/1, 1/1, 2/1, 3/1. Note:  If the shipment did not take place until 10/1, the first installment would still be eligible for processing on that same date.

See Deposit Release Date for more examples.

Applying a Pay Plan in Order Entry

Determining eligible orders: In order to assign a pay plan to an order, the system must first determine if the order is eligible for a pay plan.

An order is eligible for a pay plan if the order:

• is within the pay plan's starting and ending date

• does not contain an item that is excluded from pay plans

• contains only one credit card

• has a source code that is not excluded from pay plans

• meets the minimum dollar amount requirement for the pay plan, if any

• meets the pay type requirement for the pay plan, if any

• meets the offer requirement for the pay plan, if any

• meets the item requirement for the pay plan, if any

Selection Hierarchy

Once the system determines which payment plans are eligible for the order, it determines the most appropriate plan.

The system selects the first qualifying pay plan as the primary plan based on the following hierarchy:

• The pay plan is set to apply automatically to a qualifying order.

• The pay plan is assigned to the source code on the order header.

• Selection based on the qualification values for the pay plan:

  • An item on the order is the qualifying item for the pay plan and the order meets the qualifying merchandise dollar amount.

  • An item on the order is the qualifying item for the pay plan but the order does not meet the qualifying merchandise dollar amount.

  • The offer on the order is the qualifying offer for the pay plan and the order meets the qualifying merchandise dollar amount but does not contain the qualifying item.

  • The offer on the order is the qualifying offer for the pay plan but the order does not meet the qualifying merchandise dollar amount or contain the qualifying item.

  • The pay type on the order is the qualifying pay type for the pay plan and the order meets the qualifying merchandise dollar amount but does meet any other qualifying criteria.

  • The pay type on the order is the qualifying pay type for the pay plan but the order does not meet any of the other qualifying criteria.

  • The order meets the qualifying merchandise dollar amount but does not meet any other qualifying criteria.

If more than one pay plan meets the same qualifications, the system then determines the primary plan as follows:

• The pay plan is the first eligible plan in descending starting date sequence (most current date), or

• The pay plan is the first alphanumerically.

Applying the plan to the order: The system can apply the pay plan to the order in three different ways, depending on how you set up the pay plan:

• Automatically apply the plan to the order, or

• Prompt the operator to select a plan, or

• Require the operator to manually assign a plan

If the pay plan is set to....	The system....
automatically apply to the order	automatically applies the pay plan to the order when you enter payment method information
prompt the operator	displays the Select Payment Plan Window pop-up window, listing eligible payment plans, where the operator can select a plan to assign to the order
not automatically apply to the order	does not automatically apply the pay plan to the order or display a pop-up window; the operator must select a pay plan for the order

Demand Updates

In addition to the standard demand updates made for every order, the system updates the following fields in the Flexible Payment Options table when you accept an order:

• Number of orders

• Dollars ordered

• Number of soldouts

• Dollars soldout

• Number of cancels

• Dollars canceled

You can review history for a pay plan by selecting History for the plan at the Work with Flexible Payment Option Screen.

The system also performs updates when you confirm and ship an order containing a pay plan. See Billing Updates.

Pick Slip Generation

Authorization: Unlike regular (non-pay plan) orders, deferred or installment billing orders do not automatically require an authorization for the full pickable amount of the order when you generate pick slips. The amount authorized at pick slip generation is summarized in the table:

When you print a pick slip for...	The amount authorized is...
a regular (non-pay plan) order	the full pickable amount of the order  (including any tax, shipping, and charges)
a deferred billing pay plan order	one dollar, unless the Authorize full amount field for the pay plan is selected
an installment billing pay plan order	the first payment of the installment plan, unless the Authorize full amount field for the pay plan is selected

Pick messages: Any pick slip messages you have specified for the pay plan print on the customer's pick slip, provided your pick slip printing program supports it. You can enter up to three lines of messages for a pay plan.

Billing Updates

Flexible payment option: The system updates the total numbers and dollars shipped for the pay plan when you confirm shipment and bill. You can review history for a pay plan by selecting History for the plan at the Work with Flexible Payment Option Screen.

Invoice: In addition to all of the standard updates that occur during billing, the system calculates the deposit release date based on the terms of the pay plan. This date, which is stored in the Invoice Pay Method, indicates when the deposit will be eligible for processing. In the case of an installment plan, the deposit release date indicates when the first installment will be eligible for processing. Each installment has a separate Deposit Release Date.

Regular (non-pay plan) orders also have a deposit release date; however, it is always the same as the invoice date.

Deposit Release Date

The system assigns a deposit release date to all orders at billing. The deposit release date indicates when the deposit is eligible for processing. In the case of a regular (non-pay plan) order, the deposit release date is always the same as the invoice date, because the deposit is eligible for processing immediately. Examples of deposit release date calculation for pay plan orders are:

Pay Plan Settings	Deposit Release Date Calculation	Examples
fixed date	Use the fixed date; however, if this date has already passed, use the invoice date	Standard calculation:	Order date = 9/1 Fixed date = 10/1 Invoice date =  9/15 Deposit release date = 10/1
		If the fixed date has already passed:	Order date = 9/1 Fixed date = 10/1 Invoice date = 10/5 Deposit release date = 10/5
number of days and order date	Add the number of days to the order date; however, if the resulting date has already passed, use the invoice date; or, if the pay plan expiration date is sooner than the resulting date, use the expiration date or invoice date (whichever is later)	Standard calculation:	Order date = 9/1 Number of days = 30 Invoice date = 9/15 Deposit release date = 10/1
		If deposit release date based on standard calculation is earlier than current (invoice) date but before the pay plan expiration date	Order date = 9/1 Number of days = 30 Invoice date = 10/5 Expiration date = 10/15 Deposit release date = 10/5
		If deposit release date based on standard calculation is later than the pay plan expiration date:	Order date = 9/1 Number of days = 30 Invoice date = 9/15 Expiration date = 9/30 Deposit release date = 9/30
number of days and invoice date	Add the number of days to the invoice date; however, if the pay plan expiration date is sooner than the resulting date, use the expiration date	Standard calculation:	Order date = 9/1 Number of days = 30 Invoice date = 9/15 Deposit release date = 10/14
		If deposit release date based on standard calculation is later than the pay plan expiration date:	Order date = 9/1 Number of days = 30 Invoice date = 9/15 Expiration date = 9/30 Deposit release date = 9/30
fixed date	Use the next occurrence of the fixed day of the month and continue on that date for the number of installments; however, if the pay plan expiration date has occurred when you bill the order, use the invoice date	Standard calculation:	Order date = 9/1 Fixed date = 10 (10th of the month) Number of installments = 4 Invoice date = 9/15 Installment deposit release dates = 10/10, 11/10, 12/10, 1/10
		If expiration date has already occurred when you bill the order:	Order date = 9/1 Fixed date = 10 (10th of the month) Number of installments = 4 Invoice date = 9/15 Expiration date = 9/10 Deposit release date = 9/15 (no installments)
interval	Use the current date and add the number of interval days to each installment date to calculate the remaining installments; however, if the pay plan expiration date has occurred when you bill the order, use the invoice date	Standard calculation:	Order date = 9/1 Interval number of days = 30 Number of installments = 4 Invoice date = 9/15 Installment deposit release dates = 9/15, 10/15, 11/14, 12/14
		If expiration date has already occurred when you bill the order:	Order date = 9/1 Interval number of days = 30 Number of installments = 4 Invoice date = 9/15 Expiration date = 9/10 Deposit release date = 9/15 (no installments)

Processing Deposits

Authorization required: Unlike a regular (non-pay plan) credit card order, a pay plan order might not have a full, valid authorization at the time you process the deposit. Regular orders normally receive a full authorization at the time you generate the pick slip, and deposit processing normally occurs soon enough after pick slip generation for the authorization to still be valid. However, deposits for pay plan orders occur at intervals after pick slip generation, and authorizations from that time may no longer be valid, or may have been for less than the full deposit amount. See Pick Slip Generation.

Action codes: The system sends an action code of B to the deposit service for any pay plan deposits that require authorization. The conditions under which the system sends an action code of B are described in Processing Auto Deposits (SDEP).

Force deposit: If a pay plan deposit fails authorization, the system will “force” the deposit if you have set up the vendor response code to do so. Forcing a deposit means that the system performs all the same updates as if the authorization had been approved. For example, the invoice payment method for the order will be updated, and the deposit will not be included on reports that list unconfirmed deposits, or be available through the Resubmit Rejected Deposits function.

Rejected Deposits

Overview: Rejected or unconfirmed deposits appear on the Unconfirmed Deposits Listing when you process deposits. You can use the Resubmit Rejected Deposits Screen to work with these deposits, including:

• changing the credit card number or the deposit release date

• writing off or deleting the deposit

• entering a cash payment amount

• confirming the deposit interactively

• reviewing deposit history

You can also work with rejected deposits through standard order inquiry. See Order Inquiry.

Order Inquiry

Purpose: Use standard order inquiry to review information associated with a pay plan. The information and options listed below are not available in streamlined order inquiry.

• the total amount to deposit, the amount deposited, and the remaining amount to deposit

• credit card information

• the deposit release date

• installment schedule if the order uses an installment pay plan, such as:

  • the total number of installments

  • the number of installments remaining to deposit

  • the installment interval

  • the fixed installment day

  • the installment amount

• rejected deposit amount

• prepaid amount

Change options: You can also change this information related to the invoice payment method:

• the deposit release date

• installment information, such as:

  • the number of remaining installments

  • the installment interval

  • the fixed installment day

• the prepaid check or cash amount

• credit card information, such as:

  • the pay type

  • the credit card number

  • the credit card's expiration date

  • the authorization number

  • the authorization date

Rejected deposit options: If the invoice payment method is associated with a rejected deposit amount, you can perform the following updates through order inquiry:

• resubmit the rejected deposit

• write off the remaining amount to deposit for the invoice or write off a specified amount

• delete the rejected deposit

Deposit history: You can also review invoice deposit attempts and responses for each invoice payment method in order inquiry.  Deposit history includes whether the invoice was associated with a pay plan, the deposit amount, and the response code received from the deposit service.

Order payment history: The system records messages describing invoice activity associated with the order payment method or invoice payment method, such as:

• deposits made

• invoices netted against each other

• changes made in order inquiry

• when a pay type is deactivated

• when you add, change, or delete the pay plan associated with the payment type on the order

Returns

Purpose: When you perform a return against an order containing a payment plan, the system does not credit a customer's credit card until a deposit amount equal to or greater than the credit amount has been processed. This check ensures that the customer does not receive a credit for the return before paying for the shipment.

For deferred payment plans, the system processes the credit invoice after the debit invoice has been deposited.

For installment payment plans, the system processes the credit invoice once the debit invoice amount deposited is equal to or greater than the credit invoice amount.

Netting Credits

You can net credit invoices against debit invoices before processing the deposit on a pay plan order. The Net Credit Card Credits for Deferred and Installment Billing (F55) system control value controls whether you net credits.

If you net credits:

• For deferred payment plans, the system subtracts the credit invoice amount from the debit invoice amount and sends only the net amount to the service bureau for deposit.

• For installment payment plans, the system subtracts the credit invoice amount from the debit invoice amount.  The system then divides the remaining amount to deposit for the debit invoice by the number of remaining installments to determine the amount due for each remaining installment.

If you do not net credits, each credit deposit is processed separately from the related debit deposit.

See Processing Auto Deposits (SDEP) for more information on netting credits and examples.

Deposit release date: A credit invoice uses the deposit release date from the original (debit) invoice as long as that date is not earlier than the current date. If the deposit release date of the original invoice is earlier than the current date, the credit invoice uses the current date. This date assignment ensures that the customer is not credited until the deposit is processed; but if the customer has been billed, the credit will be released immediately.

Reporting

Related reports: The following reports may be useful in reviewing pay plan activity and status:

• Sales Journal by Pay Type (fast path = PSJP): breaks out totals billed by date, including deferred, installment, and regular (non-pay plan) orders for each pay type

• Deposit History Summary Report (fast path = PDHS): breaks out totals deposited by date, including deferred, installment, and regular (non-pay plan) orders

• Credit Card Deposit Schedule (fast path = PCCD): lists the pay plan totals scheduled for deposit for a range of dates

• Pending Payment Plan Deposits Report (fast path = PP, PD): lists pending pay plan orders for a range of invoice dates

• Deposit History Detail Report (fast path = PDHD): lists deposits processed during a specific date range. Within this date range, you can select to include only deposits for a specific authorization service, pay type, and status.

Additionally, the Submit Auto Deposits menu option produces the following reports:

• Unconfirmed Deposits Listing Report: lists each deposit that was not confirmed and processed, breaking out totals by deferred, installment, and regular (non-pay plan) invoices

• Auto Deposit Confirmation Report: breaks out totals sent and confirmed by deferred, installment, and regular (non-pay plan) orders for each pay type

More Information

Related to pay plans:

See	For information on...
Establishing Order Hold Reason Codes (WOHR)	Setting up order hold reason codes related to pay plans
Using the Order Inquiry Scan Screens (OIOM)	The screens you can use to review financial information on an order related to pay plans or to make changes to pay plan information in order inquiry
Introducing Order Maintenance	The changes you can make in order maintenance related to pay plans
Order Status and Activity Reports	Pay plan information on the Sales Journal by Pay Type
Setting Up Order Entry Values	System control values related to pay plans
Setting Up Secured Features	Secured features related to pay plans
Working with Source Codes (WSRC)	Assigning a pay plan to a source code
Performing Initial Item Entry (MITM)	Restricting an item from pay plans
Entering Orders	Entering orders for pay plans

See	For information on...
Working with the BILL_ASYNC Job	billing updates
Working with the ORDR_ASYNC Job	order updates
Setting Up Authorization Services	authorization and deposit services
Deferred/Installment Billing Setup	setup related to pay plans
Working with Flexible Payment Options (WFPO)	setting up the pay plans themselves
Processing Deposits	processing deposits, handling rejected deposits, and reports related to pay plans

Deferred/Installment Billing Setup

Purpose: Before you can used deferred or installment billing pay plans in your company, you must perform the necessary setup.  Information requiring creation and setup includes:

• system control values

• secured features

• authorization service settings, including response codes and currency codes

• order hold reason codes

• source codes that point to specific pay plans

• items that would be exempt from pay plans  

Set up pay plans: Additionally, you must set up the pay plans themselves using the Work with Flexible Payment Option Screen.

EXC flexible payment option: The system delivers the EXC Net Billing for Exchanges flexible payment option in the Working with Flexible Payment Options (WFPO) menu option to use during Credit Card Net Exchange Billing (the Use CC Net Exchange Billing (M23) system control value is selected). You cannot change or delete this flexible payment option and you cannot use this flexible payment option for deferred/installment billing. See Credit Card Net Exchange Billing for processing details.

In this topic:

• System Control Values

• Secured Features 

• Authorization Service Settings

• Order Hold Reason Codes

• Additional and Recommended Setup

System Control Values

System Control Value	Description
Deferred and Installment Billing (F51)	Select this field to be able to apply pay plans to orders. If this field is unselected, you will not be able to apply pay plans in order entry or order maintenance.
Number of Times Flexible Payment Option is Used (F52)	Enter the number of times the same credit card number can be applied against a pay plan order before being evaluated for PV hold. This system control value works together with the Number of Days Flexible Payment Option is Used (F53) field, below.
Number of Days Flexible Payment Option is Used (F53)	Enter the number of days the system should use for evaluating a credit card against the Number of Times Flexible Payment Option is Used (F52) field, above. If the same credit card number appears on orders more than the specified number of times within this number of days, the order goes on PV hold. Example:  You set the Number of Times Flexible Payment Option is Used (F52) field to 5, and the Number of Days Flexible Payment Option is Used (F53) field to 14. If the same credit card number appears on pay plan orders more than 5 times in 14 days, the sixth and subsequent orders for the credit card go on PV hold.
Dollar Threshold for Sold To Customer Orders with Flexible Payments (F54)	Enter the total dollar amount a customer can have in pay plan orders before the system puts new orders on $P hold.   Example:  You set this field to 500.00.  If a customer has 3 pay plan orders for a total of $450.00, and you take a new pay plan order for $75.00, the new order goes on $P hold.

Note:

You must also create the Order Hold Reason Codes.

Each of these fields is available at the Edit Deferred/Installment Billing screen.

Secured Features

Secured Feature	Description
Override Deferred and Installment Billing Options (A81)	Controls the ability to select a pay plan other than the primary, system-selected plan in order entry
Change Invoice Payment Information (A82)	Controls the ability to change information on an invoice once the order has been billed but before the invoice amount is fully deposited.   The Change Invoice Pay Method Screen allows you to change the deposit release date, credit card information, the number of remaining installments; apply a cash payment; or writeoff, resubmit, or delete the deposit. This screen is available in order inquiry and Submit Rejected Deposits.

Authorization Service Settings

When you are setting up an authorization service that supports deferred/installment billing, please note the following additional required settings:

• Industry code: enter your DBA number

• Deferred merchant ID

• Installment merchant ID

• Exclude from FPO: unselected

• Pay type cross reference Paytypes at the Work with Authorization Services Screen): Create a cross-reference for each pay type code you will allow on pay plan orders, using the vendor pay code information supplied by the authorization service.

• Currency cross reference (Currency at the Work with Authorization Services Screen): Create a cross-reference for each currency code you will use on pay plan orders, using the vendor currency code information supplied by the authorization service.

• Vendor responses (Responses at the Work with Authorization Services Screen): Optionally, you can select the Force deposit for FPO field.

You can also set up merchant ID overrides by entity.

Pay types: Each pay type eligible for deferred or installment billing should have the authorization service set up as its authorization and deposit service.

More information: See Working with Currency (WCUR) for more information on setting up pay types or currency codes.

Order Hold Reason Codes

The order hold reason codes you should set up in Establishing Order Hold Reason Codes (WOHR) as part of credit checking pay plan orders are described in this table:

Hold Reason Code	Used When...
P$	You enter an order that makes the sold to customer's total undeposited pay plan orders exceeds the amount specified in the Dollar Threshold for Sold To Customer Orders with Flexible Payments (F54) system control value; see System Control Values for an example.
PV	You enter an order that makes the sold to customer's total pay plan orders exceed the limit specified in the Number of Times Flexible Payment Option is Used (F52) system control value, for the period specified in the Number of Days Flexible Payment Option is Used (F53) system control value; see System Control Values for an example.
SB	Any open orders for the same sold to customer are put on hold because a deposit for this customer was rejected at the Auto Deposit Screen.
CB	Any open orders for the same credit card number are put on hold because a deposit for this credit card number was rejected at the Auto Deposit Screen.

Additional and Recommended Setup

Optionally, you can set up the fields described below for use in deferred or installment pay plans.

Source code: You can use the following fields to control how pay plans apply in order entry if this source code is on the order header:

• Flex pay code: If you enter a pay plan code, it gives the pay plan priority in the evaluation hierarchy the system uses when selecting the plans that apply to an order.

• Exclude FPO: If you select this field, orders for this source code are excluded from pay plans.

See Working with Source Codes (WSRC) for more information on setting up source codes.

Item: Select the Exclude FPO field to exclude any order containing the item from pay plans.

See Performing Initial Item Entry (MITM) for more information on setting up items.

Consolidate invoice: Selecting the Consolidated Invoice (B49) system control value if you use deferred or installment billing will simplify pay plan management considerably by limiting the number of invoices for an order.

Note:

In Order Management System 21.0 or higher, or Order Administration, you cannot select the Consolidated Invoice system control value if it is not already selected. If the system control value is currently selected (set to Y) and you deselect it (change it to N or blank), you cannot then change it back to selected. The option to consolidate invoices will be removed at a later date.

Pay plan settings: Using the following settings for each pay plan you create will simplify pay plan management:

• Auto apply: Set this field alike for all pay plans that might apply to an order to simplify the pay plan selection hierarchy in order entry.

• Ship complete: Select this field to simplify pay plan management by limiting the number of invoices for an order.

See Working with Flexible Payment Options (WFPO).

Pay type setting for CyberSource: Use the Notify of installment setting for the payment method to control whether to send a commerceIndicator set to install in the subsequent authorization and deposit request to CyberSource for an order using a deferred or installment pay plan, or to have the information passed in the ccAuthService element similar to other subsequent authorizations, such as a split shipment.

For more information: See Working with Pay Types (WPAY) for more information on setting up pay types.

Important:

In order to determine how to set this flag if you offer deferred or installment billing and use CyberSource, you need to confirm the information required by the end processor for deferred or installment payment plans for each payment type.

Credit Card Net Exchange Billing

Credit card net exchange billing allows the system to hold the credit invoice for a return to net it against the debit invoice for the associated exchange in order to reduce the number of transactions that occur for an exchange. The system uses the automatically created EXC Net Billing for Exchanges deferred payment option to determine how long to delay billing the customer’s credit card, based on the invoice date and the # of days for deferral defined for the EXC payment option.

Examples of net exchange billing: The remaining amount after the system performs credit card netting determines whether the system charges or credits the customer’s credit card.

Type of Exchange	Example
Even exchange	Credit invoice for returned item = $50.00 Debit invoice for exchange item = $50.00 During deposits, the system nets the credit invoice containing the returned item against the debit invoice containing the exchange item to determine the remaining amount to deposit: 50.00 debit - 50.00 credit = 0.00 balance  The system does not charge or credit the customer’s credit card. See CC Net Example: Even Exchange for more details.
Uneven exchange for less expensive item	Credit invoice for returned item = $100.00 Debit invoice for exchange item = $60.00 During deposits, the system nets the credit invoice containing the returned item against the debit invoice containing the exchange item to determine the remaining amount to deposit: 100.00 credit - 60.00 debit = 40.00 credit  The system credits the customer’s credit card $40.00. See CC Net Example: Uneven Exchange for Less Expensive Item for more details.
Uneven exchange for more expensive item	Credit invoice for returned item = $100.00 Debit invoice for exchange item = $140.00 During deposits, the system nets the credit invoice containing the returned item against the debit invoice containing the exchange item to determine the remaining amount to deposit: 140.00 debit - 100.00 credit = 40.00 debit  The system charges the customer’s credit card $40.00. See CC Net Example: Uneven Exchange for More Expensive Item for more details.

Eligible orders: An order is eligible for net exchange billing if:

• the Use CC Net Exchange Billing (M23) system control value is selected, and

• the Hold Days for CC Netting (M24) is set to a number greater than 0, and

• the order contains a credit card pay type, and

• a deferred or installment pay plan has not already been assigned to the credit card pay type on the order (see Deferred/Installment Billing Overview).

Accepting an exchange transaction on an order eligible for net exchange billing: When you accept an exchange transaction on an order eligible for net exchange billing, the system:

• updates the ODT Seq # field in the RA Exchange Item table with the order detail sequence number of the exchange item added to the order in order to link the exchange item to the associated returned item.

• creates a manual authorization for the return amount, using the authorization code defined in the Default Auth Code for CC Netting (M25) system control value. The expiration date for the manual authorization is based on the Reauthorization days defined for the credit card pay type.

• places the associated refund on hold and updates the Hold until date based on the # of days for deferral defined for the EXC deferred payment option. The system holds the refund for this number of days to allow time for the system to net the credit invoice containing the return item against the debit invoice containing the exchange item.

Billing an exchange transaction flagged for net exchange billing: When the exchange transaction is processed through billing, the system:

• creates the credit invoice and assigns the EXC deferred payment option to the invoice. The system considers a credit invoice pending net exchange billing if the Invoice Payment Method record contains the EXC deferred payment option code in the FPO Payment Code and the credit invoice has not yet been deposited (the Deposit created date for the Invoice Payment Method record is blank).

• updates the Deposit Release Date for the Invoice Payment Method record for the credit invoice with the calculated release date using the current date + the # of days for deferral defined for the EXC payment option. The deposit release date indicates when the deposit is eligible for processing; the system will not process the credit invoice until its deposit release date has been reached.

Reviewing the order in Order Inquiry: When reviewing orders flagged for net exchange billing:

• EXC displays under the Line # field on the Order Inquiry Detail Screen for the order detail line that contains the return item to indicate the returned item is associated with an exchange item. Note: The system identifies the order detail line that contains the exchange item by the associated Order Line History record that contains the exchange reason code. You can review order line history on the Display Order Line History Screen.

• the Net Bill field on the Display Invoices Screen for the credit invoice displays an asterisk, indicating the credit invoice is currently pending for net exchange billing. The system considers a credit invoice pending for credit card net exchange billing if the Invoice Payment Method record contains the EXC deferred payment option code in the IPM FPO Payment Code and the credit invoice has not yet been deposited (the IPM Deposit created date is blank).

Reviewing the refund: When reviewing refunds flagged for net exchange billing:

• the Net field on the Work with Refunds Screen and Work with Refunds By Order# Screen displays an asterisk for a refund that is pending net exchange billing.

• the text *NET BILLING displays next to the Amount field on the Change Refund Screen and Display Refund screen.

• the system prevents you from changing the pay type of the refund to another pay type (the Pay type field on the Change Refund screen is display-only).

• the Refund Due List by Type and the Refund Due List by Order # reports display an asterisk after the amount if the refund has been flagged for net exchange billing.

Generating a pick for the exchange item: During pick slip generation for the exchange item, the system applies the manual authorization to the shippable amount and performs batch authorization for any remaining balance due.

Shipping and billing the exchange item: When the shipment for the exchange item is processed through billing, the system:

• creates the debit invoice for the exchange item and assigns the EXC deferred payment option to the invoice.

• updates the Invoice Payment Method record for the debit invoice:

  • the IPM Auth # contains the authorization code defined in the Default Auth Code for CC Netting (M25) system control value.

  • the IPM Auth Date and IPM Deposit Release Date contain the current date.

• updates the IPM Deposit Release Date for the credit invoice flagged for net exchange billing to the current date, releasing the credit invoice for netting.

• processes the refund, even if the Hold until date for the refund has not been reached. However, the system does not print or email the credit card credit acknowledgment for the refund until the next time you run process refunds.

• updates the Pay Plan Code field for the credit card pay type on the Display Order Pay Type Screen (2 of 2) with the EXC deferred flexible payment option.

Processing deposits: When you process deposits, the system nets the credit invoice containing the return item against the debit invoice containing the exchange item.

• If the net difference is a credit, the system sends the credit invoice to the service bureau for settlement in order to refund the customer's credit card the net amount.

• If the net difference is a debit, the system sends the debit invoice to the service bureau for settlement in order to charge the customer's credit card the net amount.

• If the net difference is zero, the system does not send any invoice amount to the service bureau for settlement. No amount is applied to the customer's credit card.

Processing refunds: When you process refunds, the system defers the printing and emailing of credit card credit acknowledgments associated with refunds flagged for net exchange billing until the system nets the credit invoice containing the return item against the debit invoice containing the exchange item.

Once netting is performed, the system prints and emails credit card credit acknowledgments for refunds flagged for net exchange billing the next time you run process refunds. In addition, the Credit Card Credit Register displays an asterisk after the refund amount if the refund is flagged for net exchange billing.

The Display Refunds for Order Screen displays the amount of the refund that was processed.

• If the net difference is a debit, the refund amount updates to .00.

• If the net difference is a credit, the refund amount updates to the net credit amount.

• If the net difference is zero, the refund amount updates to .00.

Reviewing order transaction history: The system creates the following Order Transaction History records during the net exchange process to help you understand the updates that have taken place. You can view these messages on the Display Order History Screen.

When the exchange transaction is accepted and processed through billing, the system creates records similar to the following:

Type	Transaction Note	Amt	User
RTN AUTH	RA Credit pending processing	100.00	TBROWN
AUTH	MANUAL AUTH# DETECTED - CCNET	100.00	AUTH
SHIPMENT	CREDIT BILLED ON INVOICE# 0001014	100.00-	TBROWN

When you ship and bill the exchange item, the system creates records similar to the following:

Type	Transaction Note	Amt	User
REFUND	CC Crd for inv# 1014 processed-deferred	100.00	your default user
SHIPMENT	Pick# 0003977 Billed on Invoice# 0001015	60.00	TBROWN

When you process deposits, the system creates a record similar to the following:

Type	Transaction Note	Amt	User
REFUND	Refund amount netted to -40.00		TBROWN

Reviewing order payment history: The system creates the following Order Payment History records during the net exchange process to help you understand the updates that have taken place. You can view these messages on the Display Order Payment History Screen.

When the exchange transaction is accepted, the system creates records similar to the following:

Type	Note	Inv	User
B	Inv# 1014 created for $100.00-	1014	TBROWN
B	with a deposit release date of 20815.	1014	TBROWN

When you ship and bill the exchange item, the system creates records similar to the following:

Type	Note	Inv	User
B	Inv# 1015 created for $60.00	1015	TBROWN
B	with a deposit release date of 12915.	1015	TBROWN

When you process deposits, the system creates records similar to the following:

Type	Note	Inv	User
N	Pend Dep of $60.00 on INV1015 netted	1015	TBROWN
N	against CRD1014 reducing to $40.00-.	1015	TBROWN
N	Pend Dep of $60.00 on INV1015 netted	1014	TBROWN
N	against CRD1014 reducing to $40.00-.	1014	TBROWN
D	Deposit confirmed $ 40.00-.	1014	TBROWN

Net exchange billing considerations:

• An order is not eligible for net exchange billing if:

  • you return an item and then manually add an exchange item to the order.

  • the exchange item is soldout.

In these situations, the system does not link the exchange item with the return item and processes the return and exchange separately.

• If you cancel the exchange item, the system does not perform net exchange billing and credits the customer’s credit card for the amount of the return.

• If the manual authorization created for the return amount expires before the exchange item is shipped and billed, the system performs batch authorization during pick slip generation and continues to hold the credit invoice and refund in order to perform net exchange billing during deposits.

• Regardless of whether you consolidate invoices, the system flags all credit and debit invoices associated with the return and exchange transaction for net exchange billing. See the following for examples:

  • CC Net Example: Uneven Exchange for Less Expensive Item Plus Ship Alone Item; Invoices Not Consolidated

  • CC Net Example: Uneven Exchange for Less Expensive Item Plus Ship Alone Item; Invoices Consolidated

  • CC Net Example: Uneven Exchange for More Expensive Item Plus Ship Alone Item, Invoices Not Consolidated

  • CC Net Example: Uneven Exchange for More Expensive Item Plus Ship Alone Item; Invoices Consolidated

• If the order contains more than one credit card, the system includes both credit cards in the net exchange process.

• If an item on the order is shipped and billed on the same day as the exchange item, the system includes the amount of the additional item in the net exchange process. See CC Net Example: Even Exchange Plus Additional Item for an example.

In this topic:

• Credit Card Net Exchange Setup

• Credit Card Net Exchange Examples

Credit Card Net Exchange Setup

Before you can use credit card net exchange billing, you must complete the required setup. Information requiring setup includes:

• System Control Values for Credit Card Net Exchange Billing

• EXC Net Billing for Exchanges Flexible Payment Option

• Credit Card Net Exchange Edit in Work with Pay Types (WPAY)

System Control Values for Credit Card Net Exchange Billing

System Control Value	Description
Use CC Net Exchange Billing (M23)	Select this system control value if you want the system to net credit invoices with debit invoices before a deposit is sent to the service bureau for an invoice associated with an exchange.
Hold Days for CC Netting (M24)	Enter the number of days the system holds debit and credit invoices for credit card net exchange billing. The system updates the # of days for deferral field for the EXC Net Billing for Exchanges flexible payment option record with this number. Any existing refunds and Invoice Payment Method records are not updated with the new hold days. Note:  Net exchange billing does not work unless this system control value is set to a number greater than 0.
Default Auth Code for CC Netting (M25)	Enter the authorization code the system uses when creating a manual authorization to allow for the netting of invoices during the credit card net exchange process.
Preload Deposits (L78)	Deselect this system control value if the Use CC Net Exchange Billing (M23) system control value is selected. You cannot use preload deposit processing if you are using Credit Card Net Exchange Billing.

EXC Net Billing for Exchanges Flexible Payment Option

The system creates the EXC Net Billing for Exchanges flexible payment option automatically if you select the Use CC Net Exchange Billing (M23) system control value for use during the Credit Card Net Exchange process. You cannot change or delete this flexible payment option or use this flexible payment option for deferred/installment billing. The default settings for the EXC flexible payment option are described below; see Working with Flexible Payment Options (WFPO) for more information on flexible payment options.

This flexible payment option is deleted automatically if you deselect the Use CC Net Exchange Billing (M23) system control value.

Field	Description
Payment Code	Delivered as EXC.
Description	Delivered as Net Billing for Exchanges.
Type	Delivered as Deferred, indicating the system defers depositing the amount the customer owes for an order shipment for a specified period of time.
Start	Does not apply to net exchange billing.
End	Does not apply to net exchange billing.
Expiration Date	Does not apply to net exchange billing.
View in OE/OM	Delivered as unselected, since the EXC Net Billing for Exchanges flexible payment option is not an available selection during deferred/installment billing.
Restrict to entity	Delivered as 0, indicating the flexible payment option is not restricted to a specific entity.
Auth full amount	Delivered as unselected since this field is not used during the credit card net exchange process.
Merchant ID Message	Delivered blank since this field is not used during the credit card net exchange process.
Ship Complete	Delivered as unselected since this field is not used during the credit card net exchange process.
Display Summary	Delivered as unselected since this field is not used during the credit card net exchange process.
Auto apply	Delivered as No auto apply since this field is not used during the credit card net exchange process.
Validate CC ext dt	Delivered as unselected since this field is not used during the credit card net exchange process.
Pick Message	Delivered blank since this field is not used during the credit card net exchange process.
Deferred Values
# of days for deferral	Delivered as 0. The system updates this field with the number of days you enter in the Hold Days for CC Netting (M24) system control value. This is the number of days the system holds debit and credit invoices for credit card net exchange billing. The system also uses this number to determine the manual authorization date during Credit Card Net Exchange Billing.
Based On	Delivered as Invoice Dt, indicating the system uses the invoice (billing) date and # of days for deferral field to calculate the deposit date.
Fixed deferral date	Delivered as 0 since this field is not used during the credit card net exchange process.
Installment Values	The # Of Installments, Interval, and Fixed Installment day fields are set to 0 for the EXC flexible payment option.
Qualification Values	The Offer and Item fields are blank and the Minimum Amt and Pay Type fields are set to 0 for the EXC flexible payment option.

Credit Card Net Exchange Edit in Work with Pay Types (WPAY)

If the Use CC Net Exchange Billing (M23) system control value is selected, you cannot define an Alternate refund type or Alternate refund category for a Credit Card Pay type category pay type; the system displays an error message: Alt refund type/category not allowed with CC Net Exchange Billing.

Also, if an alternate refund type or alternate refund category is defined for an existing pay type, the system will ignore the alternate refund values and instead perform credit card net exchange billing for eligible orders.

Credit Card Net Exchange Examples

• CC Net Example: Even Exchange

• CC Net Example: Even Exchange Plus Additional Item

• CC Net Example: Uneven Exchange for Less Expensive Item

• CC Net Example: Uneven Exchange for Less Expensive Item Plus Ship Alone Item; Invoices Not Consolidated

• CC Net Example: Uneven Exchange for Less Expensive Item Plus Ship Alone Item; Invoices Consolidated

• CC Net Example: Uneven Exchange for More Expensive Item

• CC Net Example: Uneven Exchange for More Expensive Item Plus Ship Alone Item, Invoices Not Consolidated

• CC Net Example: Uneven Exchange for More Expensive Item Plus Ship Alone Item; Invoices Consolidated

CC Net Example: Even Exchange

The system performs the following steps during credit card net exchange processing when the returned item is the same price as the exchange item. In this example, no other items besides the exchange item are added to the order.

#	Step
1.	The customer places an order for an item for $100.00. The item is picked, shipped, and billed. The order is processed through deposits.
2.	The customer returns the item for $100.00 to exchange it for another item for the same price ($100.00). The exchange item is in-stock and reserved on the order. The customer also adds another item for $30.00 to the order.
3	When the return and exchange transaction is accepted and billed, the system: updates the ODT Seq # field in the RA Exchange Item table with the order detail sequence number of the exchange item added to the order. creates a manual authorization for the return amount ($100.00) using the authorization code defined in the Default Auth Code for CC Netting (M25) system control value. The expiration date for the manual authorization is based on the Reauthorization days defined for the credit card pay type. creates a refund for $100.00 in a held status and updates the Hold until date with the calculated hold days using the current date + the # of days for deferral defined for the EXC flexible payment option. creates a credit invoice for the returned item for $100.00 and updates the Invoice Payment Method record for the credit invoice: the FPO Payment Code contains the EXC flexible payment option code. t the Deposit Release Date is calculated using the current date + the # of days for deferral defined for the EXC flexible payment option. creates the following Order Transaction History records that you can view on the Display Order History screen: RTN AUTH RA Credit pending processing 100.00 KBROWN AUTH            MANUAL AUTH# DETECTED - CCNET       100.00     OEPICKAUTH SHIPMENT        CREDIT BILLED ON INVOICE# 0001011   100.00-    KBROWN creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B Inv# 1011 created for $100.00-                   1011     KBROWN B     with a deposit release date of 20715             1011     KBROWN
4	You run pick slip generation for the exchange item.
5	You ship and bill the exchange item and additional item. The system: creates a debit invoice for $100.00 for the exchange item and updates the Invoice Payment Method record for the debit invoice: the IPM Auth # contains the authorization code defined in the Default Auth Code for CC Netting (M25) system control value. the IPM Auth Date contains the current date. the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date contains the current date. releases the credit invoice for netting, updating the IPM Deposit Release Date to the current date. processes the refund. However, the system does not print or email the credit card credit acknowledgment for the refund until the next time you run process refunds. updates the Pay Plan Code field for the credit card pay type on the Display Order Pay Type 2 screen with the EXC flexible payment option code. creates the following Order Transaction History records that you can view on the Display Order History screen: REFUND   CC Crd for inv# 1011 processed-deferred   100.00  your default user SHIPMENT Pick# 0003974 Billed on Invoice# 0001012 100.00   KBROWN  creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B     Inv# 1012 created for $100.00                    1012     KBROWN B     with a deposit release date of 12815             1012     KBROWN
6	You process deposits. The system: nets the credit invoice containing the return item with the debit invoice containing the exchange item. In this example, the net difference is zero. No funds are credited or deposited. For the credit invoice that contains the returned item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to -100.00. The Deposit To Date field remains blank since no amount was deposited for the credit invoice. For the debit invoice that contains the exchange item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to 100.00. The Deposit To Date field remains blank since no amount was deposited for the debit invoice. updates the Refund amount on the Display Refunds for Order Screen to .00. creates the following Order Transaction History record that you can view on the Display Order History screen: REFUND        Refund amount netted to 0.00                    KBROWN creates the following Order Payment History records that you can view on the Display Order Payment History Screen: N     Pend Dep of $100.00 on CRD1011 netted                  1011     KBROWN N     against INV1012 reducing to $00.00.                    1011     KBROWN N     Pend Dep of $100.00 on CRD1011 netted                  1012     KBROWN N     against INV1012 reducing to $00.00.                    1012     KBROWN

CC Net Example: Even Exchange Plus Additional Item

The system performs the following steps during credit card net exchange processing when the returned item is the same price as the exchange item. In this example, an additional item for $30.00 is added to the order.

#	Step
1.	The customer places an order for an item for $100.00. The item is picked, shipped, and billed. The order is processed through deposits.
2.	The customer returns the item for $100.00 to exchange it for another item for the same price ($100.00). The exchange item is in-stock and reserved on the order. The customer also adds another item for $30.00 to the order.
3	When the return and exchange transaction is accepted and billed, the system: updates the ODT Seq # field in the RA Exchange Item table with the order detail sequence number of the exchange item added to the order. creates a refund for $100.00 in a held status and updates the Hold until date with the calculated hold days using the current date + the # of days for deferral defined for the EXC flexible payment option. creates a credit invoice for the returned item for $100.00 and updates the Invoice Payment Method record for the credit invoice: the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date is calculated using the current date + the # of days for deferral defined for the EXC flexible payment option. creates the following Order Transaction History records that you can view on the Display Order History screen: RTN AUTH RA Credit pending processing 100.00 KBROWN MAINT Order was maintained 130.00 KBROWN SHIPMENT CREDIT BILLED ON INVOICE# 0001033 100.00- KBROWN creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B Inv# 1033 created for $100.00- 1033 KBROWN B with a deposit release date of 30115 1033 KBROWN
4	You run pick slip generation for the exchange item and additional item. The system: creates a manual authorization for the return amount ($100.00) using the authorization number defined in the Default Auth Code for CC Netting (M25) system control value. The authorization date is the current date and the expiration date for the manual authorization is based on the Reauthorization days defined for the credit card pay type. performs batch authorization for the additional item ($30.00) added to the order. creates the following Order Transaction History record that you can view on the Display Order History screen: AUTH            MANUAL AUTH# DETECTED - CCNET       100.00     AUTH
5	You ship and bill the exchange item and additional item. The system: creates a debit invoice for $130.00 for the exchange item ($100.00) and the additional item ($30.00). The system also updates the Invoice Payment Method record for the debit invoice: the IPM Auth # contains the authorization code defined in the Default Auth Code for CC Netting (M25) system control value. the IPM Auth Date contains the current date. the IPM FPO Payment Code field contains the EXC Net Billing for Exchanges flexible payment option code. the IPM Deposit Release Date contains the current date. releases the credit invoice for netting, updating the IPM Deposit Release Date to the current date. processes the refund. However, the system does not print or email the credit card credit acknowledgment for the refund until the next time you run process refunds. updates the Pay Plan Code field for the credit card pay type on the Display Order Pay Type 2 screen with the EXC flexible payment option code. creates the following Order Transaction History records that you can view on the Display Order History screen: REFUND CC Crd for inv# 1033 processed-deferred 100.00 your default user SHIPMENT Pick# 0004031 Billed on Invoice# 0001034 130.00 KBROWN  creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B Inv# 1034 created for $130.00 1034 KBROWN with a deposit release date of 21915 1034 KBROWN
6	You process deposits. The system: nets the credit invoice containing the return item with the debit invoice containing the exchange item. In this example, the net difference is $30.00 for the additional item added to the order. The system processes the debit invoice for $30.00. For the credit invoice that contains the returned item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to -100.00. The Deposit To Date field remains blank since no amount was deposited for the credit invoice. For the debit invoice that contains the exchange item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to 130.00. The Deposit To Date field updates to 30.00. updates the Refund amount on the Display Refunds for Order Screen to .00. creates the following Order Transaction History record that you can view on the Display Order History screen: REFUND        Refund amount netted to 0.00                    KBROWN creates the following Order Payment History records that you can view on the Display Order Payment History Screen: N     Pend Dep of $100.00 on CRD1033 netted                  1033     KBROWN N     against INV1034 reducing to $30.00.                    1033     KBROWN N     Pend Dep of $100.00 on CRD1033 netted                  1034     KBROWN N     against INV1034 reducing to $30.00.                    1034     KBROWN D     Deposit confirmed $ 30.00                              1034     KBROWN

CC Net Example: Uneven Exchange for Less Expensive Item

The system performs the following steps during credit card net exchange processing when the exchange item is less expensive than the return item. In this example, no other items besides the exchange item are added to the order.

#	Step
1.	The customer places an order for an item for $100.00. The item is picked, shipped, and billed. The order is processed through deposits.
2.	The customer returns the item for $100.00 to exchange it for a less expensive item ($60.00).
3	When the return and exchange transaction is accepted and billed, the system updates the ODT Seq # field in the RA Exchange Item table with the order detail sequence number of the exchange item added to the order. creates a manual authorization for the return amount ($100.00) using the authorization number defined in the Default Auth Code for CC Netting (M25) system control value. The expiration date for the manual authorization is based on the Reauthorization days defined for the credit card pay type. creates a refund for $100.00 in a held status and updates the Hold until date with the calculated hold days using the current date + the # of days for deferral defined for the EXC flexible payment option. creates a credit invoice for the returned item for $100.00 and updates the Invoice Payment Method record for the credit invoice: the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date is calculated using the current date + the # of days for deferral defined for the EXC flexible payment option. creates the following Order Transaction History records that you can view on the Display Order History screen: RTN AUTH RA Credit pending processing 100.00 KBROWN MAINT          Order was maintained                      60.00  KBROWN AUTH           MANUAL AUTH# DETECTED - CCNET            100.00  OEPICKAUTH SHIPMENT       CREDIT BILLED ON INVOICE# 0001036.       100.00- KBROWN  creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B      Inv# 1036 created for $100.00-           1036 KBROWN B      with a deposit release date of 30115.    1036 KBROWN
4	You run pick slip generation for the exchange item
5	You ship and bill the exchange item and additional item. The system: creates a debit invoice for $60.00 for the exchange item. The system also updates the Invoice Payment Method record for the debit invoice: the IPM Auth # contains the authorization code defined in the Default Auth Code for CC Netting (M25) system control value. the IPM Auth Date contains the current date. the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date contains the current date. releases the credit invoice for netting, updating the IPM Deposit Release Date to the current date. processes the refund. However, the system does not print or email the credit card credit acknowledgment for the refund until the next time you run process refunds. updates the Pay Plan Code field for the credit card pay type on the Display Order Pay Type 2 screen with the EXC flexible payment option code. creates the following Order Transaction History records that you can view on the Display Order History screen: REFUND   CC Crd for inv# 1036 processed-deferred 100.00    your default user SHIPMENT Pick# 0004037 Billed on Invoice# 0001037 60.00    KBROWN  creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B      Inv# 1037 created for $60.00             1037    KBROWN  B      with a deposit release date of 21915.    1037    KBROWN
6	You process deposits. The system: nets the credit invoice containing the return item with the debit invoice containing the exchange item. In this example, the net difference is a 40.00 credit. The system processes the credit invoice for 40.00. For the credit invoice that contains the returned item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to -60.00 and updates the Deposit To Date field to -40.00. For the debit invoice that contains the exchange item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to 60.00. The Deposit To Date field remains blank since no amount was deposited for the debit invoice. updates the refund amount to 40.00 to reflect the actual amount refunded to the customer’s credit card. You can review the updated amount on the Display Refunds for Order Screen. creates the following Order Transaction History record that you can view on the Display Order History screen: REFUND    Refund amount netted to  -40.00                      KBROWN    creates the following Order Payment History records that you can view on the Display Order Payment History Screen: N     Pend Dep of $60.00  on INV1037  netted      1037    KBROWN    N     against CRD1036  reducing to $40.00- .      1037    KBROWN    N     Pend Dep of $60.00  on INV1037  netted      1036    KBROWN  N     against CRD1036  reducing to $40.00- .      1036    KBROWN D     Deposit confirmed $ 40.00-                  1036    KBROWN

CC Net Example: Uneven Exchange for Less Expensive Item Plus Ship Alone Item; Invoices Not Consolidated

The system performs the following steps during credit card net exchange processing when the exchange item is less expensive than the return item. In this example, the customer also orders an additional ship alone item for $30.00. The Consolidated Invoice (B49) system control value is unselected.

#	Step
1.	The customer places an order for an item for $100.00. The item is picked, shipped, and billed. The order is processed through deposits.
2.	The customer returns the item for $100.00 to exchange it for a less expensive item ($60.00). The customer also adds a ship alone item for $30.00 to the order.
3	When the return and exchange transaction is accepted and billed, the system updates the ODT Seq # field in the RA Exchange Item table with the order detail sequence number of the exchange item added to the order. creates a manual authorization for the return amount ($100.00) using the authorization number defined in the Default Auth Code for CC Netting (M25) system control value. The expiration date for the manual authorization is based on the Reauthorization days defined for the credit card pay type. creates a refund for $100.00 in a held status and updates the Hold until date with the calculated hold days using the current date + the # of days for deferral defined for the EXC flexible payment option. creates a credit invoice for the returned item for $100.00. The system also updates the Invoice Payment Method record for the credit invoice: the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date is calculated using the current date + the # of days for deferral defined for the EXC flexible payment option. creates the following Order Transaction History records that you can view on the Display Order History screen: RTN AUTH RA Credit pending processing 100.00 KBROWN MAINT          Order was maintained                      90.00  KBROWN AUTH           MANUAL AUTH# DETECTED - CCNET            100.00  OEPICKAUTH SHIPMENT       CREDIT BILLED ON INVOICE# 0001039.       100.00- KBROWN  creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B      Inv# 1039 created for $100.00-           1039 KBROWN B      with a deposit release date of 30115.    1039 KBROWN
4	You run pick slip generation for the exchange item ($60.00) and ship alone item ($30.00). The system generates a separate pick slip for each item.
5	You ship and bill the exchange item and ship alone item. The system: creates a debit invoice for $60.00 for the exchange item. The system also updates the Invoice Payment Method record for the debit invoice: the IPM Auth # contains the authorization code defined in the Default Auth Code for CC Netting (M25) system control value. the IPM Auth Date contains the current date. the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date contains the current date. creates a debit invoice for $30.00 for the ship alone item. The system also updates the Invoice Payment Method record for the debit invoice: the IPM Auth # contains the authorization code defined in the Default Auth Code for CC Netting (M25)v system control value. the IPM Auth Date contains the current date. the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date contains the current date. releases the credit invoice for netting, updating the IPM Deposit Release Date to the current date. processes the refund. However, the system does not print or email the credit card credit acknowledgment for the refund until the next time you run process refunds. updates the Pay Plan Code field for the credit card pay type on the Display Order Pay Type 2 screen with the EXC flexible payment option code. creates the following Order Transaction History records that you can view on the Display Order History screen: REFUND   CC Crd for inv# 1039 processed-deferred   100.00  your default user SHIPMENT Pick# 0004039 Billed on Invoice# 0001040   60.00  KBROWN SHIPMENT Pick# 0004040 Billed on Invoice# 0001041   30.00  KBROWN  creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B     Inv# 1040 created for $60.00                     1040   KBROWN B     with a deposit release date of 21915             1040   KBROWN B     Inv# 1041 created for $30.00                     1041   KBROWN B     with a deposit release date of 21915             1041   KBROWN
6	You process deposits. The system: nets the credit invoice containing the return item with the debit invoices containing the exchange item and ship alone item. In this example, the net difference is a 10.00 credit (100.00 credit invoice - 60.00 debit invoice - 30.00 debit invoice = 10.00 credit) The system processes the credit invoice for 10.00. For the credit invoice that contains the returned item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to -90.00 and updates the Deposit To Date field to -10.00.   For the debit invoice that contains the exchange item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to 60.00. The Deposit To Date field remains blank since no amount was deposited for the debit invoice. For the debit invoice that contains the ship alone item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to 30.00. The Deposit To Date field remains blank since no amount was deposited for the debit invoice.   updates the refund amount to 10.00 to reflect the actual amount refunded to the customer’s credit card. You can review the updated amount on the Display Refunds for Order Screen. creates the following Order Transaction History record that you can view on the Display Order History screen: REFUND    Refund amount netted to  -40.00                      KBROWN    creates the following Order Payment History records that you can view on the Display Order Payment History Screen: N     Pend Dep of $60.00 on INV1040 netted                   1040     KBROWN N     against CRD1039 reducing to $40.00-.                   1040     KBROWN N     Pend Dep of $60.00 on INV1040 netted                   1039     KBROWN N     against CRD1039 reducing to $40.00-.                   1039     KBROWN N     Pend Dep of $30.00 on INV1041 netted                   1041     KBROWN N     against CRD1039 reducing to $10.00-.                   1041     KBROWN N     Pend Dep of $30.00 on INV1041 netted                   1039     KBROWN N     against CRD1039 reducing to $10.00-.                   1039     KBROWN D     Deposit confirmed $ 10.00-                             1039     KBROWN

CC Net Example: Uneven Exchange for Less Expensive Item Plus Ship Alone Item; Invoices Consolidated

The system performs the following steps during credit card net exchange processing when the exchange item is less expensive than the return item. In this example, the customer also orders an additional ship alone item for $30.00. The Consolidated Invoice (B49) system control value is selected.

Important:

In Order Management System 21.0 or higher, or Order Administration, you cannot select the Consolidated Invoice system control value if it is not already selected. If the system control value is currently selected (set to Y) and you deselect it (change it to N or blank), you cannot then change it back to selected. The option to consolidate invoices will be removed at a later date.

#	Step
1.	The customer places an order for an item for $100.00. The item is picked, shipped, and billed. The order is processed through deposits.
2.	The customer returns the item for $100.00 to exchange it for a less expensive item ($60.00). The customer also adds a ship alone item for $30.00 to the order.
3	When the return and exchange transaction is accepted and billed, the system updates the ODT Seq # field in the RA Exchange Item table with the order detail sequence number of the exchange item added to the order. creates a manual authorization for the return amount ($100.00) using the authorization number defined in the Default Auth Code for CC Netting (M25) system control value. The expiration date for the manual authorization is based on the Reauthorization days defined for the credit card pay type. creates a refund for $100.00 in a held status and updates the Hold until date with the calculated hold days using the current date + the # of days for deferral defined for the EXC flexible payment option. creates a credit invoice for the returned item for $100.00. The system also updates the Invoice Payment Method record for the credit invoice: the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date is calculated using the current date + the # of days for deferral defined for the EXC flexible payment option. creates the following Order Transaction History records that you can view on the Display Order History screen: RTN AUTH        RA Credit pending processing        100.00     KBROWN MAINT           Order was maintained                 90.00     KBROWN AUTH            MANUAL AUTH# DETECTED - CCNET       100.00     OEPICKAUTH SHIPMENT        CREDIT BILLED ON INVOICE# 0001043   100.00-    KBROWN creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B     Inv# 1043 created for $100.00-                   1043    KBROWN B     with a deposit release date of 30115             1043    KBROWN
4	You run pick slip generation for the exchange item ($60.00) and ship alone item ($30.00). The system generates a separate pick slip for each item.
5	You ship and bill the exchange item and ship alone item. The system:  creates a debit invoice for $90.00 for the exchange item and ship alone item (60.00 exchange item + 30.00 ship alone item). The system also updates the Invoice Payment Method record for the debit invoice: the IPM Auth # contains the authorization code defined in the Default Auth Code for CC Netting (M25) system control value. the IPM Auth Date contains the current date. the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date contains the current date. releases the credit invoice for netting, updating the IPM Deposit Release Date to the current date. processes the refund. However, the system does not print or email the credit card credit acknowledgment for the refund until the next time you run process refunds. updates the Pay Plan Code field for the credit card pay type on the Display Order Pay Type 2 screen with the EXC Net Billing for Exchanges flexible payment option code. creates the following Order Transaction History records that you can view on the Display Order History screen: REFUND CC Crd for inv# 1043 processed-deferred     100.00  your default user SHIPMENT Pick# 0004042 Billed on Invoice# 0001044   60.00  KBROWN SHIPMENT Pick# 0004043 Billed on Invoice# 0001044   30.00  KBROWN  creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B     Inv# 1044 created for $60.00                     1044   KBROWN B     with a deposit release date of 21915             1044   KBROWN B     Inv# 1044 created for $60.00                     1044   KBROWN B     with a deposit release date of 21915             1044   KBROWN
6	You process deposits. The system: nets the credit invoice containing the return item with the debit invoice containing the exchange item and ship alone item. In this example, the net difference is a 10.00 credit (100.00 credit invoice - 90.00 debit invoice = 10.00 credit). The system processes the credit invoice for 10.00. For the credit invoice that contains the returned item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to -90.00 and updates the Deposit To Date field to -10.00.  For the debit invoice that contains the exchange item and ship alone item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to 90.00. The Deposit To Date field remains blank since no amount was deposited for the debit invoice. updates the refund amount to 10.00 to reflect the actual amount refunded to the customer’s credit card. You can review the updated amount on the Display Refunds for Order Screen. creates the following Order Transaction History record that you can view on the Display Order History screen: REFUND        Refund amount netted to -10.00                    KBROWN creates the following Order Payment History records that you can view on the Display Order Payment History Screen: N Pend Dep of $90.00  on INV1044  netted   1044 KBROWN N against CRD1043  reducing to $10.00- .   1044 KBROWN N Pend Dep of $90.00  on INV1044  netted   1043 KBROWN N against CRD1043  reducing to $10.00- .   1043 KBROWN D Deposit confirmed $ 10.00-               1043 KBROWN

CC Net Example: Uneven Exchange for More Expensive Item

The system performs the following steps during credit card net exchange processing when the exchange item is more expensive than the return item. In this example, no other items besides the exchange item are added to the order.

#	Step
1.	The customer places an order for an item for $100.00. The item is picked, shipped, and billed. The order is processed through deposits.
2.	The customer returns the item for $100.00 to exchange it for a more expensive item ($140.00).
3	When the return and exchange transaction is accepted and billed, the system updates the ODT Seq # field in the RA Exchange Item table with the order detail sequence number of the exchange item added to the order. creates a manual authorization for the return amount ($100.00) using the authorization number defined in the Default Auth Code for CC Netting (M25) system control value. The expiration date for the manual authorization is based on the Reauthorization days defined for the credit card pay type. creates a refund for $100.00 in a held status and updates the Hold until date with the calculated hold days using the current date + the # of days for deferral defined for the EXC flexible payment option. creates a credit invoice for the returned item for $100.00. The system also updates the Invoice Payment Method record for the credit invoice: the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date is calculated using the current date + the # of days for deferral defined for the EXC flexible payment option. creates the following Order Transaction History records that you can view on the Display Order History screen: RTN AUTH     RA Credit pending processing             100.00    KBROWN   MAINT        Order was maintained                     140.00    KBROWN SHIPMENT     CREDIT BILLED ON INVOICE# 0001046.       100.00-   KBROWN   creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B    Inv# 1046 created for $100.00-           1046    KBROWN B    with a deposit release date of 30515.    1046    KBROWN
4	You run pick slip generation for the exchange item. During pick slip generation, the system: creates a manual authorization for the return amount ($100.00) using the authorization number defined in the Default Auth Code for CC Netting (M25) system control value. The expiration date for the manual authorization is based on the Reauthorization days defined for the credit card pay type. performs batch authorization for the exchange amount that is not covered by the authorized amount already on the order. In this example, the system performs batch authorization for $40.00 since the order already was authorized for $100.00 for the item that was returned. creates the following Order Transaction History records that you can view on the Display Order History screen: AUTH            MANUAL AUTH# DETECTED - CCNET       100.00     AUTH
5	You ship and bill the exchange item and ship alone item. The system:  creates a debit invoice for $90.00 for the exchange item and ship alone item (60.00 exchange item + 30.00 ship alone item). The system also updates the Invoice Payment Method record for the debit invoice: the IPM Auth # contains the authorization code defined in the Default Auth Code for CC Netting (M25) system control value. the IPM Auth Date contains the current date. the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date contains the current date. releases the credit invoice for netting, updating the IPM Deposit Release Date to the current date. processes the refund. However, the system does not print or email the credit card credit acknowledgment for the refund until the next time you run process refunds. updates the Pay Plan Code field for the credit card pay type on the Display Order Pay Type 2 screen with the EXC Net Billing for Exchanges flexible payment option code. creates the following Order Transaction History records that you can view on the Display Order History screen: REFUND   CC Crd for inv# 1046 processed-deferred   100.00  your default user SHIPMENT Pick# 0004045 Billed on Invoice# 0001047  140.00  KBROWN    creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B     Inv# 1047 created for $140.00            1047   KBROWN B     with a deposit release date of 22315.    1018   KBROWN
6	You process deposits. The system: nets the credit invoice containing the return item with the debit invoice containing the exchange item. In this example, the net difference is 40.00. The system processes the debit invoice for 40.00. For the credit invoice that contains the returned item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to -100.00 and leaves the Deposit To Date field blank since no amount was deposited for the credit invoice.  For the debit invoice that contains the exchange item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to 100.00 and updates the Deposit To Date field to 40.00. creates the following Order Transaction History record that you can view on the Display Order History screen: REFUND        Refund amount netted to 0.00                    KBROWN creates the following Order Payment History records that you can view on the Display Order Payment History Screen:  N Pend Dep of $100.00  on CRD1046  netted  1046 KBROWN   N against INV1047  reducing to $40.00 .    1046 KBROWN     N Pend Dep of $100.00  on CRD1046  netted  1047 KBROWN     N against INV1047  reducing to $40.00 .    1047 KBROWN    D Deposit confirmed $ 40.00-               1047 KBROWN

CC Net Example: Uneven Exchange for More Expensive Item Plus Ship Alone Item, Invoices Not Consolidated

The system performs the following steps during credit card net exchange processing when the exchange item is more expensive than the return item. In this example, the customer also orders an additional ship alone item for $30.00. The Consolidated Invoice (B49) system control value is unselected.

#	Step
1.	The customer places an order for an item for $100.00. The item is picked, shipped, and billed. The order is processed through deposits.
2.	The customer returns the item for $100.00 to exchange it for a more expensive item ($140.00) and also adds a ship alone item for $30.00.
3	When the return and exchange transaction is accepted and billed, the system updates the ODT Seq # field in the RA Exchange Item table with the order detail sequence number of the exchange item added to the order. creates a manual authorization for the return amount ($100.00) using the authorization number defined in the Default Auth Code for CC Netting (M25) system control value. The expiration date for the manual authorization is based on the Reauthorization days defined for the credit card pay type. creates a refund for $100.00 in a held status and updates the Hold until date with the calculated hold days using the current date + the # of days for deferral defined for the EXC flexible payment option. creates a credit invoice for the returned item for $100.00. The system also updates the Invoice Payment Method record for the credit invoice: the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date is calculated using the current date + the # of days for deferral defined for the EXC flexible payment option. creates the following Order Transaction History records that you can view on the Display Order History screen: RTN AUTH        RA Credit pending processing        100.00     KBROWN MAINT           Order was maintained                170.00     KBROWN SHIPMENT        CREDIT BILLED ON INVOICE# 0001049   100.00-    KBROWN   creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B    Inv# 1046 created for $100.00-           1046    KBROWN B    with a deposit release date of 30515.    1046    KBROWN
4	You run pick slip generation for the exchange item. During pick slip generation, the system:  creates a manual authorization for the return amount ($100.00) using the authorization number defined in the Default Auth Code for CC Netting (M25) system control value. The expiration date for the manual authorization is based on the Reauthorization days defined for the credit card pay type.   performs batch authorization for the amount that is not covered by the manual authorization amount already on the order. In this example, the system processes a separate batch authorization for $40.00 for the exchange item and $30.00 for the ship alone item.   creates the following Order Transaction History records that you can view on the Display Order History screen: AUTH MANUAL AUTH# DETECTED - CCNET 100.00 AUTH
5	You ship and bill the exchange item and ship alone item. The system: creates a debit invoice for $140.00 for the exchange item. The system also updates the Invoice Payment Method record for the debit invoice: the IPM Auth # contains the authorization code defined in the Default Auth Code for CC Netting (M25) system control value. the IPM Auth Date contains the current date. the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date contains the current date. creates a debit invoice for $30.00 for the ship alone item. The system also updates the Invoice Payment Method record for the debit invoice: the IPM Auth # contains the authorization code defined in the Default Auth Code for CC Netting (M25) system control value. the IPM Auth Date contains the current date. the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date contains the current date. releases the credit invoice for netting, updating the IPM Deposit Release Date to the current date. processes the refund. However, the system does not print or email the credit card credit acknowledgment for the refund until the next time you run process refunds. updates the Pay Plan Code field for the credit card pay type on the Display Order Pay Type 2 screen with the EXC Net Billing for Exchanges flexible payment option code. creates the following Order Transaction History records that you can view on the Display Order History screen: REFUND   CC Crd for inv# 1049 processed-deferred   100.00  your default user SHIPMENT Pick# 0004047 Billed on Invoice# 0001050  140.00  KBROWN  SHIPMENT Pick# 0004048 Billed on Invoice# 0001051   30.00  KBROWN   creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B Inv# 1050 created for $140.00            1050 KBROWN    B with a deposit release date of 22315.    1050 KBROWN    B Inv# 1051 created for $30.00             1051 KBROWN    B with a deposit release date of 22315. 1051 KBROWN
6	You process deposits. The system:   nets the credit invoice containing the return item with the debit invoices containing the exchange item and ship alone item. In this example, the net difference is 40.00 (100.00 credit for return item- 140.00 debit for exchange item + 30.00 debit for ship alone item). The system processes the debit invoice for 30.00. For the credit invoice that contains the returned item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to -100.00 and leaves the Deposit To Date field blank since no amount was deposited for the credit invoice.  For the debit invoice that contains the exchange item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to 140.00 and updates the Deposit To Date field to 40.00   For the debit invoice that contains the ship alone item, the system leaves the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) blank and updates the Deposit To Date field to 30.00 creates the following Order Transaction History record that you can view on the Display Order History screen: REFUND        Refund amount netted to 0.00                    KBROWN creates the following Order Payment History records that you can view on the Display Order Payment History Screen:  N Pend Dep of $100.00  on CRD1049  netted  1049 KBROWN   N against INV1050  reducing to $40.00 .    1049 KBROWN     N Pend Dep of $100.00  on CRD1049  netted  1050 KBROWN     N against INV1050  reducing to $40.00 .    1050 KBROWN    D Deposit confirmed $ 40.00-               1051 KBROWN D Deposit confirmed $ 30.00 1051 KBROWN

CC Net Example: Uneven Exchange for More Expensive Item Plus Ship Alone Item; Invoices Consolidated

The system performs the following steps during credit card net exchange processing when the exchange item is more expensive than the return item. In this example, the customer also orders an additional ship alone item for $30.00. The Consolidated Invoice (B49) system control value is selected.

Important:

In Order Management System 21.0 or higher, or Order Administration, you cannot select the Consolidated Invoice system control value if it is not already selected. If the system control value is currently selected (set to Y) and you deselect it (change it to N or blank), you cannot then change it back to selected. The option to consolidate invoices will be removed at a later date.

#	Step
1.	The customer places an order for an item for $100.00. The item is picked, shipped, and billed. The order is processed through deposits.
2.	The customer returns the item for $100.00 to exchange it for a more expensive item ($140.00) and also adds a ship alone item for $30.00.
3	When the return and exchange transaction is accepted and billed, the system updates the ODT Seq # field in the RA Exchange Item table with the order detail sequence number of the exchange item added to the order. creates a manual authorization for the return amount ($100.00) using the authorization number defined in the Default Auth Code for CC Netting (M25) system control value. The expiration date for the manual authorization is based on the Reauthorization days defined for the credit card pay type.  creates a credit invoice for the returned item for $100.00. The system also updates Invoice Payment Method record for the credit invoice: the IPM FPO Payment Code field contains the EXC flexible payment option code and the IPM Deposit Release Date contains the calculated release date using the current date + the # of days for deferral defined for the EXC flexible payment option.  creates the following Order Transaction History records that you can view on the Display Order History screen: creates the following Order Transaction History records that you can view on the Display Order History screen: RTN AUTH   RA Credit pending processing             100.00     KBROWN MAINT      Order was maintained                     170.00     KBROWN SHIPMENT   CREDIT BILLED ON INVOICE# 0001053.       100.00-    KBROWN      creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B Inv# 1053 created for $100.00-           1053 KBROWN    B with a deposit release date of 30615. 1053 KBROWN
4	You run pick slip generation for the exchange item. During pick slip generation, the system:  creates a manual authorization for the return amount ($100.00) using the authorization number defined in the Default Auth Code for CC Netting (M25) system control value. The expiration date for the manual authorization is based on the Reauthorization days defined for the credit card pay type.   performs batch authorization for the amount that is not covered by the manual authorization amount already on the order. In this example, the system processes a separate batch authorization for $40.00 for the exchange item and $30.00 for the ship alone item.   creates the following Order Transaction History records that you can view on the Display Order History screen: AUTH MANUAL AUTH# DETECTED - CCNET                    100.00  AUTH
5	You ship and bill the exchange item and ship alone item. The system:   creates a debit invoice for $170.00 for the exchange item and ship alone item. The system also updates the Invoice Payment Method record for the debit invoice the IPM Auth # contains the authorization code defined in the Default Auth Code for CC Netting (M25) system control value. the IPM Auth Date contains the current date. the IPM FPO Payment Code field contains the EXC flexible payment option code. the IPM Deposit Release Date contains the current date. releases the credit invoice for netting, updating the IPM Deposit Release Date to the current date.   processes the refund for 100.00. However, the system does not print or email the credit card credit acknowledgment for the refund until the next time you run process refunds. updates the Pay Plan Code field for the credit card pay type on the Display Order Pay Type 2 screen with the EXC flexible payment option code. creates the following Order Transaction History records that you can view on the Display Order History screen: REFUND   CC Crd for inv# 1053 processed-deferred   100.00  your default user SHIPMENT Pick# 0004051 Billed on Invoice# 0001054  140.00  KBROWN     SHIPMENT Pick# 0004052 Billed on Invoice# 0001054   30.00  KBROWN     creates the following Order Payment History records that you can view on the Display Order Payment History Screen: B Inv# 1054 created for $140.00            1054 KBROWN    B with a deposit release date of 22415.    1054 KBROWN    B Inv# 1054 created for $170.00            1054 KBROWN    B with a deposit release date of 22415. 1054 KBROWN
6	You process deposits. The system:   nets the credit invoice containing the return item with the debit invoice containing the exchange item and ship alone item. In this example, the net difference is 70.00 (100.00 credit for return item- 170.00 debit for exchange item and ship alone item). The system processes the debit invoice for 70.00.. For the credit invoice that contains the returned item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to -100.00 and leaves the Deposit To Date field blank since no amount was deposited for the credit invoice.  For the debit invoice that contains the exchange item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to 140.00 and updates the Deposit To Date field to 40.00  For the debit invoice that contains the exchange item and ship alone item, the system updates the Adjusted Amt on the Display Invoice Payment Method Screen (Reviewing Detail) to 70.00 and updates the Deposit To Date field to 70.00. creates the following Order Transaction History record that you can view on the Display Order History screen: REFUND        Refund amount netted to 0.00                    KBROWN creates the following Order Payment History records that you can view on the Display Order Payment History Screen:  N Pend Dep of $100.00  on CRD1053  netted  1053 KBROWN     N against INV1054  reducing to $70.00 .    1053 KBROWN     N Pend Dep of $100.00  on CRD1053  netted  1054 KBROWN     N against INV1054  reducing to $70.00 .    1054 KBROWN       D Deposit confirmed $ 70.00 1054 KBROWN

Processing Deposits

Topics in this part:

• Processing Auto Deposits (SDEP) describes the Submit Auto Deposits menu option.

• Manage Rejected Deposits in Modern View describes how to review and work with rejected or unconfirmed deposits.

• Printing the Deposit History Summary (PDHS) describes how to print a report summarizing credit card deposits by date.

• Printing the Credit Card Deposit Schedule (PCCD) describes how to print a report listing the your projected deposits for deferred or installment billing pay plans.

• Printing the Pending Payment Plan Deposits Report (PPPD) describes how to print a report listing future deferred or installment deposits by order and invoice number.

• Printing the Deposit History Detail Report (PDHD) describes how to print a report listing deposits processed during a specific date range. Within this date range, you can select to include only deposits for a specific authorization service, pay type, and status.

E-Commerce Interface

Topics in this part:

• E-Commerce Catalog Requests describes how the system processes a catalog request received from the web storefront.

• E-Commerce Item Availability Processing describes how the system extracts item availability information for download to the web storefront.

  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

• Working with Batch Order Maintenance Transactions (WBOM) describes how the system processes a cancellation request from the web storefront and how to work with order cancel request errors.

• E-Commerce Setup describes the setup required in Order Administration for the e-commerce interface, and specifies additional documentation detailing setup requirements for communicating and for the web storefront.

• Downloading E-Commerce Offer Files (EOFR) describes the process you use to extract information related to items, source codes and offers to staging files for subsequent download to the web storefront.

• Working with E-Mail Notification Templates (WEMT) describes how to set up templates for the various email notifications you can send to customers.

• Sending Internet Order Ship Confirmation (ESCF) describes the menu option you use to send email confirmations for shipment of orders received through the web storefront.

Workflow Management

Topics in this part: The following topics describe the functions available for workflow management.

• Workflow Management Overview and Setup provides an overview on workflow management and required setup.

• Working with Tickler User Groups (WTUG) explains how to create and work with tickler user groups.

• Working with Tickler Category (WTCT) explains how to create and work with tickler categories.

• Working with Tickler Resolution Reasons (WTRR) explains how to create and work with tickler resolution reasons.

• Working with Tickler Events (WTEV) explains how to define tickler event settings at the event level and event rule level and create, change, delete, and define procedures for event rules.

• Working with Tickler Users/User Groups (WTIC) allows workflow users to review and work with ticklers in the user’s or user group’s tickler work queue.

• Workflow Management (WWFM) allows workflow supervisors to review and work with ticklers in a tickler work queue.

• Purging Ticklers (MPTK) allows you to purge resolved ticklers by date range.

Workflow Management Overview and Setup

Workflow management allows you to automate system actions, during which tasks (ticklers) are assigned to a user for action, according to a defined set of procedures, until the issues associated with the ticklers are resolved.

Tickler events are the system actions for which the system may create a workflow task (tickler).

Tickler event rules are the criteria that must be met by the system action for the system to create a tickler for a user to resolve.

Ticklers are tasks automatically created by the system and assigned to a user when a system action meets the criteria defined for a tickler event rule. For each tickler, you can define the procedures, or instructions, the user should follow to complete the task. A tickler can also be created manually.

Tickler procedures are the instructions a user follows to complete the tickler task.

Workflow Management Illustration

Example: This flowchart provides an example of the workflow process.

With workflow management:

• the system automatically creates ticklers when a task must be performed and resolved.

• the system assigns tasks to a specific user or group of users as soon as a tickler is created ensuring the tasks are not misplaced, stalled, or duplicated. Tickler assignment allows only authorized users access to the tickler and the associated data.

• supervisors are notified if a tickler remains unresolved for a specified number of days to ensure the tasks are resolved in a timely manner. Supervisors can reassign ticklers to the appropriate resource.

• the procedures to resolve a task are formally documented to ensure users are following the instructions exactly and reducing the cost of training staff.

• the most important ticklers are worked on first by a specified priority so users don’t waste time choosing which tickler to work on or putting off difficult tasks.

• a history of the activity performed against the tickler is stored for easy tracking and review of what was done and when.

In this topic:

• System Delivered Tickler Events

  • Defining Tickler Events and Event Rules

• Creating Ticklers

  • Why Wasn’t a Tickler Created?

• Working with Ticklers

  • Update All Ticklers Secured Feature

  • User Workflow Management Window

  • Customer Workflow Management Window

  • Tickler Merge/Purge

  • Resolving Ticklers

• Workflow Management Setup

  • System Control Value

  • Secured Feature

  • Number Assignment Value

  • Menu Options

  • Periodic Functions

System Delivered Tickler Events

This table describes the 11 system delivered events that can create ticklers, based on the system action and the criteria defined for the event rules. You use the Working with Tickler Events (WTEV) menu option to set up each tickler event and define criteria for each event rule.

Note:

Each tickler event is delivered as inactive.

Tickler Event...	creates a tickler when the system...	and one or more of the following criteria is met...
BO backorders	places an item on backorder	An item is backordered, regardless of any other criteria. The backordered item is initially backordered in order entry/maintenance and not by some other program. The customer’s life-to-date order dollars is less than, equal to, or greater than a specified life-to-date order dollars. The customer class defined for the sold to customer matches a specified customer class. The item/SKU on backorder matches a specified item/SKU.
		The item status of the backordered item matches a specified item status. The item class of the backordered item matches a specified item class. The ship via on the backordered order matches a specified ship via. The ship via priority for the ship via on the backordered order matches a specified ship via priority. See BO (Backorders) Event Processing.
CO cancelled orders	cancels an item	An item is cancelled, regardless of any other criteria. The item is cancelled by a batch process instead of interactively. The customer’s life-to-date order dollars is less than, equal to, or greater than a specified life-to-date order dollars. The customer class defined for the sold to customer matches a specified customer class. The cancelled item/SKU matches a specified item/SKU. The item status of the cancelled item matches a specified item status.
		The item class of the cancelled item matches a specified item class. The cancel reason matches a specified cancel reason. The ship via on the cancelled order matches a specified ship via. The ship via priority for the ship via on the cancelled order matches a specified ship via priority. See CO (Cancelled Orders) Event Processing.
HO held orders	places an order, order recipient, or order payment method on hold	The hold reason (order or pay type) matches a specified hold reason (order or pay type). The pay type on the held order matches a specified pay type. The order total for the held order is less than, equal to, or greater than a specified order total. The ship via on the held order matches a specified ship via. The ship via priority for the ship via on the held order matches a specified ship via priority. See HO (Held Orders) Event Processing.
MN manually created	manually creates a workflow task	You cannot define criteria for this tickler event. See MN (Manually Created) Event Processing.
NO new orders	updates the status of an order line to open (during order accept) or closed (during the Billing Async)	The order line status is updated to open or closed. The quantity ordered/shipped for the open/closed order line matches a specified quantity. The item status for the item on the open/closed order line matches a specified item status. The sold to customer on the order is a first time buyer. The item class for the item on the open/closed order line matches a specified item class. The item/SKU on the open/closed order line matches a specified item/SKU. The order type for the order matches a specified order type.
		The country code for the order matches a specified country code. The country code for the order is a country other than the Default Country for Customer Address (B17) system control value. The last order date for the sold to customer is past the current date by a specified number of days. The order total on the order is less than, equal to, or greater than a specified order dollars. The ship via code on the order line or order header matches the ship via code on the event rule. The priority for the ship via code on the order line or order header matches the ship via priority on the event rule. See NO (New Orders) Event Processing.
OO aged open orders	evaluates aged open orders using the Evaluate Create/Resolve Ticklers periodic function (program name PFR0072)	The order’s entered date or arrival date is older than the current date by a specified number of days. The ship via on the order matches a specified ship via. The ship via priority for the ship via on the order matches a specified ship via priority. See OO (Aged Open Orders) Event Processing.
SD stored value card activation decline	receives a declined stored value card activation response from the service bureau	You cannot define criteria for this tickler event. See SD (SVC Activation Decline) Event Processing.
SO soldout orders	sells out an item	The order line is soldout by a batch process and not interactively. The order line is sold out interactively in order entry or order maintenance. The life-to-date order dollars for the sold to customer is less than, equal to, or greater than a specified life-to-date order dollars. The customer class for the sold to customer matches a specified customer class. The soldout item/SKU matches a specified item/SKU.
		The item status for the soldout item matches a specified item status. The item class for the soldout item matches a specified item class. The ship via on the soldout order matches a specified ship via. The ship via priority for the ship via on the soldout order matches a specified ship via priority. See SO (Soldout Orders) Event Processing.
SV stored value card number assignment	processes an order containing a stored value card item without a number assignment through the Billing Async	You cannot define criteria for this tickler event. See SV (SVC Number Assignment) Event Processing.
UP unconfirmed pick tickets	evaluates unconfirmed pick slips using the Evaluate Create/Resolve Ticklers periodic function (program name PFR0072)	The pick control date for the unconfirmed pick slip is older than the system date by a specified number of days. The pick category for the unconfirmed pick slip matches a specified pick category. The ship via on the unconfirmed pick slip matches a specified ship via. The ship via priority for the ship via on the unconfirmed pick slip matches a specified ship via priority. See UP (Unconfirmed Pick Tickets) Event Processing.
VP voided pick tickets	voids a pick slip	The ship via on the voided pick slip matches a specified ship via. The ship via priority for the ship via on the voided pick slip matches a specified ship via priority. The item/SKU on the voided pick slip matches a specified item/SKU. See VP (Voided Pick Tickets) Event Processing.
WF remote workflow	receives a CWWorkflow XML message from an external system	The source value in the CWWorkflow XML message matches the value in the Source field for the event rule. See WF (Remote Workflow) Event Processing.

Defining Tickler Events and Event Rules

To create a tickler, you must define:

• the tickler events that can create a tickler; see System Delivered Tickler Events.

• tickler event settings, that define how the system creates ticklers for each event; see Tickler Event Settings.

• event rule settings, that override the settings defined at the event level and determine how the event rule is processed; see Event Rule Settings.

• event rule criteria, that define the criteria the system action must meet to create a tickler; see Event Rule Criteria.

• event rule procedures, that define the instructions a user should follow to work with and resolve a tickler created by the event rule.

You use the Working with Tickler Events (WTEV) menu option to set up the system delivered tickler events and define event rules.

Creating Ticklers

The Create Tickler program determines if the system creates a tickler during certain system actions.

You can also manually create a tickler for the MN (manually created) tickler event; see MN (Manually Created) Event Processing.

Ticker creation logic: This flowchart describes the process the system uses to determine if a tickler is created for a system action.

The Create Tickler program:

1. 1.Determines the tickler event to evaluate, based on the system action currently being performed.

   See System Delivered Tickler Events for more information on when the system evaluates tickler events.

2. Determines if the tickler event is active.

   In order to create a tickler for a tickler event, the Active field defined for the event must be selected.

   • If the Active field for the event is selected, the tickler event is active and the system can create a tickler for the event.

   • If the Active field for the event is unselected, the tickler event is not active and the system cannot create a tickler for the event.

   See Active Tickler Events and Rules.

3. Determines if any event rules for the tickler event are active.

   In order to create a tickler for an event rule, the Active field defined for the event rule must be selected.

   • If the Active field for an event rule is selected, the event rule is active and the system can create a tickler if the system action meets the rule’s criteria.

   • If the Active field for an event rule is unselected, the event rule is not active and the system cannot create a tickler for the system action.

     See Active Tickler Events and Rules.

4. Determines if the system action meets the criteria required for any of the event rules to create a tickler.

   In order to create a tickler for an event rule, the system action must meet the criteria defined for the event rule. If the system action does not meet the criteria, the system does not create a tickler.

   • the system only evaluates event rules whose Active field is selected.

   • the system evaluates the active event rules in processing sequence order, from lowest sequence number to highest. You define the processing sequence number for an event rule in the Processing sequence number field; see Event Rule Processing Sequence.

5. Determines if more than one tickler can be created.

   The Allow multiple ticklers field for the tickler event must be selected in order to create a tickler for each event rule whose criteria are met by the system action.

   • If the Allow multiple ticklers field is unselected, the system creates one tickler for the first event rule, in processing sequence order, whose criteria are met by the system action. The AR, OO, and UP tickler events do not allow multiple ticklers.

   • If the Allow multiple ticklers field is selected, the system creates a separate tickler for each event rule whose criteria are met by the system action.

     See Allowing Multiple Ticklers.

6. The system creates a tickler for the system action.

   The system creates a tickler record in the Tickler table in an open status.

7. The system determines if the assigned to user or assigned to tickler group should be notified of the created tickler.

   The Notify user/group field defined for the tickler event that created the tickler indicates whether the system sends an email notifying the user or tickler group of the created tickler.

   • If the Notify user/group field is selected, the system sends an email to the assign to user or all users associated with the assign to tickler group. The system uses the email address defined for the user in the User Extended table. See Tickler Notification to review a sample email.

   • If the Notify user/group field is unselected, the system does not send an email. The user must review the ticklers assigned to him or his user group at the Work with Tickler Screen (user/group view).

     Regardless if the user is notified by email of the newly created tickler, the user can review the ticklers assigned to him and his tickler user group at the Work with Tickler screen; see Working with Ticklers.

8. Creates a record in the Tickler History table.

   The Tickler History table tracks the work cycle of a tickler; the system creates a tickler history record when a tickler is created, updated, or resolved.You can review tickler history at the Display Tickler History Screen.

9. Creates a record in the Order Transaction History table if the tickler is associated with an order.

For MN ticklers:

MN TICKLER# 000009999 HAS BEEN CREATED

NOTE:SHORT NOTE DEFINED FOR TICKLER

For all other ticklers, where XX is the tickler event code:

XX TICKLER# 000009999 HAS BEEN CREATED

RULE:DESCRIPTION OF RULE ASSOCIATED WITH TICKLER

You can review order transaction history at the Display Order History Screen.

For more information: For more information on the processing that occurs for each tickler event, see:

• BO (Backorders) Event Processing

• CO (Cancelled Orders) Event Processing

• HO (Held Orders) Event Processing

• MN (Manually Created) Event Processing

• NO (New Orders) Event Processing

• OO (Aged Open Orders) Event Processing

• SD (SVC Activation Decline) Event Processing

• SO (Soldout Orders) Event Processing

• SV (SVC Number Assignment) Event Processing

• UP (Unconfirmed Pick Tickets) Event Processing

• VP (Voided Pick Tickets) Event Processing

• WF (Remote Workflow) Event Processing

Why Wasn’t a Tickler Created?

Use the list below as a checklist to determine why the system did not create a tickler.

A tickler is not created because...	Reason
You did not restart the background jobs after you changed an event or event rule, or created a new event rule.	The system evaluates new updates only after the background async jobs in the Background Job Control menu option are restarted.
The Active field for the tickler event is unselected.	The system only evaluates tickler events that are active. See Active Tickler Events and Rules.
The Active field for the event rule is unselected.	The system only evaluates event rules that are active. See Active Tickler Events and Rules.
The Allow multiple ticklers field for the tickler event is unselected.	If Allow multiple ticklers is selected, the system creates 1 tickler for the first event rule, in processing sequence order, whose criteria are met by the system action. If the criteria for another event rule is met, the system does not create a tickler. See Allowing Multiple Ticklers.
BO tickler event: the backordered item did not meet the BO event rule criteria.	See BO (Backorders) Event Processing.
CO tickler event: the cancelled item did not meet the CO event rule criteria.	See CO (Cancelled Orders) Event Processing.
HO tickler event: the held order did not meet the HO event rule criteria.	See HO (Held Orders) Event Processing.
NO tickler event: the open/closed order line did not meet the NO event rule criteria.	The system evaluates the NO event when an order: is accepted (because the status of an order line updates from suspended to open), before creating a pre-generated pick. If a web order is placed in an error status in an order batch, the system evaluates the NO event when you edit and accept the order batch. Note: The system does not evaluate the NO event when you accept an order in order maintenance. is processed through the Billing Async (because the status of an order line updates to closed). See NO (New Orders) Event Processing.
OO tickler event: the aged open order did not meet the OO event rule criteria.	See OO (Aged Open Orders) Event Processing.
SD tickler event: the stored value card received an approved activation response from the service bureau.
SO tickler event: the soldout item did not meet the SO event rule criteria.	See SO (Soldout Orders) Event Processing.
SV tickler event: the stored value card item was assigned a number.	See SV (SVC Number Assignment) Event Processing.
UP tickler event: the unconfirmed pick slip did not meet the UP event rule criteria.	See UP (Unconfirmed Pick Tickets) Event Processing.
VP tickler event: the voided pick slip did not meet the VP event rule criteria.	See VP (Voided Pick Tickets) Event Processing.
WF tickler event: the remote workflow message did not meet the WF event rule criteria.	See WF (Remote Workflow) Event Processing.

Working with Ticklers

Once a tickler is created, a user can review, work with, and resolve ticklers using the following screens:

• Work with Tickler Screen (user/group view)

• Workflow Management Screen (tickler supervisor)

• Work with Ticklers Screen (sold to customer view)

• Work with Ticklers Screen (ship-to customer view)

• Work with Ticklers Screen (bill-to customer view)

• Work with Ticklers Screen (order view)

Update All Ticklers Secured Feature

The Update All Ticklers (B09) secured feature controls whether you can update all ticklers, regardless if the tickler is not assigned to you or your tickler groups.

If you have access to this feature, you can update any tickler, regardless if the tickler is not assigned to you or your tickler groups by:

• selecting Change for a tickler to change it.

• selecting Delete for a tickler to delete it.

• selecting In process for a tickler to assign the tickler to yourself.

• selecting Resolve for a tickler to resolve it.

If you do not have access to this feature, you can update only ticklers assigned to you or your tickler groups. However, you can still release an order associated with the tickler from hold.

User Workflow Management Window

Purpose: The system displays this window when you sign-in to Order Administration if open or in process ticklers exist that are assigned to you or your tickler groups.

You can review, work with, and resolve ticklers assigned to you or your tickler groups using the Working with Tickler Users/User Groups (WTIC) menu option

Customer Workflow Management Window

Purpose: The system displays this window if open or in process ticklers exist that are associated with the customer or order you are reviewing.

How to display this screen:

• select Change for a customer at the Changing Sold To Customers screens.

• select Change for a ship-to customer at the Work with Customer Ship Tos Screen.

• select Change for a customer at the Change Bill-to Customer Screen.

• advance to the Order Inquiry Header Screen.

• select a customer for order entry at the Select Customer Sold To For Order Screen.

• select a customer (CTI user) at the Customer Selection Screen.

• select an order for return at the Select Orders For Return Authorization Screen.

The window displays once per functional area for each customer you review that has open or in process ticklers.

Example: In standard order inquiry, if you select an order for a customer with open ticklers, the system displays the Customer Workflow Management window; if you then advance to order maintenance for that customer, the system does not display the window again. Back in standard order inquiry, if you select an order for a different customer with open ticklers, the system re-displays the Customer Workflow Management window for the new customer you are reviewing.

Screen Option	Procedure
Review and work with the ticklers associated with the customer or order	Select Ticklers to advance to the Work with Ticklers screen. The view of this screen varies, depending on the function you were performing: sold to customers: Work with Ticklers Screen (sold to customer view) ship to customers: Work with Ticklers Screen (ship-to customer view) bill to customers: Work with Ticklers Screen (bill-to customer view) orders: Work with Ticklers Screen (order view)

Tickler Merge/Purge

Customer merge/purge: If you perform customer merge/purge (sold to or bill to), the system adds the ticklers associated with the source customers to the target customer.

Order purge: If you purge orders associated with ticklers, the system also purges the ticklers.

Resolving Ticklers

A tickler is resolved when you:

• select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

• perform an action that automatically resolves the tickler; for example when you release an order from hold, the system automatically resolves HO ticklers associated with the order.

When you resolve a tickler associated with an order, the system creates an order transaction history message indicating the tickler has been resolved.

For MN ticklers:

MN TICKLER# 000009999 HAS BEEN RESOLVED

RES RSN(XXX)BY(USER/GROUP ID)NOTE(SHORT NOTE DEFINED FOR TICKLER)

For all other ticklers, where XX is the tickler event code:

XX TICKLER# 000009999 HAS BEEN RESOLVED

RES RSN(XXX)BY(USER/GROUP ID)RULE(DESCRIPTION OF RULE ASSOCIATED WITH TICKLER)

You can review order transaction history at the Display Order History Screen.

Workflow Management Setup

Purpose: To use workflow management, you must perform the necessary setup. Information requiring creation and setup includes:

• System Control Value

• Secured Feature

• Number Assignment Value

• Menu Options

• Periodic Functions

System Control Value

System Control Value	Description
Use Workflow Management (H96)	Select this field if you wish to use workflow management.

Secured Feature

Secured Feature	Description
Update All Ticklers (B09)	Eligible users can update all ticklers, regardless if the tickler is not assigned to him or his tickler user groups. Prohibited users cannot update all ticklers, only those ticklers assigned to him or his tickler user groups.
Create Manual Tickler (B13)	Eligible users can manually create ticklers. Prohibited users cannot manually create ticklers.

Number Assignment Value

Number Assignment	Description
Tickler Number	Assigns the next available number to a newly created tickler. Note: The system automatically creates this number assignment value when the first tickler is created.

Menu Options

Menu Option	Description
Working with Tickler User Groups (WTUG)	Allows you to create, change, and delete tickler user groups. For each tickler event and event rule, you can define the tickler user group the system assigns to a newly created tickler.
Working with User Records (WUSR)	Allows you to define the e-mail address the system uses when the user is notified of a tickler. Also, allows you to assign a tickler user group to a user.
Working with Tickler Category (WTCT)	Allows you to create, change, and delete a tickler category. Tickler categories are used to further group ticklers.
Working with Tickler Resolution Reasons (WTRR)	Allows you to create, change, and delete a tickler resolution reason. The system assigns a tickler resolution reason to a tickler once it is resolved. You can define the tickler resolution reason to use for ticklers associated with a particular event or event rule.
Working with Tickler Events (WTEV)	Allows you to change the settings for a tickler event, create, change, or delete event rules, and create or modify event rule procedures. Note: You must restart the async jobs in the Background Job Control menu option after you change an event or event rule, or create a new event rule.
Working with Tickler Users/User Groups (WTIC)	Allows a user to review and work with ticklers assigned to him or his tickler user groups.
Workflow Management (WWFM)	Allows a supervisor to review and work with ticklers.
Purging Ticklers (MPTK)	Allows you to purge resolved ticklers, based on date.

Periodic Functions

Periodic Function

Description

Evaluate Create/Resolve Ticklers (program name PFR0072)

Evaluates the: OO tickler event to determine if any open orders qualify for an OO event rule. Also, determines if any existing OO ticklers can be resolved. UP tickler event to determine if any unconfirmed pick slips qualify for a UP event rule. Also, determines if any existing UP ticklers can be resolved. AR tickler event to determine if any existing AR ticklers can be created or resolved. Next notification date for an existing open or in process tickler to determine if the system sends an email to the tickler supervisor notifying him of the aged tickler.

Event Rule Settings

For each event rule you define for a tickler event, you can define:

• whether the event rule is active; see Active Tickler Events and Rules.

• the tickler user/group assigned to work with ticklers created by this event rule and the supervisor to monitor the ticklers; see Tickler Assignment.

• if tickler users are notified when a new tickler is created and if the supervisor is notified when a tickler remains unresolved for a certain number of days; see Tickler Notification.

• the tickler category assigned to ticklers created by this event rule; see Tickler Category.

• the tickler resolution reason assigned to ticklers created by this event rule; see Tickler Resolution Reason.

• how the rules are processed; see Event Rule Processing Sequence.

• the criteria the system action must meet to create a tickler; see Event Rule Criteria.

• the procedures a user should follow to resolve the tickler; see Event Rule Procedures.

You can define event rule settings at the Create Tickler Event Rule Screen or Change Tickler Event Rule Screen.

Note:

If you create or change a tickler event rule, you must restart the asyncs in the Background Job Control menu option before your updates are applied to new ticklers.

Event Rule Processing Sequence

For each event rule you create, you can define a processing sequence number. In addition, the system assigns a rule sequence number to each event rule, based on the order in which the rules were created (the first rule created is assigned rule sequence number 1, etc.).

The Processing sequence number defined for each event rule indicates the order in which the system evaluates event rules to determine if a tickler is created.

The event rule with the lowest processing sequence number is evaluated first (where 0 is the lowest number); the event rule with the highest processing sequence number is evaluated last.

If all of the event rules have the same processing sequence number, the system evaluates the rules in rule sequence order. The event rule with the lowest rule sequence number is evaluated first; the event rule with the highest rule sequence number is evaluated last.

Note:

If the event rule is not active (the Active field is unselected), the system does not evaluate the event rule and instead skips the rule and evaluates the next event rule, based on processing or rule sequence order.

Remember: Give the most important rule the lowest processing sequence number and the least important rule the highest processing sequence number. This way the system evaluates the rules in the order of the most important to the least important. This is especially true if you do not allow multiple ticklers: you want the system to create a tickler for the most important rule whose criteria are met by the system action.

If you allow multiple ticklers, you do not need to define a processing sequence number since the system creates a tickler for each rule whose criteria are met.

Example: This example displays the order in which the system evaluates tickler rules based on processing sequence number and rule sequence number.

Processing seq #	Rule seq #	Rule active?	Action meets criteria?	Results
0	2	N	N	The system does not create a tickler for this event rule since the event rule is not active and the system action does not qualify.
0	5	Y	N	The system does not create a tickler for this event rule since the system action does not qualify.
1	4	N	Y	The system does not create a tickler for this event rule since the event rule is not active.
2	1	Y	Y	The system creates a tickler for this event rule since the event rule is active and the system action qualifies.
3	3	Y	Y	The system creates a tickler for this event rule only if the Allow multiple ticklers field for the event is selected; see Allowing Multiple Ticklers.
3	6	Y	Y	The system creates a tickler for this event rule only if the Allow multiple ticklers field for the event is selected; see Allowing Multiple Ticklers.

Event Rule Criteria

For each event rule, you must define the criteria that the system action must meet to create a tickler. Different criteria display for each tickler event. You can create multiple rules for each event by defining different criteria for each rule.

You can define more than one criterion for each event rule; however, you must define at least one criterion. If you define more than one criterion for an event rule, the system action must meet all of the rule’s criteria to create a tickler.

Example: If you create an event rule whose criteria are Pay type is 1 and Ship via is 1, the system creates a tickler only if the pay type on the order is 1 and the ship via is 1. The system does not create a tickler if the ship via on the order is 1 but the pay type on the order is 4.

Remember: If you allow multiple ticklers, you must think carefully before you create event rules. For example, if you create the following rules and you allow multiple ticklers, the system creates 3 ticklers, even though event rule 3 is a combination of rules 1 and 2:

• Event rule 1: Ship via is 1 (UPS)

• Event rule 2: Pay type is 1 (cash/check)

• Event rule 3: Ship via is 1 (UPS) and Pay type is 1 (cash/check)

You can define event rule criteria at the Create Tickler Event Rule Screen.

Note:

You cannot create a duplicate event rule, meaning, you cannot create 2 rules that have the same criteria or an error message indicates: Duplicate rule exists.

Important:

If you create or change a tickler event rule, you must restart the asyncs in the Background Job Control menu option before your updates are applied to new ticklers.

For more information: For more information on the criteria you can define for each tickler event, see:

• BO (Backorders) Event Processing

• CO (Cancelled Orders) Event Processing

• HO (Held Orders) Event Processing

• MN (Manually Created) Event Processing

• NO (New Orders) Event Processing

• OO (Aged Open Orders) Event Processing

• SD (SVC Activation Decline) Event Processing

• SO (Soldout Orders) Event Processing

• SV (SVC Number Assignment) Event Processing

• UP (Unconfirmed Pick Tickets) Event Processing

• VP (Voided Pick Tickets) Event Processing

• WF (Remote Workflow) Event Processing

Event Rule Procedures

For each event rule, you can create tickler instructions for a user to follow to resolve the tickler.

You can create and modify event rule procedures at the Work with Tickler Event Rule Procedure Screen.

Example: These procedures may display for ticklers that are created when an order payment method is placed on AT (declined credit card hold) and the ship via is UPS Second Day.

1. Release order from hold.

2. Resend credit card for authorization.

3. Contact UPS to determine if they can deliver by expected arrival date.

4. If package will arrive late, notify customer of possible late delivery.

5. If customer is a valued customer, give customer 25% off coupon on next purchase.

Note:

A tickler user may not complete all of the tasks required to complete the tickler. Using the example above, the first assigned to user may release the order from hold and then assign the tickler to another user to resend the credit card for authorization.

Tickler work notes: The tickler user completing some or all of the tasks associated with the tickler can enter notes regarding the steps he performed for other users and the supervisor to review. See Tickler Work Notes.

Work with Tickler Event Screen

Purpose: Use this screen to change, review, or define rules for a tickler event.

When you first advance to this screen, the system automatically creates the system delivered tickler events if the Use Workflow Management (H96) system control value is selected. However, you must still define settings for each tickler event you wish to enable. You cannot create other tickler events for the system to evaluate for tickler creation.

Note:

You cannot delete a tickler event. If you do not wish to use a tickler event, set the Active field for the event to unselected.

How to display this screen: Enter WTEV in the Fast path field or select Work with Tickler Event from a menu.

Field	Description
Event	A code that determines the system action for which the system may create a tickler. There are 11 system actions that can create ticklers. You cannot create other tickler events for the system to evaluate for tickler creation. BO: backorders; see BO (Backorders) Event Processing CO: cancelled orders; see CO (Cancelled Orders) Event Processing HO: held orders; see HO (Held Orders) Event Processing MN: manually created; see MN (Manually Created) Event Processing NO: new orders; see NO (New Orders) Event Processing OO: aged open orders; see OO (Aged Open Orders) Event Processing SD: stored value card activation decline; see SD (SVC Activation Decline) Event Processing SO: soldout orders; see SO (Soldout Orders) Event Processing SV: stored value card number assignment; see SV (SVC Number Assignment) Event Processing UP: unconfirmed pick tickets; see UP (Unconfirmed Pick Tickets) Event Processing VP: voided pick tickets; see VP (Voided Pick Tickets) Event Processing WF: remote workflow; see WF (Remote Workflow) Event Processing Alphanumeric, 2 positions; optional.
Description	A description of the tickler event. Alphanumeric, 40 positions; optional.
Cat (Tickler event category)	A code for the tickler category assigned to the tickler event. Tickler categories are used to group ticklers. Tickler categories are defined in and validated against the Tickler Category table; see Working with Tickler Category (WTCT). Alphanumeric, 3 positions; optional.
Pty (Tickler event priority)	The priority assigned to the tickler event, used to determine the importance of ticklers created for this event. Numeric, 1 position; optional.
Act (Tickler event active flag)	Indicates whether the tickler event is active. Selected = The tickler event is currently active; the system creates a tickler if the system action qualifies for an event rule. N = The tickler event is not currently active; the system does not create a tickler, regardless of whether the system action qualifies for an event rule. See Active Tickler Events and Rules.

Screen Option	Procedure
Change the settings of a tickler event	Select Change for a tickler event to advance to the Change Tickler Event Screen.
Display a tickler event	Select Display for a tickler event to advance to the Display Tickler Event Screen. You cannot change any information at this screen. See the Change Tickler Event Screen for field descriptions.
Work with tickler event rules	Select Rules for a tickler event to advance to the Work with Tickler Event Rule Screen. You cannot define event rules for the MN (manually created) or SV (SVC number assignment) tickler events.

Create Tickler Event Rule Screen

Purpose: Use this screen to create an event rule for a specific tickler event.

This screen is divided into 2 areas:

• The top half of the screen displays the event rule settings, such as who to notify, the tickler category, resolution reason, and processing sequence number; see Event Rule Settings.

• The bottom half of the screen displays the event rule options, or criteria, that must be met by the system action in order for the system to create a tickler. The event rule options are different for each tickler event.

For each event rule you create, you must define at least one event rule option, or criterion, the system uses to determine if a tickler should be created. If you define more than one rule criterion, the system action must meet all of the options defined for the event rule to create a tickler.

Note:

You cannot create a duplicate event rule, meaning, you cannot create 2 rules that have the same criteria or an error message indicates: Duplicate rule exists.

The Processing sequence number defined for each event rule determines the sequence in which the system validates each event rule to determine if a tickler should be created, 1 being the first priority. You should assign the most important event rules a lower sequence number.

Important:

If you create or change an event rule, you must restart the async jobs in the Background Job Control menu option before your updates are applied to new ticklers.

How to display this screen: Select Create at the Work with Tickler Event Rule Screen.

Field	Description
Event	The code and description for the tickler event associated with the event rule. Code: Alphanumeric, 2 positions; display-only. Description: Alphanumeric, 40 positions; display-only.
Rule description	A description of the event rule, usually indicating the criteria defined for the rule. Alphanumeric, 40 positions; required.
Category	A code for the tickler category assigned to the event rule. Tickler categories are used to group ticklers. The tickler category at the event level defaults, but you can override it. The tickler category defined at the event rule level overrides the tickler category defined at the event level. Tickler categories are defined in and validated against the Tickler Category table; see Working with Tickler Category (WTCT). Alphanumeric, 3 positions; optional.
Resolution reason	A code for the reason why a tickler for this event rule is resolved. Tickler resolution reason codes are assigned to a tickler once the tickler has been resolved. The resolution reason at the event level defaults, but you can override it. The resolution reason defined at the event rule level overrides the resolution reason defined at the event level. You must define a tickler resolution reason for all tickler events except for the MN (manually created) tickler event. Tickler resolution reasons are defined in and validated against the Tickler Resolution Reason table; see Working with Tickler Resolution Reasons (WTRR). Alphanumeric, 3 positions; required except for MN tickler event.
Active	Indicates whether the event rule is active. selected = The event rule is currently active; the system creates a tickler for the event rule if its criteria are met by the system action. Remember, to create a tickler for the event rule, the Active flag at the event level must also be selected. unselected = The event rule is not currently active; the system does not create a tickler, regardless of whether the system action qualifies for the event rule. See Active Tickler Events and Rules.
Processing seq	The processing sequence number for the event rule. The processing sequence number defines the order in which the system evaluates the rules to determine if a tickler is created, from lowest sequence number to highest. Note:  The first tickler event rule that meets the criteria creates a tickler. It is important that you assign the most important event rule the lowest processing sequence number. If you do not define a processing sequence number for an event rule, the system assigns the event rule a processing sequence number of 0. If all of the rules have the same processing sequence number, the system evaluates the rules in rule sequence number. See Event Rule Processing Sequence. Numeric, 3 positions; optional.
Notify user/group	Indicates whether the system sends a Tickler Notification email to the assigned user or to all of the users in the assigned tickler user group when a tickler is created for this event rule. selected = Notify the assigned user/user group when a tickler is created; use the email address defined for the user in the User Extended table. If the tickler is assigned to a user group, send a notification to each user in the group, using the email address defined for each user in the User Extended table. unselected = Do not notify the assigned user/user group when a tickler is created; the user can review the ticklers in his queue at the Work with Tickler Screen (user/group view). The notify user/group setting at the event level defaults, but you can override it. The notify user/group setting at the event rule level overrides the notify user/group setting defined at the event level. See Tickler Notification for a sample Tickler Notification email.
Assign to orig user	Indicates if ticklers created for this event rule are assigned to the user that entered the order associated with the tickler. selected = Assign ticklers created for this event rule to the user that entered the associated order. If this field is selected, you must also enter a user ID in the Assign to user field. unselected = Do not assign ticklers created for this event rule to the user that entered the associated order; instead, assign the tickler to the specified user or tickler user group. The assign to original user setting at the event level defaults, but you can override it. The tickler assignment defined at the event rule level overrides the tickler assignment defined at the event level. Note:  See Tickler Assignment.
Assign to user	The user ID of the user the system assigns to ticklers for this event rule. The assign to user setting at the event level defaults, but you can override it. The assign to setting at the event rule level overrides the assign to setting defined at the event level. You can define either an assign to user or assign to user group for the event rule, but not both. Users are defined in and validated against the User table; see Working with User Records (WUSR). See Tickler Assignment. Alphanumeric, 10 positions; optional.
Assign to user group	The tickler user group the system assigns to ticklers for this event rule. The assign to user group setting at the event level defaults, but you can override it. The assign to setting at the event rule level overrides the assign to setting defined at the event level. You can define either an assign to user or assign to user group for each event, but not both. The tickler user group you enter must be defined as a user type and not a supervisor type. Tickler user groups are defined in and validated against the Tickler User Group table; see Working with Tickler User Groups (WTUG). See Tickler Assignment. Alphanumeric, 10 positions; optional.
Supervisor group	The tickler supervisor group the system assigns to ticklers for this event rule. The supervisor group setting at the event level defaults, but you can override it. The supervisor group at the event rule level overrides the supervisor group defined at the event level. The tickler user group you enter must be defined as a supervisor type and not a user type. Tickler user groups are defined in and validated against the Tickler User Group table; see Working with Tickler User Groups (WTUG). See Tickler Assignment. Alphanumeric, 10 positions; optional.
Notify supervisor	Indicates when a Supervisor Notification Count email is sent to the supervisor, based on the number of days since a tickler was created. The system uses this calculation to determine the next notification date when a tickler is first created: tickler creation date + value in Number of days to notify supervisor field for the event/rule that created the tickler = next notification date. The system does not update the next notification date after a tickler is created. The system sends the email to the email address defined for the supervisor user group in the Tickler User Group table. The system continues sending an email to the supervisor group as long as a tickler assigned to the supervisor group is in an open or in process status and the Next notification date in the Tickler table is equal to or past the current date. If the next notification date is a future date, the system does not send an email until the next notification date is reached. If all ticklers assigned to the supervisor are resolved, the system no longer sends a Supervisor Notification Count email.
	Leave this field blank if you do not want to notify the supervisor about aging ticklers for this event rule; the supervisor can review ticklers using the Workflow Management (WWFM) menu option. The notify supervisor setting at the event level defaults, but you can override it. The notify supervisor setting at the event rule level overrides the notify supervisor setting defined at the event level. If you define a number of days in this field, you must also define the supervisor group. See Tickler Notification for a sample Supervisor Notification Count email. Numeric, 3 positions; optional.

Event rule options: For each event rule, you must define the options, or criteria, that must be met by the system action in order for the system to create a tickler. The event rule options are different for each tickler event. You must define at least one option, or criterion, for each tickler event rule. For more information on defining event rule options, see:

• BO (Backorders) Event Processing

• CO (Cancelled Orders) Event Processing

• HO (Held Orders) Event Processing

• MN (Manually Created) Event Processing

• NO (New Orders) Event Processing

• OO (Aged Open Orders) Event Processing

• SD (SVC Activation Decline) Event Processing

• SO (Soldout Orders) Event Processing

• SV (SVC Number Assignment) Event Processing

• UP (Unconfirmed Pick Tickets) Event Processing

• VP (Voided Pick Tickets) Event Processing

• WF (Remote Workflow) Event Processing

BO (Backorders) Event Processing

The system creates a tickler for the BO tickler event when an item on an order is placed on backorder and the order qualifies for a BO event rule.

When is the BO event evaluated? The system evaluates the BO event when you or the system place an item on backorder:

• during order entry processing

• during order maintenance processing

• during batch order entry (this includes orders received via the phone order interface and ecommerce)

• when you void and unreserve a pick ticket in order maintenance or in the Reprinting and Voiding Pick Slips (WVRP or WSVP) menu option

• when you unreserve an item during the Working with Interactive Reservation (MIRV) menu option

Allowing multiple ticklers for the BO event:

• If you allow multiple ticklers, the system creates multiple ticklers for an order that contains one or more backordered items; a separate tickler is created for each event rule whose criteria are met.

• If you do not allow multiple ticklers, the system creates only 1 tickler per order ship to that contains one or more items on backorder, regardless of whether the backordered order qualifies for more than one event rule; the system does not create a separate tickler for each transaction that backorders an item on the order.

BO Event Rule Criteria

You can define the following criteria for a BO event rule.

Note:

The system creates a separate tickler for each ship to order that has a backordered item that meets the rule’s criteria, regardless of the Allow multiple ticklers setting.

Criterion	Event rule set up
An item is placed on backorder by a batch process, such as voiding and unreserving a pick ticket or unreserving an item during Interactive Reservation.	Deselect the Initial backorder field.
The backordered item was initially backordered in order entry/maintenance and not by some other program.	Select the Initial backorder field.
The life-to-date order dollars for the sold to customer (the $ orders LTD field in the Customer Sold To Order History table) on the order meets the comparison criteria on the event rule.	Enter a comparison value (valid values are GT greater than, GE greater than or equal to, LT less than, LE less than or equal to) in the Comparison field and a dollar amount in the LTD order dollars field. You can only define a whole number for the life-to-date order dollars. You can review the life-to-date order dollars for a sold to customer at the Display Customer Order History Screen.
The customer class for the sold to customer on the order matches the customer class on the event rule.	Enter a customer class in the Customer class field. Note:  The system does not look at the customer class defined for the ship to customer.
The item and/or SKU on backorder matches the item and/or SKU on the event rule.	Enter an item code in the Item field and optionally, a SKU code in the SKU field. If you define an item but not a SKU code and the item contains SKUs, the system creates a tickler for the item if any of the SKUs for the item are on backorder. If you define both an item and SKU, the system creates a tickler only if that specific SKU is on backorder.
The item status for the item on backorder matches the item status on the event rule.	Enter an item status in the Item status field.
The item class for the item on backorder matches the item class on the event rule.	Enter an item class in the Item class field.
The ship via for the order line or order where the item on backorder is located matches the ship via on the event rule.	Enter a ship via code in the Ship via field. The system evaluates the ship via on the detail line first, then the ship via on the order header. If you enter a Ship via, you cannot define a Ship via priority for the event rule. Note:  To create a tickler for each ship to order, the ship via for the ship to must match the ship via on the event rule.
The priority of the ship via for the order line or order where the item on backorder is located matches the ship via priority on the event rule.	Enter a ship via priority number in the Ship via priority field. The system evaluates the ship via on the detail line first, then the ship via on the order header. If you enter a Ship via, you cannot define a Ship via priority for the event rule. Note:  To create a tickler for each ship to order, the ship via priority for the ship to must match the ship via priority on the event rule.

BO Event Examples

Example 1: Allow multiple ticklers is unselected for the BO event.

The following event rules are defined for the BO event, displayed in processing sequence order.

• Event rule 1: Item is A123.

• Event rule 2: Item status is B.

• Event rule 3: LTD order dollars is greater than $100.

• Event rule 4: Customer class is CC.

You enter an order and:

• item A123 is on backorder.

• item B456 is on backorder and the item status is B.

• the sold to customer’s class is CC and life-to-date order dollars is $500.

The system creates 1 tickler for rule 1: Item is A123.

In this scenario, the system creates only 1 tickler for the order containing backordered items even though the order qualified for all of the event rules.

Example 2: Allow multiple ticklers is selected for the BO event.

The following event rules are defined for the BO event, displayed in processing sequence order.

• Event rule 1: Item is A123.

• Event rule 2: Item status is B.

• Event rule 3: LTD order dollars is greater than $100.

• Event rule 4: Customer class is CC.

You enter an order and:

• item A123 is on backorder.

• item B456 is on backorder and the item status is B.

• the sold to customer’s class is CC and life-to-date order dollars is $500.

The system creates 4 ticklers for the order:

• the first tickler is created for rule 1: Item is A123.

• the second tickler is created for rule 2: Item status is B.

• the third tickler is created for rule 3: LTD order dollars is greater than $100.

• the fourth tickler is created for rule 4: Customer class is CC.

In this scenario, the system creates 4 ticklers for the order containing backordered items; a separate tickler is created for each rule whose criteria are met.

Resolving BO Ticklers

A BO tickler is resolved when you or the system:

• select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

• receive inventory for the backordered item.

• cancel the order containing the backordered item.

CO (Cancelled Orders) Event Processing

The system creates a tickler for the CO tickler event when an order is cancelled or contains an order line that is cancelled and the order qualifies for a CO event rule.

When is the CO event evaluated? The system evaluates the CO event when you or the system cancels an order or order line during:

• order maintenance

• Working with Backorders Pending Cancellation (WBPC)

• Processing Item Substitutions (PSUB)

• Working with Credit Card Cancellations (WCCC)

• Processing Auto Soldout Cancellations (MASO)

Allowing multiple ticklers for the CO event: 

• If you allow multiple ticklers, the system creates multiple ticklers for an order that is cancelled or contains cancelled order lines; a separate tickler is created for each event rule whose criteria are met.

• If you do not allow multiple ticklers, the system creates only 1 tickler per order ship to that contains a cancelled order/order line, for example if 1 tickler is created during order maintenance another tickler cannot be created during Process Auto Soldout Cancellations.

CO Event Rule Criteria

You can define the following criteria for a CO event rule.

Note:

The system creates a separate tickler for each ship to order that has a cancelled order line and meets the rule’s criteria, regardless of the Allow multiple ticklers setting. When you cancel an order, the system creates a separate tickler for each ship to order you cancel.

Criterion	Event rule set up
The order or order line is cancelled, regardless of whether it is by a batch process or interactively.	Deselect the Batch process only field.
The order or order line is cancelled by a batch process and not interactively.	Select the Batch process only field. You can cancel an order/order line during a batch process using: Processing Item Substitutions (PSUB) Working with Credit Card Cancellations (WCCC) Processing Auto Soldout Cancellations (MASO)
The life-to-date order dollars for the sold to customer (the $ orders LTD field in the Customer Sold To Order History table) on the order meets the comparison criteria on the event rule.	Enter a comparison value (GT greater than, GE greater than or equal to, LT less than, LE less than or equal to) in the Comparison field and a dollar amount in the LTD order dollars field. You can only define a whole number for the life-to-date order dollars. You can review the life-to-date order dollars for a sold to customer at the Display Customer Order History Screen.
The customer class for the sold to customer on the order matches the customer class on the event rule.	Enter a customer class in the Customer class field. Note:  The system does not look at the customer class defined for the ship to customer.
The item and/or SKU on the cancelled order line matches the item and/or SKU on the event rule.	Enter an item code in the Item field and optionally, a SKU code in the SKU field. If you define an item but not a SKU code and the cancelled item contains SKUs, the system creates a tickler for the item if any of the SKUs for the item are cancelled. If you define both an item and SKU, the system creates a tickler only if that specific SKU is cancelled.
The item status for the item on the cancelled order line matches the item status on the event rule.	Enter an item status in the Item status field.
The item class for the item on the cancelled order line matches the item class on the event rule.	Enter an item class in the Item class field.
The cancel reason on the cancelled order line/order matches the cancel reason on the event rule.	Enter a cancel reason code in the Cancel reason field.
The ship via for the cancelled order/order line matches the ship via on the event rule.	Enter a ship via code in the Ship via field. The system evaluates the ship via on the detail line first, then the ship via on the order header. If you enter a Ship via, you cannot define a Ship via priority for the event rule. Note:  To create a tickler for each ship to order, the ship via for the ship to customer must match the ship via on the event rule.
The priority of the ship via for the cancelled order/order line matches the ship via priority on the event rule.	Enter a ship via priority number in the Ship via priority field. The system evaluates the priority of the ship via on the detail line first, then the priority of the ship via on the order header. If you enter a Ship via priority, you cannot define a Ship via for the event rule. Note:  To create a tickler for each ship to order, the priority of the ship via for the ship to customer must match the ship via priority on the event rule.

CO Event Examples

Example 1: Allow multiple ticklers is unselected for the CO event.

The following event rules are defined for the CO event, displayed in processing sequence order.

• Event rule 1: Batch process only is selected

• Event rule 2: Item is A123

• Event rule 3: LTD order dollars is greater than 500

• Event rule 4: Ship via is 1

You enter an order and:

• the ship via on the order header is 1.

• the items on the order are A123 and B456.

• the sold to customer’s life-to-date order dollars is $75.00.

• in order maintenance, you cancel order line 1 for item B456.

• in Processing Item Substitutions (PSUB), you cancel item A123.

In this scenario, the system creates 1 tickler during order maintenance for rule 4: Ship via is 1. The system does not create a tickler for the other rules whose criteria are met. The system does not create a tickler during Process Substitute Items since a CO tickler already exists for the order/order ship to.

Example 2: Allow multiple ticklers is selected for the CO event.

The following event rules are defined for the CO event, displayed in processing sequence order.

• Event rule 1: Batch process only is selected

• Event rule 2: Item is A123

• Event rule 3: LTD order dollars is greater than 500

• Event rule 4: Ship via is 1

You enter an order and:

• the ship via on the order header is 1.

• the items on the order are A123 and B456.

• the sold to customer’s life-to-date order dollars is $75.00.

• in order maintenance, you cancel order line 1 for item B456.

• in Processing Item Substitutions (PSUB), you cancel item A123.

In this scenario, the system creates 1 tickler during order maintenance for rule 4: Ship via is 1.

The system creates 2 ticklers during Process Substitute Items:

• the first tickler is created for rule 1: Batch process only is selected.

• the second tickler is created for rule 2: Item is A123.

A tickler is not created for rule 3 during Process Substitute Items because a tickler already exists for that order using that rule.

Resolving CO Ticklers

A CO tickler is resolved when you or the system select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

HO (Held Orders) Event Processing

The system creates a tickler for the HO tickler event when an order’s order header, order ship to (recipient), or order payment method is placed on hold and the order qualifies for an HO event rule. The system does not create a tickler for an order line placed on hold.

When is the HO event evaluated? The system evaluates the HO event when you or the system place an order on hold during:

• order entry processing

• order maintenance processing

• batch order entry (this includes orders received via the phone order interface and ecommerce)

• credit card authorization (during order entry (online authorization), pick slip generation, and drop ship processing)

Allowing multiple ticklers for the HO event: 

• If you allow multiple ticklers, the system creates multiple ticklers for an order or order payment method that is held; a separate tickler is created for each event rule whose criteria are met.

• If you do not allow multiple ticklers, the system creates only 1 tickler per order ship to that places an order or order payment method on hold, for example if the system creates 1 HO tickler during order entry the system will not create another HO tickler during credit card authorizations.

HO Event Rule Criteria

You can define the following criteria for an HO event rule.

Note:

The system creates a separate tickler for each ship to customer order that meets the rule’s criteria, regardless of the Allow multiple ticklers setting.

Criterion	Event rule set up
The order hold reason for the held order matches the order hold reason on the event rule.	Enter a hold reason in the Order hold reason field. This setting is used for order header holds and recipient holds. The system creates a tickler for both system and user hold reasons.
The pay type for the held order matches the pay type on the event rule.	Enter a pay type code in the Pay type field.
The pay type hold reason for the held order payment method matches the pay type hold reason on the event rule.	Enter a hold reason in the Pay type hold reason field. The system creates a tickler for both system and user hold reasons. Note:  The system does not create a tickler for the CW (awaiting credit card authorization) pay type hold.
The order total for the held order meets the order total comparison on the event rule.	Enter a comparison value (valid values are GT greater than, GE greater than or equal to, LT less than, LE less than or equal to) in the Comparison field and a dollar amount in the Order total field. You can only define a whole number for the order total. The order total is the sum of all charges on the order, including merchandise, freight, additional freight, tax, handling, and additional charges across all recipients on the order.
The ship via for the held order/order line matches the ship via on the event rule.	Enter a ship via code in the Ship via field. The system evaluates the ship via on the detail line first, then the ship via on the order header. If you enter a Ship via, you cannot define a Ship via priority for the event rule. Note:  To create a tickler for each ship to order, the ship via for the ship to customer must match the ship via on the event rule.
The priority of the ship via for the held order/order line matches the ship via priority on the event rule.	Enter a ship via priority number in the Ship via priority field. The system evaluates the priority of the ship via on the detail line first, then the priority of the ship via on the order header. If you enter a Ship via priority, you cannot define a Ship via for the event rule. Note:  To create a tickler for each ship to order, the priority of the ship via for the ship to customer must match the ship via priority on the event rule.

HO Event Examples

Example 1: Allow multiple ticklers is selected for the HO event.

The following event rules are defined for the HO event, displayed in processing sequence order.

• Event rule 1: Order hold reason is HS (sold to/ship to fraud)

• Event rule 2: Order hold reason is PT (pay type hold)

• Event rule 3: Pay type hold reason is PV (pay plan velocity hold)

You enter an order and:

• the sold to customer on the order is a fraud (F in the Hold/bypass/fraud field for the customer). The system places the order ship to customer on HS (sold to/ship to fraud).

• the order pay type on the order is credit card with deferred payment and the card has been used too many times within a specified time period with a deferred payment option. The system places the order header on PT (pay type) hold and the order pay type on PV (pay plan velocity) hold.

In this scenario, the system creates 3 ticklers:

• the first tickler is created for the order ship to hold using rule 1: Order hold reason is HS (sold to/ship to fraud).

• the second tickler is created for the order header hold using rule 2: Order hold reason is PT (pay type hold).

• the third tickler is created for the pay type hold using rule 3: Pay type hold reason is PV (pay plan velocity hold)

Example 2:

Allow multiple ticklers is unselected for the HO event.

The following event rules are defined for the HO event, displayed in processing sequence order.

• Event rule 1: Order hold reason is HS (sold to/ship to fraud)

• Event rule 2: Order hold reason is PT (pay type hold)

• Event rule 4: Pay type hold reason is PV (pay plan velocity hold)

You enter an order and:

• the sold to customer on the order is a fraud (F in the Hold/bypass/fraud field for the customer). The system places the order ship to customer on HS (sold to/ship to fraud).

• the order pay type on the order is credit card with deferred payment and the card has been used too many times within a specified time period with a deferred payment option. The system places the order header on PT (pay type) hold and the order pay type on PV (pay plan velocity) hold.

In this scenario, the system creates 1 tickler for the order ship to hold using the first rule: Order hold reason is HS (sold to/ship to fraud). The system does not create a tickler for the other rules whose criteria are met.

Resolving HO Ticklers

An HO tickler is resolved when you:

• select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

• release the order from hold by selecting Release for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

• release the order from hold by selecting Release for a tickler in the Release Held Orders menu option; see Performing the Release.

• release the order from hold in order maintenance by:

  • removing the order header hold reason.

  • adding a pay type for a balance due hold.

MN (Manually Created) Event Processing

You can manually create a tickler at the Create Tickler Screen.

How to display this screen: You can advance to the Create Tickler screen from the:

• Workflow Management Screen (workflow supervisor)

• Work with Tickler Screen (user/group view) (workflow user)

• Work with Ticklers Screen (sold to customer view)

• Work with Ticklers Screen (ship-to customer view)

• Work with Ticklers Screen (bill-to customer view)

• Work with Ticklers Screen (order view)

• Work with Return Authorization Detail Screen

• Work with Returns for Order Screen

• Work with Email by Order Number Screen

• Work with Email by Customer Sold To Number Screen

• Work with Email by Customer Ship To Number Screen

• Work with Email by Customer Bill To Number Screen

• Display Item Availability Screen

Allowing multiple ticklers for the MN event: The Allow multiple ticklers setting does not apply to manually created ticklers.

MN event rule criteria: You cannot define event rules for the MN tickler event. However, you can associate a manually created tickler with a specific:

• order number and ship to number

• customer sold to number

• customer ship to number

• customer bill to number

• existing tickler number

Depending on how you advance to the Create Tickler screen, the system automatically associates the tickler with a specific order or customer. For example, if you advance to the Create Tickler screen from the Work with Ticklers Screen (sold to customer view), the system automatically associates the manually created tickler with the sold to customer.

Resolving MN Ticklers

A MN tickler is resolved when you select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

NO (New Orders) Event Processing

The system creates a tickler for the NO tickler event when the status of an order line updates to open or closed and the order qualifies for an NO event rule.

The system creates a tickler for each order containing one or more order lines that are updated to open or closed; the system does not create a separate tickler for each order line that is updated to open or closed.

Soldout orders: The system will never create an NO tickler for an order that is entirely soldout; this is because none of the lines on the order are ever updated to open or closed.

Note:

Even if a NO tickler exists for an order, the order can continue through the order cycle.

When is the NO event evaluated? The system evaluates the NO event when an order:

• is accepted (because the status of an order line updates from suspended to open), before creating a pre-generated pick. If a web order is placed in an error status in an order batch, the system evaluates the NO event when you edit and accept the order batch. Note: The system does not evaluate the NO event when you accept an order in order maintenance.

• is processed through the Billing Async (because the status of an order line updates to closed).

Allowing multiple ticklers for the NO event: 

• If you allow multiple ticklers, the system creates multiple ticklers for an order containing one or more order lines that are updated to open or closed; a separate tickler is created for each event rule whose criteria are met.

• If you do not allow multiple ticklers, the system creates only 1 tickler for an order containing one or more order lines that are updated to open or closed, regardless of whether the order qualifies for more than one event rule; the system does not create a separate tickler for each transaction that updates or closes an order.

NO Event Rule Criteria

You can define the following criteria for an NO event rule.

The Order line status setting is used with all other criteria you define for an event rule. For example, if you define an item status, the item on the order line must match the specified item status and the status of the order line must update to open or closed (whichever order line status you specify).

Hold reason: If you enter a valid hold reason in the Hold reason field, the system places the order on hold at the user level when a NO tickler is created for the event rule. In this situation, the system removes any pick slip preparation from the order; see Preparing Orders for Pick Slip Generation.

Note:

Unless otherwise noted, the system creates a separate tickler for each ship to customer on the order that has an open/closed order line that qualifies for an event rule, regardless of the Allow multiple ticklers setting.

Criterion	Event rule set up
The order line status changes to open/closed.	Enter an order line status code in the Order line status field. blank = The order line status changes to open; for example, you enter a new order line. X = the order line status changes to closed; for example, you ship an order line.
The ordered quantity or shipped quantity for the open/closed order line is equal to or greater than the quantity on the event rule.	Enter a quantity in the Quantity ordered/shipped field. the quantity represents the ordered quantity if the Order line status is blank. the quantity represents the shipped quantity if the Order line status is X.
The item status for the item on the open/closed order line matches the item status on the event rule.	Enter an item status in the Item status field.
The open/closed order line is for a first time buyer.	Select the First time buyer field. The system considers the sold to customer a first time buyer if the Current mail type field for the customer is a value other than B (buyer). Note:  The system creates one tickler for the first ship to order if the sold to customer on the order qualifies; the system does not create a tickler for subsequent ship to orders.
The item class for the item on the open/closed order line matches the item class on the event rule.	Enter an item class in the Item class field.
The item and/or SKU on the open/closed order line matches the item and/or SKU on the event rule.	Enter an item code in the Item field and optionally, a SKU code in the SKU field. If you define an item but not a SKU code and the item contains SKUs, the system creates a tickler for the item if any of the SKUs for the item are on an open/closed order line. If you define both an item and SKU, the system creates a tickler only if that specific SKU is on an open/closed order line.
The order type on the order matches the order type on the event rule.	Enter an order type in the Order type field. Note:  A tickler is created for each ship to order whose order type matches the order type on the event rule.
The last order date for the sold to customer (the Last order field in the Customer Sold To Order History table) on the order is past the current date by the number of days on the event rule.	Enter a number in the Number days since field. You can review the last order date for a sold to customer on the Display Customer Order History Screen. Note:  The system does not create a separate tickler for each ship to.
The country code on the ship to order matches the country code on the event rule.	Enter a country code in the Country field. Note:  A tickler is created for each ship to order whose country code matches the country code on the event rule. If you define a country code you cannot exclude the default country.
The country code on the ship to order must be a country other than the Default Country for Customer Address (B17).	Select the Exclude default country field. Note:  A tickler is created for each ship to order whose country code qualifies for the event rule. If you exclude the default country you cannot define a country code.
The order total on the order meets the order dollars comparison criteria on the event rule.	Enter a comparison value (valid values are GT greater than, GE greater than or equal to, LT less than, LE less than or equal to) in the Comparison field and a dollar amount in the Order dollars field. The order total is the sum of all charges on the order, including merchandise, freight, additional freight, tax, handling, and additional charges across all recipients on the order. You can only define a whole number for the order dollars.
The ship via code on the order line or order header matches the ship via code on the event rule.	Enter a ship via code in the Ship via field. Ship via codes are defined in and validated against the Ship Via table. The system evaluates the ship via on the detail line first, then the ship via on the order header. A tickler is created for each ship to order whose ship via code at the line level or header level matches the ship via code on the event rule. If you enter a Ship via, you cannot define a Ship via priority for the event rule.
The priority for the ship via code on the order line or order header matches the ship via priority on the event rule.	Enter a ship via priority (1-9) in the Ship via priority field. The system evaluates the ship via on the detail line first, then the ship via on the order header. A tickler is created for each ship to order whose ship via code at the line level or header level has a ship via priority that matches the ship via priority on the event rule. If you enter a Ship via priority, you cannot define a Ship via for the event rule.

NO Event Examples

Example 1: Allow multiple ticklers is selected for the NO event.

The following event rules are defined for the NO event, displayed in processing sequence order.

• Event rule 1: Order line status is blank and Order type is I.

• Event rule 2: Order line status is X.

• Event rule 3: Order line status is blank and Exclude default country is selected.

You enter an order and:

• the order type is I.

• the country code on the order is JPY (the default country code is USA).

In this scenario, the system creates 2 ticklers when the order is processed by the Order Async:

• the first tickler is created for rule 1: Order line status is blank and Order type is I.

• the second tickler is created for rule 3: Order line status is blank and Exclude default country is selected.

You generate a pick ticket and ship the order. The system creates 1 tickler when the order is processed by the Billing Async for rule 2: Order line status is X.

Example 2: Allow multiple ticklers is unselected for the NO event.

The following event rules are defined for the NO event, displayed in processing sequence order.

• Event rule 1: Order line status is blank and Order type is I.

• Event rule 2: Order line status is X.

• Event rule 3: Order line status is blank and Exclude default country is selected.

You enter an order and:

• the order type is I.

• the country code on the order is JPY (the default country code is USA).

In this scenario, the system creates 1 tickler when the order is processed by the Order Async for rule 1: Order line status is blank and Order type is I.

You generate a pick ticket and ship the order. The system does not create a tickler when the order is processed by the Billing Async.

Resolving NO Ticklers

A NO tickler is resolved when you:

• select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

• use Manage Held Ordersin Modern View to release the order from hold. The system resolves the tickler when you release the order from hold only if the reason the order was held was because of the tickler and a resolution reason is defined for the tickler event rule.

OO (Aged Open Orders) Event Processing

The system creates a tickler for the OO tickler event when an aged open order exists.

An aged open order is:

• an order whose order header is open or held, and

• the order contains one or more order lines that are open or held, and

• the order line is not reserved (Quantity reserved is 0) or is reserved but not printed (Quantity reserved is greater than 0 and Quantity printed is 0), and

• the order is older than a specified number of days, based on entered date or arrival date defined for the order lines on the order.

One tickler is created for each ship to customer on an aged open order that qualifies for an OO event rule; if an aged open order qualifies for more than 1 event rule, the system creates 1 tickler for the first event rule, in processing sequence order, that qualifies.

Note:

The system does not allow multiple ticklers for the OO event (the Allow multiple ticklers field must be unselected).

When is the OO event evaluated? The system evaluates the OO event when you run the Evaluate Create/Resolve Tickler periodic function (program name PFR0072).

Graduating OO ticklers: Each time you run the Evaluate Create/Resolve Tickler periodic function, the system determines is any existing OO ticklers should be graduated.

• If an OO tickler exists for an aged open order and the aged open order qualifies for a new event rule, based on processing sequence order, the system keeps the existing tickler open and applies the new event rule to the tickler.

• If an OO tickler exists for an aged open order and the aged open order qualifies for the event rule currently assigned to the existing tickler, the system does not create a new tickler and keeps the existing tickler without any updates.

• If an OO tickler exists for an aged open order and the aged open order no longer qualifies for the current event rule and does not qualify for any other OO event rules, the system resolves the tickler; see Resolving OO Ticklers.

The system updates the existing tickler with the information related to the event rule that is now associated with the tickler:

• Rule number updates to the new event rule assigned to the tickler.

• Category updates to the category for the new event rule.

• Priority updates to the priority for the new event rule.

• Assigned to updates to the assigned to user/group for the new event rule.

• Assigned date updates to the date the tickler is graduated.

• Supervisor group updates to the supervisor group for the new event rule.

• Date to notify supervisor updates, based on the new supervisor group assigned.

• Tickler procedures updates to the procedures for the new event rule.

• if the tickler was in-process, the system changes the status back to open.

• if the Notify user/group field is selected for the new event rule, the system sends a Tickler Reassignment email; see Tickler Notification for a sample email. Note: The system sends a Tickler Reassignment email only if the new event rule has a different assigned to user/group from the previous event rule assigned to the tickler.

• the system creates a tickler history record, indicating the tickler has been graduated from one event rule to another.

OO Event Rule Criteria

You can define the following criteria for an OO event rule.

The Orders older than date setting is used with all other criteria you define for an event rule. For example, if you define a ship via, the aged open order must match the specified ship via and the order’s entered/arrival date must be older than the system date by the number of days defined.

Note:

The system creates a separate tickler for each ship to order that has an order line that qualifies; the system does not create a separate tickler for each order line that qualifies.

Criterion	Event rule set up
The order line’s entered date/arrival date is older than the current date by the number of days on the event rule.	Enter a date indicator code (E = entered date, A = arrival date) in the Date indicator field and enter a number in the Orders older than field. The system requires you to enter a date indicator and number of days. Note:  The system evaluates the entered date/arrival date on the order detail line; the system does not evaluate the entered date/arrival date on the order header.
The ship via for the aged open order matches the ship via on the event rule.	Enter a ship via code in the Ship via field. The system evaluates the ship via on the detail line first, then the ship via on the order header. If you define a ship via for the event rule, you cannot define a ship via priority. Note:  To create a tickler for each ship to order, the ship via for the ship to customer must match the ship via on the event rule.
The priority of the ship via for the aged open order matches the ship via priority on the event rule.	Enter a ship via priority number in the Ship via priority field. The system evaluates the priority of the ship via on the detail line first, then the priority of the ship via on the order header. If you define a ship via priority for the event rule, you cannot define a ship via. Note:  To create a tickler for each ship to order, the priority of the ship via for the ship to customer must match the ship via priority on the event rule.

OO Event Example

The following event rules are defined for the OO event rule, in processing sequence order.

• Event rule 1: Orders older than 5 days by Arrival date and Ship via is 2

• Event rule 2: Orders older than 1 day by Arrival date and Ship via is 2

You run the Evaluate Create/Resolve Ticklers periodic function and:

• Order # 6599 qualifies for event rule 2 (an order line’s arrival date is older than 1 day and the ship via is 2)

• Order # 6601 qualifies for event rule 2 (an order line’s arrival date is older than 1 day and the ship via is 2)

The system creates an OO tickler for each order.

You run the Evaluate Create/Resolve Ticklers periodic function again and:

• Order # 6599 qualifies for event rule 1 (an order line’s arrival date is older than 5 days and the ship via is 2)

• Order # 6601 qualifies for event rule 2 (an order line’s arrival date is older than 1 day and the ship via is 2)

The system graduates the existing tickler for order # 6599 to event rule 1; the existing tickler for order # 6601 continues using rule 2.

You run the Evaluate Create/Resolve Ticklers periodic function again, and:

• order # 6599 qualifies for event rule 1 (an order line’s arrival date is older than 5 days and the ship via is 2)

• order # 6601 does not qualify for any rules (a pick has been generated)

The existing tickler for order # 6599 continues using rule 1. The system resolves the existing tickler for order # 6601.

Resolving OO Ticklers

An OO tickler is resolved when you:

• select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

• run the Evaluate Create/Resolve Ticklers periodic function (program name PFR0072), if the tickler no longer applies to any OO event rules. For example, the order is now cancelled.

• generate a pick slip for the order. Note: When you generate a pick slip for the order, the system resolves the tickler automatically and does not wait until you run the Evaluate Create/Resolve Ticklers periodic function.

SD (SVC Activation Decline) Event Processing

The system creates a tickler for the SD tickler event when a stored value card activation request receives a declined activation response from the service bureau.

The system creates a tickler for each stored value card activation request that receives a declined response.

The tickler indicates the:

• order number and ship to number associated with the stored value card

• customer number (sold to and ship to) on the order

• stored value card item number, SKU code, and description

To activate a declined stored value card: You must call the service bureau to activate the card.

When is the SD tickler event evaluated? The system evaluates the SD tickler event when the SVC_OUT job receives a stored value card activation response from the service bureau.

Allowing multiple ticklers for the SD event: The Allow multiple ticklers setting does not apply to SD ticklers.

SD event rule criteria: You cannot define event rules for the SD tickler event.

Resolving SD Ticklers

An SD tickler is resolved when you select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

For more information: See Stored Value Card Purchase and Activation.

SO (Soldout Orders) Event Processing

The system creates a tickler for the SO (soldout orders) event each time an item on an order is soldout and the order qualifies for an SO event rule.

When is the SO event evaluated? The system evaluates the SO event when you or the system sell out an item during:

• order entry processing

• order maintenance processing

• batch order entry (this includes orders received via the phone order interface and ecommerce)

• Processing Auto Soldout Cancellations (MASO)

Quotes: The system does not evaluate the SO tickler event for a quote until you convert it to an order.

Allowing multiple ticklers for the SO event: 

• If you allow multiple ticklers, the system creates multiple ticklers for an order containing soldout order lines; a separate tickler is created for each event rule whose criteria are met.

• If you do not allow multiple ticklers, the system creates only 1 tickler per order ship to that sells out an order line, for example if the system creates 1 tickler during order entry the system will not create another tickler during auto soldout cancellations.

SO Event Rule Criteria

You can define the following criteria for an SO event rule.

Hold reason: If you enter a valid hold reason in the Hold reason field, the system places the order on hold at the user level when an SO tickler is created for the event rule unless the order is in a closed status. If the order contains more than one ship to, both ship to orders are placed on hold.

Note:

The system creates a separate tickler for each ship to order that has a soldout item, regardless of the Allow multiple ticklers setting.

Criterion	Event rule set up
The order line is soldout by a batch process, such as Process Auto Soldout Cancellations, and not interactively.	Select the Batch process only field. Note:  If the Batch process only field is selected, the Interactive mode field must be blank.
The order line is sold out interactively in order entry, order maintenance, or batch order entry (this includes orders received via the phone order interface and ecommerce).	Enter a mode in the Interactive mode field. E = The order line is soldout interactively in order entry or batch order entry. M = The order line is soldout interactively in order maintenance. B = The order line is soldout interactively in order entry, order maintenance, or batch order entry. Note:  If you enter a value in the Interactive mode field, the Batch process only field must be unselected; this means the system creates ticklers for soldout items during the specified interactive mode and during batch processing.
The life-to-date order dollars for the sold to customer (the $ orders LTD field in the Customer Sold To Order History table) on the order meets the life-to-date order dollars comparison on the event rule.	Enter a comparison value (valid values are GT greater than, GE greater than or equal to, LT less than, LE less than or equal to) in the Comparison field and a dollar amount in the LTD order dollars field. You can only define a whole number for the life-to-date order dollars. You can review the life-to-date order dollars for a sold to customer at the Display Customer Order History Screen.
The customer class for the sold to customer on the order matches the customer class on the event rule.	Enter a customer class in the Customer class field. Note:  The system does not look at the customer class defined for the ship to customer.
The item and/or SKU on the soldout order line matches the item and/or SKU on the event rule.	Enter an item code in the Item field and optionally, a SKU code in the SKU field. If you define an item but not a SKU code and the soldout item contains SKUs, the system creates a tickler for the item if any of the SKUs for the item are soldout. If you define both an item and SKU, the system creates a tickler only if that specific SKU is soldout.
The item status for the soldout item matches the item status on the event rule.	Enter an item status in the Item status field.
The item class for the soldout item matches the item class on the event rule.	Enter an item class in the Item class field.
The ship via for the soldout order line matches the ship via on the event rule.	Enter a ship via code in the Ship via field. The system evaluates the ship via on the detail line first, then the ship via on the order header. If you enter a Ship via, you cannot define a Ship via priority for the event rule. Note:  To create a tickler for each ship to order, the ship via for the ship to customer must match the ship via on the event rule
The priority of the ship via for the soldout order line matches the ship via priority on the event rule.	Enter a ship via priority number in the Ship via priority field. The system evaluates the ship via on the detail line first, then the ship via on the order header. If you enter a Ship via priority, you cannot define a Ship via for the event rule. Note:  To create a tickler for each ship to order, the priority of the ship via for the ship to customer must match the ship via priority on the event rule.

SO Event Examples

Example 1: Allow multiple ticklers is unselected for the SO event.

The following event rules are defined for the SO event, displayed in processing sequence order.

• Event rule 1: Ship via is 1

• Event rule 2: Item is A123

• Event rule 3: LTD order dollars is greater than $100

• Event rule 4: Interactive mode is M (order maintenance)

You enter an order and:

• the ship via on the order header is 1.

• the item on the order is A123 and is not soldout in order entry.

• the sold to customer’s life-to-date order dollars is $75.00.

• in order maintenance, you sell out item A123.

In this scenario, the system creates 1 tickler during order maintenance for the first rule: Ship via is 1. The system does not create a tickler for the other rules whose criteria are met.

Example 2: Allow multiple ticklers is selected for the SO event.

The following event rules are defined for the SO event, displayed in processing sequence order.

• Event rule 1: Ship via is 1

• Event rule 2: Item is A123

• Event rule 3: LTD order dollars is greater than $100

• Event rule 4: Interactive mode is M (order maintenance)

You enter an order and:

• the ship via on the order header is 1.

• the item on the order is A123 and is not soldout in order entry.

• the sold to customer’s life-to-date order dollars is $75.00.

• in order maintenance, you sell out item A123.

In this scenario, the system creates 3 ticklers during order maintenance:

• the first tickler is created for rule 1: Ship via is 1.

• the second tickler is created for rule 2: Item is A123.

• the third tickler is created for rule 4: Interactive mode is M (order maintenance).

A tickler is not created for rule 3: LTD order dollars is greater than $100, since the sold to customer’s life-to-date order dollars is less than $100.

Resolving SO Ticklers

An SO tickler is resolved when you select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

SV (SVC Number Assignment) Event Processing

The system creates a tickler for the SV tickler event when an order containing a stored value card item is processed by billing without a number assignment. This may occur if you send a physical stored value card item to the manifesting station without first using the Working with Physical Stored Value Card Assignment (WPSA) menu option to assign a number to the card.

The system creates a tickler for each unit of the item that is not assigned a stored value card number.

The tickler indicates the:

• order number and ship to number associated with the stored value card

• customer number (sold to and ship to) on the order

• stored value card item number, SKU code, and description

• pick control number containing the stored value card item

If the stored value card is a physical card (SVC type P or E), you must call the customer, indicate the stored value card has not yet been activated, and ask for the number printed on the card.

If the stored value card is a virtual card (SVC type V), you must assign a number from the Virtual Card Number Table (FLSVCA) to the card and email this information to the recipient card holder.

When is the SV tickler event evaluated? The system evaluates the SV tickler event when an order containing a stored value card item is processed through the Billing Async.

Allowing multiple ticklers for the SV event: The Allow multiple ticklers setting does not apply to SV ticklers.

SV event rule criteria: You cannot define event rules for the SV tickler event.

Resolving SV Ticklers

An SV tickler is resolved when you select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

For more information: See Stored Value Card Purchase and Activation.

UP (Unconfirmed Pick Tickets) Event Processing

The system creates a tickler for the UP tickler event when a pick ticket exists that has not been confirmed.

Note:

You can use the UP event in place of printing the Carryover report.

The system considers a pick ticket unconfirmed if the pick control header status is blank (open), M (submitted to manifest), or O (carryover). If the pick ticket’s status is some other value, the system does not create a tickler for the pick ticket.

One tickler is created for each unconfirmed pick ticket that qualifies for a UP event rule; if an unconfirmed pick ticket qualifies for more than 1 event rule, the system creates 1 tickler for the first event rule, in processing sequence order, that qualifies.

Note:

The system does not allow multiple ticklers for the UP event (the Allow multiple ticklers field must be unselected).

When is the UP event evaluated? The system evaluates the UP event when you run the Evaluate Create/Resolve Tickler periodic function (program name PFR0072).

Graduating UP ticklers: Each time you run the Evaluate Create/Resolve Tickler periodic function, the system determines is any existing UP ticklers should be graduated.

• If a UP tickler exists for an unconfirmed pick ticket and the unconfirmed pick ticket qualifies for a new event rule, based on processing sequence order, the system keeps the existing tickler open and applies the new event rule to the tickler.

• If a UP tickler exists for an unconfirmed pick ticket and the unconfirmed pick ticket qualifies for the event rule currently assigned to the existing tickler, the system does not create a new tickler and keeps the existing tickler without any updates.

• If a UP tickler exists for an unconfirmed pick ticket and the unconfirmed pick ticket no longer qualifies for the current event rule and does not qualify for any other UP event rules, the system resolves the tickler; see Resolving UP Ticklers.

The system updates the existing tickler with the information related to the event rule that is now associated with the tickler:

• Rule number updates to the new event rule assigned to the tickler.

• Category updates to the category for the new event rule.

• Priority updates to the priority for the new event rule.

• Assigned to updates to the assigned to user/group for the new event rule.

• Assigned date updates to the date the tickler is graduated.

• Supervisor group updates to the supervisor group for the new event rule.

• Date to notify supervisor updates, based on the new supervisor group assigned.

• Tickler procedures updates to the procedures for the new event rule.

• if the tickler was in-process, the system changes the status back to open.

• if the Notify user/group field is selected for the new event rule, the system sends a Tickler Reassignment email; see Tickler Notification for a sample email. Note: The system sends a Tickler Reassignment email only if the new event rule has a different assigned to user/group from the previous event rule assigned to the tickler.

• the system creates a tickler history record, indicating the tickler has been graduated from one event rule to another.

UP Event Rule Criteria

You can define the following criteria for a UP event rule.

Note:

The Pick older than setting is used with all other criteria you define for an event rule. For example, if you define a pick category, the pick ticket must match the specified pick category and the pick control date for the pick ticket must be older than the system date by the number of days defined.

Criterion	Event rule set up
The Pick control date for the unconfirmed pick ticket is older than the system date by the number of days on the event rule.	Enter a number in the Picks older than field. The system requires you to enter a number of days.
The pick category defined for the pick ticket matches the pick category on the event rule.	Enter a pick category code in the Picks category field. D = The pick category for the unconfirmed pick ticket is D (drop ship pick ticket). R = The pick category for the unconfirmed pick ticket is R (regular pick ticket). S = The pick category for the unconfirmed pick ticket is S (special handling pick ticket.
The ship via for the unconfirmed pick ticket matches the ship via on the event rule.	Enter a ship via code in the Ship via field. The system evaluates the ship via on the unconfirmed pick ticket, not the ship via on the order. If you enter a ship via for the event rule, you cannot define a ship via priority.
The priority of the ship via for the unconfirmed pick ticket matches the ship via priority on the event rule.	Enter a ship via priority number in the Ship via priority field. The system evaluates the priority of the ship via on the unconfirmed pick ticket, not the ship via on the order. If you enter a ship via priority for the event rule, you cannot define a ship via.

UP Event Example

The following event rules are defined for the UP event rule, in processing sequence order.

• Event rule 1: Pick control date is 5 days for Pick category R (regular picks)

• Event rule 2: Pick control date is 1 day for Pick category R (regular picks)

You run the Evaluate Create/Resolve Ticklers periodic function and:

• Pick ticket # 69 qualifies for event rule 2

• Pick ticket # 72 qualifies for event rule 2

The system creates a UP tickler for each pick ticket.

You run the Evaluate Create/Resolve Ticklers periodic function again and:

• Pick ticket # 69 qualifies for event rule 1

• Pick ticket # 72 qualifies for event rule 2

The system graduates the existing tickler for pick ticket # 69 to event rule 1; the existing tickler for pick ticket # 72 continues using rule 2.

You run the Evaluate Create/Resolve Ticklers periodic function again, and:

• pick ticket # 69 qualifies for event rule 1

• pick ticket # 72 does not qualify for any rules (the pick ticket has been confirmed)

The existing tickler for pick ticket # 69 continues using rule 1. The system resolves the existing tickler for pick ticket # 72.

Resolving UP Ticklers

A UP tickler is resolved when you:

• select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

• run the Evaluate Create/Resolve Ticklers periodic function (program name PFR0072), if the tickler no longer applies to any OO event rules. For example, the pick ticket has been voided or reprinted.

• confirm the pick ticket. Note: When you confirm the pick ticket, the system resolves the tickler automatically and does not wait until you run the Evaluate Create/Resolve Ticklers periodic function.

VP (Voided Pick Tickets) Event Processing

The system creates a tickler for the VP tickler event when a pick ticket is voided.

When is the VP event evaluated? The system evaluates the VP event when you void a pick ticket by:

• selecting Void or Void/Unreserve for a pick ticket in the Reprinting and Voiding Pick Slips (WVRP or WSVP) menu option or order maintenance.

• selecting Void for a pick ticket during Manually Confirming Shipments (MCON).

• selecting Void All/Cancel Order in the Reprinting and Voiding Pick Slips (WVRP or WSVP) menu option.

• selecting Void All in order maintenance.

Note:

The Void Pick Batch (WSVP) option does not create VP ticklers.

Allowing multiple ticklers for the VP event: 

• If you allow multiple ticklers, the system creates multiple ticklers for the voided pick ticket; a separate tickler is created for each event rule whose criteria are met.

• If you do not allow multiple ticklers, the system creates only 1 tickler for the voided pick ticket.

VP Event Rule Criteria

You can define the following criteria for a VP event rule.

Hold reason: If you enter a valid hold reason in the Hold reason field, the system places the order on hold at the user level when a VP tickler is created for the event rule. In this situation, the system removes any pick slip preparation from the order; see Preparing Orders for Pick Slip Generation.

Criterion	Event rule set up
The ship via for the order ship to associated with the voided pick ticket matches the ship via on the event rule.	Enter a ship via code in the Ship via field. If you enter a Ship via, you cannot define a Ship via priority for the event rule. The system evaluates the ship via on the order ship to, on the ship via on the pick ticket header.
The priority of the ship via for the order ship to associated with the voided pick ticket matches the ship via priority on the event rule.	Enter a ship via priority number in the Ship via priority field. If you enter a Ship via priority, you cannot define a Ship via for the event rule. The system evaluates the ship via on the order ship to, not the ship via on the pick ticket header.
The item and/or SKU on the voided pick ticket matches the item and/or SKU on the event rule.	Enter an item code in the Item field and optionally, a SKU code in the SKU field. If you define an item but not a SKU code and the item contains SKUs, the system creates a tickler for the item if any of the SKUs for the item are on a voided pick ticket. If you define both an item and SKU, the system creates a tickler only if that specific SKU is on a voided pick ticket.

VP Event Examples

Example 1: Allow multiple ticklers is unselected for the VP event.

The following event rules are defined for the VP event, displayed in processing sequence order.

• Event rule 1: Ship via is 1

• Event rule 2: Item is A123

• Event rule 3: Item is SKU2002 RED

You void 2 pick tickets:

• pick ticket 55 is for ship via 1 and contains 2 pick ticket lines:

• pick ticket line 1: item A123

• pick ticket line 2: item B456

• pick ticket 56 is for ship via 2 and contains 2 pick ticket lines:

• pick ticket line 1: item SKU2002 GRN

• pick ticket line 2: item SKU2002 RED

In this scenario, the system creates:

• 1 tickler for pick ticket 55 for rule 1: Ship via is 1.

• 1 tickler for pick ticket 56 for rule 3: Item is SKU2002 RED.

The system does not create a tickler for the other rules whose criteria are met.

Example 2: Allow multiple ticklers is selected for the VP event.

The following event rules are defined for the VP event, displayed in processing sequence order.

• Event rule 1: Ship via is 1

• Event rule 2: Item is A123

• Event rule 3: Item is SKU2002 RED

You void 2 pick tickets:

• pick ticket 55 is for ship via 1 and contains 2 pick ticket lines:

• pick ticket line 1: item A123

• pick ticket line 2: item B456

• pick ticket 56 is for ship via 2 and contains 2 pick ticket lines:

• pick ticket line 1: item SKU2002 GRN

• pick ticket line 2: item SKU2002 RED

In this scenario, the system creates:

• 2 ticklers for pick ticket 55 for rule 1: Ship via is 1 and rule 2: Item is A123.

• 1 tickler for pick ticket 56 for rule 3: Item is SKU2002 RED.

Resolving VP Ticklers

A VP tickler is resolved when you select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

WF (Remote Workflow) Event Processing

The system creates a tickler for the WF tickler event when a CWWorkflow XML message is received into Order Administration from an outside source.

When is the WF event evaluated? The system evaluates the WF event when the Workflow Processing integration layer job receives the CWWorkflow XML message into Order Administration.

CWMessageIn web service: You can use the CWMessageIn Web Service to route CWWorkFlow messages. In this situation, the target for each inbound message must match the Inbound program name for the integration layer process queue, as specified at the Integration Layer Process Queue Screen.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Web service authentication: Use the Working with Web Service Authentication (WWSA) menu option to define a valid user for basic web service authentication, or client ID if using OAuth. You must also create a corresponding user profile in Oracle Identity Cloud Service and assign the user to the corresponding web service role defined for the Order Management application.

Allowing multiple ticklers for the WF event: The Allow multiple ticklers setting does not apply to the WF tickler event.

WF Event Rule Criteria

You can define the following criterion for a WF event rule. 

Criterion	Event rule set up
The source of the workflow XML message received matches the message source defined for the event rule.	Enter a message source code in the Message source field. Note:  The source from the CWWorkflow XML message must match the Message source for the WF event rule.

Resolving WF Ticklers

A WF tickler is resolved when you select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen.

Work with Tickler Event Rule Procedure Screen

Purpose: Use this screen to create or change the procedures, or instructions, a user should follow when working with a tickler.

How to display this screen: Select Procedures for an event rule at the Work with Tickler Event Rule Screen.

Field	Description
Event	The code and description for the tickler event associated with the tickler event rule procedures. Code: Alphanumeric, 2 positions; display-only. Description: Alphanumeric, 40 positions; display-only.
Rule	The description of the event rule associated with the event rule procedures. Alphanumeric, 40 positions; display-only.
Procedure	Free-form lines where you can enter procedures, or instructions, a user should follow to resolve the tickler. Alphanumeric, 60 positions; optional.

Screen Option	Procedure
Toggle the procedure lines between add mode and change mode	Select Add/Change to toggle the procedure lines between add mode and change mode. In add mode, you can enter new procedure lines; in change mode, you can enter new procedure lines and also change existing procedure lines.

Work with Tickler Event Rule Screen

Purpose: Use this screen to create, change, and delete event rules defined for a specific tickler event. You can also create procedure notes for each event rule.

Note:

Event rules display on this screen in processing sequence order, allowing you to easily see the order in which the system evaluates the rules to determine if a tickler is created; see Event Rule Processing Sequence.

How to display this screen: Select Rules for a tickler event at the Work with Tickler Event Screen.

Field	Description
Event	The code and description of the event associated with the event rules. Code: Alphanumeric, 2 positions; display-only. Description: Alphanumeric, 40 positions; display-only.
Proc seq #	The processing sequence number for the event rule. The processing sequence number defines the order in which the system evaluates the rules to determine if a tickler is created, from lowest sequence number to highest. Note:  The first tickler event rule that meets the criteria creates a tickler. It is important that you assign the most important tickler event rule the lowest processing sequence number. If you do not define a processing sequence number for an event rule, the system assigns the event rule a processing sequence number of 0. If all of the rules have the same processing sequence number, the system evaluates the rules in rule sequence number. See Event Rule Processing Sequence. Numeric, 3 positions; optional.
Rule seq #	The rule sequence number for the event rule. The system assigns a rule sequence number to each rule you create; the first rule you create is assigned a rule sequence number of 1, etc. Note:  If all of the rules have the same processing sequence number, the system evaluates the rules to determine if a tickler is created in rule sequence number, from lowest rule number to highest. See Event Rule Processing Sequence. Numeric, 3 positions; optional.
Description	A description of the event rule, usually indicating the criteria defined for the rule. Alphanumeric, 40 positions; optional.
Pty (Priority)	The priority assigned to the event rule, used to determine the importance of ticklers created for the event rule. You can scan for ticklers by priority at the Work with Tickler Screen (user/group view) (tickler users) and Workflow Management Screen (tickler supervisors). You can assign a tickler event priority between 1-9, where 1 is the lowest priority and 9 is the highest priority. The priority defined at the tickler event level defaults, but you can override it. The tickler priority defined at the event rule level overrides the tickler priority defined at the event level. Numeric, 1 position; display-only.
Act (Active flag)	Indicates whether the event rule is active. selected = The event rule is currently active; the system creates a tickler for the event rule if its criteria are met by the system action. Remember, to create a tickler for the event rule, the Active flag at the event level must also be selected. unselected = The event rule is not currently active; the system does not create a tickler, regardless of whether the system action qualifies for the event rule. See Active Tickler Events and Rules.
Cat (Tickler category)	A code for the tickler category assigned to the event rule. Tickler categories are used to group ticklers. Tickler categories are defined in and validated against the Tickler Category table; see Working with Tickler Category (WTCT). Alphanumeric, 3 positions; optional.

Screen Option	Procedure
Create a tickler event rule	Select Create to advance to the Create Tickler Event Rule Screen.
Change a tickler event rule	Select Change for an event rule to advance to the Change Tickler Event Rule Screen. You can change all fields on this screen except Event code. See Create Tickler Event Rule Screen for field descriptions. Note:  If you create or change a tickler event rule, you must restart the asynchronous jobs the Background Job Control menu option before your updates are applied to new ticklers.
Delete a tickler event rule	Select Delete for an event rule to delete it. Note:  You can delete an event rule only if it is not associated with an open or in process tickler.
Display a tickler event rule	Select Display for an event rule to advance to the Display Tickler Event Rule Screen. You cannot change any information at this screen. See the Create Tickler Event Rule Screen for field descriptions.
Create or change tickler event rule instructions	Select Procedures for an event rule to advance to the Work with Tickler Event Rule Procedure Screen.

Change Tickler Event Screen

Purpose: Use this screen to define tickler event settings at the event level.

Important:

If you change a tickler event, you must restart the asyncs in the Background Job Control menu option before your updates are applied to new ticklers.

How to display this screen: Select Change for a tickler event at the Work with Tickler Event Screen.

Field	Description
Event	A code that determines the system action for which the system may create a tickler. There are 11 system actions that can create ticklers. You cannot create other tickler events for the system to evaluate for tickler creation. BO: backorders; see BO (Backorders) Event Processing CO: cancelled orders; see CO (Cancelled Orders) Event Processing HO: held orders; see HO (Held Orders) Event Processing MN: manually created; see MN (Manually Created) Event Processing NO: new orders; see NO (New Orders) Event Processing OO: aged open orders; see OO (Aged Open Orders) Event Processing SD: stored value card activation decline; see SD (SVC Activation Decline) Event Processing SO: soldout orders; see SO (Soldout Orders) Event Processing SV: stored value card number assignment; see SV (SVC Number Assignment) Event Processing UP: unconfirmed pick tickets; see UP (Unconfirmed Pick Tickets) Event Processing VP: voided pick tickets; see VP (Voided Pick Tickets) Event Processing WF: remote workflow; see WF (Remote Workflow) Event Processing Alphanumeric, 2 positions; display-only.
Description	A description of the tickler event. Alphanumeric, 40 positions; required.
Category (Tickler category)	A code for the tickler category assigned to the tickler event. Tickler categories are used to group ticklers. You can also define a tickler category for each event rule; the tickler category defined at the event rule level overrides the tickler category defined at the event level. Tickler categories are defined in and validated against the Tickler Category table; see Working with Tickler Category (WTCT). Alphanumeric, 3 positions; optional.
Resolution reason	A code for the reason why a tickler for this event is resolved. Tickler resolution reason codes are assigned to a tickler once the tickler has been resolved. You can also define a resolution reason for each event rule; the resolution reason defined at the event rule level overrides the resolution reason defined at the event level. You must define a tickler resolution reason for all tickler events except for the MN (manually created) tickler event. Tickler resolution reasons are defined in and validated against the Tickler Resolution Reason table; see Working with Tickler Resolution Reasons (WTRR). Alphanumeric, 3 positions; required except for MN tickler event.
Priority	The priority assigned to the tickler event, used to determine the importance of ticklers created for this event. You can assign a tickler event priority between 1-9, where 1 is the lowest priority and 9 is the highest priority. You can also define a tickler priority for each event rule; the tickler priority defined at the event rule level overrides the tickler priority defined at the event level. Numeric, 1 position; required.
Active	Indicates whether the tickler event is active. selected = The tickler event is currently active; the system creates a tickler if the system action qualifies for an event rule. unselected = The tickler event and its event rules are not currently active; the system does not create a tickler, regardless of whether the system action qualifies for an event rule. See Active Tickler Events and Rules.
Allow mult ticklers	Indicates if the system creates multiple ticklers for this tickler event if the system action qualifies for more than one event rule. selected = The system creates a tickler for each event rule whose criteria are met by the system action. unselected (default) = The system creates one tickler for the first event rule, in processing sequence order, whose criteria are met by the system action. The system does not create more than one tickler for the tickler event, regardless of whether the system action meets the criteria of more than one event rule. Multiple ticklers are not allowed for tickler events OO (aged open orders) or UP (unconfirmed pick tickets). See Allowing Multiple Ticklers.
Assign to orig user	Indicates if ticklers created for this tickler event are assigned to the user that entered the order associated with the tickler. selected = Assign ticklers created for this tickler event to the user that entered the associated order. If this field is selected, you must also enter a user ID in the Assign to user field. unselected (default) = Do not assign ticklers created for this tickler event to the user that entered the associated order; instead, assign the tickler to the specified user or tickler user group. You must also define tickler assignment for each event rule; the tickler assignment defined at the event rule level overrides the tickler assignment defined at the event level. Note:  This field defaults to selected for MN (manually created) ticklers. See Tickler Assignment.
Notify user/group	Indicates whether the system sends a Tickler Notification email to the assigned user or to all of the users in the assigned tickler user group when a tickler is created for this tickler event. selected = Notify the assigned user/user group when a tickler is created; use the email address defined for the user in the User Extended table. If the tickler is assigned to a user group, send a notification to each user in the group, using the email address defined for each user in the User Extended table. unselected (default) = Do not notify the assigned user/user group when a tickler is created; the user can review the ticklers in his queue at the Work with Tickler Screen (user/group view). You must also define the Notify user/group setting for each event rule; the notify user/group setting at the event rule level overrides the notify user/group setting defined at the event level. See Tickler Notification for a sample Tickler Notification email.
Assign to user	The user ID of the user the system assigns ticklers to for this tickler event. You must also define the Assign to setting for each event rule; the assign to setting at the event rule level overrides the assign to setting defined at the event level. You can define either an assign to user or assign to user group for each event, but not both. Users are defined in and validated against the User table; see Working with User Records (WUSR). See Tickler Assignment. Alphanumeric, 10 positions; optional.
Assign to group	The tickler user group the system assigns ticklers to for this tickler event. You must also define the Assign to setting for each event rule; the assign to setting at the event rule level overrides the assign to setting defined at the event level. You can define either an assign to user or assign to user group for each event, but not both. The tickler user group you enter must be defined as a user type and not a supervisor type. Tickler user groups are defined in and validated against the Tickler User Group table; see Working with Tickler User Groups (WTUG). See Tickler Assignment. Alphanumeric, 10 positions; optional.
Supervisor group	The tickler supervisor group the system assigns ticklers to for this tickler event. You can also define the Supervisor group for each event rule; the supervisor group at the event rule level overrides the supervisor group defined at the event level. The tickler user group you enter must be defined as a supervisor type and not a user type. Tickler groups are defined in and validated against the Tickler User Group table; see Working with Tickler User Groups (WTUG). See Tickler Assignment. Alphanumeric, 10 positions; optional.
Notify supervisor	Indicates when a Supervisor Notification Count email is sent to the supervisor based on the number of days since a tickler was created. The system uses this calculation to determine the next notification date when a tickler is first created: tickler creation date + value in Number of days to notify supervisor field for the event/rule that created the tickler = next notification date. The system does not update the next notification date after a tickler is created. The system sends the email to the email address defined for the supervisor user group in the Tickler User Group table. The system continues sending an email to the supervisor group as long as a tickler assigned to the supervisor group is in an open or in process status and the Next notification date in the Tickler table is equal to or past the current date. If the next notification date is a future date, the system does not send an email until the next notification date is reached. If all ticklers assigned to the supervisor are resolved, the system no longer sends a Supervisor Notification Count email.
	Leave this field blank if you do not want to notify the supervisor about aging ticklers; the supervisor can review ticklers using the Workflow Management (WWFM) menu option. You can also define the Notify supervisor setting for each event rule; the notify supervisor setting at the event rule level overrides the notify supervisor setting defined at the event level. If you define a number of days in this field, you must also define the supervisor group. See Tickler Notification for a sample Supervisor Notification Count email. Numeric, 3 positions; optional.
Note type	Indicates the type of notes you enter for ticklers created for this tickler event. A = Action notes; you use the Edit Customer Actions Window to enter tickler notes. B = Bill to notes; you use the Work with Bill To Notes Screen to enter tickler notes. O = Order notes; you use the Work with Order Messages Screen to enter tickler notes. S = Sold to notes; you use the Edit Customer Notes Screen to enter tickler notes. T = Tickler notes; you use the Work with Tickler Notes Screen to enter tickler notes. You can only define the tickler work notes setting at the event level. If you change the note type for a tickler event, the system does not change the note type for previous ticklers. Alphanumeric, 1 position; required.

Tickler Event Settings

For each tickler event, you must define settings that determine how the system creates ticklers for the event. The settings you define are used as defaults for the created ticklers. You can also define settings at the event rule level. Unless otherwise noted, the settings at the event rule level override the settings at the event level.

You can define tickler event settings at the Change Tickler Event Screen and event rule settings at the Create Tickler Event Rule Screen or Change Tickler Event Rule Screen.

Active Tickler Events and Rules

The Active field defines whether the system creates ticklers for the event or event rule.

• Select the Active field for a tickler event to have the system evaluate the event when the associated system action is performed. The system does not create ticklers for tickler events that are not active, regardless of whether one or more of the event’s rules is active.

• Select the Active field for an event rule to have the system evaluate the event rule when the associated system action is performed. The system does not create ticklers for event rules that are not active, regardless of whether the event rule criteria are met.

If you do not want the system to create ticklers for a system action, deselect the Active field for the associated tickler event.

If you want the system to create ticklers for a system action, but do not want the system to create ticklers for a specific event rule, select the Active field for the associated tickler event and deselect the Active field for the event rule. Remember, to create a tickler for a tickler event at least one event rule must be active.

Tickler Assignment

You can define the user(s) to work with and resolve ticklers created for the tickler event and also the tickler supervisor to monitor the ticklers created for the tickler event.

The tickler assignment settings at the event rule level override the tickler assignment settings at the event level.

Tickler user: You can define the user or group of users to work with and resolve ticklers created by the tickler event.

• select the Assign to original user field to assign ticklers to the order entry operator that entered the order associated with the tickler. If you assign ticklers to the original order entry operator, you must also enter a user ID in the Assigned to user field in case the original order entry operator is no longer valid. Note: If the order is an ecommerce order, the system uses the user ID from the Assigned to user field.

• enter a user ID in the Assigned to user field to assign ticklers to a specific user.

• enter a tickler user group code in the Assigned to group field to assign ticklers to a specific tickler user group. You can create tickler user groups using the Working with Tickler User Groups (WTUG) menu option; the tickler user group type indicates if the tickler group is a user group (type U).

Tickler supervisor: Optionally, you can define the supervisor to monitor the ticklers created by the tickler event by entering a supervisor group in the Supervisor group field.

Tickler supervisors perform all the actions a tickler user performs (works with and resolves ticklers) and also monitors the ticklers assigned to his supervisor group or monitor all ticklers, regardless of the assigned supervisor. A tickler supervisor can also reassign ticklers to different users or different tickler user groups.

You can create supervisor groups using the Working with Tickler User Groups (WTUG) menu option; the tickler user group type indicates if the group is a supervisor group (type S).

Tickler assignment example: The flowchart below displays tickler assignment at the event level and event rule level. In this example:

• ticklers created for event rule 1 are assigned to user group TUSERS and placed in this group’s work queue. Any user belonging to the TUSERS user group can work with and resolve the ticklers. Additionally, the supervisor group SUPER1 monitors the ticklers created for event rule 1. Any user belonging to the SUPER1 supervisor group can monitor the ticklers.

• ticklers created for event rule 2 are assigned to user ERIKH and placed in his work queue. User ERIKH belongs to user group TUSERS, but other members of this group cannot work with and resolve ticklers created for event rule 2 unless user ERIKH or a supervisor reassigns the tickler. Additionally, the supervisor group SUPER2 monitors the ticklers created for event rule 2. User JANEC monitors the ticklers since she is the only user assigned to this supervisor group.

Allowing Multiple Ticklers

The Allow multiple ticklers field defines whether the system creates more than one tickler for a tickler event.

• Select this field to create a tickler for each event rule whose criteria are met by the system action.

• Deselect this field to create one tickler for the first event rule, in processing sequence order, whose criteria are met by the system action. The system does not create more than one tickler for the tickler event, regardless of whether the system action meets the criteria of more than one event rule. The Allow multiple ticklers setting must be unselected for the AR, OO, and UP tickler events.

Regardless of the Allow multiple ticklers setting:

• the system creates a separate tickler for each tickler event that qualifies. For example, if you enter an order and the order meets the criteria for a HO event rule and a SO event rule, the system creates a separate tickler for each event.

• the system does not create a tickler if a tickler already exists for the same event/order/order ship to combination. For example, if a tickler already exists for the NO tickler event, order 5988, and order ship to 1, the system does not create another tickler if you add a new order line to order 5988 for ship to 1 and it qualifies for an NO event rule.

Remember: If you allow multiple ticklers, you must think carefully before you create event rules. For example, if you create the following rules and you allow multiple ticklers, the system creates 3 ticklers, even though event rule 3 is a combination of rules 1 and 2:

• Event rule 1: Ship via is 1 (UPS)

• Event rule 2: Pay type is 1 (cash/check)

• Event rule 3: Ship via is 1 (UPS) and Pay type is 1 (cash/check)

Tickler Notification

For each tickler event, you can define whether the system sends an email when:

• a tickler is created for the event

• an existing tickler for the event is reassigned to another user or user group

• existing open or in process ticklers exist and are older than a specified number of days

Tickler Notification email: The Tickler Notification email informs the assigned to user/group that a new tickler has been created and placed in the tickler work queue. Users can review and work with ticklers assigned to them or their tickler user group using the Working with Tickler Users/User Groups (WTIC) menu option.

To generate: An email is generated and sent to the assigned to user or to all of the users in the assigned to user group each time the system creates a new tickler or a user manually creates a tickler and the Notify user/group field in the Tickler table is selected. The system uses the email address from the User Extended table.

The notify user/group setting at the event rule level overrides the notify user/group setting at the event level.

Email template: The format of the Tickler Notification email differs based on whether the system action that creates the tickler is an interactive process or batch process.

• If ticklers are created for an interactive process, such as order entry, the system sends an email to the assigned to user/user group for each tickler created.

• If ticklers are created for a batch process, the system sends one email to the assigned to user/user group for all of the ticklers created by the batch process. The system includes a report with the email, which displays the ticklers created by the batch process. The batch processes that create ticklers are:

  • Processing Auto Soldout Cancellations (MASO)

  • Working with Credit Card Cancellations (WCCC)

  • Working with Backorders Pending Cancellation (WBPC)

  • Processing Item Substitutions (PSUB)

• Evaluate Tickler periodic function (program name PFR0072); used to create ticklers for the OO and UP tickler events.

Note:

When you manually create a tickler and assign the tickler a future date, the system sends a Tickler Notification email when the tickler is created, not when the assigned future date is reached.

Sample email (interactive): The system generates an email similar to the sample below for all interactive system actions that create ticklers.

From: [e-mail]

To: [e-mail]

Subject: Tickler # 000002923 CO# 555

Tickler # 000002923 ORDER LINE STATUS IS BLANK (OPEN) has been assigned to you with a date of 10/11/22.

Contents:

• From: The email address of the user that started the background async jobs.

• To: The Email address field in the User Extended table for:

  • the assigned to user.

  • the user belonging to the assigned to user group.

  • the user that entered the order associated with the tickler (the assigned to original user).

• Subject: Standard subject for tickler notification emails.

  • the tickler number is the next available number for the Tickler Number number assignment value.

  • the company number is the company where the system action occurred that created the tickler.

• Message line: Standard message notifying the user of the newly created tickler.

  • For MN ticklers, the text defined for the Short note displays after the tickler number. The date is the assigned date defined for the tickler. The text of the line differs if the tickler is assigned to you (...assigned to you...) or one of your tickler groups (...assigned to KAB...).

  • For all ticklers except MN, the description of the event rule that created the tickler displays after the tickler number. The date is the assigned date defined for the tickler. The text of this line differs if the tickler is assigned to you (...assigned to you...) or one of your tickler groups (...assigned to KAB...).

Sample email (batch): The system generates an email similar to the sample below for batch processes that create ticklers.

From: flast&EXAMPLE.COM

To: [e-mail]

Submject: XXREPORT.TXT

Sold Out Orders Report Count for CO# 555 for KAB is 4. Please see attached report for more information.

Contents:

• From: The email address of the user that started the background async jobs.

• To: The Email address field in the User Extended table for:

  • the assigned to user.

  • the user belonging to the assigned to user group.

  • the user that entered the order associated with the tickler (the assigned to original user).

• Subject: Standard subject for tickler notification batch emails, where XX is the tickler event code.

• Message line: Standard message notifying the user of the newly created ticklers, displaying:

  • the name of the process that created the ticklers, for example Sold Out Orders.

  • the user ID or tickler group assigned to the ticklers.

  • the number of ticklers created.

Tickler Notification batch report: The report sorts in event, user/user group, created date, tickler number sequence.

The name of the report is based on the batch process that created the ticklers:

• Backorders Report displays for newly created BO ticklers.

• Cancelled Orders Report displays for newly created CO ticklers.

• Aged Open Orders Report displays for newly created OO ticklers.

• Sold Out Orders Report displays for newly created SO ticklers.

• Unconfirmed Picks Report displays for newly created UP ticklers.

10/15/02  12:02:15 KAB Co.                        Sold Out Orders Report    for KAB

Event: SOLD OUT ORDERS

User:  KBROWN

 Created Assigned  Tickler# Sts Evnt Cat Rule Description/Note

10/15/02 10/15/02      3132  O   SO  SO   001 BATCH PROCESS ONLY IS Y

  Order#       Sts  Customer#  Name/Email                                Telephone#

    6270 - 001  X           6  PAWS AND CLAWS PET SUPPLIES ATTN: LAST  508  555-0100

                               [e-mail]

--------------------------------------------------------------------------------------

10/15/02 10/15/02      3133  O   SO  SO   002 INTERACTIVE MODE IS M

  Order#       Sts  Customer#  Name/Email                                Telephone#

    6270 - 001  X          11  NONNIE, NONA                              978  555-0101

                               [e-mail]

--------------------------------------------------------------------------------------

10/15/02 10/15/02      3134  O   SO  SO   003 ITEM IS BLUEBERRY

  Order#       Sts  Customer#  Name/Email                                Telephone#

    6270 - 001  X          16  LAST, FIRST                       508  555-0102

                               [e-mail]

--------------------------------------------------------------------------------------

Total ticklers for event SO               3

Total ticklers               3

• Contents:

• Event: The description of the tickler event associated with the ticklers created by the batch process.

• User/user group: The user or tickler group assigned to the newly created ticklers.

• Created: The date the tickler was created.

• Assigned: The date the tickler was assigned to the current user/tickler user group; the assigned date is the same date as the created date.

• Tickler#: The newly created tickler number.

• Status: The status of the tickler; when a tickler is first created, the status is O (open).

• Event: the code for the tickler event associated with the newly created tickler.

• Category: The tickler category assigned to the tickler.

• Rule: The event rule that created the tickler.

• Description: A description of the event rule that created the tickler.

• Order#: The order associated with the tickler.

• Status: The status of the order associated with the tickler.

• Customer#: The sold to customer associated with the tickler. If this email is for the AR tickler event, the bill to customer associated with the tickler displays.

• Name: The sold to customer associated with the tickler.

• Email: The primary email address defined for the sold to customer.

• Telephone: The telephone number defined for the sold to customer.

• Total ticklers for event: The total number of newly created ticklers for the tickler event.

• Total ticklers: The total number of newly created ticklers across all tickler events.

Tickler Reassignment email: The system sends an email each time an existing tickler is reassigned to a new user or tickler user group.

Note:

The system sends a Tickler Reassignment email only if the Notify user/group field for the event rule associated with the tickler is selected.

To generate: An email is generated when an existing tickler is:

• reassigned to a new user or tickler user group. A tickler user can reassign ticklers currently assigned to him at the Change Tickler Screen; a tickler supervisor can reassign ticklers, regardless of who is currently assigned, at the Change Tickler screen or Reassign Ticklers Window.

• graduated to a new event rule; only ticklers for the AR, OO, and UP events are graduated. The system sends a Tickler Notification Reassignment email only if the new event rule has a different assigned to user/group from the previous event rule assigned to the tickler.

From: flast&EXAMPLE.EXAMPLE.COM

To: [e-mail]

Subject: Tickler # 000002923 CO# 555 (REASSIGNED)

Tickler# 7159 OLDER THAN 5 DAYS (ARRIVAL0, SHIP VIA 2 has been assigned to KAB with a date of 10/14/02.

Contents:

• From: The email address of the user that started the background async jobs.

• To: The Email address field in the User Extended table for:

  • the new assigned to user.

  • the user belonging to the new assigned to user group.

• Subject: Standard subject for tickler reassignment emails.

  • The tickler number is the number of the tickler that has been reassigned.

  • the company number is the company where the system action occurred that created the tickler.

• Message line 1: Standard message notifying the user of the reassigned tickler.

  • For MN ticklers, the text defined for the Short note displays after the tickler number. The date is the assigned date defined for the tickler. The text of the line differs if the tickler is assigned to you (...assigned to you...) or one of your tickler groups (...assigned to KAB...).

  • For all ticklers except MN, the description of the event rule defined for the tickler displays after the tickler number. The date is the assigned date defined for the tickler. The text of this line differs if the tickler is assigned to you (...assigned to you...) or one of your tickler groups (...assigned to KAB...).

Supervisor Notification Count email: The Supervisor Notification Count email informs the users in the tickler supervisor group that open and in process ticklers exist that are assigned to the supervisor group and have not yet been resolved. The email includes a report which displays the number of open ticklers assigned to the supervisor group that have not yet been resolved. The tickler supervisor can use the report to determine if he should reassign ticklers based on the current workload of users assigned to work with and resolve the ticklers.

To generate: An email is generated and sent to all of the users in the supervisor group when you run the Evaluate Tickler periodic function if:

• an open or in process tickler exists, and

• the tickler is assigned to a supervisor group, and

• the Next notification date defined for the tickler in the Tickler table is equal to or past the current date.

The system sends an email to the email address defined for the supervisor user group in the Tickler User Group table.

Note:

If a user belongs to more than one tickler supervisor group, that user will receive a separate Supervisor Notification Count email for each tickler supervisor group that has aged ticklers.

The supervisor setting at the event rule level overrides the supervisor setting at the event level.

Once an initial Supervisor Notification Count email is sent to the supervisor group, the system sends an email each time you run the Evaluate Tickler periodic function.

• When the system creates a tickler, the system calculates the date when the supervisor should be notified and updates the Next notification date field in the Tickler table with the initial notice date. The system uses this calculation to determine the next notification date when a tickler is first created: tickler creation date + value in Number of days to notify supervisor field for the event rule that created the tickler = next notify date.

• Once an initial Supervisor Notification Count email is sent to the supervisor, the system sends an email to the supervisor group each time you run the Evaluate Tickler periodic function since the next notification date is past the current date. The system does not update the next notification date once an initial email is sent to the supervisor.

Note:

The system does not use the Notify user/group setting defined for the event to determine if a Supervisor Notification Count email is sent to the supervisor.

The system continues sending an email to the supervisor as long as a tickler assigned to the supervisor group is in an open or in process status and the Next notification date is equal to or past the current date. If all ticklers assigned to the supervisor are resolved, the system no longer sends a Supervisor Notification Count email.

Sample email:

From: flast&EXAMPLE.COM

To: [e-mail]

Subject: SUPERVSR.TXT

Supervisor Notification Count for CO# 555 for HOSUPER is 55. Please see attached report for more information.

Contents:

• From: The email address of the user that started the background async jobs.

• To: The email address defined for the supervisor user group in the Tickler User Group table.

• Subject: Standard subject for supervisor notification count emails.

• Message line: Standard message notifying the supervisor of the supervisor notification count. The tickler count is the number of ticklers in an open or in process status that are assigned to the supervisor group and the next notification date for the tickler in the Tickler table is equal to or past the current date.

Supervisor Notification report: The Supervisor Notification report breaks by event and within event by user/user group. The report sorts in event, user/user group, created date, tickler number sequence. A total displays for each event and across all events.

10/15/02   8:11:11 KAB Co.                        Supervisor Notification   for SUPERKAB

Event: HELD ORDERS

User:  KAB

 Created Assigned  Tickler# Sts Evnt Cat Rule Description/Note

 9/18/02 10/15/02      3060  O   HO  HO   001 ORDER HOLD REASON IS AT

  Order#       Sts  Customer#  Name/Email                                Telephone#

    6261 - 001  H          11  LAST, FIRST                              5085550103

                               [e-mail]

--------------------------------------------------------------------------------------

Total ticklers for event HO               1

Event: BACKORDERS

User:  DDICESARE

 Created Assigned  Tickler# Sts Evnt Cat Rule Description/Note

 9/28/02 10/15/02      3263  O   BO  BO   003 ITEM IS AB10000

  Order#       Sts  Customer#  Name/Email                                Telephone#

    6781 - 001  H          19  LAST, FIRST                       9785550103

                               [e-mail]

--------------------------------------------------------------------------------------

Total ticklers for event BO               1

Total ticklers               2

Contents:

• Supervisor group: The name of the supervisor group assigned to the open or in process ticklers.

• Event: The description of the tickler event associated with open or in process ticklers.

• User/user group: The user or tickler group assigned to open or in process ticklers for the event.

• Created: The date the tickler was created.

• Assigned: The date the tickler was assigned to the current user/tickler user group.

• Tickler #: The tickler number that is open or in process.

• Status: The status of the tickler; O (open) or I (in process).

• Event: The code for the tickler event associated with the tickler.

• Category: The tickler category assigned to the tickler.

• Rule: The event rule that created the tickler.

• Description/Note: 

  • For MN ticklers: the text from the Short note field displays. If the Short note field for the tickler is blank, the description of the MN event displays.

  • For all ticklers except MN: the description of the event rule displays.

• Order#: The order and ship to associated with the tickler.

• Status: The status of the order.

• Customer#: The sold to customer associated with the tickler.

• Name: The name of the sold to customer.

• Email: The primary email address defined for the sold to customer.

• Telephone#: The telephone number defined for the sold to customer.

• Total ticklers for event: The number of open or in process ticklers assigned to the supervisor group for the tickler event.

• Total ticklers: The number of open or in process ticklers assigned to the supervisor group across all tickler events

Tickler Work Notes

The Note type field defines the type of tickler work notes a user enters for each tickler event; these work notes describe resolution notes and progress notes.

• A = Action notes; the user enters tickler work notes at the Edit Customer Actions Window.

• B = Bill to notes; the user enters tickler work notes at the Work with Bill To Notes Screen.

• O = Order notes; the user enters tickler work notes at the Work with Order Messages Screen.

• S = Sold to notes; the user enters tickler work notes at the Edit Customer Notes Screen.

• T = Tickler notes; the user enters tickler work notes at the Work with Tickler Notes Screen.

You can only define the tickler work notes setting at the event level. If you change the note type setting, the system does not change the note type for previously created ticklers.

Tickler Priority

The tickler priority defines the importance of ticklers created for the tickler event; you can scan for ticklers by priority at the Work with Tickler Screen (user/group view) (tickler users) and Workflow Management Screen (tickler supervisors).

You can assign a tickler priority between 1-9, where 1 is the lowest priority and 9 is the highest priority.

The tickler priority defined at the event rule level overrides the tickler priority defined at the event level.

Tickler Category

Optionally, if you wish to group ticklers, you can assign a tickler category to ticklers.

You can scan for ticklers assigned to this category at the Work with Tickler Screen (user/group view) (tickler users) and Workflow Management Screen (tickler supervisors).

Example:To view only ticklers created for a specific HO rule, create a tickler category for each HO rule you create. This way you can view all ticklers created for HO rule 1 (paytype hold reason is AT) versus ticklers created for HO rule 2 (order hold reason is SF). In this example, tickler category for rule 1 may be HAT and tickler category for rule 2 may be HSF.

The tickler category defined at the event rule level overrides the tickler category defined at the event level.

You can create tickler categories using the Working with Tickler Category (WTCT) menu option.

Tickler Resolution Reason

Tickler resolution reasons are required when you or the system resolves a tickler; the resolution reason indicates the reason why the tickler is resolved.

You can define a tickler resolution reason for a tickler event or event rule; when the system creates a tickler for the tickler event/rule, the system updates the Resolution reason field in the Tickler table.

It is recommended you create at least 2 ticklers resolution reasons: one reason to use when the system resolves the tickler, and one reason to use when you manually resolve a tickler.

The resolution reason defined at the event rule level overrides the resolution reason defined at the event level.

You can create tickler resolution reasons using the Working with Tickler Resolution Reasons (WTRR) menu option

Point of Sale Integration

Topics in this part: This part describes integration between Order Administration and a POS (point of sale) system.

• Point of Sale Integration Overview provides a brief overview of the various integrations available.

• Generic Inventory Transaction Upload describes the process of uploading inventory transactions.

• Generic Item Download API describes the process of downloading item/SKUs.

• Generic Vendor Download API describes the process of downloading vendors.

• Generic Invoice Download API describes the process of downloading invoices.

• Working with Outbound Interface Transactions (WOIT) allows you to review triggers in the IL Outbound Trigger table.

• Generating Outbound Interface Triggers (GOIT) describes how to create triggers in the IL Outbound Trigger table for item/SKUs, vendors, and/or invoices.

• Generic Customer History API describes how the system responds to requests for customer or order history information.

• Generic Inventory Inquiry API describes how the system responds to requests for inventory information about an item/SKU.

• Generic Inventory Download API describes the process of downloading item availability information.

• Generic Customer Inquiry (Search) API describes how the system responds to requests for customer records based on various search criteria.

• Work with Store Cross Reference (WSCR) describes how to set up a cross reference table to map store locations between Order Administration and an external system such as Order Orchestration or a POS application.

• Store Upload explains how to upload store cross reference information from an external system to create or update records the Store Cross Reference table.

• Generic Customer Download API describes the process of downloading customer information.

• Mass Customer Download describes the process of creating a batch file containing customer information for sold to customers that meet the Mass Customer Download customer class criterion. Note that this option is not currently implemented.

• Customer Engagement Batch Customer and Sales Integration describes the process of sending customer, item, sales and return information from Order Administration to Oracle Retail Customer Engagement.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Point of Sale Integration Overview

Purpose: The point of sale integration allows you to send data from Order Administration to your point of sale system and receive data from your point of sale system into Order Administration.

In this topic:

• Point of Sale Download Processing

  • What Data Can I Download?

  • When are Download Triggers Created?

  • Identifying Download Triggers

  • Outbound Interface Trigger Rules

  • Outbound Interface Trigger Monitor

  • Trigger Cleanup

  • Processing Delete Triggers

  • Outbound Interface Message Builder

  • Outbound Interface Queues

  • Generic Download Message Formatting

• Point of Sale Upload Processing

  • Generic Order Interface

  • Inventory Transaction Upload

• Point of Sale Bi-Directional Processing

  • Customer Inquiry (Search) Integration

  • Customer History Integration

  • Inventory Inquiry Integration

• Point of Sale Integration Setup

  • System Control Values

  • Menu Options

  • Periodic Functions

Point of Sale Download Processing

Overview: Order Administration allows you to capture the following information to download to a point of sale system:

• item/SKUs; see Generic Item Download API

• vendors; see Generic Vendor Download API

• invoices; see Generic Invoice Download API

• inventory: see Generic Inventory Download API

• customers: see Generic Customer Download API

For information on the above referenced APIs, see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Information flow: This flowchart explains how information is downloaded from Order Administration to a point of sale system.

What Data Can I Download?

Jobs in the Working with Integration Layer Processes (IJCT) menu option control what information is downloaded to another system:

• Item Outbound job: generates an item download XML message for each trigger in the IL Outbound table with a File code of SKU.

• Vendor Outbound job: generates a vendor download XML message for each trigger in the IL Outbound table with a File code of VND.

• Invoice Outbound job: generates an invoice download XML message for each trigger in the IL Outbound table with a File code of IHD.

• Inventory Outbound job: generates an inventory download XML message for each trigger in the IL Outbound table with a File code of ITW.

• Customer Download job: generates a customer download XML message for each trigger in the IL Outbound table with a File code of CST.

When are Download Triggers Created?

System control values control the type of data downloaded to a point of sale system.

• If the system control value is selected, certain actions in Order Administration triggers the system to create triggers in the IL Outbound Trigger table. The IL Outbound Trigger table acts as a “to do” list for the data that requires download.

• If the system control value is unselected, the system does not create triggers in the IL Outbound Trigger table.

You can also create triggers for existing data in your company using the Generating Outbound Interface Triggers (GOIT) menu option.

System Control Value	Description
Create Generic Item Download Trigger Records (I15)	Select this field to create item download triggers in the IL Outbound Trigger table to download to the point of sale system.
Create Generic Vendor Download Trigger Records (I16)	Select this field to create vendor download triggers in the IL Outbound Trigger table to download to the point of sale system.
Create Generic Invoice Download Trigger Records (I17)	Select this field to create invoice download triggers in the IL Outbound Trigger table to download to the point of sale system.
Create Generic Inventory Download Triggers (I32)	Select this field to create inventory download triggers in the IL Outbound Trigger table to download to the point of sale system.
dCreate Generic Customer Download Triggers (L12)	Select this field to create customer download triggers in the IL Outbound Trigger table to download to the point of sale system.

Identifying Download Triggers

Each trigger in the IL Outbound Trigger table has a:

• File code: indicating the type of information to download and which IL process job processes the trigger.

• Key: indicating the specific record to download.

• Capture type: indicating the type of activity performed against the record:

  • A = the record was created.

  • C = the record was maintained. Note: The system removes any duplicate change triggers; see Trigger Cleanup.

  • D = the record was deleted. Note: The system processes delete triggers immediately; see Processing Delete Triggers.

You can review point of sale download triggers in the Working with Outbound Interface Transactions (WOIT) menu option.

File code	Created when	Refers to table(s)	Key	IL Process job
SKU	An item/SKU is added, updated or deleted; see Item Outbound Trigger Activities For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Item SKU	11122222222222233333333333333 where: 111 is the company code 222222222222 is the item number 33333333333333 is the SKU code	Item Outbound
IHD	An invoice is created or updated; see Invoice Outbound Trigger Activities For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Invoice Header Order Header	111222222233333333 where: 111 is the company code 2222222 is the order number 33333333 is the invoice number	Invoice Outbound
VND	A vendor is added, updated or deleted; see Vendor Outbound Trigger Activities For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Vendor	1112222222 where: 111 is the company code 2222222 is the vendor code	Vendor Outbound
ITW	Item/SKU available quantity changes; see Creating Inventory Download Triggers Interactively Due to Changes in Availability For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Item SKU Warehouse Item Warehouse Item UPC	11122222222222233333333333333 where: 111 is the company code 222222222222 is the item number 33333333333333 is the SKU code	Inventory Outbound
CST	You create, change, or delete a customer; see Customer Outbound Trigger Activities For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Customer Sold To tables Customer Ship To tables Customer Bill To tables	1112222222 where: 111 is the company code 2222222 is the customer code	Customer Download Outbound

Outbound Interface Trigger Rules

Outbound interface trigger rules define the criteria a record must meet in order for the system to create an IL outbound trigger. For each IL Process outbound job, you can define trigger rules for certain tables. For example, you can define trigger rules for the Item table and SKU table for the Item Outbound job. If you define more than one criterion, the record must meet all of the criteria defined in order to generate a trigger.

See Defining Outbound Interface Trigger Rules for more information on setting up trigger rules for each IL Process job.

For IL Process job:	you can create trigger rules for:	Example:
Item Outbound	Item table SKU table	You can specify to only create item download triggers for company 555, items that are SKU’ed and whose SKUs are located in warehouse 20. To do this: in the Item table trigger rules, enter EQ and 555 next to the Company trigger field and EQ and ’Y’ next to the Allow SKU’s trigger field. In the SKU table trigger rules, enter EQ and 20 next to the Warehouse trigger field. See Item Outbound Trigger Rules in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
Invoice Outbound	Invoice Header table Order Header table	You can specify to only create invoice download triggers for debit invoices and not credit invoices. To do this, enter EQ and I (invoice) next to the Invoice type trigger field. See Invoice Outbound Trigger Rules. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
Vendor Outbound	Vendor table	You can specify to only create vendor download triggers for companies 27 and 555 and vendor 202. To do this, enter LIST and 27 555 next to the Company trigger field and EQ and 202 next to the Vendor # trigger field. See Vendor Outbound Trigger Rules. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
Inventory Outbound	Item SKU Warehouse Item Warehouse Item UPC	You can specify not to create inventory download triggers for non-inventory items. To do this, enter NE and ’Y’ next to the Non-inventory trigger field.
Customer Download Outbound	Company Customer class Inactive? Country	You can specify not to create customer download triggers for inactive customers. To do this, enter NE and ’Y’ next to the Inactive? trigger field. See Customer Outbound Trigger Rules. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Outbound Interface Trigger Monitor

When active, each IL Outbound job monitors the IL Outbound Trigger table for unprocessed triggers at defined intervals, based on the Outbound delay time.

Each IL Outbound job:

• looks for triggers with the appropriate File code and a Status of ready (R).

  • the Item Outbound job looks for File code SKU.

  • the Invoice Outbound job looks for File code IHD.

  • the Vendor Outbound job looks for File code VND.

  • the Inventory Outbound job looks for File code ITW.

  • the Customer Download Outbound job looks for File code CST.

• sends each trigger to the IL Outbound message builder to generate an XML message.

Trigger Cleanup

Before processing triggers in the IL Outbound table, the system looks for duplicate unprocessed download triggers with the same Capture type for the same File code and Key. If duplicate triggers exist, the system removes the duplicates, leaving only the most recent trigger for the Capture type, File code and Key.

Example: The following change triggers exist in the IL Outbound table.

File	Status	Key	Results
SKU	unprocessed	555AB105004 RED GRLS SMLL	The system deletes 2 of these triggers, leaving only one trigger to process.
SKU	unprocessed	555AB105004 RED GRLS SMLL
SKU	unprocessed	555AB105004 RED GRLS SMLL

Note:

If both an add and change trigger exist for the same File code and Key, the system generates a download message for both triggers.

Processing Delete Triggers

The system processes triggers in the IL Outbound Trigger table with a delete (D) Capture type immediately, regardless if the IL Outbound job is active or inactive.

Note:

Since you cannot delete an invoice, the system never creates a delete download trigger for an invoice.

If one or more unprocessed triggers exist in the IL Outbound Trigger table for the same File code and Key, the system:

• if one of the matching triggers is an add (A) Capture type: does not create the delete trigger and removes any other matching triggers (add and change). Since the point of sale system never received the add trigger, you do not want to send a delete trigger or any other triggers.

  Note:

  However, if an Original processed date and time exist for the add trigger (indicating the trigger was previously downloaded and then reset to reprocess again), the system generates a download message for the delete trigger and removes any other matching triggers (add and change). Since the point of sale system previously received the add trigger, you want to send a delete notification to the system.

• if the matching trigger is a change (C) Capture type: generates a download message for the delete trigger and removes any other matching change triggers. Since the point of sale system is receiving a delete trigger, you do not need to send any change triggers.

Outbound Interface Message Builder

For each trigger, the IL Outbound message builder:

• determines what information requires download. The system uses the Key field for the trigger to determine which records require download.

  • The Key field for item download triggers consists of company + item number + SKU code. The SKU code is included only if the item is a SKU’ed item. For example the Key 555AB100112 BLUE GRLS SMLL indicates the item and SKU information is located in company 555 for item number AB100112 and SKU code BLUE GRLS SMLL.

  • The Key field for invoice download triggers consists of company + order number + invoice number. For example the Key 55500049680000583 indicates the invoice information is located in company 555 for order number 4968 and invoice number 583.

  • The Key field for vendor download triggers consists of company + vendor number. For example the Key 5550002006 indicates the vendor information is located in company 555 for vendor number 2006.

  • The Key field for inventory download triggers consists of company + item number + SKU code. The SKU code is included only if the item is a SKU’ed item. See the description of the item download trigger key above.

• determines which elements to include in the download message, based on XML inclusion rules. You can define XML inclusion rules for each IL Outbound job at the Outbound Interface XML Inclusion Screen. XML inclusion defines which elements to include in a download message.

  • If the element is included, that element and its parents are included in the generated download XML message.

  • If the element is excluded, that element and its children are excluded from the generated download message.

• sends the generated download message to the queues defined for the Outbound job that are active.

For more information:

• item download: Item Outbound XML Inclusion

• vendor download: Vendor Outbound XML Inclusion

• invoice download: Invoice Outbound XML Inclusion

• inventory download: Inventory Download XML Inclusion

• customer download: Customer Outbound XML Inclusion

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Outbound Interface Queues

Once the Outbound message builder determines which elements to include in the download XML message, the IL Outbound job sends each download XML message to the appropriate queues whose Enabled field is selected. If the queue is not enabled, the system does not send the download message to that queue.

You can define outbound queues for each IL Outbound job at the Work with Integration Layer Process Queues Screen.

For example, you can define a separate queue to send the download message to your:

• retail store

• warehouse management system

Generic Download Message Formatting

For each download message:

• numeric fields are not zero-filled, for example 000001 displays as 1.

• blank spaces are removed from the beginning and end of alphanumeric fields.

• decimal places for numeric fields are implied.

• empty elements are not included; for example, if an item/SKU does not have a vendor item defined, the system does not send the VendorItem element or its children (VITPriceBreak, VITAdditionalCharge, VITNote, and VITUserField) in the item download message.

• empty attributes are not included; for example, if the Kit type field for an item/SKU is blank, the system does not send the Kit_type attribute in the item download message.

For more information:

• Item Download XML Message (CWItemOut)

• Vendor Download XML Message (CWVendorOut)

• Invoice Download XML Message (CWInvoiceOut)

• Inventory Download XML Message (CWInventoryDownload)

• Customer Download XML Message (CWCustomerDownload)

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Point of Sale Upload Processing

The following uploads allow you to bring information into Order Administration from another system.

Generic Order Interface

Overview: Use the generic order interface to send orders into Order Administration. You can use this interface for any type of order, including retail point of sale transactions, orders received through a remote call center, and orders taken at a web storefront.

Options: Your options through the generic order interface include:

• response: generating a detailed response, a simple response, or no response

• separate payment message: sending the payment information separately or in the same message as the rest of the order information

• batching: batched or non-batched orders

• deposit and refund suppression: suppressing the order from deposit processing and refund generation

• returns: entering a return by specifying a negative order quantity

• customer updates: updating an existing sold-to, or creates a new sold-to, bill-to, or permanent ship-to customer

For more information: See the Generic Order Interface (Order API) in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1)

Inventory Transaction Upload

Overview: You can use the Generic Inventory Transaction Upload to synchronize inventory levels in Order Administration with another system. For example, you can upload counts in retail stores. To do so, you can identify each store as a warehouse in Order Administration. The inventory counts of each store are then available for review through a menu option such as Using Inventory Inquiry (DINI) or Inquiring into Item Availability (DIAV).

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

You can use the upload for any type of inventory transaction that is also available in Working with Inventory Transactions (WITI); for example, you can upload transfers, adjustments, returns to vendor, and resets of on-hand quantity. System transactions such as shipments or purchase order receipts are not allowed. The upload performs the same edits and validations as in batch or interactive inventory transactions.

For more information: See Generic Inventory Transaction Upload in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Other inventory integrations: In addition to the inventory transaction upload, you can use the:

• Generic Inventory Download API to download current inventory information, such as availability and warehouses where an item/SKU is stored, to an external system, such as Order Orchestration. You can schedule the download periodically, such as once a day; the system also creates trigger records based on changes to availability levels.

• Generic Inventory Inquiry API to respond to requests for inventory information from an external system. Through this API, the system responds to requests “behind the scenes,” and the activity is not visible on any screen.

  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

• integration with Order Orchestration to share item and inventory information with multiple systems and to submit orders to another system for fulfillment. See the Order Orchestration Integration Overview for background.

Point of Sale Bi-Directional Processing

The following process allows you to receive a request from an external system or Order Orchestration, and generate a response.

Customer Inquiry (Search) Integration

Purpose: Use the generic customer inquiry integration to enable an external system to find a customer based on standard search criteria, such as alternate customer number, postal code, last name, phone number, or email address. The information in the response from Order Administration includes the customer number as well as name and address.

This search function has options similar to the Select Customer Sold To Screen, and produces similar results. When you enter search criteria at the Select Customer Sold To Screen, you advance to a subsequent screen listing customers in alphanumeric order based on values that match your search criteria. Similarly, when the system receives a customer inquiry request, it responds with a message listing customers in alphanumeric order based on values that match the search criteria from the request.

You can use this integration together with the customer history integration described below so that, once Order Administration has provided the matching customer(s) from the Customer Sold To table, the external system can then send a customer history request for a selected customer.

For more information: See Generic Customer Inquiry (Search) API in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Customer History Integration

Purpose: Use the generic customer history integration to provide a customer’s order history to an external system and detailed information about a single order.

The external system can request information using the Order Administration customer number or order number. It can also use its own numbers if they map to the alternate customer number or alternate (web) order number in Order Administration.

When the request provides information on the customer, Order Administration produces a customer history message in response. When the request provides information on the order, Order Administration produces a detailed or summary order message. The request can include the Order Administration customer or order numbers, or the external system can use its own numbers if they map to the alternate customer number or alternate (web) order number in Order Administration.

For more information: See Generic Customer History API in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Inventory Inquiry Integration

Purpose: Use the generic inventory inquiry integration to provide current inventory information for items upon request. For example, you might use this integration to send up-to-date inventory information when it is requested by an external system. See Inventory Transaction Upload for a comparison between this integration and other generic inventory integrations.

For more information: See Generic Inventory Inquiry API in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Point of Sale Integration Setup

You must perform the necessary Order Administration setup and processing to use the point of sale Integration.

Information requiring setup includes:

• System Control Values

• Menu Options

• Periodic Functions

For more information: See the Generic Order Interface (Order API) and the Generic Inventory Transaction Upload  in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for information on setup related to these interfaces.

System Control Values

System Control Value	Description
Create Generic Item Download Trigger Records (I15)	Select this field to create item download triggers in the IL Outbound Trigger table to download to the point of sale system.
Create Generic Vendor Download Trigger Records (I16)	Select this field to create vendor download triggers in the IL Outbound Trigger table to download to the point of sale system.
Create Generic Invoice Download Trigger Records (I17)	Select this field to create invoice download triggers in the IL Outbound Trigger table to download to the point of sale system.
Create Generic Inventory Download Triggers (I32)	Select this field to create inventory download triggers in the IL Outbound Trigger table to download to the point of sale system.
Create Generic Customer Download Triggers (L12)	Select this field to create customer download triggers in the IL Outbound Trigger table to download to the point of sale system.
Outbound Interface Trigger File Purge Days (I14)	Enter the number of days to retain records in the IL Outbound Trigger table before purging them. Run the PURGIJT periodic function (program name ILR0026) to delete any records if: Last processed date is less than the current system date by the number of purge days and Status is X. You can also use the Purge option at the Work with Outbound Interface Transactions Screen to purge records. Example:  Today is 2/07, and you have set this value to 1. Any record whose Last processed date is 2/06 or earlier is purged.

Menu Options

Menu Option	Description
Generating Outbound Interface Triggers (GOIT)	Allows you to create an IL outbound trigger record for each item/SKU, vendor, and/or invoice in your company. Run this process to initially send your data to the point of sale system.
Working with Outbound Interface Transactions (WOIT)	Allows you to review, delete, or resend IL outbound trigger records.
Working with Integration Layer Processes (IJCT)	Use this option to create the process queues and required message queues and queue managers to send and receive messages for each integration. Also, define trigger rules, XML inclusion rules, and queues for the following IL Process jobs related to point of sale: Item Outbound: processes triggers with a File code of SKU and generates an item download message. Invoice Outbound: processes triggers with a File code of IHD and generates an invoice download message. Vendor Outbound: processes triggers with a File code of VND and generates a vendor download message. Inventory Outbound: processes triggers with a File code of ITW and generates an inventory download message.

Periodic Functions

Periodic Function	Description
Purge IJCT Download (program name ILR0026)	Run this periodic function to purge processed IL outbound triggers, based on the Outbound Interface Trigger File Purge Days (I14) system control value: Capture date is less than the current system date by the number of purge days and Status is X
Start All IJCT Jobs (program name MSX1288)	Run this periodic function to start all IL Process jobs in the Working with Integration Layer Processes (IJCT) menu option.
Stop All IJCT Jobs (program name MSX1289)	Run this periodic function to end all IL Process jobs in the Working with Integration Layer Processes (IJCT) menu option.

Batch Inventory Overlay Upload

Purpose: Use the batch inventory overlay upload process to update the on-hand quantities for a batch of item locations.

A periodic function processes the contents of a pipe-delimited text file that is placed in the CWDIRECTCP_UPLOAD_DIRECTORY through the Work with File Uploads (WUPL) option, or uploaded through the File Storage API.

Processing: The batch overlay upload:

• Processes the inventory upload file if it is found in the directory:

  • Defined in the CWDIRECTCP_UPLOAD_DIRECTORY property or,

  • In the OMS-IMPORTS container of the FILE_STORAGE table.

• For each row in the file, updates the Item Location record with the on-hand quantity, or creates the Item Location record if the Item Warehouse exists.

• Resets the on-hand quantity for the Item Warehouse record.

• Submits a record to the Evaluate Backorder queue, if needed.

• Writes any errors to an error file in the:

  • Errors subfolder of the CWDIRECTCP_UPLOAD_DIRECTORY, as described below, or

  • OMS-ERRORS container of the FILE_STORAGE table.

• Deletes the file after processing is complete after writing any errors to the:

  • Errors subfolder, or

  • OMS-ERRORS container of the FILE_STORAGE table. You can download this file through the file storage API.

The periodic function does not:

• Reset the on-hand quantity to be lower than the reserved quantity.

• Write an Inventory Transaction History record.

Setup:  Setup for the batch overlay process includes:

• Create the INVOVRL (Program Name PFINVOVR) periodic function and assign it to a periodic process.

• Working with Admin Properties (CPRP): Set the following admin properties:

  • COMMIT_RATE: The number of records to process at a time. In most cases, should be set to 1000 for optimal processing.

  • OVERLAY_DEBUG: Set to Y in order to create entries in the Job.log file. The log notes the number of records in the file, the number of records successfully processed, the number of errors, and the time to process, for example: File: INV_OVERLAY_005.TXT Rows: 4 Success: 1 Errors: 3 Start Time: Mon Mar 04 16:03:11 EST 2019 End Time: Mon Mar 04 16:03:11 EST 2019 Time In Seconds: 0.041420431 Time In Minutes: 6.903405166666667E-4

  • CWDIRECTCP_UPLOAD_ DIRECTORY: Indicates the location where the periodic function looks for the batch overlay import file if you are not using the file storage API; otherwise, see the File Storage API for more setup information.

File name: The batch overlay upload file placed in the upload directory or uploaded through the file storage API should be named INV_OVERLAY_SEQ.TXT. A zip file such as INV_OVERLAY_SEQ.ZIP is also supported if using the file storage API, provided the zip file includes a single file using the same name, for example, INV_OVERLAY_SEQ.ZIP contains INV_OVERLAY_SEQ.TXT. In all cases, the SEQ is a unique, optional sequence number. If there are multiple files in the upload directory or the OMS-IMPORTS container, the function processes them in order based on the sequence number.

File layout: A sample row in the batch overlay upload file is:

6|1000|RED 5|1|A010101|50

Where:

• 6 is the company.

• 1000 is the item code.

• RED 5 is the SKU, if any; otherwise, this field should be empty.

• 1 is the warehouse code.

• A010101 is the warehouse location.

• 50 is the new on-hand quantity to overlay the current on-hand quantity.

Errors: If the function finds any errors, it writes a copy of the file in:

• The Errors subfolder in the CWDIRECTCP_UPLOAD_DIRECTORY or

• The OMS-ERRORS container of the FILE_STORAGE table.

The TXT suffix is replaced with ERROR: for example, INV_OVERLAY_123.ERROR. The function adds a description of the error to the row in the error file. Possible errors include:

• Location is not valid: Either the location or the company is invalid.

• No Item Warehouse row found: Possible explanations include:

  • A matching Item Warehouse record does not exist for the specified Item Location.

  • The item specified is invalid.

  • No SKU is specified for a SKU’d item.

Note:

Matching for alphanumeric data, including the item, SKU, and location code, is case-sensitive.

• Requested overlay brings on hand below Printed or Reserved: The overlay quantity is lower than the current printed or reserved quantity for the Item Location.

• Invalid number of entries: Possible explanations include:

  • A row is empty.

  • There is no company or quantity specified for the row.

• One or more entries are invalid: Possible explanations include:

  • No item was specified.

  • No warehouse was specified.

  • o location was specified.

Logging: The process writes records to the App.log file indicating:

• The number of records successfully updated.

• The number of records in error.

• That the file was deleted after processing.

Note:

• To prevent potential errors, Oracle recommends not passing updates to the same Item Location in the same upload file.

• If the zip file in the OMS-IMPORTS folder does not contain a text file with a matching name, no processing occurs and the file is deleted.

Importing Store Cross Reference Locations through Order Orchestration’s Discovery Web Service

Purpose: You can use Order Orchestration’s discovery web service to request the codes, descriptions and addresses of locations from Order Orchestration, and use this information to create Store Cross Reference records in Order Administration. A periodic function calls the web service and specifies the system in Order Orchestration whose locations should be imported and used to create the cross-reference records.

Location discovery setup:

• Periodic function: Create a periodic function such as IMPSTLC using the Program name PFR0122 and assign it to a periodic process. The Parameter for the periodic function is composed of up to 11 positions, where:

  • position 1 = Y or y if the store cross-reference records should be created with the Ship for Pickup flag selected; otherwise, you would typically set the first position to N. If the first position is set to anything other than Y or y, the Ship for pickup flag is unselected for the Store Cross Reference record.

  • positions 2-11 = The code identifying the system associated with the locations. Must be a valid system code in Order Orchestration.

    Example: If the parameter is set to NPOS, the periodic function imports location records for system POS in Order Orchestration, and leaves the Ship for pickup flag for each imported location unselected.

• Required property file setting: To import locations using the discovery web service, you need to set the OROB_DISCOVERY_SERVICES_WSDL_LOCATION property in Working with Customer Properties (PROP) to the endpoint for the Discovery Services web service. This entry should be set to https://SERVER:8443/Locate/DiscoveryServices, where SERVER is the name of your Oracle Retail Order Orchestration server.

Note:

If the discovery web service requires basic web service authentication, you must define a valid web service authentication user and password in Working with Web Service Authentication (WWSA), or client ID if using OAuth.

Location discovery processing: The periodic function:

• Sends a request to Order Orchestration’s discovery web service for locations in the system specified in the Parameter for the periodic function, as described above.

• Receives a response from Order Orchestration’s discovery web service, listing all locations in the specified system, excluding the Default Unfulfillable Location.

• For each location code specified in the response message that does not match an existing record, creates a new Store Cross Reference record in the company specified for the periodic process, using the first position of the periodic function’s Parameter to determine whether to select the Ship for Pickup flag for the new record. See below for mapping details.

Note:

• Prior to Order Broker 15.0, the Default Unfulfillable Location is labeled the Default Shipping Location at the Preferences screen.

• If there is already a Store Cross Reference record for a location specified in the response message, the function does not update it.

• If the first position of the Parameter is not Y or y, the Store Cross Reference records are created with the Ship for pickup flag unselected.

• If a valid system in Order Orchestration is not specified by positions 2-11 of the Parameter, Order Orchestration does not return any locations in the response, and no Store Cross Reference records are created.

• All characters are converted to uppercase when creating the Store Cross Reference records.

• If the information passed for a field from Order Orchestration exceeds the length of the corresponding field in Order Administration, it is truncated.

• Only the fields listed below are mapped. For example, the apartment or suite, if any, for the location is not mapped from Order Orchestration to Order Administration.

• Order Orchestration does not log the discovery web service messages; however, Order Administration logs the activity in the OROB (Oracle Retail Order Orchestration) Log.

• The function does not validate the data passed, such as city, state, or postal code, when creating new records.

For more information: See:

• the Order Orchestration Web Services Guide https://support.oracle.com (ID 2953017.1) for details on the discovery web services.

• Working with Periodic Functions (WPER) and Working with Periodic Processes (WPPR) for information on setting up and running the periodic function.

• Work with Store Cross Reference (WSCR) for information on working with Store Cross References and on how they are used.

Location data mapping: The table below describes how the function maps the data from the web service response when creating Store Cross Reference records.

From OROB	Store Cross Reference Record	Comments
N/A	Company code	From the Company specified when executing the periodic process.
location code	Store #
Name	Description
N/A	Ship for Pickup	From the first position of the Parameter specified for the periodic function; see above.
Address lines 1-4	Address lines 1-4	Truncated if they exceed 32 positions.
City	City
State or province	State	Truncated if it exceeds 2 positions.
Postal code	Postal code
Country code	Country code
Telephone number	Telephone number	Truncated if it exceeds 14 positions.
N/A	Active	Selected (set to Y).

Stored Value Card Integration

Topics in this part: The following topics describe the functions available for stored value card integration.

• Stored Value Card Overview and Setup provides an overview of stored value card processing and required setup.

• Stored Value Card Purchase and Activation describes the processing that occurs when a stored value card is purchased and activated.

• Working with Physical Stored Value Card Assignment (WPSA) describes how to assign a number to a physical stored value card.

• Stored Value Card Balance Inquiry (MSVB) describes the processing that occurs when you perform a stored value card balance inquiry.

• Stored Value Card Authorization Reversal describes the processing that occurs when you reimburse a stored value card payment a cancellation or deactivation amount.

• Transmitting Activation and Reversal Transactions (SSVC) describes how to process stored value card download triggers and generate stored value card XML messages to send to the service bureau for processing.

• Generating Stored Value Card Refunds describes how to generate a new stored value card to send to the sold to customer when you process a stored value card credit.

• Customer Engagement Stored Value Card Integration describes the integration between Order Administration and the Oracle Retail Customer Engagement stored value card system.

Stored Value Card Overview and Setup

Overview: Stored value cards are gift cards assigned a pre-paid dollar amount that you can purchase and use as a form of payment. There are two types of stored value cards available in Order Administration: physical cards you ship to the recipient card holder and virtual cards you email to the recipient card holder.

In this topic:

• Stored Value Card Overview

• Stored Value Card Setup

  • Creating a Stored Value Card Item

  • System Control Values

  • Periodic Function

  • Menu Options

  • Virtual Card Number Table (FLSVCA)

  • Creating a Stored Value Card Pay Type

  • Notify Properties

For more information:

• Stored Value Card Purchase and Activation: provides information on purchasing and activating a physical or virtual stored value card.

• Working with Physical Stored Value Card Assignment (WPSA): provides information on assigning a number to a physical stored value card.

• Stored Value Card Balance Inquiry (MSVB): provides information on inquiring on the remaining balance of a stored value card.

• Stored Value Card Authorization Reversal: provides information on reimbursing a stored value card when you process a cancellation or deactivate the card and an open, unused authorization exists.

• Transmitting Activation and Reversal Transactions (SSVC): provides information on processing stored value card download triggers to generate activation and authorization reversal messages to send to the service bureau for processing.

• Generating Stored Value Card Refunds: provides information on generating a new stored value card for a refund amount.

• Customer Engagement Stored Value Card Integration: provides information on the integration between Order Administration and the Oracle Retail Customer Engagement stored value card system.

Stored Value Card Overview

In Order Administration:

• You can create an item identified as a physical or virtual stored value card.

  • Physical stored value cards are cards that you can stock in a warehouse or retail location. Physical cards are reserved on an order based on available inventory and printed on a separate pick slip from the other items on the order. Once the card is activated, the system delivers the physical card to the recipient card holder on the order.

  • Virtual stored value cards are cards that you do not stock. Virtual cards are automatically reserved on an order and express-billed during pick slip generation. Once the card is activated, an email is sent to the recipient card holder on the order, notifying the customer that a stored value card has been purchased and providing the stored value card number and dollar amount to use as a form of payment.

• Customers can purchase the stored value card item on an order; see Stored Value Card Purchase and Activation.

• Once you generate a pick slip for the order, you must assign a number to the physical stored value card before the card is shipped to the customer. The system automatically assigns a number to virtual stored value cards during pick slip generation.

• Once the stored value card is billed, the card is sent to the service bureau for activation.

• Once activated, the card is delivered to the recipient card holder on the order.

• The customer can then use the stored value card as a form of payment on an order.

• The service bureau authorizes and deposits the amount assigned to the stored value card payment.

• The customer can inquire on the remaining balance on the stored value card; see Stored Value Card Balance Inquiry (MSVB).

• In addition:

  • If the customer cancels an order or order line that is paid for by a stored value card payment with an open authorization or deactivates the stored value card payment, the system generates a stored value card authorization reversal to reimburse the stored value card the original authorization amount; see Stored Value Card Authorization Reversal.

  • If the customer returns a line that is paid for by a stored value card payment, the system generates a refund credit against the stored value card. When you deposit a refund credit against a stored value card, the service bureau sends back a new authorization number with the deposit response; because of this, the system creates a new authorization for the credit amount that is already updated to a deposit status. At this point, the credit amount is reimbursed to the stored value card.

  • You can define a stored value card credit as an alternate refund type; when you process stored value card credits, the system issues a new stored value card to the sold to customer for the refund amount; see Generating Stored Value Card Refunds.

Stored value card process flow

Stored Value Card Setup

Purpose: Before you can use stored value cards, you must perform the necessary setup.

Required setup includes:

• Creating a Stored Value Card Item

• System Control Values

• Periodic Function

• Menu Options

• Virtual Card Number Table (FLSVCA)

• Creating a Stored Value Card Pay Type

• Notify Properties

Creating a Stored Value Card Item

There are two types of stored value cards in Order Administration:

Physical stored value cards are physical cards that you can stock in a warehouse or retail location. Physical stored value cards are reserved on an order based on available inventory and printed on a separate pick slip from the other items on the order. You must assign a number to the physical card before the card can be billed. Once the card receives an approved activation from the service bureau, the system delivers the physical card to the recipient card holder on the order. In addition, an email may be sent to the recipient card holder, notifying the customer that the physical card is in the process of being delivered.

Virtual stored value cards are virtual (non-physical) cards that you do not stock. Virtual stored value cards are automatically reserved on an order and express-billed during pick slip generation. During pick slip generation, the system also assigns a number to the virtual card. Once the card receives an approved activation from the service bureau, an email is sent to the recipient card holder on the order, notifying the customer that a stored value card has been purchased and providing the stored value card number and dollar amount to use as a form of payment.

The SVC type field at the item level indicates if the stored value card is a physical or virtual card:

• Physical Card indicates the stored value card is a physical card.

• Physical Card/Early Notify indicates the stored value card is a physical card and, as soon as the stored value card is activated, the system sends an email notification to the recipient card holder on the order, notifying the customer that a stored value card has been purchased and is in the process of being delivered.

• Virtual Card indicates the stored value card is a virtual (non-physical) card. Virtual cards automatically reserve when added to an order and are express-billed during pick slip generation, regardless of the Non-inventory flag. Once the stored value card is activated, the system sends an email notification to the recipient card holder on the order, notifying the customer that a stored value card has been purchased and the stored value card number to use when making a purchase.

Some things to note when creating a stored value card:

• The offer price is used as the pre-defined amount assigned to the stored value card if the Stored Value Card Activation Pricing Method (I25) system control value is set to OFFER. This is important to note if you create a stored value card as a SKU item and each SKU represents a different dollar amount; make sure you create a SKU offer for each SKU instead of using the item offer; otherwise each SKU of the stored value card will be assigned the dollar amount defined at the item offer level.

• It is recommended you create the stored value card as a regular SKU or non-SKU item. For example, do not create the stored value card as a membership item or with a kit type.

• You can create the stored value card item as an inventory or non-inventory item. If you wish to track how many cards are available for pre-defined denominations, you should create the stored value card as an inventory item.

• You cannot assign a specific group of numbers to a stored value card item. See Assigning a Stored Value Card Number.

Stored value card refund item: When you process stored value card refunds, the system adds a stored value card item to the order for the refund amount. You define the stored value card refund item in the Default SVC Refund Item Number (I73) system control value. This item must be a non-SKU item with the SVC type field set to P or E. See Generating Stored Value Card Refunds.

Stored Value Card example using non-SKU:

Item Level	Item Offer Level
Item #: SVCE25 SVC type: Physical Card/Early Notify	Price: $25.00
Item #: SVCE50 SVC type: Physical Card/Early Notify	Price: $50.00
Item #: SVCE75 SVC type: Physical Card/Early Notify	Price: $75.00

Stored Value Card example using SKU:

Item Level	SKU Level	SKU Offer Level
Item #: SVCV SVC type: V (virtual card)	SKU: 25	Price: $25.00
Item #: SVCV SVC type: V (virtual card)	SKU: 50	Price: $50.00
Item #: SVCV SVC type: V (virtual card)	SKU: 75	Price: $75.00

System Control Values

The Stored Value Card Processing Values (I71) umbrella system control value contains the following values to control how stored value cards are processed.

System Control Value	Description
Use Streamlined Stored Value Card Billing (I23)	Select this field if you wish the system to send pick control records containing physical stored value cards to billing once you assign numbers to the physical cards; this assumes you never send pick control records containing physical stored value cards to a manifesting station to wand and bill the stored value card items.
Stored Value Card Modulus Checking Method (I24)	Enter the type of modulus check, if any, you wish to perform against the stored value card number. If you enter a modulus check, you can validate the stored value card number before sending the card to the service bureau for activation.
Stored Value Card Activation Pricing Method (I25)	Enter the price the system will assign to the stored value card as the card’s issue amount. You can select the offer price or order detail line price.
Stored Value Card Activation Authorization Service (I26)	Enter the code for the service bureau used to process stored value card activation requests. If you use the Customer Engagement Stored Value Card Integration, you must enter RLT.
Stored Value Card Email Notification Program (I30)	Enter the name of the program the system uses to generate a Stored Value Card Notification Email. You can send an email notification to the recipient card holder for virtual stored value cards and physical stored value cards set up with email notification, or generate the Outbound Email XML Message (CWEmailOut). For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1). The base program name is SVCNOTF.
Use Activation / Reversal Batch Processing (I50)	Select this field if you wish to process stored value card activation and authorization reversal transactions in batch mode. When you activate a stored value card or process a stored value card authorization reversal, the system generates a stored value card download trigger record. If this system control value is selected, the system does not process the stored value card trigger records until you submit the batch process using the Transmitting Activation and Reversal Transactions (SSVC) menu option or a periodic function. In this situation, the SVC Activation and SVC Reversal integration layer jobs can remain inactive. If this system control value is unselected, when active, the SVC Activation and SVC Reversal integration layer jobs monitor for stored value card download trigger records to process immediately.
Default SVC Refund Item Number (I73)	Enter the stored value card item the system adds to an order when you process a stored value card refund. This item represents the new stored value card that is sent to the customer for the amount of the processed refund. The system adds this item to the order at no charge and defaults the Price Override Reason for SVC Refund Item (I74) to the order line.
Price Override Reason for SVC Refund Item (I74)	Enter the price override reason code the system defaults to the stored value card no charge order line that is added to an order when you process a stored value card refund.
Default Pick Generation Template for SVC Refund Processing (I75)	Enter the streamlined pick slip generation template (WSPS) the system uses to automatically generate a pick slip for the stored value card item that is added to an order when you process a stored value card refund.
Perform Balance Inquiry during Batch Authorizations (J19)	Select this field if you wish to perform a balance inquiry against a stored value card pay type before performing a batch authorization against the card. The system sends a balance inquiry request in batch format to the service bureau to determine the balance on the card. If the balance on the card is equal to or greater than the amount to authorize for the pay type on the order, the system continues with pick slip generation and sends a batch authorization request to the service bureau to authorize the card for the specified amount. If the balance on the card is less than the amount to authorize for the pay type on the order, and: the stored value card is the catch-all pay type on the order, the system places the order on hold, using the Hold Reason for Stored Value Cards with Insufficient Funds (J18) and does not generate a pick slip for the order. Note: If a hold reason code is not defined, a pick slip is not generated; however, the order remains in an open status. there is a different catch-all pay type on the order, such as a credit card, the system authorizes the stored value card for the remaining balance and authorizes the catch-all pay type for the remaining amount to authorize. See Batch Authorization Balance Inquiry for more information. If you are using the Customer Engagement Stored Value Card Integration, select this system control value. Oracle Retail Customer Engagement will approve an authorization for an amount that is less than the required authorization amount for an order. If you do not select this system control value, you must require another credit card payment on an order.
Hold Reason for Stored Value Cards with Insufficient Funds (J18)	Enter the hold reason code the system uses to place an order on hold when you Perform Balance Inquiry during Batch Authorizations (J19) and the balance remaining on a catch-all stored value card pay type is less than the amount to authorize.
Perform Authorization Reversal during Deposit Processing (J20)	Select this field if you wish to perform a stored value card authorization reversal during deposits processing if the authorization amount is greater than the deposit amount. Deselect this system control value if you are using the Customer Engagement Stored Value Card Integration.
Retain Unused Stored Value Card Authorization After Deposit (J21)	Select this field if you want the system to retain a stored value card authorization after it has been partially deposited. For example, if the authorization amount is 50.00 and the deposit amount is 40.00, the system retains the remaining 10.00 on the authorization. Leave this field unselected if you want the system to void the remaining balance against the authorization. For example, if the authorization amount is 50.00 and the deposit amount is 40.00, the system voids the remaining 10.00 on the authorization. If there are multiple authorizations for the order, the system does not void the other authorizations. Select this system control value if you are using the Customer Engagement Stored Value Card Integration.
Use Gift Card Fraud Checking (L72)	If selected, the system places an order on GC Gift Card order hold if it contains a stored value card item and a stored value card payment method.

Periodic Function

Periodic Function	Description
Stored Value Card Unactivated Report (program name PFR0075)	Create this periodic function to generate the Unactivated Stored Value Card Report. Use this report to review any stored value cards that require attention because: the stored value card was declined by the service bureau for activation the stored value card was billed at the manifest station without a number assignment
Process Stored Value Card Activations (program name PFR0076)	Create this periodic function to process stored value card activation trigger records that are in a ready (R) status.
Process Stored Value Card Reversals (program name PFR0077)	Create this periodic function to process stored value card authorization reversal trigger records that are in a ready (R) status.

Menu Options

Menu Option	Description
Working with Physical Stored Value Card Assignment (WPSA)	Allows you to assign a number to a physical stored value card. See Assigning Numbers to Physical Stored Value Cards for more information.
Working with Tickler Events (WTEV)	Activate the SV tickler event to generate a tickler when a stored value card item is billed without a number assignment. Activate the SD tickler event to generate a tickler when a stored value card activation request is declined by the service bureau. Note: To create ticklers, the Use Workflow Management (H96) system control value must be selected.
Working with Pay Types (WPAY)	Create a stored value card pay type. See Creating a Stored Value Card Pay Type for additional setup. Additionally, if you wish to always generate a stored value card refund for a particular pay type, enter a stored value card pay type as the alternate refund type.
Working with Integration Layer Processes (IJCT)	Stored Value Card Reversal: The SVC_REVRSL job creates a stored value card authorization reversal request for each unprocessed AHR download trigger in the IL Outbound Trigger table. If the Communication type field for the service bureau is Integration Layer, you must define: the outbound queue where messages are placed to send to the service bureau. the inbound queue that receives responses from the service bureau. Note: Order Administration is hard-coded to use the SVC_REVRSL job to process stored value card authorization reversals; you cannot create a new integration layer job with a different process name to process stored value card authorization reversals. Note: To avoid conflict, make sure you set up each integration layer process that sends messages to the external system with a unique queue so that the system can identify the different types of messages it is receiving.
Defining Authorization Services (WASV)	Create a service bureau for the service that you will use to process stored value cards.
Transmitting Activation and Reversal Transactions (SSVC)	Allows you to process stored value card download triggers and generate stored value card XML messages to send to the service bureau for processing.
Working with Refunds, Writeoffs and Balances Due (WREF)	Allows you to change a refund to a stored value card refund (refund type V) by entering a stored value card pay type in the Pay type field.
Order Entry/Maintenance Balance Inquiry	Allows you to inquire on the remaining amount available on a specified stored value card pay type and card number.

Virtual Card Number Table (FLSVCA)

Use this table to automatically assign the next available number to a virtual stored value card during pick slip generation. Once the system assigns the number to a virtual stored value card, the number is removed from this table and the virtual stored value card is processed through billing.

Oracle Retail Customer Engagement stored value card integration: If you use the Customer Engagement Stored Value Card Integration, you do not need to populate this table; during pick slip generation for a virtual stored value card, Order Administration sends a Generate Card Request to Oracle Retail Customer Engagement and Oracle Retail Customer Engagement returns a Generate Card Response to Order Administration with the assigned virtual card number.

Note:

It is your responsibility to populate this table with stored value card numbers supplied by your service bureau. If this table does not contain an available number to assign to a virtual stored value card, the order for the stored value card will not be billed and the order will print on the Stored Value Card Assignment Errors Report.

Field	Description
Company	The company where the virtual stored value cards are processed.
Card #	A number to assign to a virtual stored value card, provided by the service bureau.
ID #	An ID number to assign to a virtual stored value card, provided by the service bureau. Note: Define an ID number only if your stored value card processor supports it.

Virtual card numbers threshold: You can define a threshold for the system to notify you when the number of records in the Virtual Card Number table is below a specified number. When the actual number of records in the Virtual Card Number table falls below the threshold value, the system sends an email notification to the specified email address, providing you time to add records to this table before all of the virtual stored value card numbers are used.

If you do not already have the Virtual Card Number threshold created, the system automatically creates the threshold when you run the Batch Order Control job; however, you still need to define the threshold criteria; see Updating Threshold Actual Values.

Example: The threshold number you define is 25 with a less than comparison (the actual value must be less than the threshold value you define). Once the actual number of available virtual card number records is 24, the system sends an email to the specified email address.

Threshold Code and Description	Comparison	Number Value	Actual Number	Email address
VC: Virtual card numbers	L (actual value is less than the threshold value)	25	24	[e-mail]

Sample email: A sample Threshold Monitor Breach email is displayed below.

From: [e-mail]

To: [e-mail]

Subject: **ALERT** Threshold Monitor Breach

Virtual Card Numbers threshold exceeded.

Add numbers to the Virtual Card Number file (FLSVCA)

Co#:  555  Actual$:  000000024  > Thresh$: 000000025

Review screens and reports to monitor this breach.

For more information: See Working with Threshold Values (WTHR) for more information on defining threshold values.

Creating a Stored Value Card Pay Type

When creating a stored value card pay type in Working with Pay Types (WPAY), you must define the following information:

• Pay category: enter Credit Card as the pay category.

• Card type: enter Stored Value as the card type.

• Authorization service: enter the authorization service that you will you to process stored value cards.

• Deposit service: enter the deposit service that you will use to process stored value cards.

• Reauthorization days: Enter the number of days before a stored value card authorization is set to expire. Enter 999 if you use the Customer Engagement Stored Value Card Integration.

• Modulus check: enter a modulus check to verify the stored value card number is valid before sending the card to the service bureau for authorization.

In addition to creating a stored value card pay type:

• Enter the stored value card pay type in the Alternate refund type field for each pay type for which you always wish to generate a stored value card refund.

• Create a credit card number format if you do not want the full stored value card number to display on Order Administration screens and reports.

Notify Properties

In order to respond to Order Administration jobs that may require user intervention to proceed, you must set up the notify properties in Working with Admin Properties (CPRP).

Why would a job require user intervention?

• An error occurred during processing

• The job is used to send transactions to another system and communication failures occur before the transmission completes

Which types of job require user intervention?

• Stored Value Card (activation, balance inquiry or authorization reversal) integration layer job

• Authorization (batch only, for all card types) integration layer job

• Deposit integration layer job

Property Name	Description
RESPONSE_RETRIES	The number of times Order Administration looks for a response to a job that requires user intervention before using the default response in order to proceed with the job. For example, if this setting is 5, Order Administration will look for a user response five times, waiting 60 seconds between each time.
RESPONSE_EMAILS	The list of email addresses that receive the Response Required email when a job requires user intervention. Each email address entered must be separated by a semi-colon (;). For example: [e-mail];[e-mail].

For more information: See Working with Required Responses (WREQ) for more information on the steps performed when a job requires user intervention.

Stored Value Card Purchase and Activation

Purpose: You can purchase a stored value card item on an order to deliver to the recipient card holder by mail or email. However, before the recipient card holder can use the stored value card as a form of payment, the card must be activated by the service bureau.

Activation processing: To activate a stored value card:

#	Step
1.	A customer purchases a stored value card item on an order. If the stored value card is a virtual card, the system verifies that an email address is defined for the recipient card holder. See Purchasing a Stored Value Card.
2.	During pick slip preparation, the system creates a separate pre-generated pick for each physical stored value card. After the picks are printed, you must: Use Working with Physical Stored Value Card Assignment (WPSA) to assign a number to physical stored value cards by pick control number, OR If you use an external system to assign numbers to physical cards, receive the card number in the CWPickIn XML Message. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1). See Assigning Numbers to Physical Stored Value Cards for additional details. For virtual stored value cards, during pick slip generation the system: Assigns a number to the card from the Virtual Card Number Table (FLSVCA), OR If you are using the Customer Engagement Stored Value Card Integration, assigns a number to the card by sending a Customer Engagement Generate Card Request to the Oracle Retail Customer Engagement system. See Assigning Numbers to Virtual Stored Value Cards.
3.	Once the stored value card is billed (see Billing a Stored Value Card), the system generates an SVC download trigger containing the information required to activate the card.
4.	The system sends a stored value card activation request to the service bureau for activation. If the Use Activation / Reversal Batch Processing (I50) system control value is selected, the system does not process the SVC download trigger until you submit the batch process from the Transmitting Activation and Reversal Transactions (SSVC) menu option. In this situation, the SVC Activation integration layer job can remain inactive. If the Use Activation / Reversal Batch Processing (I50) system control value is unselected, when active, the SVC Activation integration layer job monitors for SVC download trigger records to process immediately. See Activating a Stored Value Card.
5.	Once an approved stored value card activation is received from the service bureau, the system updates the stored value card and sends a Stored Value Card Notification Email to the customer, if defined, indicating the stored value card activation information.

Stored Value Card Activation Process:

In this topic:

• Purchasing a Stored Value Card

  • Stored Value Card Email Hierarchy

• Assigning a Stored Value Card Number

  • Assigning Numbers to Physical Stored Value Cards

  • Pick Stored Value Card Table

  • Assigning Numbers to Virtual Stored Value Cards

• Billing a Stored Value Card

  • Stored Value Card Table

• Activating a Stored Value Card

  • Identifying SVC Download Triggers

  • Generating the Stored Value Card Activation Request

  • What Happens When the Stored Value Card Activation is Approved?

  • Stored Value Card Notification Email

  • What Happens When the Stored Value Card Activation is Declined?

• Reviewing Stored Value Card Activation Status

  • Display Stored Value Cards Screen

Purchasing a Stored Value Card

You purchase a stored value card as you would any item.

Physical stored value cards: When you purchase a physical stored value card (SVC type Physical Card or Physical Card/Early Notify), the system:

• Reserves the item on the order, based on available inventory.

• Does not require an email address, even if the stored value card is eligible for email notification. If you ordered a physical stored value card (with email notification) and an email address is not defined, the system still allows you to accept the order; however, the Stored Value Card Notification Email is not sent.

Note:

You can create a custom special handling template to capture stored value card information, such as the gift giver’s name, recipient’ name, and any gift message.

Virtual stored value cards: When you purchase a virtual stored value card (SVC type Virtual Card), the system:

• Automatically reserves the item on the order and express bills the item during pick slip generation.

• Requires an email address to send the Stored Value Card Notification Email to the recipient card holder. An email address is required because the email notification is the only way the recipient of the virtual stored value card will receive the stored value card number associated with the order. If you order a virtual stored value card item and an email address is not defined or the opt in/out value is invalid, the system displays an error and does not allow you to accept the order: Invalid e-mail address/opt in for order containing virtual SVC item. A similar error also displays when you process a web order. See Stored Value Card Email Hierarchy.

For more information: See Assigning a Stored Value Card Number for more information on how to assign a number to a stored value card.

Gift card hold: If the Use Gift Card Fraud Checking (L72) system control value is selected, the system places an order on GC Gift Card order hold if it contains a stored value card item and a stored value card payment method.

Stored Value Card Email Hierarchy

When a stored value card is activated and an email address is defined, the system sends a Stored Value Card Notification Email to the recipient of the stored value card.

The system uses the following hierarchy to determine the email address used to send a Stored Value Card Notification email to the recipient card holder. This email validation occurs in order entry and maintenance and during the generic order interface edit.

1.   Send to ship to email address: Send the email to the email address defined for the ship to on the order.

• Order ship to: Send the email to the email address defined for the order ship to. The system requires an email address for the order ship to if a stored value card item exists on the order: Invalid email address/opt in for order containing virtual SVC item.

• Customer ship to: If an order ship to does not exist, send the email to the email address defined for the customer ship to. The system requires an email address for the customer ship to if a stored value card item exists on the order. In addition, the Opt in/opt out setting must allow for email delivery (codes O1 or O2): Invalid email address/opt in for order containing virtual SVC item.

• Recipient (Sold To/Recipient): If an order ship to or customer ship to does not exist, send the email to the email address defined for the recipient customer. The system requires an email address for the recipient if a stored value card item exists on the order. In addition, the Opt in/opt out setting must allow for email delivery (codes O1 or O2): Invalid email address/opt in for order containing virtual SVC item.

2.   Send to customer sold to email address: If a ship to does not exist on the order, send the email to the email address defined for the customer sold to. The system requires an email address for the customer sold to if a stored value card item exists on the order. In addition, the Opt in/opt out setting must allow for email delivery (codes O1 or O2): Invalid email address/opt in for order containing virtual SVC item.

Note:

If the email address or opt in/opt out value changes after the order has been accepted and before the stored value card is activated, it is possible that a Stored Value Card Notification Email may not be generated.

Assigning a Stored Value Card Number

Before you can activate a stored value card, you must first assign a number to the card. Assigning a number to a stored value card occurs during or after pick slip generation, depending on if the stored value card is a physical or virtual card.

• Assigning Numbers to Physical Stored Value Cards

• Assigning Numbers to Virtual Stored Value Cards

Assigning Numbers to Physical Stored Value Cards

Follow these steps to assign a number to a physical stored value card (SVC type Physical Card or Physical Card/Early Notify):

1.   Generate a pick slip for the order containing the physical stored value card.

When you generate a pick slip for an order containing a physical stored value card, the system:

• prints a separate pick slip for each order line containing a physical stored value card. However, if you wish to print a separate pick slip for each unit of the stored value card item, set up the item as ship alone (Ship alone = Ship Alone).

• creates a record in the Pick Stored Value Card Table for each unit of the stored value card item printed.

• includes the stored value card item on the Pick Unit Report.

Pick Stored Value Card Table

This table contains a record for each physical stored value card item purchased whose pick control number has not yet been confirmed. Once you confirm the pick control number, the system deletes the stored value card record from this table. The system also uses this table to validate that a number has been assigned to the physical card before the card is shipped and confirmed.

Field	Description
Company	The company where you created the pre-generated pick containing the stored value card item.
PCH control #	The pick control number assigned to the pick containing the stored value card item.
Line #	The pick control line number containing the stored value card item.
Seq#	The pick stored value card sequence number.
Card Number	The number assigned to the stored value card. This field is blank when the record is created during pick slip preparation; you use the Working with Physical Stored Value Card Assignment (WPSA) menu option or the svc_card_nbr in the CWPickIn XML Message to assign a number to the physical stored value card after pick slip generation. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

If you void or reprint the pick slip: The system updates the Pick Stored Value Card table if you use the Reprinting and Voiding Pick Slips (WVRP or WSVP) menu option to void or reprint a pick slip and the pick control number containing the physical stored value card item has not yet been billed.

In WVRP when you:	The system:
Decrease the quantity allocated	Deletes the last pick stored value card record(s) created for the order line.
Void the pick slip	Deletes the associated pick stored value card records.
Reprint the pick slip	Deletes the associated pick stored value card records referencing the old pick control number and creates new pick stored value card records for the new pick control number.
Void and unreserve the pick slip	Deletes the associated pick stored value card records.

2.   Assign a number to the physical stored value card.

• Use Working with Physical Stored Value Card Assignment (WPSA) to assign a number to a physical stored value card by pick control number, OR

• Use the svc_card_nbr tag in the CWPickIn XML Message to receive a card assignment from an external system.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

3.   Bill the pick control number containing the stored value card item.

The Use Streamlined Stored Value Card Billing (I23) system control value determines when the physical stored value card is sent to billing.

• If this system control value is selected, the system sends the pick control number assigned to the stored value card to billing immediately after you assign a number to the card.

• If this system control value is unselected, the system sends the pick control number assigned to the stored value card to billing after you wand and bill the card at the manifesting station.

If you use the Manually Confirming Shipments (MCON) menu option to confirm a pick control number containing a stored value card item, the system verifies that the stored value card is assigned a number. If the stored value card is not assigned a number, the system does not allow you to confirm the pick control number or change the status of the pick slip to carryover and instead displays an error message: All stored value card numbers must be entered before accepting.

For more information: See Billing a Stored Value Card for more information on the processing the system performs when you bill a stored value card.

Assigning Numbers to Virtual Stored Value Cards

To assign a number to a virtual stored value card (SVC type V), generate a pick slip for the order containing the virtual stored value card.

When you generate a pick slip for an order containing a virtual stored value card, the system:

• automatically assigns a stored value card number to the virtual card, using the next available number from the Virtual Card Number Table (FLSVCA) and deletes the record from the Virtual Card Number table.

Note:

Make sure a number is available in the Virtual Card Number table to assign to the virtual stored value card; if a number is not available to assign to the card, the entire order line containing the stored value card item will not be billed and the order will print on the Stored Value Card Assignment Errors Report.

• express bills the item and sends the pick control number containing the virtual stored value card to billing.

• does not include the stored value card item on the Pick Unit Report.

Oracle Retail Customer Engagement Stored Value Card integration: If you are using the Customer Engagement Stored Value Card Integration, the system does not assign a number to a virtual card from the Virtual Card Number table. Instead, the system:

• generates a Customer Engagement Generate Card Request and sends the message to Oracle Retail Customer Engagement.

• receives the Customer Engagement Generate Card Response from Oracle Retail Customer Engagement, containing the assigned card number.

• express bills the item and sends the pick control number containing the virtual stored value card to billing.

• does not include the stored value card item on the Pick Unit Report.

For more information: See Billing a Stored Value Card for more information on the processing the system performs when you bill a stored value card.

Billing a Stored Value Card

When a pick control record containing a stored value card item is billed, the system:

1.   Deletes the associated record in the Pick Stored Value Card Table, if the stored value card is a physical card.

2.   Determines the issue amount to apply to the stored value card.

The  system control value determines the price the system uses as the amount to apply to the stored value card.

• Stored Value Card Activation Pricing Method (I25)

• If this system control value is set to OFFER, the stored value card amount is the offer price. If the offer price is $0.00, the system uses the order line price.

• If this system control value is set to ORDER or blank, the stored value card amount is the order line price. If the order line price is $0.00, the system uses the offer price.

If both the offer price and order line price are $0.00, the stored value card amount is $0.00.

3.   Creates a record in the Stored Value Card Table for each unit of the stored value card item.

Stored Value Card Table

This table contains a record for each stored value card item that has been billed.

Once you receive an approved activation response from the service bureau, the system updates this table with the activation information. You can review the stored value card at the Display Stored Value Cards Screen.

Additionally, when you purge an order, the system deletes any associated records in this table.

Field	Description
Company	The company where you processed the stored value card.
Order #	The order number where the stored value card was purchased.
Ship to #	The ship to number receiving the stored value card.
Seq #	The order line sequence number.
Seq #	The stored value card sequence number.
Card #	The stored value card number. If the Remove Stored Value Card Number After Activation (J22) system control value is selected, the words REMOVED BY SYSTEM display instead of the credit card number.
Card type	The type of stored value card. P = Physical card E = Physical card with email notification V = Virtual card
Issue date	The date the stored value card was billed.
Issue amount	The amount assigned to the stored value card.
Activation date	The date the stored value card was activated; this is the date the system received and processed the approved stored value card activation response.
Activation time	The time the stored value card was activated; this is the time the system received and processed the stored value card activation response.
Email sent date	The date a Stored Value Card Notification Email was sent to the customer. The system sends an email when an approved activation response is received from the service bureau.
Auth service	The service bureau where the stored value card was sent for activation.
Response code	The activation response received from the service bureau. The system does not update this field until the system receives a stored value card activation response from the service bureau.
ID #	The ID number assigned to the stored value card.

4.   Creates an SV tickler, if you Use Workflow Management (H96), for each stored value card item that was processed through billing without a number assignment.

A stored value card may be billed without a number assignment if you send the physical stored value card to the manifesting station without first using the Working with Physical Stored Value Card Assignment (WPSA) menu option to assign a number to the card. The system will not create a SVC download trigger for the stored value card until the card is assigned a number.

See SV (SVC Number Assignment) Event Processing for more information on how to resolve this tickler.

5.   Creates an SVC download trigger in the Outbound Interface Transaction table for each stored value card that has been billed and is assigned a stored value card number.

You can review download triggers in the Working with Outbound Interface Transactions (WOIT) menu option. See Identifying SVC Download Triggers.

For more information: See Activating a Stored Value Card for more information on processing the SVC download triggers.

Activating a Stored Value Card

The system creates an SVC download trigger in the IL Outbound Trigger table when a stored value card item is billed (see Billing a Stored Value Card).

Identifying SVC Download Triggers

You can view all download triggers in the IL Outbound Trigger table at the Work with Outbound Interface Transactions Screen.

Each SVC download trigger in the IL Outbound Trigger table contains a:

• File code: indicating the type of information to download and which IL process job processes the trigger. For SVC download triggers, the File code is SVC.

• Key: indicating the specific record to download. For SVC download triggers, the Key identifies the specific company, order number, ship to number, order detail sequence number, and stored value card sequence number associated with the SVC download trigger. For example, the Key 555000066760010000100004 indicates the stored value card information is located in company 555 for order number 6676, ship to number 1, order detail sequence number 1, and stored value card number 4.

• Capture type: indicating the type of activity performed against the record. SVC download triggers are always capture type A indicating the stored value card was created.

SVC download triggers in a ready status are processed by the SVC_OUT integration layer job.

File code	Refers to table	Key	IL Process job
SVC	Stored Value Card	111222222223334444455555 where: 111 is the company code 22222222 is the order number 333 is the ship to number 44444 is the order detail line sequence number 55555 is the stored value card sequence number	SVC_OUT

Generating the Stored Value Card Activation Request

To generate a stored value card activation request, the system:

#	Step
1.	Creates an SVC download trigger when an order containing a stored value card item assigned a number is billed; see Identifying SVC Download Triggers.
2.	Looks for unprocessed SVC download triggers to process, based on the setting of the Use Activation / Reversal Batch Processing (I50) system control value. If this system control value is selected, the system does not process the stored value card trigger records until you submit the batch process using the Transmitting Activation and Reversal Transactions (SSVC) menu option or the SVCACT periodic function (program name PFR0076). In this situation, the SVC Activation integration layer job can remain inactive.  If this system control value is unselected, when active, the SVC Activation integration layer job monitors for stored value card download trigger records to process at defined intervals, based on the Outbound delay time. The system: looks for SVC download triggers with the File code SVC and a status of ready (R). determines which stored value card activation to download, based on the Key field for the activation download trigger. looks for a record in the Stored Value Card Table that contains this information.
3.	Looks at the Stored Value Card Activation Authorization Service (I26) system control value to determine the service bureau used to activate stored value cards.
4.	Looks at the Communication type field for the service bureau to determine how transactions are processed between Order Administration and the service bureau. Integration Layer = The system sends activation transactions to the service bureau using the queues defined for the activation integration layer job. Payment Link = Point-to-point integration. The system sends activation transactions to the service bureau using a point-to-point integration. You must define communication settings in Working with Customer Properties (PROP). The system does not use the activation integration layer job to communicate with the service bureau; however, the system uses the job to process activation triggers. See Process Activations Using Payment Link Communication: Process Activations Using Payment Link Communication If the Communication type field for the service bureau is Payment Link: Order Administration uses the settings in Working with Customer Properties (PROP) to send the activation request directly to the service bureau in the format of the other system. The service bureau receives the activation request, processes the activation, and sends a response back to Order Administration.
5.	Order Administration processes the activation response accordingly. See: What Happens When the Stored Value Card Activation is Approved? What Happens When the Stored Value Card Activation is Declined?

What Happens When the Stored Value Card Activation is Approved?

A stored value card receives an approved activation if the activation response contains an authorization number. In this case, the system:

• updates the associated record in the Integration Process Control table to CMP complete (if the Communication type field for the service bureau is Integration Layer).

• updates the associated record in the Stored Value Card Table with the activation date, activation time, and activation response.

• generates a Stored Value Card Notification Email and sends the email to the recipient card holder.

You can review the activated stored value card at the Display Stored Value Cards Screen. The activated stored value card number will have an Activation date, time, and response. Additionally, if a Stored Value Card Notification Email was sent, the Email sent field will display the date the email was sent to the customer.

Note:

If you receive a declined stored value card activation response after you have already received an approved response, the system does not deactivate the stored value card; the card remains activated and available to use as payment.

If a customer returns a stored value card or reports the card stolen: If a customer returns a stored value card or reports the card stolen, you must call the service bureau to deactivate the card.

Stored Value Card Notification Email

The system sends a Stored Value Card Notification email or XML message to the recipient card holder when the SVC_OUT job processes an approved stored value card activation request and:

• The SVC type field for the stored value card item is E (physical card with notification) or V (virtual card).

• An email is defined for the recipient card holder. The system uses the Stored Value Card Email Hierarchy to determine the email address used to send a Stored Value Card Notification email to the stored value card recipient.

• The Stored Value Card Email Notification Program (I30) system control value specifies a valid program name.

A separate email is sent for each unit of a stored value card item ordered. For example, if a customer purchases a stored value card for a quantity of 2 to send to a recipient customer, the recipient card holder receives 2 stored value card emails.

Order history message: The system writes an order transaction history message, indicating a stored value card notification was sent to the stored value card recipient customer: SVC Notice to [e-mail].

For more information: See Working with E-Mail Notification Templates (WEMT) for more information on how the system generates email notifications, and see Stored Value Card Notification Sample and Contents for a sample email message. Also, see the Outbound Email API for information on when the system generates the Outbound Email XML Message (CWEmailOut) instead of an email, and the XML message layout.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

What Happens When the Stored Value Card Activation is Declined?

A stored value card receives a declined activation if the activation response does not contain an authorization number. In this case, the system:

• updates the associated record in the Integration Process Control table to FLD error (if the Communication type field for the service bureau is Integration Layer).

• creates a SD tickler if you Use Workflow Management (H96), indicating the stored value card activation request was declined. See SD (SVC Activation Decline) Event Processing for more information on how to resolve this tickler.

• includes the order containing the declined stored value card on the Unactivated Stored Value Card Report. This report prints when you run the Unactivated Stored Value Cards periodic function (program name PFR0075).

• does not send a Stored Value Card Notification Email to the customer, since the stored value card was not activated.

You can review the declined stored value card at the Display Stored Value Cards Screen. The declined stored value card number will have an Activation response, but a blank Activation date and time.

To activate a declined stored value card: You must call the service bureau to activate the card. You cannot re-send an activation request to the service bureau.

Reviewing Stored Value Card Activation Status

In standard Order Inquiry, you can review the stored value cards purchased on an order at the Display Stored Value Cards screen. This screen is also helpful if the customer purchased a virtual stored value card and forgot the number to use when making a purchase.

Note:

This screen is not available until the stored value card item has been assigned a number and processed through billing.

Display Stored Value Cards Screen

This screen indicates:

• the type of stored value card purchased

• the issue amount applied to the stored value card

• the card number

• the date the card was processed through billing

• the date and time the card was activated and the response received (if the card received a declined activation response, the system updates the Response field but does not update the Activation date and time)

• the date a Stored Value Card Notification Email was sent to the customer

If the Remove Stored Value Card Number After Activation (J22) system control value is selected, the words REMOVED BY SYSTEM display instead of the credit card number.

How to display this screen: At the standard Order Inquiry detail screen, select SVC for an order line containing a stored value card that has been billed.

Field	Description
Order#	The order number and ship to number where the stored value card item was purchased. Order#: Numeric, 8 positions; display-only. Ship to#: Numeric, 3 positions; display-only.
Line#	The order line number containing the stored value card item. Numeric, 3 positions; display-only.
Card type	Indicates the type of stored value card purchased. Physical card Physical card with email notification Virtual card Alphanumeric, 1 position; display-only.
Issue amount	The initial amount applied to the stored value card. This amount does not reflect the remaining balance on the card, if the card has already been used as payment for a purchase. Numeric, 13 positions with a 2-place decimal; display-only.
Card#	The number assigned to the stored value card. If the Remove Stored Value Card Number After Activation (J22) system control value is selected, the words REMOVED BY SYSTEM display instead of the credit card number. Alphanumeric, 20 positions; display-only.
Issue date	The date the stor ed value card was processed through billing. Numeric, 6 positions (user date format); display-only.
Activation date	The date the stored value card was activated; this is the date the SVC_OUT process received and processed the approved stored value card activation response. Numeric, 6 positions (user date format); display-only.
Activation time	The time the stored value card was activated; this is the time the SVC_OUT process received and processed the stored value card activation response. Numeric, 6 positions (user date format); display-only.
Activation response	The activation response received from the service bureau. Alphanumeric, 10 positions; display-only.
Email sent	The date a Stored Value Card Notification Email was sent to the customer. The system sends an email when an approved activation response is received from the service bureau. Numeric, 6 positions (user date format); display-only.

Stored Value Card Authorization Reversal

Overview: When you process a cancellation associated with a stored value card payment or deactivate a stored value card payment, the system reimburses the original authorization amount to the stored value card.

In addition, if the Perform Authorization Reversal during Deposit Processing (J20) system control value is selected, when you process deposits and the deposit amount is less than the original authorization amount, the system reimburses the stored value card the difference; see Authorization Reversal Process During Deposits.

In this topic:

• Stored Value Card Authorization Reversal Process

  • What Happens When the Authorization Reversal is Approved?

  • What Happens When the Authorization Reversal is Declined?

• Authorization Reversal Process During Deposits

Stored Value Card Authorization Reversal Process

Purpose: The system reimburses a stored value card the original authorization amount associated with the card when you process a cancellation associated with a stored value card payment or deactivate the stored value card.

Note:

If the Perform Authorization Reversal during Deposit Processing (J20) system control value is selected, when you process deposits and the deposit amount is less than the original authorization amount, the system reimburses the stored value card the difference; see Authorization Reversal Process During Deposits.

Stored Value Card Authorization Reversal Process:

#	Step
1.	You process a cancellation associated with a stored value card payment or deactivate the stored value card. You can process a cancellation by: Selecting Cancel for an order line or selecting Cancel to cancel the entire order in order maintenance. Selecting Void All/Cancel Order to void the pick slip and cancel the order at the Reprint/Void Pick Slips by Order Screen. Selecting Cancel Group to cancel a group of order lines based on the cancellation date or item in the Working with Backorders Pending Cancellation (WBPC) menu option. Processing soldout cancellations by submitting the job using the Processing Auto Soldout Cancellations (MASO) menu option or by selecting Sell Out for an order line in order maintenance. Submitting a job to cancel orders flagged for cancellation due to credit card decline using the Working with Credit Card Cancellations (WCCC) menu option. Submitting a job to cancel order lines for a given item and adding a substitute item to each order using the Processing Item Substitutions (PSUB) menu option. Cancelling an order line or order on the web storefront using the Maintenance E-Commerce Process. You can deactivate a stored value card payment by selecting Deactivate for a stored value card payment at the Enter Payment Method Screen.
2.	The system determines if the order is eligible for stored value card authorization reversal. For an order to be eligible for stored value card authorization reversal, the order must: contain a stored value card payment method that is associated with a cancellation or deactivation. Stored value card payments have a Pay category of Credit Card and a Card type of Stored Value. have an open, unused authorization remaining for the stored value card. An open, unused authorization is an authorization that is: in an A (authorized) or O (authorized, but not used) status not associated with an outstanding pick slip for the order not partially confirmed or deposited. Also, a reversal is not submitted when any lines on the order are submitted to Order Orchestration for fulfillment. Multiple payment methods: If the order contains one or more stored value card and/or credit card payments, the system performs authorization reversal for each eligible payment method. Authorizations in sent status: When you process a cancellation or deactivate a stored value card payment and the authorization is in an S (sent, but not received) status, the system does NOT create a SVC authorization reversal for the payment even if you later receive an approved authorization response. Expired authorizations: If the original authorization for an order is expired and the order received a new authorization during pick slip generation, the system will create an authorization reversal against the expired authorization when you process deposits. However, the service bureau will reject this authorization reversal since they have already expired the authorization and reimbursed the stored value card. Note: When the Send reversal flag is not selected for the authorization service, the system does not create an authorization reversal trigger record, described below, unless the reversal is created because the stored value card payment method is deactivated.

Example 1: The following transactions are applied against a stored value card payment on an order.

Order Activity	Result
You enter an order and pay for the order with a stored value card payment. The balance on the stored value card is 46.31. The order amount is 10.00. You send the stored value card for authorization using online authorization.	The system authorizes the stored value card for $10.00. The balance on the stored value card is 36.31.
You cancel the order in order maintenance.	The system creates a stored value card authorization reversal for $10.00. Once the authorization reversal is processed, the balance on the stored value card is updated to 46.31.

Example 2: The following transactions are applied against a stored value card payment on an order.

Order Activity	Result
You enter an order and pay for the order with a stored value card payment. The balance on the stored value card is 46.31. The order amount is 10.00. You send the stored value card for authorization using online authorization.	The system authorizes the stored value card for $10.00. The balance on the stored value card is 36.31.
You cancel an order line in order maintenance for 4.00.	The system creates a stored value card authorization reversal for $10.00. Once the authorization reversal is processed, the balance on the stored value card is updated to 46.31. The remaining items on the order will be resent to the service bureau for authorization during pick slip generation.

Example 3: The following transactions are applied against a stored value card payment on an order.

Order Activity	Result
You enter an order and pay for the order with a stored value card payment. The balance on the stored value card is 40.31. The order amount is 10.00. You send the stored value card for authorization using online authorization.	The system authorizes the stored value card for $10.00. The balance on the stored value card is 30.31.
You generate a pick slip for an order line on the order for 6.00.	The balance on the stored value card remains at 30.31.
You cancel the remaining order line in order maintenance for 4.00.	The system does not create an authorization reversal. The balance on the stored value card remains at 30.31.
You ship and bill the order line for 6.00.	The system updates the deposit amount for the authorization on the Authorization History Details screen to 6.00. The balance on the stored value card remains at 30.31.
You deposit the order line for 6.00.	The system creates a deposit record for 6.00 and updates the status of the authorization to voided. The balance on the stored value card is updated to 34.31.

#	Step
3.	The system creates an authorization reversal for the original authorization amount, not the actual amount of the reversal.
4.	The system creates a record in the Auth History SVC Reversal table for the authorization amount to reimburse.

Auth History SVC Reversal table:

Field	Description
Company	The company where you processed the stored value card authorization reversal.
Order #	The order number associated with the stored value card authorization reversal.
OPM Seq #	The order payment method sequence number associated with the stored value card payment.
AUH Seq #	The authorization history sequence number associated with the stored value card payment.
Seq#	The Auth History SVC Reversal sequence number.
Creation date	The date, in CYYMMDD format, the stored value card authorization reversal was created.
Creation time	The time, in HHMMSS format, the stored value card authorization reversal was created.
Approval date	The date, in CYYMMDD format, the stored value card authorization reversal was approved by the service bureau.
Approval time	The time, in HHMMSS format, the stored value card authorization reversal was approved by the service bureau.
Reversal amount	The amount to reimburse to the stored value card. In the case of PayPal, this is the original authorization amount.
Response	The response received from the service bureau, indicating if the authorization reversal was approved or declined.

#	Step
5.	The system creates an authorization reversal download trigger for the stored value card authorization reversal. You can view all download triggers in the IL Outbound Trigger table at the Work with Outbound Interface Transactions screen. Each authorization reversal download trigger in the IL Outbound Trigger table contains a: File code: indicating the type of information to download and which IL process job processes the trigger. For authorization reversal download triggers, the File code is AHR. Key: indicating the specific record to download. For AHR download triggers, the Key identifies the specific company, order number, order payment method sequence number, authorization sequence number, and authorization reversal sequence number in the SVC Authorization Reversal table. For example, the Key 55500006794001001001 indicates the authorization reversal information is located in company 555 for order number 6794, order payment method sequence number 001, authorization sequence number 001, and authorization reversal sequence number 001. Capture type: indicating the type of activity performed against the record. AHR download triggers are always capture type A indicating the authorization reversal was created.
6.	Looks at the Authorization service field defined for the stored value card payment to determine the service bureau used to process the authorization reversal. Note: When the Send reversal flag is not selected for the authorization service, the system does not create an authorization reversal trigger record unless the reversal is created because the stored value card payment method is deactivated.
7.	The system looks for unprocessed AHR download triggers to process, based on the setting of the Use Activation / Reversal Batch Processing (I50) system control value. If this system control value is selected, the system does not process the stored value card trigger records until you submit the batch process using the Transmitting Activation and Reversal Transactions (SSVC) menu option or the SVCREV periodic function (program name PFR0077). If this system control value is unselected, the SVC Activation and SVC Reversal integration layer jobs monitor for stored value card download trigger records to process at defined intervals, based on the Outbound delay time. The system: looks for AHR download triggers with the File code AHR and a status of ready (R). determines which stored value card authorization reversal to download, based on the Key field for the authorization reversal download trigger.
8.	For each authorization reversal download trigger, the system generates a Stored Value Card Authorization Reversal Request.
9.	The system looks at the Communication type field for the service bureau to determine how transactions are processed between Order Administration and the service bureau. Integration Layer = The system sends authorization reversal transactions to the service bureau using the queues defined for the authorization reversal integration layer job. Payment Link = Point-to-point integration. The system sends authorization reversal transactions to the service bureau using a point-to-point integration. You must define communication settings in Working with Customer Properties (PROP). The system does not use an integration layer job to communicate with the service bureau; however, the system uses the job to process authorization reversal triggers. Note: This option is available for the Customer Engagement Stored Value Card Integration. See Processing Authorization Reversals Using Payment Link Communication. Processing Authorization Reversals Using Payment Link Communication If the Communication type field for the service bureau is Payment Link: Order Administration sends the authorization reversal request in the format of the other system. If you are using the Customer Engagement Stored Value Card Integration, the system sends the Customer Engagement Release Auth Request to the Oracle Retail Customer Engagement system. The service bureau receives the Authorization Reversal Request, processes the authorization reversal, and sends a response back to Order Administration. If you are using the Customer Engagement Stored Value Card Integration, the system receives the authorization reversal response from Oracle Retail Customer Engagement in the Customer Engagement Release Auth Response message.
10.	Order Administration processes the authorization reversal response accordingly. See: What Happens When the Authorization Reversal is Approved? What Happens When the Authorization Reversal is Declined? When Communication Failures Occur Note: Stored value card authorization reversal responses contain a Response code and Response date, but may not contain an Authorization code. In this case, if the Response code is 100, the system updates the Authorization code with a dummy authorization number so that the authorization reversal is approved.

What Happens When the Authorization Reversal is Approved?

An authorization reversal is approved if the Authorization Reversal Response message contains an authorization number. In this case, the system:

• updates the associated record in the Integration Process Control table to CMP complete (if the Communication type field for the service bureau is Integration Layer).

• updates the associated record in the SVC Authorization Reversal table with the approval date, approval time, and reversal response.

• creates an order transaction history message indicating the authorization reversal was approved: Reversal Has Been Approved.

• voids the authorization history record.

Note:

If the stored value card authorization reversal response contains an amount, the system ignores the amount sent back and continues to use the amount from the Auth History SVC Reversal table.

You can review the stored value card authorization reversal at the Display Authorization Reversals Screen. The approved reversal will have a Response and an Approval date and time.

What Happens When the Authorization Reversal is Declined?

An authorization reversal receives a declined reversal if the Authorization Reversal Response Message does not contain an authorization number. In this case, the system creates an order transaction history message indicating the authorization reversal was declined: Reversal Has Been Rejected.

You can review the declined stored value card authorization reversal at the Display Authorization Reversals Screen. The declined reversal will have a blank Response, Approval date and time. You cannot resend a SVC authorization reversal request to the service bureau.

Note:

• Except for the order transaction history message, there is no other indication that the stored value card authorization reversal request was declined.

• Because the cancellation or deactivation amount was not reimbursed to the stored value card, the customer will not be able to use that amount on future purchases paid for against the stored value card.

• The response received from the service bureau does not display in the Response field on the Display Authorization Reversals Screen unless it is set up as a vendor response for the service bureau in Work with Authorization Services (WASV).

When Communication Failures Occur

Communication failures can occur if the SVC_REVRSL job is inactive, the connection between Order Administration and the service bureau is down, or the system times out before a response is received. If communication failures occur and you do not receive a response from the service bureau, the system:

• updates the associated record in the Integration Process Control table to FLD error (if the Communication type field for the service bureau is Integration Layer).

• does not update the associated record in the SVC Authorization Reversal table.

• does not create an order transaction history message.

You cannot resend a stored value card authorization reversal request to the service bureau.

Authorization Reversal Process During Deposits

Purpose: If the Perform Authorization Reversal during Deposit Processing (J20) system control value is selected, when you process deposits and the deposit amount is less than the original authorization amount, the system reimburses the stored value card the difference.

#	Step
1.	You process a deposit for an amount that is less than the original authorization amount.
2.	The system looks at the Communication type field for the service bureau to determine how transactions are processed between Order Administration and the service bureau. Integration Layer = The system sends authorization reversal transactions during deposits to the service bureau using the queues defined for an integration layer job. Payment Link = Point-to-point integration. The system sends authorization reversal transactions during deposits to the service bureau using a point-to-point integration. You must define communication settings in Working with Customer Properties (PROP). The system does not use the integration layer job to communicate with the service bureau; however, the system uses the job to process authorization reversal triggers. Note: This option is available for the Customer Engagement Stored Value Card Integration and this integration does not allow authorization reversals during deposits. See Process Authorization Reversals During Deposits using Payment Link Communication. Process Authorization Reversals During Deposits using Payment Link Communication If the Communication type field for the service bureau is Payment Link: Order Administration uses the settings in Working with Customer Properties (PROP) to send the deposit request directly to the service bureau in the format of the other system. The service bureau receives the deposit request, processes the deposit, and sends a response back to Order Administration.
3.	When a deposit response is received, Order Administration: compares the merchantReference value in the deposit response against the Alpha order # field in the CC Deposit Transaction table to match a received deposit with a sent deposit record. When a match is found, the system updates the Credit Card Deposit Transaction table with the values in the deposit response message. updates the status of the Integration Layer Process Control record to CMP complete (if the Communication type field for the service bureau is Integration Layer). updates the Credit Card Deposit History table. completes auto deposit processing.

Examples:

Original authorization amount is equal to deposit amount

Stored Value Card Activity	SCV J20 selected	SCV J20 unselected
Before placing an order, you inquire on the remaining balance for a stored value card. Stored value card balance:	53.49	53.49
You pay for the order using the stored value card as payment. The order total is 11.50. You authorize the stored value card and generate a pick slip for the order. Authorization amount:	11.50	11.50
After the stored value card is authorized, you inquire on the remaining balance for the stored value card. Stored value card balance:	41.99	41.99
You ship the order and bill the order. The invoice amount is 11.50. You process deposits. The deposit amount (11.50) equals the original authorization amount (11.50). Deposit amount:	11.50	11.50
Once the deposit is processed, you inquire on the remaining balance on the stored value card. Stored value card balance:	41.99	41.99

Original authorization amount is greater than deposit amount

Note:

The following example does not apply to PayPal reversals.

Stored Value Card Activity	SCV J20 selected	SCV J20 unselected
Before placing an order, you inquire on the remaining balance for a stored value card. Stored value card balance:	88.49	88.49
You pay for the order using the stored value card as payment. The order total is 11.50. You authorize the stored value card and generate a pick slip for the order. Authorization amount:	11.50	11.50
After the stored value card is authorized, you inquire on the remaining balance for the stored value card. Stored value card balance:	76.99	76.99
You void one of the items from the pick slip. You partial ship the remaining items on the pick slip and bill the order for the shipment amount. The invoice amount is 6.25. You process deposits. The original authorization amount is greater than the deposit amount. Deposit amount: Reversal amount:	6.25 5.25	6.25 blank
Once the deposit is processed, you inquire on the remaining balance on the stored value card. Stored value card balance:	82.24	76.99

Original authorization amount is less than deposit amount

Note:

The following example does not apply to PayPal reversals.

Stored Value Card Activity	SCV J20 selected	SCV J20 unselected
Before placing an order, you inquire on the remaining balance for a stored value card. Stored value card balance:	82.24	82.24
You pay for the order using the stored value card as payment. The order total is 11.50. You authorize the stored value card and generate a pick slip for the order. Authorization amount:	11.50	11.50
After the stored value card is authorized, you inquire on the remaining balance for the stored value card. Stored value card balance:	70.74	70.74
You add an item to the order for 5.25. You authorize the stored value card and generate a pick slip for the added item. Authorization amount:	5.25	5.25
After the stored value card is authorized, you inquire on the remaining balance for the stored value card. Stored value card balance:	65.49	65.49
You ship the entire order and bill the order for the shipment amount. The invoice amount is 16.75. You process deposits. Deposit amount:	16.75	16.75
Once the deposit is processed, you inquire on the remaining balance on the stored value card. Stored value card balance:	65.49	65.49

Generating Stored Value Card Refunds

Stored value card refunds allow you to generate a credit card credit against the original stored value card on the order or generate a new stored value card for the amount of the refund to send to the customer when you process a refund.

In this topic:

• Stored Value Card Refunds: Credit Card Credit

• Stored Value Card Refunds: New Stored Value Card

• Changing the Type of Stored Value Card Refund Generated

• When is a New Stored Value Card Generated for a Refund?

• Consolidating New Stored Value Cards Generated for Refunds by Order

• Processing New Stored Value Cards Generated for Refunds

For more information: See:

• overview and setup: Stored Value Card Overview and Setup

• activating the new stored value card for the refund amount: Stored Value Card Purchase and Activation

Stored Value Card Refunds: Credit Card Credit

If you process a return against a stored value card pay type that does not have an alternate pay type or alternate refund category defined, the system generates a credit card credit refund against the original stored value card pay type, allowing you to reimburse the refund amount to the original stored value card instead of sending a new stored value card to the customer.

Stored Value Card Refunds: New Stored Value Card

If you process a return against a stored value card pay type that has an alternate pay type or alternate refund category of stored value card defined, the system generates a new stored value card to send to the customer when you process a refund. The card is issued for the refund amount. When you process stored value card refunds, the system adds a stored value card item to the order at no charge and performs pick slip preparation. You can then follow the normal process of generating a pick slip for the stored value card item so that the card can be picked, activated, billed, and shipped to the customer.

You may wish to generate a new stored value card for the refund amount if:

• The sold to customer paid for the order using a stored value card, but has since thrown the card away. Instead of reimbursing the original stored value card on the order the refund amount, the customer has requested a new stored value card.

• The sold to customer paid for the order using multiple pay types. Instead of refunding each separate pay type on the order, the customer has requested the refund amount in the form of a stored value card.

Changing the Type of Stored Value Card Refund Generated

You can use Working with Refunds, Writeoffs and Balances Due (WREF) to change the type of refund that is generated for a stored value card pay type.

Credit card credit refund: If the original pay category and current pay category associated with the refund is a stored value card pay type (pay category Credit Card and Card type Stored Value), the system allows you to change the refund by entering a different refund type in the Type field on the Change Refund Screen. You can only change the refund type to a credit card credit refund (C) or stored value card refund (V). If you change the refund type to a credit card credit refund, the system adds the refund amount to the original stored value card on the order.

Stored value card refund: The system allows you to change any refund to a stored value card refund by entering a stored value card pay type in the Pay type field on the Change Refund Screen.

In addition, if the original pay category and current pay category associated with the refund is a stored value card pay type (pay category Credit Card and Card type Stored Value), the system allows you to change the refund by entering a different refund type in the Type field on the Change Refund Screen. You can only change the refund type to a credit card credit refund (C) or stored value card refund (V). If you change the refund type to a stored value card refund, the system generates a new stored value card for the refund amount.

When is a New Stored Value Card Generated for a Refund?

If the pay type associated with the refund is set up to generate a stored value card refund, the system generates a refund for refund type V (stored value card).

The system generates a stored value card refund when:

• The alternate refund type defined for a pay type is a stored value card.

• You process a return outside the Return Grace Period (B52) and the Alternate Pay Type (B51) is a stored value card pay type.

• You change a refund to a stored value card refund (refund type V) in Working with Refunds, Writeoffs and Balances Due (WREF).

Alternate currency and stored value card refunds: The system can process stored value cards in the US currency only. If the order is for a currency other than US, you should change the refund to a refund type other than stored value card.

Consolidating New Stored Value Cards Generated for Refunds by Order

The system consolidates open stored value card refunds that are for the same pay type on the same order.

Example: The following activity occurs for an order. The pay type on the order has an alternate refund type of stored value card.

Activity	Results
You return order line 1 for 50.00	The system creates a stored value card refund for 50.00.
You return order line 2 for 25.00	The system updates the existing refund to 75.00.
You process stored value card refunds	The system generates a stored value card for a refund amount of 75.00.
You return order line 3 for 30.00	Since the first stored value card refund for the order has been processed, the system creates a new stored value card refund for 30.00.

Multiple pay types on the same order: If the system generates a stored value card refund for different pay types on the same order, the system will not consolidate the stored value card refunds.

Example: The following activity occurs for an order. The order contains 2 pay types: cash/check for 50.00 and credit card for 55.00. Both pay types have an alternate refund type of stored value card.

Activity	Results
You return order line 1 for 50.00	The system creates a stored value card refund for 50.00. The current pay category assigned to the refund is credit card; the original pay category assigned to the refund is cash/check.
You return order line 2 for 25.00	The system creates a stored value card refund for 25.00. The current pay category assigned to the refund is credit card; the original pay category assigned to the refund is credit card.
You process stored value card refunds	The system generates 2 stored value cards: 1 for a refund amount of 50.00 and the other for a refund amount of 25.00.

Note:

In Working with Refunds, Writeoffs and Balances Due (WREF), if you change existing refunds for an order to stored value card refunds (by entering a stored value card pay type in the Pay type field at the Change Refund Screen), the system will not consolidate the stored value card refunds. For example, if 2 refunds exist for an order and you change both refunds to stored value card, the system will not consolidate the 2 refunds.

Processing New Stored Value Cards Generated for Refunds

To generate stored value card refunds, select a Bank, select the Generate SVC credits field and optionally, specify the Amount to generate at the Process Refunds Screen.

Note:

If multiple stored value card refunds exist for an order and the first stored value card refund processed places the order on hold (due to credit checking), the system will not process the subsequent stored value card refunds since the order is now on hold.

When you process stored value card refunds, the system:

• Produces the Stored Value Card Credit Register; this report displays each order and sold to customer associated with a stored value card refund and the amount of the refund.

• Writes an order transaction history message: F Stored Value Card refund created.

• Adds the Default SVC Refund Item Number (I73) to the order and performs pick slip preparation. This item represents the new stored value card that is sent to the customer for the amount of the processed refund. The system adds this item to the order at no charge and defaults the Price Override Reason for SVC Refund Item (I74) to the order line.

  Note:

  The system will not generate a stored value card refund unless the stored value card refund item has available inventory. If the item does not have available inventory, the stored value card refund remains unprocessed.

• Automatically generates a pick slip for the new stored value card item added to the order if the Default Pick Generation Template for SVC Refund Processing (I75) system control value contains a pick slip generation template. If a pick slip generation template is not defined, you will need to advance to Streamlined Pick Slip Generation (WSPS) and select to generate a pick slip for the stored value card refund item.

Once a pick slip is generated for the stored value card item, the system goes through the regular process of assigning a number, activating, billing, and shipping the new stored value card to the sold to customer. See Activating a Stored Value Card.

Once the customer receives the stored value card containing the refund amount, the card can be used on future purchases.

Importing Item/SKU and Set Data

Topics in this part: The following topics describe how to import item/SKU and set data into Order Administration from an external system.

• Importing Item-Related Supporting Data (SDUP) provides details on importing items/SKU information, item-related supporting table information, and set components into Order Administration.

• Importing Set Components (WCUP) provides details on building sets, including finished goods and variable sets.

  • Work with Component Upload Screen (WCUP)

Integration Layer Processes and Web Services

Purpose: This topic provides a master listing of integration layer processes and their characteristics, including whether they process inbound or outbound messages, require queues, or must be stopped and started. This topic also includes a listing of web services that do not use integration layer processes, and provides troubleshooting information for XML messages.

In this topic:

• Integration Layer Processes

• Web Services without Integration Layer Processes

• Troubleshooting XML Messages and Integration Layer Processes 

For more information: See:

• Generic Web Services describes how to use the CWMessageIn Web Service to process XML messages for integration layer jobs that ordinarily use advanced queuing. This topic also describes how to use the CWMessageIn Web Service, which does not require an integration layer job to process the message.

  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

• Working with Integration Layer Processes (IJCT) describes the screens you use to work with and configure integration layer jobs.

• Advanced Queuing for more information on using advanced queuing to send messages between Order Administration and an external system.

• Working with Web Service Authentication (WWSA) describes how to define which Order Administration web service endpoints require web service authentication.

Integration Layer Processes

This table describes:

• the integration layer processes

• their functions

• the jobs they initiate

• the messages they handle

• whether they require a queue

• whether they need to be active

• their communication type setting

Process	Function	Submitted job or program	Messages	Needs Queue?	Must be Active?	Comm type?
Order Orchestration integration	Order Administration sends and receives order information and updates. See the Order Orchestration Integration for an overview.	BROKER (ILR0022)	Sends and receives information using Order Orchestration’s message formats; see Sample Order Orchestration Messages for examples.	no	yes	web service
Customer history, order inquiry (inbound/ outbound)	Order Administration receives a CustHistRequest for customer order history or information on a specific order, and generates a response (CWCUSTHISTOUT or CWORDEROUT). See Generic Customer History API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	CUST_HIST (ILO0012)	CustHistRequest (to Order Administration)   CWCUSTHISTOUT (from Order Administration)   CWORDEROUT (from Order Administration)	no (if passing target of CUSTHISTIN)	no (if passing target of CUSTHISTIN)	message queue or CWMessageIn web service
Customer download (outbound)	Order Administration generates an outbound CWCustomerDownload XML message when you create, change, or delete a customer. See Generic Customer Download API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	CUST_OUT (ILR0022)	CWCustomerDownload (from Order Administration)	yes	yes	message queue
Customer inquiry/ search (inbound/ outbound)	Order Administration receives a CWCustomerInqRequest for information on one or more customers matching specific search criteria, and generates a CWCustomerInqResponse. See Generic Customer Inquiry (Search) API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	CUST_SRCH (ILO0022)	CWCustomerInq Request (to Order Administration)   CWCustomerInq Response (from Order Administration)	no (if passing target of CWCUSTSRCH)	no (if passing target of CWCUSTSRCH)	message queue or CWMessageIn web service
Customer API (inbound)	Order Administration receives a new customer or a change to an existing customer. See Generic Customer API for an overview. Note:  If using the CWCustomer web service, the CUSTOMR_IN IJCT job is not used. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	CUSTOMR_IN (ILO0019)	CWCustomerIn (to Order Administration)	no	no	CWCustomer web service or CWMessageIn web service
Email (outbound)	Order Administration generates the a generic outbound XML message rather than an actual email, so that you can you can use the information to produce a reformatted HTML email that includes promotional material. See Outbound Email API. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	EMAIL_OUT	CWEmailOut (from Order Administration)	yes	yes	message queue
Inventory download (outbound)	Order Administration sends inventory availability information to another system in the CWInventoryDownload message. See Generic Inventory Download API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	INV_DOWNLD (ILR0022)	CWInventory Download (from Order Administration)	yes	yes	message queue
Inventory inquiry (inbound/ outbound)	Order Administration receives a CWInventoryInquiryRequest for inventory availability on a specific item/SKU and generates a CWInventoryInquiryResponse. See Generic Inventory Inquiry API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	INV_INQURY (ILO0013)	CWInventoryInquiry (to Order Administration)   CWInventoryInquiryResponse (from Order Administration)	yes	yes	message queue or CWMessageIn web service
Invoice Outbound (outbound)	Order Administration sends invoice information in the CWInvoiceOut message to another system, such as a retail store, financial system, or warehouse management system. See Generic Invoice Download API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	INVOIC_OUT (ILR0022)	CWInvoiceOut (from Order Administration)	yes	yes	message queue
Inventory transaction processor (inbound)	Order Administration receives inventory transactions in the inCreateInvXaction message and updates inventory information, such as in the Item Location and Item Warehouse tables. Any errors create Item Transaction Error records. See Generic Inventory Transaction Upload for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	INVTRAN_IN (ILO0008)	inCreateInvXaction (to Order Administration)	yes	yes	message queue or CWMessageIn web service
Item Outbound (outbound)	Order Administration sends item and SKU information in the CWItemOut message to another system, such as a retail store or warehouse management system. See Generic Item Download API. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	ITEM_OUT (ILR0022)	CWItemOut (from Order Administration)	yes	yes	message queue
Merchandise locator (outbound/ inbound)	Order Administration sends a request for inventory information to an external system, such as Order Orchestration, and receives a response listing external warehouse and store locations where the specified item is available. See Merchandise Locator API for an overview.	N/A	LocateItems request (from Order Administration)   LocateItems response (to Order Administration)   Note:  The CWMerchLoc request and response messages are used only to support processing the LocateItems request and response messages and the merchandise locator API, and are not themselves generic API messages.	no	no	web service
Order Cleanup	Rejects orders that have been abandoned on the web storefront if, for example, the customer closes the browser window. This process uses the Time Limit for Suspended E-Commerce Orders (G43) setting to determine the number of minutes to wait before rejecting an order. Only orders of the type specified in the E-Commerce Order Type (G42) system control value are eligible for cleanup. The system generates the E-Commerce Orders Cleanup Log each time it deletes a suspended order and writes a record in the Deleted Order Table.	ORDER_CLN	This job does not generate or receive any messages and is used only to submit the order cleanup.	no	no	message queue
Order processor (inbound/ outbound)	Order Administration receives new orders through a generic order interface and optionally generates detailed or simple acknowledgments, as requested in the inbound order message. See Generic Order Interface (Order API) for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	ORDER_IN (ILO0003) If the ORDER_IN job uses a web service and does not read from or write to queues (the default setting in Order Management System 1.1 or higher),or Order Administration, there is no need to start or stop the job.	CWOrderIn (to Order Administration)   CWOrderOut (from Order Administration)	no	no	CWOrderIn web service (but can specify message queue or use CWMessageIn web service)
Pick Outbound	Order Administration sends a Pick Message from Order Administration (CWPickOut) for each pick slip generated. See Generic Pick Out API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	PICK_OUT (ILR0022)	CWPickOut (from Order Administration)	yes	yes	message queue
Purchase Order Outbound	Order Administration sends a CWPurchaseOrderOut message to a warehouse management system or an EDI vendor. See Generic Outbound Purchase Order API. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	PO_OUT (ILR0022)	CWPurchaseOrderOut (from Order Administration)	yes	yes	message queue
Return Inbound	Order Administration receives a Return Request Message (CWReturnIn) to create and process a return against a specified order line. Optionally, the process sends a Return Response Message (CWReturnOut) to the external system, indicating if the return processed successfully or if an error occurred. See Inbound Return API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	RETURN_IN (ILO0021)	CWReturnIn (to Order Administration) CWReturnOut (from Order Administration)	no (if passing target of CWRETURNIN)	no (if passing target of CWRETURNIN)	message queue or CWMessageIn web service
Return Authorization Outbound	Order Administration sends a Return Authorization Outbound XML Message (CWReturnRAOut) when a return authorization is created, changed, or deleted.	RETURN_OUT (ILR0022)	CWReturn AuthorizationOut (from Order Administration)	yes	yes	message queue
Tax Request (inbound / outbound)	Order Administration sends a request for tax information for an order to an external system, and then receives the response. See Use Generic Tax XML Interface (J10) and the Vertex Interface.	TAX_INT This process does not submit a job; it is used to determine the XML message format and the queue used to transmit the message. You do not need to start or end this job.	CWTaxRequest (from Order Administration) CWTaxResponse (to Order Administration)	no	no	web service
Vendor Outbound (outbound)	Order Administration sends a CWVendorOut message to another system, such as a retail store or warehouse management system. See Generic Vendor Download API for more information. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	VENDOR_OUT (ILR0022)	CWVendorOut (from Order Administration)	yes	yes	message queue
Workflow processing (inbound)	Order Administration receives the CWWorkflow XML message from an outside source and creates a tickler, based on the information in the message. This process does not process any message other than CWWorkflow. See Workflow Management Overview and Setup and WF (Remote Workflow) Event Processing.	WORKFLOW (ILO0002)	CWWorkflow (to Order Administration)	yes	yes	message queue or CWMessageIn web service

Web Services without Integration Layer Processes

The following web services allow you to process XML messages directly without using a process at the Work with Integration Layer Process Screen.

Web Service	Inbound Message	Outbound Message	For More Information
CWOrderIn	Inbound Order XML Message (CWORDERIN)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Detailed Order XML Response (CWORDEROUT), or Order Acknowledgement XML Message (CWORDEROUT) For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Generic Order Interface (Order API) For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
CWCustomer	Inbound Customer Message (CWCustomerIn)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Outbound Customer Response Message (CWCustomerOut)	Generic Customer API
CWReceiptIn	PO Receipt In XML Message (CWReceiptIn)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	none	Purchase Order Receipt In API For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
CWPickIn	CWPickIn XML Message For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	none	Generic Pick In API (Shipments, Voids, and Backorders) For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
CWServiceIn	Order Transaction History Message (CWOrderTransactionHistory)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	none	Generic Order Transaction History API For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
	Order Line History In Message (CWOrdLnHstIn)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	none	Order Line History In API  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
	Item Availability Request XML Message (CWItemAvailabilityWeb)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Availability Response XML Message (CWItemAvailabilityResponseWeb) For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Item Availability API For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
	E-Commerce Cancel Request Message (CWCancel)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	none	E-Commerce Cancel Process
	E-Commerce Catalog Request Message (CWCatRequest)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	E-Commerce Catalog Request Response Message (CWCatreqResponse) For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	E-Commerce Catalog Requests For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
	CWProcessIn Message  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	none	Using the CWProcessIn Message to Start a Periodic Process For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
CWMessageIn this web service works with any of the integration layer processes set up through Working with Integration Layer Processes (IJCT); see CWMessageIn Web Service for more information For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Inbound Customer Search Message (CWCustomerInqRequest)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Outbound Customer Search Response (CWCustomerInqResponse)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	queue not required if target is CWCUSTSRCH; see Generic Customer Inquiry (Search) API  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
	Inbound Customer Message (CWCustomerIn) For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Outbound Customer Response Message (CWCustomerOut)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	queue not required if type is CWCustomerIn; see Generic Customer API  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
	Customer History Request XML Message (CWCustHistIn)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Customer History Response XML Message (CWCustHistOut) or Detailed Order Inquiry Response XML Message (CWORDEROUT) For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	queue not required if target is CUSTHISTIN; see Generic Customer History API  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
	Email XML Message (CWEmail)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	none	Email Repository Overview   For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
	Inventory Inquiry Request XML Message (CWInventoryInquiry)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Inventory Inquiry Response XML Message (CWInventoryInquiryResponse) For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Generic Inventory Inquiry API  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
	Inventory Transaction Upload XML Message (inCreateInvXaction) For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	none	Generic Inventory Transaction Upload  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
CWMessageIn continued	Inbound Order XML Message (CWORDERIN) For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Detailed Order XML Response (CWORDEROUT) or Order Acknowledgement XML Message (CWORDEROUT) For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Generic Order Interface (Order API)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
	Return Request Message (CWReturnIn)  For more information see theOrder Administration Web Services Guide on My Oracle Support (ID 2953017.1).	Return Response Message (CWReturnOut)  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).	queue not required if target is CWRETURNIN; see Inbound Return API  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
	Generic Workflow XML Message (CWWorkflow)		Workflow Management Overview and Setup and WF (Remote Workflow) Event Processing

Troubleshooting XML Messages and Integration Layer Processes

See also Using the JOBCLN Function to Resolve Job Status Across Servers.

Question	Possible Solution
What are some reasons why inbound messages might not be processed?	If the process uses a JMS provider (advanced queuing): Is the queue name correct? (Note: Queue names are case-sensitive.) Is the Enabled flag selected for the process queue at the Integration Layer Process Queue Screen? Did the server end unexpectedly while the process was active? If so, the Work with Integration Layer Process Screen might display a Status of Active even if the process is no longer running. See Starting or Ending a Process for information on how to reset the status.
Do you need to use a JMS provider (advanced queuing) for integration layer processes or e-commerce?	You can use the Generic Web Services to send XML messages if you prefer not to use advanced queuing. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
What is the purpose of an integration layer job that doesn’t need to be stopped or started?	Some possible purposes: To specify the version of an outbound XML message To specify the queue where an interactive process writes an outbound message
Are all integration layer processes listed at the Work with Integration Layer Process Screen?	If you have hidden a process, it is not listed. See Hiding an Integration Layer Process.
How can I track the messages processed?	See Order Administration Application Logs for information on the logs you can use to track XML messages.
How can the version number of an XML message be higher than the Order Administration release number?	XML version numbers do not increase in sync with the current Order Administration release number; instead, the XML version number increases each time new elements or attributes are added to the message, which can occur multiple times between major Order Administration releases. See XML Versions for a discussion.
Does the inbound XML version number matter?	The inbound XML version number is informational, indicating when new elements or attributes are added. Even if the inbound XML version number is lower than the one in which the new elements or attributes were added, the integration layer job can still process the inbound message if the elements or attributes were added prior to the current Order Administration release. See XML Versions for a discussion.
Is it necessary to start and stop a process manually?	See Scheduling Jobs and Additional Interface (INT) Periodic Functions for more information on how to schedule a periodic function and for a list of the periodic functions used to start and stop the integration layer jobs.
Where can I find DTDs and schemas, for XML messages?	See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

 

Merchandise Locator API

Purpose: Use the merchandise locator integration to request current availability information about an item/SKU in retail stores within a geographic search area or in external warehouses.

The merchandise locator search finds locations where the item is available for pickup, as well as indicating whether the item is available for shipment from a location. Your search specifies the requested quantity, and Order Administration uses the ProductAvailability request and response to communicate with Order Orchestration.

Does not create orders: The merchandise locator search is an inquiry only, and does not create or update an order. See the Order Orchestration Integration for information on submitting a brokered backorder (delivery or ship-for-pickup), store pickup, or ship-for-pickup order to Order Orchestration.

For more information: See:

• Order Orchestration Integration Overview for background on integration between Order Orchestration and Order Administration

• Order Orchestration Configuration for required setup in Order Administration

• the Order Orchestration Web Services Guide on https://support.oracle.com (ID 2953017.1) for details on the LocateItems request and response messages or the ProductAvailability request and response messages, your options in configuring merchandise locator searching, and details on logging and troubleshooting in Order Orchestration

In this topic:

• Merchandise Locator Process Overview

  • Searching for Pickup Locations and Shipment Availability

  • Merchandise Locator for Different Types of Items

  • Merchandise Locator Troubleshooting

• Merchandise Locator Search Window (Searching for an Item)

• Merchandise Locator Search Results Screen

• Display Merchandise Locator Search Result Screen

Merchandise Locator Process Overview

Searching for Pickup Locations and Shipment Availability

Overview: A typical process of inquiring on locations where an item is available for pickup, as well as whether the item is available for shipment from a location, is described below.

1. A customer wants to know if an item/SKU is available for pickup at a nearby store or available for shipment from a store location. You select the item/SKU for merchandise locator inquiry. This option is available in order entry, order maintenance, and at the Display Item Availability Screen.

2. You advance to the Merchandise Locator Search Window (Searching for an Item), where you provide or confirm the customer’s geographic location, the requested quantity of the item, and the radius to search within (for example, search all stores within 25 miles of the customer’s home).

   Note:

   Order Orchestration supports merchandise locator searches only in the U.S. and Canada.

3. In the background, the MERCH_LOC process:

   • Generates the ProductAvailability request message and sends it to Order Orchestration. Order Orchestration checks the availability of the item in stores that stock the item/SKU within the search area, as well as whether the item is available for shipment at any store locations within the same search area.

   • Receives the ProductAvailability response returned by Order Orchestration. This message lists:

     • the item/SKU’s current or estimated availability in each searched location that stocks the item for pickup

     • an indicator of whether the requested quantity of the item/SKU is available for shipment within the search area

4. You advance to the Merchandise Locator Search Results Screen, displaying the item/SKU’s availability for pickup in each of the locations, including information on any open purchase orders. The screen also indicates whether the requested quantity of the item/SKU is available for delivery from a store within the same search area.

How does Order Orchestration select the locations to include?

• Locations eligible to fulfill pickup orders:

  • Only store locations flagged as Pickup available can be included in the search results displayed at the Merchandise Locator Search Results Screen.

  • Order Orchestration uses any probability rules you have set up to determine whether to include locations in the results, and the available quantity to indicate. For example, you might set up a probability rule for certain locations indicating to exclude them if the available quantity falls below 5 units, or to reduce the available quantity returned in the response message by 10%.

  Results displayed: For each location included in the search results as eligible for a pickup order, the Merchandise Locator Search Results Screen indicates:

  • the available quantity, next purchase order date, and next purchase order quantity

  • whether the store location will ship the item for pickup in another store location

  • the name, address, and phone number of the location

  • the distance from the search address:

    • locations are sorted in ascending order by distance (closest location listed first)

    • locations that are not flagged to Use Proximity Locator are listed without a distance

Note:

• Any locations associated in Order Orchestration with your Order Administration system are excluded from the results, regardless of whether there is a corresponding warehouse record in Order Administration.

• If a location that stocks the item and is within the search radius is flagged in Order Orchestration as Backorder Available, it is returned in the search results even if it does not have the item available. In this case, the Pickup avail qty listed can be blank, or can be a negative quantity.

• If there are locations that stock the item and are within the search radius, but none have the full requested quantity available (and are not flagged as Backorder Available), the Merchandise Locator Search Results Screen displays the locations, but does not indicate the Dist, Pickup avail qty, Open PO qty, or Next PO date. This situation could occur if, for example, the customer requests 5 units, and none of the locations have more than 4 units available. To display the full information for the displayed locations, search again with a lower Search quantity.

• Locations eligible to fulfill delivery orders: Only store locations flagged as Shipping available are eligible to fulfill a delivery order. Also, Order Orchestration:

  • uses any probability rules you have set up to determine whether to include locations in the results, and the available quantity. For example, you might set up a probability rule for certain locations indicating to exclude them if the available quantity falls below 5 units, or to reduce the available quantity indicated in the response message by 10%.

  • does not exclude locations flagged as Backorder available, even if the available quantity in the location is less than the requested quantity.

  • restricts eligible locations to a fulfillment zone based on the search address, if configured in Order Orchestration.

  • excludes locations associated with Order Administration’s system in Order Orchestration, if the Disallow shopping within same system option is selected for the Order Administration system in Order Orchestration.

  • excludes locations that have already been assigned the Maximum Daily Orders, if Use Maximum Order Limits preference is selected in Order Orchestration.

  Results displayed: If the results indicate that one or more locations could deliver the requested quantity, the Merchandise Locator Search Results Screen indicates Delivery From Store Is Available; otherwise, the screen indicates Delivery From Store Is Not Available. This message might be displayed even if one or more locations could ship the requested quantity, even if these locations are not displayed in the search results.

Note:

The delivery evaluation uses the same search radius as the pickup evaluation. To determine whether the item can be shipped without restricting the results to locations within driving distance of the customer, retry the search with a higher search radius.

For more information: See the Merchandise Locator Search Results Screen and the Order Administration Web Services Guide on https://support.oracle.com (ID 2953017.1) for more information on the search results.

ProductAvailability request not used when creating a pickup order: Unlike the merchandise locator search described here, when you create a pickup order in order entry by selecting the Store Pickup option, Order Administration uses the LocateItems request message to search for store locations where the customer can pick up the order, regardless of the CW_LOCATE_MESSAGE_VERSION specified in Working with Customer Properties (PROP).

Merchandise Locator for Different Types of Items

Merchandise locator searches are not useful for the following types of items:

• membership item

• subscription item

• component of a set (although you can include the main set item)

Also, an item must have its OROB eligible flag selected in order to be eligible for a merchandise locator search. Typically, you would use this flag to exclude inappropriate items, such as gift cards or any other items that are not available in external store locations.

Note:

The restriction against set components applies only if the item is added to the order as a component of a set. If you enter the item as a separate order line, merchandise locator searching is still available.

Merchandise Locator Troubleshooting

Problem	Possible Explanation or Solution
A location that stocks the requested item is not listed at the Merchandise Locator Search Results Screen	The location might: not have the Pickup available flag selected in Order Orchestration be excluded because of probability rules be outside of the search radius
The merchandise locator request message is producing invalid XML	Check that text fields included in the message, such as the item or SKU description, do not include any special characters. For example, the carat (^) and the pipe symbol (¦) are not valid characters in an XML message.
The Merchandise Locator Search Results Screen displays the error: Availability information is not accessible at this time	Could occur because: communications between Order Administration and Order Orchestration are not active Order Orchestration could not identify the search location based on the information sent in the search request (for example, it has no record of the provided zip code). See the Order Orchestration Web Services Guide https://support.oracle.com (ID 2953017.1) for more information. None of the locations within the search area have the item/SKU in stock. You can select Search again to change the search location or distance to search within. None of the locations within the search area stock the item/SKU. You can select Search again to change the search location or distance to search within. The customer address information provided in the merchandise locator request was invalid or incomplete. This could occur if, for example, you entered a Canadian address, but the database used to identify customer locations in Order Orchestration includes only U.S. addresses.
The Merchandise Locator Search Results Screen displays the error Item/Sku not Merchandise Locator eligible	The item’s OROB eligible flag is unselected, so Order Orchestration would not be able to identify the item.
The Merchandise Locator Search Results Screen displays the error FAILED: 1002 - Invalid item (system product), item (ROBOT ) does not exi	The selected item is OROB eligible, but has not yet been created in Order Orchestration.
The Merchandise Locator Search Results Screen does not indicate the Dist, Pickup avail qty, Open PO qty, or Next PO date	This situation can occur if there are locations that stock the item and are within the search radius, but none have the full requested quantity available (and are not flagged as Backorder Available): for example, the customer requests 5 units, and none of the locations have more than 4 units available. To display the full information for the displayed locations, search again with a lower Search quantity.
The Merchandise Locator Search Results Screen lists a location with no quantity, or with a negative quantity	This situation can occur if a location that stocks the item and is within the search radius is flagged in Order Orchestration as Backorder Available.

Merchandise Locator Search Window (Searching for an Item)

Purpose: Use this window to check availability for an item across external locations, such as retail stores, typically through Order Orchestration. To search, you need to specify the customer’s location, either by city and state or postal code, the search radius, and a search quantity.

Address defaults: If you advance to this window in order entry or order maintenance, the customer’s address information defaults. Also, if you have overridden the address information in order entry or order maintenance, the system continues to default the override information until you are working with a different customer. For example, if you perform a search using the customer’s work address for an item/SKU, and then select another item/SKU for a search while working with the same order, the customer’s work address defaults.

How to display this window: Select Merch locator for an item at the:

• Work with Order Lines Screen (Adding Items to the Order)

• SKU Scan Screen

• Scan Order Lines Screen

• Display Item Availability Screen

Note:

This option is available only if:

• The Use Merchandise Locator (I38) system control value is selected. Otherwise, the screen displays an error message: Merchandise Locator is not enabled. Also, merchandise locator searching is not available for all items; see Merchandise Locator for Different Types of Items for a listing of items that are not eligible.

• You have not already selected a quantity of the item to add to the current order at the Display Item Availability Screen in order entry. Otherwise, the screen displays an error message: Option not allowed since item already selected.

Important:

Order Orchestration supports merchandise locator searches only within the U.S. and Canada.

The merchandise locator search is an inquiry only, and does not create or update an order. See the Order Orchestration Integration for information on submitting a brokered backorder, store pickup, or ship-for-pickup order to Order Orchestration.

Field	Description
Item	The item selected at the previous screen. The SKU information, if any, is to the right. Item code: alphanumeric, 12 positions; display-only. SKU: alphanumeric, three 4-position fields; display-only.
Item description	The description of the item. Even if the item has SKUs, the item description is displayed. Alphanumeric, 120 positions; display-only.
Postal code	Note: If you advanced to this window from order entry or order maintenance, the customer’s address information defaults. The customer’s U.S. zip or Canadian postal code, to serve as the central point for the search radius. For example, if the Search within field is set to 25 miles, the search includes stores within 25 miles of this postal code. The search radius applies only to locations that use proximity rules. You might set up Order Orchestration so that proximity rules apply to stores only and not warehouses. Note: Your entry in this field is not validated against the Zip/City/State table. Alphanumeric, 10 positions; required if you do not enter a city and state.
Address	The customer’s street address, to serve as the central point for the search radius. The search radius applies only to locations that use proximity rules. You might set up Order Orchestration so that proximity rules apply to stores only and not warehouses. Alphanumeric, 32 positions; optional.
City	The customer’s city, to serve as the central point for the search radius. The search radius applies only to locations that use proximity rules. You might set up Order Orchestration so that proximity rules apply to stores only and not warehouses. Alphanumeric, 25 positions; required if you do not enter a postal code.
State	The customer’s U.S. state or Canadian province, to identify the location of the city. The search radius applies only to locations that use proximity rules. You might set up Order Orchestration so that proximity rules apply to stores only and not warehouses. Alphanumeric, 2 positions; required if do not enter a postal code.
Country	The customer’s country. The country defaults from the customer address if you advanced to this window from order entry or order maintenance; otherwise, it defaults from the vDefault Country for Customer Address (B17) system control value. Defined in and validated against the Country table; see Setting Up the Country Table (WCTY) for more information. The search radius applies only to locations that use proximity rules. You might set up Order Orchestration so that proximity rules apply to stores only and not warehouses. Alphanumeric, 2 positions; required.
Search quantity	The requested quantity of the item. Defaults to 1. Numeric, 7 positions; required.
Search within	Indicates the search radius, in miles or kilometers, to search within for the selected item. The search radius defaults from the Default Search Within Radius (I40) system control value, but you can override it. Note: The search radius applies only to locations that use proximity rules. You might set up Order Orchestration so that proximity rules apply to stores only and not warehouses. The distance unit of measure (miles or kilometers) specified with the Merchandise Locator Distance Measurement (I39) system control value is displayed to the right. Typically, a search for a delivery location can use a broader search radius than a search for a pickup location, which is generally within driving distance. To see if the item is available for delivery as opposed to pickup, you might search twice, specifying a different search radius when determining if the item is available for delivery. Numeric, 5 positions; required.

Completing this window:

• If they have not already defaulted, indicate the postal code or the city and state to serve as the central point for the search radius.

• Optionally, override the Search quantity.

• Optionally, override the Search within radius to a different distance.

• Click OK. The system generates the ProductAvailability request message. See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information.

When the system receives the response message, you advance to the Merchandise Locator Search Results Screen.

Merchandise Locator Search Results Screen

Purpose: Use this screen to review an item’s availability in external locations and the details about the external location.

The Ship for Pickup and Pickup Available Quantity fields indicate whether the store location supports store pickup orders, ship-for-pickup orders, or both.

• If the Ship for Pickup field is set to Y and a quantity is defined in the Pickup Available Quantity field, the store location supports both ship-for-pickup orders and store pickup orders.

• If the Ship for Pickup field is set to Y and the Pickup Available Quantity field is blank, the store location supports ship-for-pickup orders but not store pickup orders.

• If the Ship for Pickup field is set to N and a quantity is defined in the Pickup Available Quantity field, the store location supports store pickup orders but not ship-for-pickup orders.

• If the Ship for Pickup field is set to N and the Pickup Available Quantity field is blank, the store location does not support ship-for-pickup orders or store pickup orders.

If you advanced to this screen during Order Entry and the Ship for Pickup field is set to Y for a store, you can select Ship for Pickup to convert the order to a ship-for-pickup order; in this situation, the system updates the one-time ship to address on the order to the store’s name and address and sends a broker backorder for the ship-for-pickup order to the Order Orchestration for fulfillment assignment. See Brokered Backorders for processing details.

How to display this screen: Complete the Merchandise Locator Search Window (Searching for an Item) and click OK.

Troubleshooting: See Merchandise Locator Troubleshooting.

For more information: See the Order Administration Web Services Guide on https://support.oracle.com (ID 2953017.1) for an example of the actual response messages used to populate the information on this screen.

Note:

You cannot submit an order to Order Orchestration through this screen. See the Order Orchestration Integration for information on submitting a brokered backorder, store pickup, or ship-for-pickup order to Order Orchestration.

Field	Description
Locations closest to	The address information provided at the Merchandise Locator Search Window (Searching for an Item). This information could be just a postal code or a city and state, or could include additional information such as the street address. The information is truncated if it exceeds the space allowed on this screen. The search radius applies only to locations that use proximity rules. You might set up Order Orchestration so that proximity rules apply to stores only and not warehouses. Alphanumeric, 55 positions; display-only.
Radius	The Search within radius selected at the Merchandise Locator Search Window (Searching for an Item). The setting of the Merchandise Locator Distance Measurement (I39) (miles or kilometers) is to the right. The search radius applies only to locations that use proximity rules. You might set up Order Orchestration so that proximity rules apply to stores only and not warehouses. Numeric, 5 positions; display-only.
Location types	Always set to All (both stores and warehouses). Alphanumeric, 3 positions; display-only.
Item	The item selected for search. The SKU information, if any, is to the right. Item code: alphanumeric, 12 positions; display-only. SKU: alphanumeric, three 4-position fields; display-only.
Item description	The description of the item. Even if the item has SKUs, the item description is displayed. Alphanumeric, 120 positions; display-only.
Delivery availability (unlabeled field to the right of the item description)	If the results indicate that one or more locations could deliver the requested quantity, the Merchandise Locator Search Results Screen indicates Delivery From Store Is Available; otherwise, the screen indicates Delivery From Store Is Not Available. This message might be displayed even if one or more locations could ship the requested quantity, even if these locations are not displayed in the search results.
Dist	Each location in the search results where the customer could pick up the item is displayed below. Locations are sorted by distance (nearest to farthest away). The number of miles or kilometers, based on the Merchandise Locator Distance Measurement (I39), from the search location. This distance might be approximate, depending on the actual criteria used to search (for example, postal code or city), and does not represent an actual driving distance. No distance is displayed if the location is not set up in Order Orchestration to use proximity rules. In this situation, the location is always considered to be within the specified search radius. Also, no distance is displayed if the store location and the search location are in the same zip or postal code. The distance is rounded down when determining whether to include the location in the search results. For example, if the Search radius is 10 miles, and the location is 10.84 miles away, the location is included in the results. The distance is shown if the location is shown. The location is shown when: Pickup qty > 0 and store flagged as pickup even though not ship for pickup Pick qty = 0, store not flagged as pickup available but store is flagged for ship for pickup Location is not shown if no inventory and not flagged as ship for pickup. Numeric, 7 positions with a 2-place decimal.
Ship for Pickup	Indicates whether the store location is available for selection as a destination for a ship-for-pickup order. This is from the Ship for Pickup setting for the store location in the Work with Store Cross Reference (WSCR) menu option. Y = the store location is available for selection as a destination for a ship-for-pickup order. During Order Entry, if you select Ship for Pickup for the store location, the system updates the ship to address on the order to the address defined for the store location and converts the order to a ship-for-pickup order. See Brokered Backorders for processing details. N = the store location is not available for selection as a destination for a ship-for-pickup order. Alphanumeric, 1 position; display-only.
Location	The description and address of the location where the item/SKU is available, and can include: description city state postal code country This information is provided directly from Order Orchestration, and is not derived from the Store Cross Reference table in Order Administration. Note: Searching the locations displayed on the screen based on location name is not currently implemented. Description: alphanumeric, 40 positions; display-only. City: alphanumeric, 25 positions; display-only. State: alphanumeric, 2 positions; display-only. Postal code: alphanumeric, 10 positions; display-only. Country: alphanumeric, 3 positions; display-only.
Pickup avail qty	The quantity of the item/SKU reported in the response message as available for pickup in this location. Depending on your settings within Order Orchestration, this quantity may be approximate, or calculated based on probability rules. Note: If a location that stocks the item and is within the search radius is flagged in Order Orchestration as Backorder Available, it is returned in the search results even if it does not have the item available. In this case, the Pickup avail qty listed can be blank, or can be a negative quantity. If there are locations that stock the item and are within the search radius, but none have the full requested quantity available (and are not flagged as Backorder Available), the Merchandise Locator Search Results Screen displays the locations, but does not indicate the Dist, Pickup avail qty, Open PO qty, or Next PO date. This situation could occur if, for example, the customer requests 5 units, and none of the locations have more than 4 units available. To display the full information for the displayed locations, search again with a lower Search quantity. Numeric, 7 positions; display-only.
Open PO qty	The quantity of the item/SKU reported on open purchase orders for this location; depends on how the external system calculates the open PO quantity. Note: If there are locations that stock the item and are within the search radius, but none have the full requested quantity available (and are not flagged as Backorder Available), the Merchandise Locator Search Results Screen displays the locations, but does not indicate the Dist, Pickup avail qty, Open PO qty, or Next PO date. This situation could occur if, for example, the customer requests 5 units, and none of the locations have more than 4 units available. To display the full information for the displayed locations, search again with a lower Search quantity. Numeric, 7 positions; display-only.
Next PO date	The date when the next purchase order for this item/SKU is due to be received at this location; depends on how the externals system calculates the next PO date. Note: If there are locations that stock the item and are within the search radius, but none have the full requested quantity available (and are not flagged as Backorder Available), the Merchandise Locator Search Results Screen displays the locations, but does not indicate the Dist, Pickup avail qty, Open PO qty, or Next PO date. This situation could occur if, for example, the customer requests 5 units, and none of the locations have more than 4 units available. To display the full information for the displayed locations, search again with a lower Search quantity. Numeric, 6 positions (user date format); display-only.

Option	Procedure
Display a location	Select Display for a location to advance to the Display Merchandise Locator Search Result Screen.
Select the store location as the pickup location for a ship-for-pickup order Note: This option is available only if you advanced to this screen during Order Entry.	Select Ship for Pickup for a location. The system: updates the one-time ship to name and address on the order to the selected store location and converts the order to a ship-for-pickup order. sends a broker backorder for the ship-for-pickup order to the Order Orchestration for fulfillment assignment. See Brokered Backorders for processing details.
Search again	Select Search again to return to the Merchandise Locator Search Window (Searching for an Item).

Display Merchandise Locator Search Result Screen

Purpose: Use this screen to review additional details about a location where the customer might be able to pick up the item. You cannot make any changes on this screen.

The address components, such as postal code, country, and phone number, are provided by external systems and might not be formatted or validated at this screen the same way as they are for data stored in Order Administration.

How to display this screen: Select Display for a location at the Merchandise Locator Search Results Screen.

Field	Description
Item	The item selected for search. The SKU information, if any, is to the right. Item code: alphanumeric, 12 positions; display-only. SKU: alphanumeric, three 4-position fields; display-only.
Description	The description of the item. Even if the item has SKUs, the item description is displayed. Alphanumeric, 120 positions; display-only.
Loc type	Always set to All (both stores and warehouses). Note: Not included if the CW_LOCATE_MESSAGE_VERSION in Working with Customer Properties (PROP) specifies a message version of 5.0 or higher. Alphanumeric, 3 positions; display-only.
Distance	The number of miles or kilometers, based on the Merchandise Locator Distance Measurement (I39), from the search location. This distance might be approximate, depending on the actual criteria used to search (for example, postal code or city), and does not represent an actual driving distance. The setting of the Merchandise Locator Distance Measurement (I39) (miles or kilometers) is to the right. The distance displayed is .00 if the location is not set up in Order Orchestration to use proximity rules. In this situation, the location is always considered to be within the specified search radius. Numeric, 7 positions with a 2-place decimal.
Location	The description and address of the location where the item/SKU is available, consisting of: description (the Name from Order Orchestration) street address (up to four lines) city state postal code country phone number (does not include the extension or the fax number) This information is provided directly from Order Orchestration, and is not derived from the Store Cross Reference table in Order Administration. Description: alphanumeric, 40 positions; display-only. Street: alphanumeric, 40 positions each; display-only. City: alphanumeric, 25 positions; display-only. State: alphanumeric, 2 positions; display-only. Postal code: alphanumeric, 10 positions; display-only. Country: alphanumeric, 3 positions; display-only. Phone number: alphanumeric, 14 positions; display-only.
Available	The quantity of the item/SKU reported in the response message as available for pickup in this location. Depending on your settings within Order Orchestration, this quantity may be approximate, or calculated based on probability rules. Note: If a location that stocks the item and is within the search radius is flagged in Order Orchestration as Backorder Available, it is returned in the search results even if it does not have the item available. In this case, the Pickup avail qty listed can be blank, or can be a negative quantity. If there are locations that stock the item and are within the search radius, but none have the full requested quantity available (and are not flagged as Backorder Available), the Merchandise Locator Search Results Screen displays the locations, but does not indicate the Dist, Pickup avail qty, Open PO qty, or Next PO date. This situation could occur if, for example, the customer requests 5 units, and none of the locations have more than 4 units available. To display the full information for the displayed locations, search again with a lower Search quantity. Numeric, 7 positions; display-only.
Open PO	The quantity of the item/SKU reported on open purchase orders for this location; depends on how the external system calculates the open PO quantity. If there are locations that stock the item and are within the search radius, but none have the full requested quantity available (and are not flagged as Backorder Available), the Merchandise Locator Search Results Screen displays the locations, but does not indicate the Dist, Pickup avail qty, Open PO qty, or Next PO date. This situation could occur if, for example, the customer requests 5 units, and none of the locations have more than 4 units available. To display the full information for the displayed locations, search again with a lower Search quantity. Numeric, 7 positions; display-only.
Next PO	The date when the next purchase order for this item/SKU is due to be received at this location; depends on how the externals system calculates the next PO date. If there are locations that stock the item and are within the search radius, but none have the full requested quantity available (and are not flagged as Backorder Available), the Merchandise Locator Search Results Screen displays the locations, but does not indicate the Dist, Pickup avail qty, Open PO qty, or Next PO date. This situation could occur if, for example, the customer requests 5 units, and none of the locations have more than 4 units available. To display the full information for the displayed locations, search again with a lower Search quantity. Numeric, 6 positions (user date format); display-only.

Brokered Backorders

Purpose: If the Send B/O to OROB (K08) system control value is selected, you can use the Order Orchestration Integration to send backordered order lines to Order Orchestration for fulfillment.

• If the Use OROB for Fulfillment Assignment (M31) system control value is unselected, the system sends eligible backordered items to Order Orchestration for fulfillment. Order Orchestration will choose the best store location to fulfill and ship the item to the customer. Items that are in stock follow normal reservation and fulfillment processing.

• If the Use OROB for Fulfillment Assignment (M31) system control value is selected, the system bypasses reservation and places all eligible items on backorder, even if the item is available in an Order Administration warehouse. Order Orchestration will choose the best store location or Order Administration location to fulfill and ship the item to the customer.

• If the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS, the system bypasses reservation in order to send eligible items on a ship-for-pickup order to Order Orchestration for fulfillment assignment. In this situation, the fulfilling location may be a store location or an Order Administration warehouse and the merchandise is shipped to the customer’s selected store for pickup. See Creating a Ship-for-Pickup Order in Order Administration for more information on how to create a ship-for-pickup order.

Note:

If the item is flagged as a active PO item the system does not submit it to Order Orchestration for fulfillment using the standard process described here; instead, it uses the process described under Enterprise Order Integration (Future Receipts and Active PO/Pre-Order Processing).

When using Order Orchestration for fulfillment assignment, the fulfilling location can be a store location or an OACS warehouse location. In addition, for ship-for-pickup orders, the fulfilling location ships the order to the customer’s selected store for pickup.

In this topic:

• Brokered Backorder Processing Overview

• Brokered Backorder Fulfillment: Initial Order Creation

• Fulfillment Process: After Order Creation and Status Updates

• Rules for Submitting Backorders to Order Orchestration

  • BROKER Periodic Function

• Brokering Items with Soldout Control Codes

• Things to Note About Brokered Backorders

Brokered Backorder Processing Overview

Order Orchestration assignment: Assigning a backordered item to Order Orchestration can occur through:

• order entry or order API: When you create an order that includes a backordered line, Order Administration assigns the line, if eligible, to Order Orchestration for fulfillment, and withholds it from normal fulfillment processing within Order Administration.

  Note:

  • If the Use OROB for Fulfillment Assignment (M31) system control value is selected, the system bypasses reservation for all eligible items on an order and places them on backorder so that Order Orchestration can determine the fulfilling location.

  • If the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS, the system bypasses reservation for all eligible items on a ship-for-pickup order and places them on backorder so that Order Orchestration can determine the fulfilling location.

• batch process: A periodic function finds eligible backordered lines and assigns them to Order Orchestration.

Eligibility rules: Order Administration determines whether an order line is eligible for Order Orchestration fulfillment based on certain basic criteria, such as whether it is fully backordered and authorized; also, you can use related system control values to further restrict Order Orchestration assignment based on your business rules, such as omitting items you are due to receive soon on open purchase orders. Also, the item must be flagged as OROB eligible. See Rules for Submitting Backorders to Order Orchestration for details.

If the authorization for the order line has expired, the system obtains a new authorization.

Does each line create a separate order in Order Orchestration? Each eligible backordered line on an order is sent to Order Orchestration:

• as a separate order if the Use Split Order (L56) system control value is unselected. In this case, the fulfillment of each line is tracked individually. Order Orchestration does not attempt to assign multiple order lines from the same fulfilling location.

• as part of a single order if the Use Split Order (L56) system control value is selected. In this case, Order Orchestration attempts to assign all lines on the same order to the same fulfilling location; however, it notifies Order Administration about multiple assigned fulfilling locations if the order or lines are split. If a single backordered item is unfulfillable through Order Orchestration, that line returns to standard backorder processing, but additional lines on the order can still be fulfilled through Order Orchestration.

What information is sent to Order Orchestration? Order Administration sends the following information to Order Orchestration:

• sold-to and ship-to customers’ names and addresses.

• details on the requested item.

It does not send payment information, although only fully paid and authorized items are eligible for Order Orchestration fulfillment. If the Payment at POS for Ship for Pickup Orders (L60) system control value is selected, ship-for-pickup orders are authorized for verification only and payment is collected when the customer picks up the items at the store.

If the authorization for an order line has expired, the system obtains a new authorization.

For more information on the information sent to Order Orchestration, see Sample Order Orchestration Messages in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Brokered Backorder Fulfillment: Initial Order Creation

#	Step
1.	The process begins when you create an order in Order Administration. If the Send B/O to OROB (K08) system control value is selected, the system sends eligible backordered items to Order Orchestration to determine the fulfilling location. In addition: If the Use OROB for Fulfillment Assignment (M31) system control value is selected, the system bypasses reservation and places all eligible items on backorder, even if the item is available in an Order Administration warehouse, in order to have Order Orchestration determine the fulfilling location. If the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS, the system bypasses reservation and places all eligible items on a ship-for-pickup order on backorder, even if the item is available in an Order Administration warehouse, in order to have Order Orchestration determine the fulfilling location. The order creation can occur through interactive order entry, batch order entry, or the order API. You can also use the BROKER periodic function to submit existing backordered lines to the Order Orchestration for fulfillment; see Additional Order Orchestration Setup in Order Administration for more information.
2.	If the order line meets the Rules for Submitting Backorders to Order Orchestration, the BROKER_ORD process in Order Administration generates a request message to Order Orchestration and creates an Order Orchestration record. Note: Order lines that meet the Rules for Submitting Backorders to Order Orchestration do not sell out initially, even if the items are flagged with soldout control codes. See Brokering Items with Soldout Control Codes for more information. If the order includes multiple backordered lines and the Use Split Order (L56) system control value is selected, the request message includes all eligible backordered lines; otherwise, each backordered item is submitted as a separate order. Each Order Orchestration record has a status of R (ready) at creation. Also, the order line is updated to restrict it from standard backorder processing in Order Administration: the Drop ship flag is set to D. the Printed quantity is updated to the ordered quantity. an order line that is assigned to Order Orchestration for fulfillment displays a status of OBR in standard order inquiry. the quantity to be brokered does not update the Backordered quantity for the Item Warehouse. if the Use OROB for Fulfillment Assignment (M31) system control value is selected, the Bypass reservation flag is selected with a Backorder reason of Reservation bypassed indicating the brokered backorder was created for fulfillment assignment. if the order is a ship-for-pickup order sent for fulfillment assignment, the Bypass reservation flag is selected with a Backorder reason of Reservation bypassed indicating the brokered backorder was created for fulfillment assignment.
3.	If the BROKER_ORD process in Working with Integration Layer Processes (IJCT) is active, it immediately generates the submit order request message to Order Orchestration to request order creation and assignment in Order Orchestration. At this time, it also changes each Order Orchestration record’s status to W (waiting) and creates an Order Orchestration History record for each line to track the order submission (A - Send Order Request). See the Sample Order Orchestration Messages in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1). Note: Although the BROKER_ORD process generates the submit order requests (and cancellation requests, if needed), the BROKER process handles other requests to Order Orchestration.
4.	The Routing Engine module in Order Orchestration receives the submit order message. If Order Administration sent each line separately, Order Orchestration creates each order line as a separate order in its database; otherwise, if you use the split order option, Order Orchestration creates a single order including all of the order lines that were eligible for submission as brokered backorders. Order Orchestration assigns each order or line to a location for fulfillment based on inventory availability and the business rules you have defined in Order Orchestration. At this point, the order status in the Order Orchestration database is new_order.
5.	Order Orchestration sends a response message to Order Administration indicating each assigned fulfilling location and the unique request ID it uses to identify each order. See the Submit Order Response Message Sample in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1). Note: The message version is specified in the Order Orchestration Properties; this property must be set to 16.0 or higher in order to use brokered backorders for fulfillment assignment and to use ship-for-pickup processing.
6.	If Order Orchestration successfully created an order and assigned it to one or more fulfilling locations, Order Administration: updates each Order Orchestration record with: the fulfilling location, using the description set up through the Work with Store Cross Reference (WSCR) option. the request ID. a status of A (acknowledged). writes an Order Transaction History message indicating that the order line was acknowledged by Order Orchestration (for example, Ln#: 2 Acknowledged by Broker). creates an Order Orchestration History record (B - Receive Order Response).

Split line? If the Allow Split Line? preference in Order Orchestration is selected, Order Orchestration might split the quantity of a single brokered backorder line across more than one fulfilling location. For example, you create an order for item AB100 with a quantity of 10. There is no single location that has a quantity of 10 available. Order Orchestration assigns 8 units to location 100, and 2 units to location 200.

Order Orchestration splits order lines or line quantities only if you have selected the Allow Split Order? and Allow Split Line? preferences in Order Orchestration, and if there is not a single location that can fulfill the entire order or line quantity. See the Use Split Order (L56) system control value for examples, and see the Order Orchestration Operations Guide or online help for background.

If Order Administration is the fulfilling location: If the Use OROB for Fulfillment Assignment (M31) system control value is selected or the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS, Order Orchestration may determine that a warehouse in Order Administration is the best location to fulfill the order, or some portion of the order. In this situation:

• Order Orchestration assigns the Order Administration location to the order in Order Orchestration as the Fulfilling location.

• When the order in the fulfillments response message is received:

  • If the original order is not a ship-for-pickup order, it creates a new delivery order and assigns the order type defined in the Order Type for Delivery Orders Originating in OROMS (M33) system control value to the order.

  • If the original order is a ship-for-pickup order, it creates a new retail pickup order and assigns the order type defined in the Order Type for Retail Pickup Orders Originating in OROMS (M35) system control value to the order.

• In order to tie the originating order (the original order sent to Order Orchestration for fulfillment assignment) with the new fulfilling order (the delivery or retail pickup order created to fulfill the original order), Order Administration:

  • stores the originating order number in the E-commerce order number field in the Order Header Extended table for the newly created sourcing order. For example, the system updates the E-commerce order number with ORIG#: 9999-001, where ORIG#: indicates the order has been created as a result of OROB fulfillment assignment, 9999 is the order number, and 001 is the ship-to number.

  • assigns the Request ID defined for the originating order to the newly created sourcing order.

See Retail Pickup (including Ship-for-Pickup) or Delivery Orders for more information on how Order Administration processes a delivery or retail pickup order.

If the assigned fulfilling location rejects the order: The location assigned to fulfill an order or line can reject it if, for example, it does not have sufficient inventory. In this situation, Order Orchestration uses the rules set up at the Preferences screen in Order Orchestration to select another location to fulfill the order. If the location where the order is currently assigned changes, Order Administration updates this information the next time it sends a status inquiry to Order Orchestration, typically through pick slip generation, and receives the new information in the response.

Note:

An order normally remains in Rejected status in Order Orchestration only for a moment. If for any reason Order Orchestration receives a status inquiry request when the order’s status is Rejected, Order Administration does not update the order until the next time it sends a periodic status inquiry.

What if Order Orchestration cannot find a location to fulfill the order or line? In some cases, Order Orchestration cannot assign an order to a location because there are no locations with sufficient inventory that are eligible based on the business rules set up in Order Orchestration at the Preferences screen. In this situation, Order Orchestration assigns the order to the Default Unfulfillable Location specified in Order Orchestration, which should match the setting of the OROB Default Location Code for Unfulfillable Orders (K56) system control value. When Order Administration receives a response message indicating that the order was assigned to the unfulfillable location and has a status of Unfulfillable, it:

• Clears the Drop ship flag and the Printed quantity on the Order Detail line.

• If the Use OROB for Fulfillment Assignment (M31) system control value is selected or the original order is a ship-for-pickup order, unselects the Bypass reservation flag and updates the Backorder reason to Not enough avail in whse.

• Changes the status of the Order Orchestration record to U (unfulfillable).

• Writes an Order Transaction History record (for example, Ln#: 2 Unfulfillable by Broker).

• Returns the line to standard backorder or soldout processing, including updating the Backorder quantity for the Item Warehouse and updating the PO Layering record.

An order might be flagged as unfulfillable when Order Orchestration first receives the request message, or after one or more locations have rejected the order for fulfillment; in this case, Order Administration receives notification the next time it sends a periodic status inquiry, as described below.

Notifying the customer of fulfillment assignment through Order Orchestration: The order confirmation email indicate a status of Store Ship for order lines assigned to Order Orchestration. See the Order Confirmation Email Sample and Contents for more information.

Fulfillment Process: After Order Creation and Status Updates

Status list inquiry request and response process: The BROKER IJCT job no longer calls the OOCS Status List request message for the latest status where the brokered status is still considered open. Instead, a web service is used to accept status updates from OOCS real-time. After each status update is complete in OOCS, a new Status Update message is sent immediately to OACS giving the current Quantity and Status of every line that was sent in the Status Update request.

If status has not changed: Once the order line is in Accepted status, Order Administration does not write a history record for the status list inquiry response as long as the record remains in this status.

Activity	Status in OOCS	Status in OACS	Updates to Order Orchestration and Order Transaction History
Order Administration sends the submit order message to Order Orchestration and restricts the order line from standard processing in Order Administration by setting the Drop ship flag and the Printed quantity.	not yet created	Waiting (W)	creates an Order Orchestration History record to track the order submission (A - Send Order Request)
Order Administration receives the submit order response from Order Orchestration	new_order	Acknowledged (K)	If there is a single fulfilling location: creates an Order Orchestration History record to track the response (B - Receive Order Response) updates the Order Orchestration record with the assigned fulfilling location writes an Order Transaction History message (for example, Ln#: 1 Acknowledged by Broker) Otherwise, if there are multiple fulfilling locations, Order Administration sends a status inquiry request to Order Orchestration and performs the above activities when it receives the response.
Polling: Each fulfilling location is responsible for polling Order Orchestration periodically to check for new orders. Once Order Orchestration receives a polling request from a location, it sends a polling response, listing the details of all new orders assigned to the location for fulfillment.	polled	Polled (P) (after receiving status inquiry response)	creates an Order Orchestration History record (D - Receive Status Response) writes an Order Transaction History message (for example, Ln#: 1 Polled by Broker)
Order accepted? If the assigned location can fulfill the order or line, it sends a status update message accepting the order or line to Order Orchestration.	accepted	Accepted (A) (after receiving status inquiry response)	creates an Order Orchestration History record (D - Receive Status Response) writes an Order Transaction History message (for example, Ln#: 1 Accepted by Broker) Note: Once the order line is in Accepted status, Order Administration does not write a history record for the status inquiry response as long as the record remains in this status.
Order rejected? If the assigned fulfilling or sourcing location cannot fulfill the order or line, or the pickup location for a ship-for-pickup order indicates that the inventory for the item was not received or was damaged in transit, it sends a status update rejecting the order or line to Order Orchestration. Order Orchestration then:
Attempts to find another location, subject to the rules you have set up in Order Orchestration. If it finds another location, Order Orchestration updates the record in its database and changes the order status back to new_order. Then the process begins again as Order Orchestration waits until the newly-assigned location polls for orders.	new_order	Acknowledged (K) (after receiving status inquiry response)	creates an Order Orchestration History record (D - Receive Status Response) writes an Order Transaction History message (for example, Ln#: 1 Acknowledged by Broker)
If Order Orchestration does not find another fulfilling location, it flags the order or line as unfulfillable by assigning it to the Default Unfulfillable Location you have set up in Order Orchestration (matching the OROB Default Location Code for Unfulfillable Orders (K56) in Order Administration). When Order Administration receives the status inquiry update indicating a fulfilling location that matches the OROB Default Location Code for Unfulfillable Orders (K56), it flags the order or line as unfulfillable and returns the line to standard backorder or soldout processing, clearing the Drop ship flag and the Printed quantity for the order line.	new_order	unfulfillable (U) (after receiving status inquiry response)	creates an Order Orchestration History record (D - Receive Status Response) writes an Order Transaction History message (for example, Ln#: 5 Unfulfillable by Broker)
In Transit (ship-for-pickup, retail pickup): The location assigned to fulfill a ship-for-pickup order has sent the inventory to the location where the customer will pick up the order. Once the fulfilling location has shipped the order or line, it sends a status update message to Order Orchestration, providing the ship via and tracking number if available. Order Orchestration changes the status to In Transit and stores the ship via and tracking number so that it can send this information to Order Administration. The tracking number is not available as a live link on screens.	In Transit	intransit	creates an Order Orchestration History record (D - Receive Status Response) writes Order Transaction History messages indicating the ship via and the tracking number passed from Order Orchestration (for example, ----VIA: UPS and ----TRK#: ABCDEFG1234567890). If there is not tracking information available, writes an Order Transaction History message such as Ln#: 1 Store Shipped Order Create invoice? If the Invoice Ship For Pickup Order Once Intransit (M73) system control value is selected, Order Administration may create the invoice for the originating order when it receives a status inquiry response from Order Orchestration indicating that order lines on a ship-for-pickup order are now in transit. See that system control value for more information. Note: OACS no longer tries to combine Order Orchestration fulfillments into a single invoice but rather it is based on how the fulfilling system sends the request to OOCS. Therefore, for integrating systems, if you send status updates, you need to consider if you send them together or one at a time.
Intransit Polled (ship-for-pickup): The pickup location for a ship-for-pickup order: has received the order in the intransit response message, if the system is not flagged to Require Status Update; or has sent a status update request changing the status to intransit polled	In Transit Polled	intransit polled	creates an Order Orchestration History record (D - Receive Status Response) writes an Order Transaction History message (for example, Ln#: 1 Intransit Polled by Broker) Create invoice? If the Invoice Ship For Pickup Order Once Intransit (M73) system control value is selected, Order Administration may create the invoice for the originating order when it receives a status inquiry response from Order Orchestration indicating that order lines on a ship-for-pickup order are now in transit polled, if the invoice was not already created. See that system control value for more information. Note: OACS no longer tries to combine Order Orchestration fulfillments into a single invoice but rather it is based on how the fulfilling system sends the request to OOCS. Therefore, for integrating systems, if you send status updates, you need to consider if you send them together or one at a time.
Received (ship-for-pickup, retail pickup): The transferred inventory has been received at the location where the customer is picking up a ship-for-pickup order.	Received	received	creates an Order Orchestration History record (D - Receive Status Response) writes an Order Transaction History message (for example, Ln#: 1 Store Received) Create invoice? If the Invoice Ship For Pickup Order Once Intransit (M73) system control value is selected, Order Administration may create the invoice for the originating order when it receives a status inquiry response from Order Orchestration indicating that order lines on a ship-for-pickup order are now received, if the invoice was not already created. See that system control value for more information. Note: OACS no longer tries to combine Order Orchestration fulfillments into a single invoice but rather it is based on how the fulfilling system sends the request to OOCS. Therefore, for integrating systems, if you send status updates, you need to consider if you send them together or one at a time.
Order shipped (delivery) or picked up (ship-for-pickup, retail pickup): Once the fulfilling location has shipped the order or line (delivery) or the customer has picked up the merchandise at the store location (ship-for--pickup), it sends a status update message to Order Orchestration. For delivery orders, the update message also provides the ship via and tracking number if available. Order Orchestration changes the status to fulfilled and stores the ship via and tracking number so that it can send this information to Order Administration. When Order Administration receives notification, it clears the Drop ship flag and the Printed quantity, and submits the order line to billing. If Order Orchestration provides a valid ship via code and a tracking number, the tracking number is a live link in the shipment confirmation email, although not on screens. See the OrderShipmentLineDetail in the outbound email message for details. For more information see the Web Services Guide on https://support.oracle.com My Oracle Support (ID 2953017.1).	fulfilled	completed (X) (after receiving status inquiry or inquiry list response)	writes an Order Transaction History message (for example, Ln#: 2 Store Shipped Order) writes Order Transaction History messages indicating the ship via and the tracking number passed, if any, from Order Orchestration (for example, ----VIA: UPS and ----TRK#: ABCDEFG1234567890) Billing the order: When processing status update responses for the same order, if the status of an order line changes to fulfilled, the BROKER job: Changes the status to fulfilled for each order line if that status is indicated in the response message; Identifies the order lines that were previously in the same status, such as accepted, and are now in fulfilled status; Submits these order lines to billing as a single billing header record. Example: An order previously had two lines in accepted status and one line in acknowledged status. The response message indicates that all three lines are now in fulfilled status. The two order lines whose status changed from accepted to fulfilled are submitted to billing under a single billing header record, creating a single invoice. The one order line whose status changed from acknowledged to fulfilled are submitted to billing as a separate billing header record, creating a separate invoice. Note: Generating a single invoice takes place regardless of whether the fulfilled order lines have different Order Orchestration request IDs, provided the updates take place as described above. Note: The billing async job does not complete billing the order until one of the following occurs: The BROKER job ends, or Another brokered order is submitted to the billing data queue, or All the current status inquiry responses are processed for the company. If a large number of orders were submitted in the status list request, there could be a delay of several minutes before the order is billed. Note: If there are multiple order lines confirmed as fulfilled on a single order, but for different ship-tos, this generates separate billing header records and invoice ship-tos. Multiple invoices are created for a single order if not all order lines are included in the same status list response message.
Order status changes? If the Send Held Orders to OROB (M18) system control value is selected, Order Administration sends held brokered backorders to Order Orchestration, but with the Under Review flag set to Y; also, Order Administration sends an order update to Order Orchestration if the order’s status changes from held to open, or vice versa.	no change	no change	when the change occurs after initial order creation and submission, writes an Order Transaction History message (for example, Request ID: 78390 Under Review: N)

Picked? If the assigned fulfilling location reports that a brokered backorder is in Picked status, the Working with Order Broker (WOBR) option indicates a status of Accepted.

Canceling a brokered backorder: See Canceling a Brokered Backorder Request for a discussion of the updates that take place when you cancel an Order Orchestration request at the Work with Order Broker Screen or in order maintenance.

Reviewing brokered backorders in order inquiry: You can use the Brokered Backorder Summary Screen to review the current status of all brokered backordered lines on a single order. Also, you can select D/S Status for a single brokered backorder line at the Order Inquiry Detail Screen to advance to the Display Order Broker Details Screen, where you can review a single brokered backorder line on the order.

Quantity not indicated in order transaction history messages: The order transaction history messages do not specify the quantity affected by the update; however, if you split orders and lines, the quantity affected may be less than the total order line quantity. For example, if Order Orchestration splits an order line across two locations for fulfillment, and one of the locations fulfills its assigned quantity, the order transaction history message of Ln#: 2 Store Shipped Order does not indicate the fulfilled quantity.

Rules for Submitting Backorders to Order Orchestration

To be eligible for submission to Order Orchestration, the backordered item must have the OROB eligible flag selected. Also, the order line must be:

• fully backordered

• in open status

In addition, if the Use OROB for Fulfillment Assignment (M31) system control value is selected or the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS and the original order is a ship-for-pickup order, the order or order line can include the following; otherwise, the order or order line cannot include the following.

• be gift wrapped

• have any special handling

  Note:

  only custom special handling instructions are sent to Order Orchestration in the submit order request; however, the system does not prevent items with standard special handling from being sent to Order Orchestration

• have a future arrival date or be flagged as a future order

• be for a customer flagged to bypass reservation

If the Use OROB for Fulfillment Assignment (M31) system control value is set to ALWAYS, the originating location passed to Order Orchestration on a delivery order is the location defined in the Originating Location to Pass to OROB (M32) system control value.

Also, if the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS, the order line can be on a ship-for-pickup order; otherwise, if this system control value is set to NEVER or blank, order lines on a ship-for-pickup order are not eligible for submission to Order Orchestration to determine fulfillment assignment and instead are sent to Order Orchestration during pick slip generation and drop ship order processing time; see Ship-for-Pickup Orders.

Regardless of the settings of the Use OROB for Fulfillment Assignment (M31) and Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control values, the order line must not be:

• Flagged as a drop ship item

• A retail pickup or delivery order received from Order Orchestration

• A main set item or a set component

• A membership item

• A stored value card item

• A non-inventory item

Order Administration does not consider the item’s Projected returns quantity, if any, when determining whether the item is eligible for fulfillment through Order Orchestration.

Also, the order must be:

• Open, if the Send Held Orders to OROB (M18) system control value is unselected; otherwise, the order can be held. In this case, the order’s Under Review flag is selected. See the system control value for more information.

• Fully paid and authorized. If the Payment at POS for Ship for Pickup Orders (L60) system control value is selected, ship-for-pickup orders are authorized for verification only and payment is collected when the customer picks up the items at the store.

System control values: If the Use OROB for Fulfillment Assignment (M31) system control value is selected or if the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS and the original order is a ship-for-pickup order, regardless of the setting of the following system control values, the system sends items to Order Orchestration for fulfillment assignment. Otherwise, the following system control values also determine whether an order line is eligible to send to Order Orchestration for fulfillment:

• Order Broker Due Date Threshold (K11): the system does not send an item to Order Orchestration if the item is expected on an open purchase order line for the related warehouse with a due date within the threshold defined in this system control value.

• Order Broker Include Ship Complete Orders (K12): if this system control value is unselected, the system does not send items to Order Orchestration that are on an order flagged to ship complete.

• Order Broker Include Coordinate Grouped Orders (K13): if this system control value is unselected, the system does not send items to Order Orchestration that are coordinate grouped with other items.

• Order Broker Include Gift Orders (K14): if this system control value is unselected, the system does not send items to Order Orchestration that are on a gift order.

Sellout prevented: If an order line meets all of the criteria, it is brokered even if the item is flagged with a soldout control code. See Brokering Items with Soldout Control Codes for a discussion.

BROKER Periodic Function

The BROKER periodic function submits orders to Order Orchestration if they were not eligible for submission when they were created. For example, the periodic function submits order lines if:

• Your company was not configured to send brokered backorders to Order Orchestration when the order was created.

• The order was in held status at initial creation and was subsequently released from hold, and the Send Held Orders to OROB (M18) system control value is unselected.

• The order previously included an active PO item (see About Active PO Items for background).

• The order line was partially reserved, but then the reserved quantity was shipped and there is still a backordered quantity remaining on the order line. The order line is not eligible to be submitted to Order Orchestration until any reserved quantity is printed and shipped.

  Note:

  This situation occurs only if the Use OROB for Fulfillment Assignment (M31) system control value is unselected; also, this situation does not apply to ship-for-pickup orders sent to Order Orchestration for fulfillment assignment.

Note:

When the periodic function submits an order line as a brokered backorder, the function performs all the updates described under Brokered Backorder Fulfillment: Initial Order Creation, but also decreases the Backorder quantity for the Item Warehouse record, since this quantity had been increased when the line was created.

If an authorization is required, the BROKER function obtains an authorization for the entire order.

See Additional Order Orchestration Setup in Order Administration for background on setting up the BROKER periodic function.

Brokering Items with Soldout Control Codes

Items that are OROB eligible and flagged with a S/O control code are still eligible for brokering rather than selling out, provided they meet the Rules for Submitting Backorders to Order Orchestration.

In addition, the following applies if the Use OROB for Fulfillment Assignment (M31) system control value is unselected and the order is not a ship-for-pickup order.

If the soldout control status is:

• sell out immediately: the item is eligible for brokering even if there is an available quantity in an allocatable warehouse.

• include on-order: the item is eligible for brokering if it is backordered. There cannot be an open purchase order that could fulfill the order that is due within Order Orchestration Due Date Threshold (K11), if specified. If no Order Broker Due Date Threshold (K11) is specified, the item is eligible for brokering regardless of open purchase orders. The Projected returns quantity, if any, for the item is not evaluated; see Projected Returns for background on how you can use the Projected returns quantity to prevent selling out items in certain situations.

• exclude on-order: the item is eligible for brokering if it is backordered, regardless of whether there are any open purchase orders.

If the item is unfulfillable: If Order Orchestration is unable to fulfill an order line, the line returns to standard backorder or soldout processing. The process flow is:

• An item is assigned a soldout control value and would be sold out on the order if the item were not OROB eligible. Order Administration submits the order line to Order Orchestration, but there is no store location that can fulfill the item, so Order Orchestration returns a status of Unfulfillable.

• When Order Administration receives the status update from Order Orchestration, it changes the order line status to sold out (S) if the order line is currently eligible to sell out based on the soldout control value and availability.

• The next time you use the Processing Auto Soldout Cancellations (MASO) option, the soldout line is listed on the Auto Soldout Register, even though it did not sell out through Process Auto Soldouts and even if it is not assigned a soldout control status of 1 (sell out immediately).

• The next time you use the Generating Soldout Notifications (MSON) option, Order Administration generates a soldout notification.

The same processing occurs if Order Orchestration returns an error for the brokered order line.

Gift wrap or special handling: Based on the Rules for Submitting Backorders to Order Orchestration, if the Use OROB for Fulfillment Assignment (M31) system control value is unselected or the order is not a ship-for-pickup order, an order line is not eligible for brokering if it is flagged for gift wrap or special handling. If gift wrap or special handling applies to the item:

• When the order line is initially created, then the line does not broker; instead, it sells out or remains backordered, as if it were not flagged as OROB eligible. This is the case when the order API or ecommerce interface creates the order.

• After the order line is initially created (for example, by selecting Special Handling for the line in order entry), then if the soldout control status is:

  • sell out immediately: the line sells out the next time you use Processing Auto Soldout Cancellations (MASO).

  • include on-order quantity or exclude on-order quantity: the line does not sell out automatically.

You can use a backorder report to identify order lines that could not be brokered because of gift wrap or special handling, and that did not sell out automatically. See Order Status and Activity Reports for more information.

Future orders: If the Use OROB for Fulfillment Assignment (M31) system control value is unselected or the order is not a ship-for-pickup order, future orders are not eligible to be brokered; in this situation, items flagged OROB eligible and assigned soldout control values sell out automatically on future orders, just as they would if they were not flagged OROB eligible. Once an order is no longer considered a future order, OROB eligible items on the order can be brokered through the BROKER periodic function if they meet the Rules for Submitting Backorders to Order Orchestration.

If reserving against a non-allocatable warehouse: Based on the Reserve from Non-Allocatable Warehouse (J25) and Disregard Soldout Controls for Non-Allocatable Warehouses (J27) system control values, you can reserve inventory against a non-allocatable (retail) warehouse for a retail order, and disregard an item’s soldout control assignment. In this case, even if the item’s OROB eligible field is selected, the item reserves against the non-allocatable (retail) warehouse if the order type is associated with that warehouse and there is inventory in that warehouse.

Things to Note About Brokered Backorders

Canceling order lines: It is important to confirm that the remote store location assigned to fulfill the order line has not begun the shipment process before you cancel an order line or Order Orchestration request in Order Administration. Depending on the Order Broker Status Update Interval (K10), the most current information about the Order Orchestration request in Order Administration might be out of date.

Freight charges included? Freight charges for the order are included in the SubmitOrder message only if the Use Split Order (L56) system control value is selected.

Customer address updates: If you change the customer’s name or address in Order Administration after generating the initial Order Orchestration request, the Order Orchestration integration does not send this updated information to the assigned fulfilling location. For ship-for-pickup orders, the system does not allow you to change the store location defined as the one-time ship-to address on the order once the order is accepted.

Held orders submitted? When the Send Held Orders to OROB (M18) system control value is unselected, if an order is initially created in held status and then released from hold, Order Administration does not automatically submit the order to Order Orchestration. To submit the order, you can run the BROKER Periodic Function (program PFR0083). See Order Orchestration Configuration for background.

Order lines not resubmitted: If an order line has previously been submitted to Order Orchestration and the Order Orchestration request was flagged as unfulfillable or put in error status, the BROKER periodic function does not resubmit the order line to Order Orchestration for fulfillment.

Reserve quantity limit: If an order line exceeds the Reserve qty (Reserve quantity limit) specified for an item, Order Administration still submits the order line to Order Orchestration for fulfillment, provided the line is eligible based on the Rules for Submitting Backorders to Order Orchestration.

Inventory transaction history: If the Create Item Transaction History for Non-Inventory Items (E39) system control value is selected, Order Administration writes a NONINVISSU transaction record when the BROKER process receives a status update indicating that the assigned location has shipped the order or line. See that system control value for more information.

Backorder notices: The Generate Backorder Notices (GBOC) option does not generate backorder notices for an order line when it has an Order Orchestration request in process; however, if the status of the Order Orchestration request changes to unfulfillable (U) or error (E), or if you cancel the Order Orchestration request (Z) without canceling the order line itself, the order line returns to standard backorder processing and is eligible to have backorder notices generated.

Tracking numbers in shipment confirmation email: If the fulfilling location supplies information on the shipping agent and a tracking number, Order Orchestration passes this information to Order Administration. If the shipping agent matches a valid ship via code in Order Administration, the shipment confirmation email lists the description of the ship via and the tracking number as a live link. Otherwise, if the shipping agent does not match a ship via set up in Order Administration, then the shipment confirmation lists the shipping agent as it was passed from Order Orchestration, and the tracking number is plain text.

Note:

If a brokered backorder ships on the same day as a warehouse shipment, the shipment confirmation email includes just the tracking number for the brokered backorder. This occurs regardless of whether you consolidate invoices.

See the Shipment Confirmation Email Sample and Contents for more information, and see the OrderShipmentLineDetail for detailed mapping.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Important:

In Order Management System 21.0 or higher, or Order Administration, you cannot select the Consolidated Invoice system control value if it is not already selected. If the system control value is currently selected (set to Y) and you deselect it (change it to N or blank), you cannot then change it back to selected. The option to consolidate invoices will be removed at a later date.

Tracking numbers in customer history API: If Order Orchestration passes the shipping agent and a tracking number, the Detailed Order Inquiry Response XML Message (CWORDEROUT) includes this information provided Order Administration can link the line number, shipping agent, and tracking number from the Order Transaction History messages to the invoice based on date.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Example:

The fulfilling location supplies information on the shipping agent and the tracking number to Order Orchestration, and Order Orchestration passes this information to Order Administration.

Order Administration writes Order Transaction History records such as:

SHIPMENT Ln#: 5 Store Shipped Order

SHIPMENT ----VIA: ABC

SHIPMENT ----TRK#: ABI123

The Order Transaction History records have the same date as the invoice.

The CWORDEROUT message passed through the customer history API includes the tracking information, for example:

<Shipment invoice_nbr="123456" invoice_ship_quantity="1" invoice_ship_date="11292011" invoice_tracking_nbr="ABI123" invoice_ship_via_desc="ABC"/>

Note:

• If Order Administration 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 Administration 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.

• The tracking information from Order Orchestration is not available as a live link on screens.

Other Order Orchestration orders not eligible: Order Administration does not submit a backordered delivery or retail pickup order to Order Orchestration for fulfillment. In addition, if the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to NEVER or blank, Order Administration does not submit a backordered ship-for-pickup order to Order Orchestration for fulfillment.

Line_locate_eligible flag in the CWORDEROUT message: If the Send B/O to OROB (K08) system control value is selected, the Detailed Order XML Response (CWORDEROUT) message used in the generic order API includes a flag for each order line to indicate whether the order line meets the Rules for Submitting Backorders to Order Orchestration. Even if this flag is set to Y, it is possible that the line cannot be fulfilled as a brokered backorder if, for example, Order Orchestration does not find a location that has the item available.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

The Generic Customer History API also uses the CWORDEROUT message. The message includes the line_locate_eligible flag if the order line is still open. In the case of the generic customer history API, the line_locate_eligible flag might be set to Y even if, for example, the line was already submitted to Order Orchestration, and then returned to normal backorder processing because Order Orchestration did not find a location to fulfill it.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Order Orchestration requires postal code: If the shipping address on a brokered backorder does not include a postal code, the Order Orchestration Order Orchestration rejects it. The Require postal code? flag for the country determines whether a postal code is required. See Setting Up the Country Table (WCTY) for background.

Reviewing brokered backorders in order inquiry: You can use the Brokered Backorder Summary Screen to review the current status of all brokered backordered lines on a single order. Also, you can select D/S Status for a single brokered backorder line at the Order Inquiry Detail Screen to advance to the Display Order Broker Details Screen, where you can review a single brokered backorder line on the order.

The OBR status remains on each order line that is fully or partially fulfilled through Order Orchestration as a brokered backorder. This status is displayed on the Order Inquiry Detail Screen.

The original backorder reason remains on the order line after fulfillment through Order Orchestration as a brokered backorder. This reason is displayed on the Display Order Detail Screen (Reviewing Order Line Detail). Typically, the backorder warehouse also remains on the order line as well, and is displayed on the Display Order Detail Screen (Reviewing Order Line Detail); however, if a shipment from the warehouse follows the fulfillment through Order Orchestration, the backorder warehouse field is cleared.

Order Orchestration Originating Location, Fulfilling Location, and Pickup Location

The screens in the Working with Order Broker (WOBR) menu option display the following types of locations: originating, fulfilling, and pickup.

• The Originating location is the location (store or warehouse) where the order originated. This location displays as the Placed location in Order Orchestration.

• The Fulfilling location is the location supplying the inventory for the order. This location displays as the Sourced location in Order Orchestration.

• The Pickup location is the location where the customer picks up the order; this location does not display for orders that are shipped to the customer. This location displays as the Pickup location in Order Orchestration.

The following table explains how the system determines the originating, fulfilling, and pickup locations for each broker delivery type.

Broker delivery type	Originating location	Fulfilling location	Pickup location
blank (brokered backorder for delivery or ship-for-pickup)	an Order Administration warehouse this is the location_cd in the store_location element of the submit order request message: if the transaction_type_id is DELIVERY and the Use OROB for Fulfillment Assignment (M31) is unselected, from the OROB Default Location (K51) if the transaction_type_id is DELIVERY and the Use OROB for Fulfillment Assignment (M31) is selected or the transaction_type_id is SHIPFORPICKUP, from the Originating Location to Pass to OROB (M32)	the store location or Order Administration warehouse assigned to ship the item to the customer this is the fulfillment_location_cd in the fulfillment_detail element of the submit order response message; when a status request response message is received, the location may update based on the fulfilling_location_cd in the items element	delivery: N/A; the order is shipped to the customer ship-for-pickup: this is the location_cd in the shipforpickup_location element of the submit order request message: from the store code in the one-time ship-to address
delivery	a store location or Order Administration warehouse this is the request_location_cd in the store_location element of the fulfillments response message	an Order Administration warehouse this is the location_cd in the store_location element of the fulfillments response message	N/A; the order is shipped to the customer
store pickup	an Order Administration warehouse this is the location_cd in the store_location element of the submit order request message: from the OROB Default Location (K51)	the store location the customer has selected to pick up the order; the inventory is available at this location and does not need to be transferred there this is the fulfillment_location_cd in the fulfillment_detail element of the submit order response message	the store location where the customer has selected to pick up the order this is the location_cd in the first transaction_detail element of the submit order request message: from the location, selected at the Store Pickup Search Results Screen, where the customer wants to pick up the order
retail pickup (traditional retail pickup and retail pickup created as a result of a brokered ship-for-pickup)	the store location where the customer would like to pick up the merchandise this is the request_location_cd in the store_location element of the fulfillments response message	an Order Administration warehouse this is the location_cd in the store_location element of the fulfillments response message	the store location where the customer has selected to pick up the order this is the location_cd in the shipforickup_location element of the fulfillments response message
ship-for-pickup (pick gen/drop ship)	an Order Administration warehouse this is the location_cd in the store_location element of the submit order request message: from the OROB Default Location (K51) if the Send Inventory by Warehouse to OROB (L06) system control value is unselected or for a drop ship item; otherwise, from the OROB location from the warehouse associated with the order	an Order Administration warehouse this is the location_cd in the transaction_detail element of the submit order request message: from the OROB Default Location (K51) if the Send Inventory by Warehouse to OROB (L06) system control value is unselected or for a drop ship item; otherwise, from the OROB location from the warehouse associated with the order	the store location where the customer has selected to pick up the order this is the location_cd in the shipforpickup_location element of the submit order request message: from the store code in the one-time ship-to address

Location description: Even if the location is a warehouse within your company in Order Administration, the description of the location is from the cross-reference record set up through Work with Store Cross Reference (WSCR), and is separated from the code by a hyphen. For example, a request assigned to warehouse 10, East Coast DC, lists a location of 10 - East Coast. Although the location code field in the Order Administration database is 25 positions, you cannot create a code that exceeds 10 positions in Order Orchestration.

Note:

• The location description is stored in the Order Orchestration table. Entering or updating a location cross reference through Work with Store Cross Reference (WSCR) does not update the originating location displayed here.

• The location description displayed here is blank if you had not set up the cross reference at the time the response was received from Order Orchestration.

• Even if the location is an Order Administration warehouse, the warehouse description is not displayed here; you need to set up the cross-reference through Work with Store Cross Reference (WSCR).

When is the fulfilling location blank? The fulfilling location is blank for:

• store pickup orders: if you canceled the order in Order Administration. If another location sent a cancel request to Order Orchestration, which relayed it to Order Administration through a status inquiry request, the Order Orchestration record retains the fulfilling location; however, if a single line on a store pickup order is rejected, the entire order (including any additional lines) is canceled, and in this situation the fulfilling location is blank for all items except the rejected item.

• brokered backorders whose status is:

  • Z: Canceled

  • C: Closed

  • J: Rejected

  • R: Ready

  • W: Waiting

The field might also be blank for requests in E: Error status, depending on the nature of the error. For example, requests that Order Orchestration did not receive and create successfully are not assigned to fulfilling locations.

Unfulfillable status: If Order Orchestration was unable to find a location to fulfill a brokered backorder, the fulfilling location matches the OROB Default Location Code for Unfulfillable Orders (K56) system control value. In this situation, the current status is Unfulfillable.

Order Orchestration Status Summary Table

The following table summarizes the status codes displayed at the screens in the Working with Order Broker (WOBR) menu option.

OACS status	OOCS status	Order types	Description
A (Accepted)	Accepted or Picked	brokered backorder (delivery or ship-for-pickup) or store pickup	The location assigned to fulfill the order has accepted it, or has accepted the order and is preparing it for shipment or pickup.
C (Closed)	N/A	brokered backorder (delivery or ship-for-pickup)	You canceled the request when its status was R (Ready), before it was submitted to Order Orchestration.
E (Error)	N/A	Any order type	Order Orchestration has returned an error response. See Troubleshooting the Order Orchestration Integration for information on some possible errors. A record might also be in Error status if another system submitted a status update request to Order Orchestration to cancel the order line.
F (Picking)	New_Order or Picked	retail pickup, delivery, or ship-for-pickup (pick gen/drop ship)	The pick slip has been printed.
G (Resend Fulfilled)	N/A	delivery	The Order Status Update request message to change the status in Order Orchestration to fulfilled did not generate a response message from Order Orchestration, possibly because message authentication failed or communication is down. In this case, the BROKER_ORD job re-sends the Order Status Update request the next time it runs.
H (Resend Intransit)	N/A	ship-for-pickup	The Order Status Update request message to change the status in Order Orchestration to intransit did not generate a response message from Order Orchestration, possibly because message authentication failed or communication is down. In this case, the BROKER_ORD job re-sends the Order Status Update request the next time it runs.
I (In Process)	Accepted	retail pickup or delivery	The order was received from Order Orchestration and created without error.
J (Rejected)	unknown (order reassigned to new fulfilling location)	retail pickup or delivery	The order was sold out after creation in Order Administration.
K (Acknowledged)	New_Order	brokered backorder (delivery or ship-for-pickup) or store pickup	Order Orchestration has received the order request, assigned a request ID, selected a fulfilling location (brokered backorder), and created the order in its database.
L (Partial Fulfill)	Partially Fulfilled	retail pickup, ship-for-pickup, or store pickup	The customer has picked up one or more items on the order, but not the complete order.
N (New)	Polled	retail pickup or delivery	The order was received from Order Orchestration but is in error.
O (Posted)	Posted	brokered backorder, store pickup, or ship-for-pickup	Order Orchestration has submitted the order or order line for enterprise fulfillment. See Enterprise Order Integration (Future Receipts and Active PO/Pre-Order Processing) for background.
P (Polled)	Polled	Any order type	Brokered backorder (delivery or ship-for-pickup) or store pickup: The assigned fulfilling location has polled Order Orchestration for new orders and been notified of this order. Retail pickup or delivery order: Order Administration created the order in held status.
R (Ready)	N/A	brokered backorder (delivery or ship-for-pickup), store pickup	Brokered backorder: The request is ready to be sent to Order Orchestration, but the BROKER_ORD process has not yet generated the request message. Store pickup: Order Administration attempted to send the order to Order Orchestration, but Order Orchestration has not responded. In this case, Order Administration retains the order information in the Store Pickup tables until communication with Order Orchestration resumes.
S (Received by Store)	Received	brokered backorder (ship-for-pickup), retail pickup or ship-for-pickup	The order has been received by the store location but not yet picked up by the customer. NOTE: This status is not displayed for ship-for-pickup or retail pickup orders that are actually in this status in Order Orchestration after Order Administration has submitted a status update message to Order Orchestration indicating that the merchandise is in transit to the pickup location; instead, the displayed status is X (Completed).
T (In Transit)	Intransit	brokered backorder (ship-for-pickup), retail pickup or ship-for-pickup	Ship-for-pickup: The location fulfilling the order has shipped the merchandise to the store for pickup. NOTE his status is displayed for ship-for-pickup if Use OROB for Ship for Pickup Fulfillment Assignment (M34) is set to ALWAYS; however, it is not displayed for retail pickup orders, or for ship-for-pickup orders if Use OROB for Ship for Pickup Fulfillment Assignment is set to NEVER, if the orders are actually in this status in Order Orchestration after Order Administration has submitted a status update message to Order Orchestration indicating that the merchandise is in transit to the pickup location; instead, the displayed status is X (Completed).
U (Unfulfillable)	N/A (brokered backorder) or Rejected (store pickup)	brokered backorder (delivery or ship-for-pickup) or store pickup	Brokered backorder: Order Orchestration has not found a location able to fulfill the order based on the rules set up in Order Orchestration. When it receives a response indicating that Order Orchestration cannot fulfill the order, Order Administration returns the order line to standard backorder or soldout processing. Store pickup: the assigned store location has rejected the order.
V (In Transit Polled)	Intransit Polled	brokered backorder (ship-for-pickup), retail pickup or ship-for-pickup (pick gen/drop ship)	The pickup location for a ship-for-pickup order line: has received the order line in the intransit response message, if the system is not flagged to Require Status Update; or has sent a status update request changing the status to intransit polled. Only the pickup location for a ship-for-pickup order can update the status to intransit polled. This status applies only to ship-for-pickup orders. NOTE: This Status is not displayed for ship-for-pickup or retail pickup orders that are actually in this status in Order Orchestration after Order Administration has submitted a status update message to Order Orchestration indicating that the merchandise is in transit to the pickup location; instead, the displayed status is X (Completed).
W (Waiting)	unknown	brokered backorder (delivery or ship-for-pickup)	The order request message has been sent to Order Orchestration, but Order Administration has not yet received a response.
X (Completed)	Fulfilled	all order types	Brokered backorder (delivery or ship-for-pickup): The fulfilling location assigned by Order Orchestration has shipped the item to the customer or the customer has picked up the entire order from the store. When Order Administration receives a status update indicating that the order line has been shipped, it bills the order line and saves the ship via and tracking number, if indicated in the response message, to the Order Transaction History table. Delivery: You have confirmed shipment of the order to the customer. Retail pickup, ship-for-pickup (pick gen), or store pickup: The customer has picked up the entire order. NOTE: This status is also displayed for retail pickup orders, and ship-for-pickup orders if Use OROB for Ship for Pickup Fulfillment Assignment (M34) is set to NEVER, after Order Administration has submitted a status update message to Order Orchestration indicating that the merchandise is in transit to the pickup location, even if the customer has not yet picked up the order.
Y (Pending Cancel)	unknown	brokered backorder (delivery or ship-for-pickup), store pickup, retail pickup, delivery, or special ship-for-pickup	Brokered backorder: You have canceled the order line (including the Order Orchestration request), or you have canceled just the Order Orchestration request at the Work with the Order Orchestration Screen, but you have not yet received a confirmation of the cancellation from Order Orchestration. Store pickup: You have canceled the order, but you have not yet received a confirmation of the cancellation from Order Orchestration. Retail pickup, delivery, or special ship-for-pickup: You have voided the pick slip through the generic pick in API and the Cancel Reason (Pick In) (L86) system control value specifies a cancel reason, or a backorder cancellation reason code is specified in the CWPickIn XML Message, but you have not yet received a confirmation of the cancellation from Order Orchestration. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
Z (Canceled)	Canceled	brokered backorder (delivery or ship-for-pickup), store pickup, special ship-for-pickup, or retail pickup	You have requested that the Order Orchestration order be canceled, and Order Orchestration has confirmed the cancellation. If the order line itself is not canceled, it returns to regular backorder processing. Note: If a status inquiry list response from Order Orchestration indicates that a brokered backorder line is canceled, the original Order Administration order line is put in error status; as a result, the canceled order line is either reserved, backordered, or sold out in Order Administration. If there is a fulfilling (bounceback) order that was created in Order Administration, it is put in Held status, with an order transaction history note of Order held - line[s] canceled in Order B.

Retail Pickup (including Ship-for-Pickup) or Delivery Orders

Overview: Use the retail pickup or delivery options in the Order Orchestration Integration to receive orders from Order Orchestration in order to fulfill the orders in Order Administration.

• If the order is a retail pickup order or a retail pickup order that originated as a ship-for-pickup order, Order Administration ships the merchandise to the customer-selected store location for pickup.

• If the order is a delivery order, Order Administration ships the merchandise to the customer’s ship-to address.

If the originating location was Order Administration: If the Use OROB for Fulfillment Assignment (M31) system control value is selected or the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS, the order may have originated in Order Administration and during Brokered Backorders processing, Order Orchestration determined that Order Administration was the best fulfilling location. In this situation:

• Order Orchestration assigns the Order Administration location to the originating order in Order Orchestration as the Fulfilling location. See Brokered Backorders for additional processing information.

• At defined intervals, the BROKER process in Work with Integration Layer Processes (IJCT) periodically sends a fulfillments request message to Order Orchestration to poll for newly assigned orders (those whose Fulfilling location is an Order Administration location). See Retail Pickup (including Ship-for-Pickup) and Delivery Order Processing for additional processing information.

• When the BROKER process receives the order in the fulfillments response message, it looks at the values in the fulfillments response to determine the type of order to create.

  • The system creates a new delivery order if the transaction_type_id is DELIVERY.

  • The system creates a new retail pickup order if the transaction_type_id is RETAILPICKUP or SHIPFORPICKUP.

  See Building the Retail Pickup (including Ship-for-Pickup) or Delivery Order for additional information.

• In order to tie the originating order (the original order sent to Order Orchestration for fulfillment assignment) with the new sourcing order (the delivery or retail pickup order created to fulfill the original order), Order Administration stores the originating order number in the E-commerce order number field in the Order Header Extended table for the newly created sourcing order and prefixes the order number with the text ORIG#:. For example, the system updates the E-commerce order number with ORIG#: 9999-001, where ORIG#: indicates the order has been created as a result of Order Orchestration fulfillment assignment, 9999 is the order number, and 001 is the ship-to number. See Reviewing Retail Pickup (including Ship-for-Pickup) or Delivery Orders in Order Inquiry for additional information.

In this topic:

• Retail Pickup (including Ship-for-Pickup) and Delivery Order Processing

• Building the Retail Pickup (including Ship-for-Pickup) or Delivery Order

• Retail Pickup (including Ship-for-Pickup) or Delivery Processing after Order Creation

• Reviewing Retail Pickup (including Ship-for-Pickup) or Delivery Orders in Order Inquiry

• Things to Note about Retail Pickup (including Ship-for-Pickup) and Delivery Orders

For more information: See Reauthorization and Under Review Hold Scenarios for Orders Fulfilled through Order Orchestration.

Retail Pickup (including Ship-for-Pickup) and Delivery Order Processing

Poll for orders? If both the Order Type for Orders Brokered for Delivery (K91) and Order Type for Retail Pickup Orders Brokered to OROMS (K92) system control values specify order types, the BROKER process in Working with Integration Layer Processes (IJCT) periodically sends a fulfillments request message to Order Orchestration to poll for newly assigned orders. The polling interval is based on the Outbound delay time specified for the BROKER process.

fulfillments request: Information in the fulfillments request message includes:

• requesting location: From the OROB Default Location (K51) if the Send Inventory by Warehouse to OROB (L06) system control value is unselected; otherwise, from the OROB location from each warehouse that has this field populated. The requesting location must match an existing location set up in Order Orchestration.

• message source and requesting system: From the OROB System (K50).

• destination: From the OROB Account (K49).

See the Fulfillments Request Message Sample (Retail Pickup, Ship-for-Pickup, or Delivery Orders) in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for an example.

The endpoint where Order Administration sends the fulfillments request message is specified in Working with Customer Properties (PROP).

Create order? When the BROKER process receives an order in the fulfillments response message, it:

• Checks the setting of the Retain Backordered Lines Brokered to OROMS (K89) system control value. If this value is unselected and there is not a purchase order that might be able to fulfill the order expected within the Order Broker Due Date Threshold (K11), the process rejects the order. The process uses the Send Inventory by Warehouse to OROB (L06) system control value to determine whether to check a specific warehouse, or to check across all warehouses.

• Regardless of the setting of the Retain Backordered Lines Brokered to OROMS (K89) system control value, if the only item on the order is sold out, the process rejects the order.

Note:

• Drop ship items are eligible to be fulfilled on a retail pickup or delivery order regardless of whether any units are currently stocked in the warehouse, provided they are not flagged with a soldout control value.

• If a retail pickup or delivery order includes multiple order lines, and one of them is sold out, Order Administration still accepts the order. To avoid this situation, have integrating systems submit each order line as a separate order.

Multiple order lines? Submit each ordered unit to Order Orchestration as a separate order. Sending orders this way prevents any inconsistencies in order status that might occur if, for example, a multi-line order in Order Administration included a soldout item, but the other order lines could still be shipped from the warehouse, or if a multi-unit line was split across different warehouses for fulfillment.

Building the Retail Pickup (including Ship-for-Pickup) or Delivery Order

The processing to build a new retail pickup or delivery order from the contents of the fulfillments response message is similar to that used by the generic order API. In addition to the system (company) and location (warehouse) sent in the fulfillments request message, the information used to build the order includes the following.

• Header Information

• Customer Mapping and Updates

• Ship-to Information

• Detail Information

• Payment Information

• Order Messages

• Additional Information on Mapping

Header Information

• order type: from one of the following system control values:

  • Order Type for Orders Brokered for Delivery (K91): the system assigns this order type to delivery orders whose originating location is not Order Administration.

  • Order Type for Retail Pickup Orders Brokered to OROMS (K92): the system assigns this order type to retail pickup orders whose originating location is not Order Administration.

  • Order Type for Delivery Orders Originating in OROMS (M33): the system assigns this order type to delivery orders whose originating location is Order Administration. The system identifies the originating location as Order Administration if the request_system_cd in the fulfillments response message matches the system code in the OROB System (K50) system control value.

  • Order Type for Retail Pickup Orders Originating in OROMS (M35): the system assigns this order type to retail pickup orders whose originating location is Order Administration. The system identifies the originating location as Order Administration if the request_system_cd in the fulfillments response message matches the system code in the OROB System (K50) system control value.

  The transaction_type_id in the fulfillments response message indicates whether the order is a retail pickup or delivery order.

  • DELIVERY displays if the order is a delivery order.

  • RETAILPICKUP displays if the order is a retail pickup order.

  • SHIPFORPICKUP displays if the order is a retail pickup order that originated as a brokered ship-for-pickup order.

• order channel (Internet order): set to C. The transaction_channel specified in the fulfillments response message is not used.

• alternate order number: from the order number in the originating system, passed as the order_id from the fulfillments response (the external system’s order number). The system stores this number in the E-commerce order number field in the Order Header Extended table. If the originating location is Order Administration, the system prefaces the alternate order number with ORIG#: 1234-001, where ORIG#: indicates the order was created as a result of OROB fulfillment assignment, 1234 is the order number, and 001 is the ship-to number.

  Note:

  The system identifies the originating location as Order Administration if the request_system_cd in the fulfillments response message matches the system code in the OROB System (K50) system control value.

• order date: the current date.

• entered date: the current date.

• source code:

  • If the order did originate in Order Administration:

    • Use the Order Broker Source Code (K93), if specified; otherwise, if this system control value is blank,

    • Use the source code, if any, specified for the store cross reference record for the originating location, which is based on the Originating Location to Pass to OROB (M32) system control value; otherwise,

    • Use the source code passed in the fulfillments response message from Order Orchestration, which would be from the originating order.

  • If the order did not originate in Order Administration:

    • Use the source_code, if any, passed in the fulfillments response message from Order Orchestration; otherwise,

    • Use the source code, if any, specified for the store cross reference record for the originating location; otherwise,

    • Use the Order Broker Source Code (K93), if specified; otherwise, if this system control value is blank,

    • The order is created in error status because of the missing source code.

Customer Mapping and Updates

If the ORCE Customer ID in OROB Fulfillment (M72) system control value is NOT selected:

• customer number:

  • if the customer_no passed in the fulfillments response is a valid customer number, then use this customer. For example, a customer_no of 13827 or 000013827 indicates sold-to customer 13827. Zero-filling the customer number is optional. Otherwise,

  • if the customer_no passed is invalid, or if no customer_no was passed, then Order Administration uses standard name and address matching. See Customer Sold To Selection, Creation and Update in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more background.

    Note:

    If the customer_no is invalid, the error is logged in Order Administration’s APP.log file, even though the order can still be created successfully using the name and address information in the message.

  Note:

  If the Sold to Email Update for Orders Brokered to OROMS (K96) or Sold to Address Update for Orders Brokered to OROMS (K97) system control values are selected, Order Administration updates the existing customer record with any changed information.

• email address updated? The Sold to Email Update for Orders Brokered to OROMS (K96) system control value indicates whether to update the customer’s email address with the email address passed for the order.

• sold-to phone numbers: the phone1 passed updates the customer’s daytime phone number and the phone2 passed updates the customer’s evening phone number if the Sold to Address Update for Orders Brokered to OROMS (K97)Sold to Address Update for Orders Brokered to OROMS (K97)Sold to Address Update for Orders Brokered to OROMS (K97)Sold to Address Update for Orders Brokered to OROMS (K97)Sold to Address Update for Orders Brokered to OROMS (K97)Sold to Address Update for Orders Brokered to OROMS (K97) system control value is selected. Any non-numeric characters passed in the phone numbers are stripped out.

If the ORCE Customer Integration (L37) system control value IS selected and the ORCE Customer ID in OROB Fulfillment (M72) is not selected:

• customer number:

  • Matching customer number: if the customer_no passed in the fulfillments response is a valid customer number, then use this customer. For example, a customer_no of 13827 or 000013827 indicates sold-to customer 13827. Zero-filling the customer number is optional.

    • If the matching customer based on the customer number has an ORCE customer ID, update the customer and pass the update to Customer Engagement.

    • If the matching customer based on the customer number does not have an ORCE customer ID, update the customer and pass the update to Customer Engagement, then update the customer with the ORCE customer ID returned from Customer Engagement.

  • No matching customer number: if the customer_no passed is invalid, or if no customer_no was passed, then Order Administration uses standard name and address matching. See Customer Sold To Selection, Creation and Update in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more background.

  • Order Administration then passes the customer information to Customer Engagement, and updates the customer with the ORCE customer ID returned from Customer Engagement.

    Note:

    If the customer_no is invalid, the error is logged in Order Administration’s APP.log file, even though the order can still be created successfully using the name and address information in the message.

If the ORCE Customer Integration (L37) system control value IS selected and the ORCE Customer ID in OROB Fulfillment (M72) IS ALSO selected:

• Matching customer based on ORCE customer ID: If the ORCE customer ID is passed as the customer_no, and a customer with same ORCE customer ID is found, update the customer record if needed but do not send an update to Customer Engagement.

• No matching customer based on ORCE customer ID: If the ORCE customer ID is passed as the customer_no, but no matching customer based on the ORCE customer ID is found, call out to Customer Engagement to get the customer information based on the ORCE customer ID, and create the customer in Order Administration based on the response from Customer Engagement.

• No customer_no passed: Order Administration uses standard name and address matching. See Customer Sold To Selection, Creation and Update  in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more background.

• Order Administration then passes the customer information to Customer Engagement, and updates the customer with the ORCE customer ID returned from Customer Engagement.

Additional customer information updates if not matching based on ORCE customer ID:

• sold-to name and address: the information passed in the fulfillments response message is used to create or update the customer; however, if the customer number passed in the fulfillments response is valid and the Sold to Address Update for Orders Brokered to OROMS (K97) system control value is unselected, the process does not update the customer information. If the customer does not already exist, the name is created in all upper case even if passed from Order Orchestration in upper and lower case.

• apartment or address line 4:

  • If the apartment tag is passed, the first 10 positions are saved as the sold-to apartment number.

  • If no apartment tag is passed, but an address line 4 is passed, the first 10 positions of address line 4 are saved as the sold-to apartment number.

  • If both the apartment tag and address line 4 are passed, then the first 10 positions of the apartment are saved as the sold-to apartment number, as indicated above, and address line 4 is saved as the fourth address line for the sold-to customer.

• email address updated? The Sold to Email Update for Orders Brokered to OROMS (K96) system control value indicates whether to update the customer’s email address with the email address passed for the order.

• sold-to phone numbers: the phone1 passed updates the customer’s daytime phone number and the phone2 passed updates the customer’s evening phone number if the Sold to Address Update for Orders Brokered to OROMS (K97) system control value is selected. Any non-numeric characters passed in the phone numbers are stripped out.

Ship-to Information

• ship complete? from the ship_complete setting passed in the fulfillments response message; otherwise, from the Ship Complete for Orders Brokered to OROMS (L01) system control value.

• ship via: from the Order Broker Ship Via (K94) system control value if there is not a valid, numeric ship_via passed in the fulfillments response message. If the Order Broker Ship Via (K94) is blank, the Default Ship Via (A77) applies.

• gift order? from the Gift Flag for Orders Brokered to OROMS (L03). This system control value overrides the setting passed in the fulfillments response message.

• freight charges: from the freight_amount specified in the fulfillments response message, if any; otherwise, Order Administration calculates freight. If an additional freight charge is specified for the ship via, Order Administration adds it to the order.

• tax: the total of the detail-level tax amount passed in the fulfillments response message for each item, plus any tax calculated based on freight and handling charges. The order-level tax amount passed in the message is not used to build the order.

• freight tax override: always selected, regardless of the setting of the Tax on Freight (B14) system control value.

• purchase order number: from the ref_transaction_no passed in the fulfillments response message. Displayed at the Display Order Properties Screen in standard order inquiry and at the Third Streamlined Order Inquiry Screen (Order Summary).

• warehouse: If the Send Inventory by Warehouse to OROB (L06) system control value is selected, this is based on the OROB location for the warehouse sending the fulfillments request message.

• delivery type (retail pickup or delivery): from the transaction_type_id specified in the fulfillments response message. SHIPFORPICKUP transaction types map to a retail pickup delivery type.

• ship-to name and address: from the ship_to information for the first item on the order; the ship-to information for any additional item(s) is not used. Creates an Order Ship To Address record, which you can review at the Display Alternate Address Screen. The one-time ship-to phone number is from the phone1, if any, for the first item. If no phone1 is passed for the first item, then the phone2 for the first item is used. For a retail pickup order, the ship-to name and address should specify the name and address of the originating store location. The process creates a one-time ship-to address. If the customer does not already exist, the name is created in all upper case even if passed from Order Orchestration in upper and lower case.

• store location and system:

  • location_cd: the location fulfilling the order. This is the fulfilling, or sourced, location. For delivery and retail pickup orders, this is always an Order Administration warehouse. This is the Store # for the Store Cross Reference record.

  • system_cd: Order Administration. This is the OROB System (K50).

  • request_location_cd: the location generating the order. This is the originating, or placed, location. This can be a store location or an Order Administration warehouse if the original order was from Order Administration and was brokered for fulfillment assignment. This is the Store # for the Store Cross Reference record.

  • request_system_cd: If the order originated in a store, this is the code identifying your POS system, from the System Code, if any, for the Store Cross Reference record; otherwise, from the Name in OROB for Point of Sale (L09). If the order originated in Order Administration, from the System Code, if any, for the Store Cross Reference record; otherwise, from the OROB System (K50).

• ship-for-pickup location and system:

  • location_cd: the store location where the customer picks up a ship-for-pickup order. This is the pickup location. From the Store # for the Store Cross Reference record.

  • system_cd: The code identifying your POS system, from the System Code, if any, for the Store Cross Reference record; otherwise, from the Name in OROB for Point of Sale (L09).

Detail Information

The process creates an order detail line for each item passed in the fulfillments response message. Also:

• price: the unit_price from the fulfillments response message. Order Administration does not recalculate the price.

• price override reason code: from the Order Broker Price Override (K95) system control value.

• requesting system line number: from the requesting_system_line_no passed in the fulfillments response message. Identifies the line number in the originating system.

• quantity: the qty from the fulfillments response message.

• gift wrap: from the order_line_gift_wrap flag setting passed in the fulfillments response message. The gift wrap charge specified in the Item Offer, multiplied by the unit quantity, is included in the Handling bucket.

• order line messages: from the order_line_message passed in the fulfillments response message:

  • If the message passed exceeds the field length of 60 positions, the message is continued on an additional message line.

  • The Print flag for the message lines is set to B (both invoices and pick slips).

• customization: customization is created for an order line only if:

  • the Item Offer associated with the source code on the order header specifies an additional charge code for a custom special handling format that includes a single line of customization instructions, and

  • the customizations element in the message specifies a customization_code and customization_message

    If:

  • there is no custom special handling format specified for the Item Offer, the information from the customization_code and customization_message are saved as Order Line Messages, with a Print flag of P (Picks), and the order is not suspended with an error.

  • the special handing format detail specifies any valid responses, and the customization message passed is not one of the responses, the order is suspended with an error of Input not valid response

  • the special handling format detail specifies a Max # characters, and the customization message passed exceeds this length, the order is suspended with an error of Exceeds max character

  Note:

  • Order Administration does not validate that the customization_code matches the Field label for the special handling format detail.

  • Custom special handling formats that include more than one detail line are not currently supported for retail pickup and delivery orders received from Order Orchestration.

  • Regardless of whether Order Administration creates custom special handling for an order line, any order_line_customization_charge is still applied to the Handling bucket on the order.

  • The Evaluate Special Handling Charges by Order Line (D67) system control value determines whether to multiply the customization charge passed in the message by the unit quantity.

• Tax amount: from the tax amount passed for the item in the fulfillments response message. Order Administration does not recalculate tax for items.

Note:

Only the tax amounts passed at the detail level are added to the order in Order Administration; the transaction_tax from the fulfillments response message header level is not used.

Payment Information

• pay type: from the Order Broker Payment Type (K98).

• credit card number: From the description of this pay type.

• suppress deposit flag: set to Y.

• suppress refund flag: set to Y.

Note:

The tender information, if any, passed in the fulfillments response message is not used.

Order Messages

• originating store location: written as an Order Message, for example: Originating Store: 317.

• request ID: written as an Order Message, for example: OROB Request ID: 123456. This information is also saved in the Order Orchestration record.

• special instructions: the special_instructions at the Order level from the fulfillments response message are written as an Order Message in capital letters, for example: ADD MONOGRAM HEB.

• additional order messages: the order_message is written as one or more Order Message lines:

  • If the message passed exceeds the field length of 60 positions, the message is continued on an additional message line.

  • The Print flag for the message lines is set to B (both invoices and pick slips).

Note:

Special instructions passed at the item level in the fulfillments response message are not retained.

See the Fulfillments Response Message Sample in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for an example.

Additional Information on Mapping

If any of the information passed in the fulfillments response message exceeds the maximum field length in Order Administration, the information is truncated.

Order count and demand updates: If the originating location is Order Administration, the system does not increase the order count that is displayed on the About Application Screen or perform any demand updates for the delivery or retail pickup order.

Note:

The system identifies the originating location as Order Administration if the request_system_cd in the fulfillments response message matches the system code in the OROB System (K50) system control value. In this situation, the system prefaces the E-commerce order number in the Order Header Extended table with ORIG#: 9999-001, where ORIG#: indicates the order was created as a result of OROB fulfillment assignment, 9999 is the order number, and 001 is the ship-to number.

Not mapped: The following information is not mapped from Order Orchestration when creating the order in Order Administration:

• order additional freight charges

• order additional charges

• the setting of the Under Review flag

• order line extended freight

• the setting of the order line Ship Alone flag

• order line ship weight

• item UPC or EAN codes

Response messages: After receiving the fulfillments response message, depending on whether it was able to create the order successfully:

• order creation successful: The BROKER process sends a status update message with a status of Accepted.

• order created on hold: The BROKER process sends a status update message with a status of Polled.

• order in error: If the Re-Polling for Orders Brokered to OROMS (L04) system control value is:

  • selected: the BROKER process sends a status update message with a status of Polled

  • unselected: the BROKER process does not send a status update message

  Also, if the order is in error, it is assigned to the Order Broker Error Batch Number (K90).

• order cannot be created: If the BROKER process cannot create the order in Order Administration, it sends a status update with a status of Rejected.

Order Orchestration record: The process creates an Order Orchestration record regardless of whether the order is in error. The initial status of the Order Orchestration record is New if there are any errors; otherwise, it is In process.

Canceled by originating system? If the order is initially created in Order Administration in error status and then corrected, Order Administration sends an inquiry request to Order Orchestration before changing the order’s status to open. If the response from Order Orchestration indicates that the originating system has canceled the order, Order Administration then puts the order on hold and writes an order transaction history message, such as: Order held - line[s] canceled in Order B.

Changing the order in batch order entry: If the order is suspended or in error, you can use batch order entry to make changes to the order, although you cannot add an order line. Once the order is in held or open status, the restrictions described under Maintaining Retail Pickup or Delivery Orders from the Order Orchestration apply.

Retail Pickup (including Ship-for-Pickup) or Delivery Processing after Order Creation

Checking for canceled or under review retail pickup or delivery orders during pick slip generation: Pick slip generation sends an inquiry to Order Orchestration for all retail pickup and delivery orders eligible for pick slips based on their current status, item availability, and the pick slip selection criteria, to determine whether an eligible order has been canceled in the originating system.

When the response indicates that an order is in canceled status, the program does not generate a pick slip for the order; instead, it puts the order on hold using the Order Broker Hold Reason (Cancel) (L02) system control value.

When the response indicates that an order is under review, the program does not generate a pick slip for the order; instead, it puts the order on hold using the AU hold reason (BROKER ORDER UNDER REVIEW).

Otherwise, Order Administration puts the Order Orchestration record into Picking status when the pick slip is printed and sends a status update message to Order Orchestration indicating that the order or line is in Picked status. Note that this occurs regardless of whether communication with Order Orchestration is successful when pick slip generation sends the inquiry.

Note:

Pick slip generation does not check that the sourcing location for the order is still set to an Order Administration location. For example, a user in Order Orchestration may have changed the sourcing location for the order to a location other than an Order Administration location. In this situation, Order Administration will still generate a pick slip for the order.

Which status request message? Pick slip generation uses the order inquiry status request only if the Use OROB Status Inquiry List Web Service (M05) system control value is set to NO or blank; otherwise, it uses the order status list request. See Use OROB Status Inquiry List Web Service (M05) for details on how Order Administration confirms whether to generate a pick slip for retail pickup and delivery orders.

Streamlined allocation? If there are any retail pickup or delivery orders eligible for pick slip generation, the program can use streamlined allocation only when it uses the status list request. See Use Streamlined Allocation (L63) for background.

Sample messages: See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Shipment confirmation: Once the shipment is confirmed, the Order Orchestration record status changes to Intransit for a retail pickup order, or Completed for a delivery order. The corresponding statuses for the orders in Order Orchestration are Intransit and Fulfilled.

Status updates after shipment of a retail pickup order: Once the Order Orchestration record for a retail pickup is in Intransit Polled status, the order status in Order Administration is X (completed); however the requesting store location still needs to receive the order, notify the customer, and have the customer pick up the order.

Deactivating the payment method: When you ship a retail pickup or delivery order, the billing async job deactivates the payment method. Once the payment method is deactivated, you cannot process a refund against the order unless you add a new payment method.

Sending the ship via and tracking number to Order Orchestration: When you confirm shipment, the BROKER process sends a message to Order Orchestration. The information includes the description of the ship via used (even if it is different from the ship via on the order) and the tracking number, if available.

This information is available for review in Order Orchestration at the Order screen. The actual ship via used and tracking number used are displayed on the History tab.

Status inquiry: The BROKER process includes shipped retail pickup orders in order status inquiry list requests just once a day. The Order Orchestration record might be put in any of the following statuses:

• Received: indicates that the originating store has received the transfer.

• Completed: indicates that the customer has picked up the order.

• Partially fulfilled: indicates that the customer has picked up part of the order.

See Setting the Daily Status Inquiry Time Window (all versions) for more information.

Other status updates after order creation:

Order Orchestration integration supports a business process in which only the originating location cancels a retail pickup or delivery order, since the customer is not necessarily aware that the distribution center can be involved in order fulfillment. As a result:

• Sell out: If you sell out an order line, either in order maintenance or through the Process Auto Soldouts option, Order Administration sends a status update to Order Orchestration indicating the order or order line (based on whether you split orders) was Rejected. Order Orchestration then attempts to reassign the order or line to another location for fulfillment. The Order Orchestration record’s status in Order Administration changes to Rejected.

• Cancel: If you cancel an order or order line, Order Administration changes the Order Orchestration record’s status to Canceled and sends a status inquiry request to Order Orchestration. If the order’s status in Order Orchestration is:

  • Canceled: Order Administration does not send a status update to Order Orchestration; otherwise,

  • If the order’s status in Order Orchestration is anything but Canceled, Order Administration sends a status update to Order Orchestration indicating the order was Rejected. In this situation, if Order Orchestration is configured to “reshop” the order and there are any other possible fulfilling locations, Order Orchestration reassigns the order to the next possible location based on the fulfillment rules set up in Order Orchestration, and the order returns to new order status; otherwise, if Order Orchestration cannot “reshop” the order, the order is assigned to the OROB Default Location Code for Unfulfillable Orders (K56), and the order status is unfulfillable.

  You cannot cancel a partial quantity of an order line on a retail pickup or delivery order.

  Note:

  Although Order Administration does not prevent you from canceling a retail pickup or delivery order, some business processes require that only the originating location can cancel an order. In this situation, if the customer contacts the call center to cancel the order, the operator notifies the originating store location and requests that the store perform the cancellation and trigger the status update to Order Orchestration. Using this process, Order Administration receives notification of the cancellation the next time it sends a periodic status inquiry on the order to Order Orchestration, and then holds the entire order (even if only one line was canceled) using the Order Broker Hold Reason (Cancel) (L02).

• Voiding a pick slip for a retail pickup or delivery order: If the Cancel Reason (Pick In) (L86) system control value specifies a valid cancel reason or if a backorder cancellation reason code is specified in the CWPickIn XML Message, and you use the generic pick in API to void a pick slip for a retail pickup or delivery order, then Order Administration cancels the order and sends a status update to Order Orchestration to reject the order. Otherwise, if the system control value is blank, you need to use order maintenance to cancel the order and send the status update to Order Orchestration.

  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

• Rejecting the order: If you reject a batch that includes a retail pickup or delivery order, the BROKER process sends a status update rejecting the order; also, it deletes the related Order Orchestration and Order Orchestration History records.

Cancel reason sent? The status update message to reject a retail pickup or delivery order includes a cancel reason code and description if you:

• cancel the order in order maintenance: the entered cancel reason is sent

• void the pick slip: the Cancel Reason (Pick In) (L86) system control value is sent if a backorder cancellation reason code is not specified in the CWPickIn XML Message,

  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

• reject the batch that includes the retail pickup or delivery order: no cancel reason is sent

For more information: See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for a sample of the information sent to Order Orchestration when you cancel a retail pickup or delivery order.

Reviewing Retail Pickup (including Ship-for-Pickup) or Delivery Orders in Order Inquiry

In addition to reviewing information through the Working with Order Broker (WOBR) menu option, you can also use standard order inquiry. Your options include:

• Finding the order number: Use the Order cross ref # at the Order Inquiry Scan Screen to find a retail pickup or delivery order based on the order number in the originating system. This number also displays as the Alt ord number at the Display Order Properties Screen. The system stores the originating order number in the E-Commerce order number field in the Order Header Extended table. If the originating system is Order Administration, the system prefaces the originating order number with the text ORIG#:. For example: ORIG#: 9999-001, where ORIG#: indicates the order originated in Order Administration, 9999 is the original order number in Order Administration, and 001 is the ship-to number.

  Note:

  To review all retail pickup and delivery orders whose originating system is Order Administration, you can enter ORIG#: in the Order cross ref # field and select OK to advance to the Scan by Order Cross Reference # screen where all orders whose E-Commerce order number in the Order Header Extended table begin with ORIG#: display.

• Originating order message: If the E-Commerce order number in the Order Header Extended table begins with the text ORIG#:, indicating the originating system for a retail pickup or delivery order is Order Administration, the message This order is fulfilling another order: 9999-001 displays for the sourcing order, where 9999 is the originating order number in Order Administration, and 001 is the ship-to number. This message displays on the Order Inquiry Header screen (OIOM), Order Inquiry Detail screen (OIOM), and in Streamlined Order Inquiry (DORI) for the sourcing order.

• Broker detail and history: Use the Display Order Broker Details Screen to review Order Orchestration Detail and Order Orchestration History, as well as other information such as the delivery type and the request ID.

• Identifying the Order Orchestration type: In addition to the Display Order Broker Details Screen, you can also review the Broker delivery type at the Display Order Properties Screen and the Display Order Broker Details Screen to determine whether the order originated as a Retail Pickup or Delivery order.

• Originating store, request ID, and special instructions: The originating store number and request ID are available for review at the Work with Order Messages Screen, for example:

  Originating Store: 317

  OROB Request ID: 70122

  Also, if any special instructions were passed for the order, this information is also available for review at this screen.

• Order history: The Display Order History Screen displays activity related to sending status updates to and from Order Orchestration, such as:

  • Ln#: 1 Ready for Fulfillment: Written for each line received on a retail pickup or delivery order when the order is accepted and put into Open or Held status.

  • Ln#: 1 Selected for Fulfillment: Written for each line printed on a pick slip.

  • Ln#: 1 Fulfilled: Written for each delivery order line when you confirm shipment.

  • Ln#: 1 In Transit: Written for each retail pickup order line when you confirm shipment.

    Note:

    After you ship a retail pickup order, Order Administration checks for status updates on a daily basis, and writes a single Order Transaction History message for each status change until the order is fulfilled. See Setting the Daily Status Inquiry Time Window (all versions) for setup information.

  •  Ln#: 1 Store Received: Written after the originating store location has received a retail pickup order.

  • Ln#: 1 Customer Partial Pick Up: Written after the customer has picked up part of a retail pickup order.

  • Ln#: 1 Customer Picked Up: Written after the customer has picked up all units of a retail pickup order.

  • Ln#: 1 Cancel Acknowledged by Broker: Written when you cancel an order line in order maintenance or through Working with Backorders Pending Cancellation (WBPC).

  • Ln#: 1 Rejected for Fulfillment: Written when Order Administration rejects an order line because the item is soldout or backordered; if you reject the order when it is suspended; or when you sell out a line afterward in order maintenance or through Processing Auto Soldout Cancellations (MASO).

  • Order held - line[s] canceled in OROB: Written if Order Orchestration responds to a status inquiry indicating that any of the lines on the order were canceled. In this situation, Order Administration puts the order on hold using the Order Broker Hold Reason (Cancel) (L02).

Things to Note about Retail Pickup (including Ship-for-Pickup) and Delivery Orders

Both system control values required: You need to complete both the Type for Orders Brokered for Delivery (K91) and the Order Type for Retail Pickup Orders Brokered to OROMS (K92) system control values in order for Order Administration to request new orders from Order Orchestration, even if you do not process both order types.

In addition:

• if the Use OROB for Fulfillment Assignment (M31) system control value is selected, you need to complete the Order Type for Delivery Orders Originating in OROMS (M33) system control value in order for Order Administration to assign the correct order type to delivery orders created as a result of the Brokered Backorders process assigning an Order Administration warehouse to fulfill a brokered backorder.

• if the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS, you need to complete the Order Type for Retail Pickup Orders Originating in OROMS (M35) system control value in order for Order Administration to assign the correct order type to retail pickup orders created as a result of the Brokered Backorders process assigning an Order Administration warehouse to fulfill a brokered backorder on a ship-for-pickup order.

• if the Send Inventory by Warehouse to OROB (L06) system control value is selected but the OROB location for a warehouse does not specify a valid location in Order Orchestration, the fulfillments request message is not generated.

Discounts: If the customer is eligible for a discount, such as one from a loyalty membership, Order Administration still applies the discount to a retail pickup or delivery order.’

Additional freight: If the ship via on the order is subject to additional freight charges, these charges are added to the order.

Gift flag: The setting of the Gift Flag for Orders Brokered to OROMS (L03) system control value overrides the setting of the gift flag passed in the fulfillments response message.

Outbound invoice message: If you generate the CWInvoiceOut message, the message is generated for retail pickup or delivery orders unless excluded based on trigger rules (for example, not including these order types).

Tax: The tax amount for each order detail line is passed as a tax override amount.

Customer matching: If the fulfillments response message from Order Orchestration does not specify a valid sold-to customer number, Order Administration uses its standard customer name and address matching to either select an existing customer or create a new customer.

Oracle Retail Customer Engagement customer integration: If you use the Customer Engagement Customer Integration, Order Administration may also new customer records in Oracle Retail Customer Engagement as part of creating retail pickup and delivery orders. See Building the Retail Pickup (including Ship-for-Pickup) or Delivery Order for more information.

Order maintenance: The Maintain Brokered Fulfillment Orders (B20) secured feature controls the ability to maintain a retail pickup or delivery order. Even if you have authority under this secured feature, your ability to maintain the order is limited. For example, you cannot add or change an order line. See Maintaining Retail Pickup or Delivery Orders from the Order Orchestration for a discussion.

Creating the invoice for a ship-for-pickup order: The Invoice Ship For Pickup Order Once Intransit (M73) system control value controls whether to create the invoice for a ship-for-pickup order when Order Orchestration indicates that the order is now in transit or received. See that system control value for more information.

If the payment method expires: If the payment method for an order expires, the system sends an update to Order Orchestration indicating to put the order Under Review. Also, if a fulfilling retail pickup order was created for the originating order, the order goes on hold, and any open pick slips are canceled.

Processing returns: If the Suppress Returns for Retail Pickup/Delivery (L88) system control value is:

• selected: You cannot process a return against a retail pickup or delivery order, or create a return authorization

• unselected: You can process a return against a retail pickup or delivery order or create a return authorization; however, the Order Broker Payment Type (K98) is deactivated when you ship a retail pickup or delivery order. As a result, in order to process a return against the order, you need to add a new payment method.

Note:

Regardless of the setting of the Suppress Returns for Retail Pickup/Delivery (L88) system control value, you cannot process an exchange against a retail pickup or delivery order, enter an item with a negative quantity, enter a negative additional charge, or apply a discount to a shipped order line.

Order Administration does not send a status update to Order Orchestration when you process a return against a retail pickup or delivery order.

Membership items: You should not set up your Order Orchestration integration to include membership items on retail pickup or delivery orders, since the customer membership would not be created correctly in Order Administration. To prevent Order Administration from sending membership items to Order Orchestration as part of Order Orchestration’s Product, Product Location, and Incremental Inventory Import Process, do not flag them as OROB eligible.

Voiding or reprinting pick slips:

• If you use Reprinting and Voiding Pick Slips (WVRP or WSVP) to void or reprint a pick slip for a retail pickup or delivery order, this activity does not produce a status update to Order Orchestration.

• If you use the Generic Pick In API (Shipments, Voids, and Backorders) to void a pick slip for a retail pickup or delivery order and the Cancel Reason (Pick In) (L86) system control value specifies a cancel reason code, or if a backorder cancellation reason code is specified in the CWPickIn XML Message, Order Administration cancels the order using the specified cancel reason and sends a status update rejecting the order to Order Orchestration, including the cancel reason from the system control value.

  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Important:

To prevent inconsistent updates to Order Orchestration for retail pickup and delivery orders:

• Prevent Order Administration from generating multiple pick slips for a single retail pickup or delivery order:

  • Select the Ship Complete for Orders Brokered to OROMS (L01) system control value.

  • Do not create retail pickup or delivery orders for ship-alone items.

  • Do not select the Retain Backordered Lines Brokered to OROMS (K89) system control value.

• Do not process void/unreserve transactions or partial backorders for these orders through the Generic Pick In API (Shipments, Voids, and Backorders); confirm or void the entire pick slip.

  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Note:

Retail pickup and delivery orders that originate in Xstore include a single item.

Documents for store receiving: In order to support store receiving, you can generate the Pick Message from Order Administration (CWPickOut) or the PO Download XML Message (CWPurchaseOrderOut). Each of these messages includes details on the order, including the Order Orchestration request ID, the order number in the originating system, and the delivery type. See the Generic Pick Out API and the Generic Outbound Purchase Order API in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information.

For more information: See Reauthorization and Under Review Hold Scenarios for Orders Fulfilled through Order Orchestration.

Ship-for-Pickup Orders

Overview: You can use the ship-for-pickup option in the Order Orchestration Integration to send the merchandise for an order to a designated store, where the customer can pick it up. The Order Orchestration integration facilitates communication between Order Administration and the designated store location, so the store receives notification that the order is in transit, and sends notification back to Order Administration after the merchandise is received and when the customer picks up the order.

The items on the order do not need to be stocked in the store. In addition, the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value controls whether Order Administration fulfills the order or whether the order is sent to Order Orchestration for fulfillment assignment.

•  If this system control value is set to NEVER, Order Administration fulfills the order and sends the items on the order to the store selected for customer pick up. In this situation, if an item on the order is not in stock, the item is placed on backorder until it can be fulfilled by Order Administration. The order can include up to two locations for processing:

  • the originating, or placed, location that creates the order. For ship-for-pickup orders, the originating location is always an Order Administration warehouse.

  • the fulfilling, or sourcing, location that provides the inventory for the order. If the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to NEVER, this is always an Order Administration warehouse.

  • the pickup location where the customer picks up the items on the order. For ship-for-pickup orders, this is always the store location the customer selected for pickup.

• If this system control value is set to ALWAYS, the system sends the order to Order Orchestration for fulfillment assignment. In this situation, Order Orchestration determines the best location to fulfill the order and the order can include up to three locations for processing:

  • the originating, or placed, location that creates the order. For ship-for-pickup orders, the originating location is always an Order Administration warehouse.

  • the fulfilling, or sourcing, location that provides the inventory for the order. If the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS, this is the location Order Orchestration selected for fulfillment of the order. This location can be a store location or an Order Administration warehouse.

  • the pickup location where the customer picks up the items on the order. For ship-for-pickup orders, this is always the store location the customer selected for pickup.

If Order Orchestration determines that Order Administration is the best location to fulfill the order, the system creates a new retail pickup order in Order Administration to fulfill the ship-for-pickup order; see Retail Pickup (including Ship-for-Pickup) or Delivery Orders

Important:

Regardless of when you send ship-for-pickup orders to Order Orchestration, in order to use ship-for-pickup processing, you must select the Enable Ship For Pickup option on the Organization window in Order Orchestration. Once you enable ship for pickup, the Ship for Pickup Enabled Date displays on the Organization window and this option cannot be changed.

Examples: Examples of ship-for-pickup include the following.

Example 1 (three different locations):

The customer places an order on the web site (originating location A, Order Administration) and wants to pick the order up at store location B. Order Orchestration selects store location C as the fulfilling, or sourcing, location. Store location C ships the inventory to store location B, where the customer can pick it up.

Example 2 (fulfilling location and pickup location are the same):

The customer places an order on the web site (originating location A, Order Administration) and wants to pick the order up at store location B. Order Orchestration selects store location B as the fulfilling, or sourcing, location. Once the order is ready at store location B, the customer can pick it up.

Example 3 (originating location and fulfilling location are the same):

The customer places an order on the web site (originating location A, Order Administration) and wants to pick the order up at store location B. Order Orchestration selects warehouse location A, Order Administration, as the fulfilling, or sourcing, location. Order Administration ships the items on the order to store location B. Once the order is ready at store location B, the customer can pick it up.

Example 4 (originating location and fulfillment location are the same; items on the order are shipped to the store during pick slip generation/drop ship processing):

The customer places an order on the web site (originating location A, Order Administration) and wants to pick the order up at store location B. Order Administration fulfills the items on the order and during pick slip generation, ships the items on the order to store location B. Order Orchestration manages communication between Order Administration and store location B. Once the order is ready at store location B, the customer can pick it up.

Version compatibility: Fulfillment assignment and ship-for-pickup functionality is available in release 16.0 or higher of Order Management System, or Order Administration, and release 16.0 or higher of Order Broker, or Order Orchestration. Also, in order to use ship-for-pickup processing, you must select the Enable Ship For Pickup option on the Organization window in Order Orchestration. Once you enable ship for pickup, the Ship for Pickup Enabled Date displays on the Organization window and you cannot deselect this option.

An OROB_MESSAGE_VERSION of 16.0 or higher is required to use the Ship-for-Pickup Orders integration with Order Orchestration. Note that this property cannot be set higher than 19.9 for integration with Order Broker 19.x, or higher than 21.1 for integration with Order Orchestration 22.2.301.0 or higher.

In this topic:

• Creating a Ship-for-Pickup Order in Order Administration

• Communicating with Order Orchestration about a Ship-for-Pickup Order

• Special Ship-for-Pickup Orders

• Collect Payment for a Ship-for-Pickup Order at the Store?

• Updates to a Ship-for-Pickup Order in Order Administration

• Ship-for-Pickup Order Processing on or after Shipment

• Reviewing a Ship-for-Pickup Order in Order Inquiry

Creating a Ship-for-Pickup Order in Order Administration

You can create a ship-for-pickup order through interactive order entry, or through the order API.

Note:

A ship-for-pickup order should have a single ship-to.

Creating a Ship-for-Pickup Order in Order Entry

Ship-for-pickup orders originate in Order Administration, either through order entry or through the generic order API. The order creation process is similar to that of a regular order, except that a ship-for-pickup order includes a one-time ship-to address representing the store location.

To select the store location in order entry:

1. Select the One Time Ship To option.

2. At the Create One Time Ship To Address Screen, select Store.

3. Select a store at the Store Location Screen. This screen displays each store location set up through Work with Store Cross Reference (WSCR) whose Ship for Pickup flag is selected. The description and address set up for the Store Cross Reference default to the Create One Time Ship To Address screen.

4. Complete entry of the order.

   • If the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to NEVER, the system uses existing logic to reserve items in order to fulfill the ship-for-pickup order from an Order Administration warehouse. See Sending a Ship-for-Pickup Order to Order Orchestration during Pick Slip Generation and Drop Ship Order Processing.

   • If the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS and the Send B/O to OROB (K08) system control value is selected, the system bypasses reservation and places all eligible items on backorder, even if the item is available in an Order Administration warehouse, in order to send all eligible items to Order Orchestration for fulfillment assignment; see Rules for Submitting Backorders to Order Orchestration. Order Orchestration will choose the best store location or Order Administration location to fulfill and ship the item to the store location selected by the customer for store pickup. See Brokered Backorders for processing details.

Note:

To avoid shipment problems, once you accept a ship-for-pickup order, the system does not allow you to change the store selected as the one-time ship-to address; in order to change the pickup store location, you must cancel the order and create a new ship-for-pickup order.

Ship-alone items on ship-for-pickup orders: If an item is flagged as Ship alone, Order Administration does not let you enter an order line on a ship-for-pickup order with a quantity greater than one. If the customer wants more than one unit, enter a separate order line for each unit. This restriction applies even if the item is not flagged as OROB eligible.

Creating a Ship-for-Pickup Order through the Generic Order API

In the Inbound Order XML Message (CWORDERIN):

• use the store_code attribute to specify the store location code. This needs to be a store location set up through Work with Store Cross Reference (WSCR), as described above for order entry.

• specify a delivery_type of S

• use the ShipTo element in the Inbound Order XML Message (CWORDERIN) to specify the shipping address of the store, or leave the shipping name and address attributes blank in order to use the information set up in the Store Cross Reference record.

  For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Name and address for ship-for-pickup order: If the ship-to name and address fields are passed for a ship-for-pickup order, these fields should indicate the shipping address of the store selected for pickup; otherwise, if no ship-to name and address is passed, the information defaults from the Store Cross Reference record.

Partial ship-to address? The name or address fields from the Store Cross Reference record default for any fields not passed in the message.

Example: If the CWOrderIn message indicates the ship-to customer’s first and last name, this information defaults to the order, in addition to the company name and address from the Store Cross Reference record.

Communicating with Order Orchestration about a Ship-for-Pickup Order

Submitting the order to Order Orchestration: The setting of the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value controls when the order is submitted to Order Orchestration.

The system submits a ship-for-pickup order to Order Orchestration for fulfillment assignment when the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS and the Send B/O to OROB (K08) system control value is selected, and:

• You create an order that contains an eligible item in interactive order entry or through the generic order interface (Order API).

• You run the BROKER Periodic Function to find eligible items to send to Order Orchestration.

See Brokered Backorders for processing details.

The system submits a ship-for-pickup order to Order Orchestration during pick slip generation or drop ship purchase order processing in the following scenarios.

• When the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to NEVER or blank, or

• When the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS but the Send B/O to OROB (K08) system control value is unselected.

See Sending a Ship-for-Pickup Order to Order Orchestration during Pick Slip Generation and Drop Ship Order Processing for processing details.

Sending a Ship-for-Pickup Order to Order Orchestration during Pick Slip Generation and Drop Ship Order Processing

Submitting the order to Order Orchestration: The system submits a ship-for-pickup order to Order Orchestration when you generate the pick slip or drop ship purchase order in the following scenarios.

• When the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to NEVER or blank.

• When the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to ALWAYS but the Send B/O to OROB (K08) system control value is unselected.

At this time, the system also creates the Order Orchestration record displayed at the Work with the Order Orchestration Screen.

Which items are included in the Submit Order message? Only items that are flagged as OROB eligible are included in the message to Order Orchestration. However, all items that print on the pick slip or purchase order can be included in the shipment to the store location.

Note:

It is important to confirm that including additional items on the pick slip or purchase order and in the shipment will not present a problem to the store receiving the ship-for-pickup order.

No items OROB eligible? If you create a ship-for-pickup that does not include any OROB eligible items, Order Administration does not submit the order to Order Orchestration or create an Order Orchestration record; however, you can still generate the pick slip or drop ship purchase order and ship the order to the store location for customer pickup. It is important to note that, in this case, the selected store does not receive advance notification of the order.

For more information on the contents of the message, see theOrder Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Submit separate orders for each order line? If the Create Separate Picks for Ship for Pickup Orders (L89) system control value is selected, Order Administration generates a separate pick slip or drop ship purchase order for each item, and as a result, submits each order line as a separate order to Order Orchestration. Creating separate orders in Order Orchestration can prevent confusion about order status if, for example, a single order line is canceled or fulfilled. See the Create Separate Picks for Ship for Pickup Orders (L89) system control value for more information.

What if Order Orchestration is unavailable? If Order Orchestration does not respond to the submit order request during pick slip or drop ship purchase order generation, Order Administration does not print the pick slip or purchase order. Instead, it writes an order transaction history message: Submit Order Failed - OROB Unavailable. The order is eligible for selection the next time you generate pick slips or drop ship purchase orders.

Creating the Order Orchestration record: When the job generates the Submit Order request, it initially creates the Order Orchestration record in In Process status.

Message response: The Submit Order response message indicates whether Order Orchestration was able to create the order:

• Order rejected? If Order Orchestration returns an error in the response message, Order Administration puts the order on hold using the Hold Reason for Errored Ship for Pickup Orders (L10). Order Orchestration might return an error if, for example, the order includes an item that does not exist in Order Orchestration or in the point-of-sale system associated with the store location. In this case, the Order Orchestration record in Order Administration is deleted and Order Transaction History indicates:

  Submit Order Rejected/Order Held

  Rsn:PRODUCT NOT STOCKED IN REQUESTED LOCATION.

• Order accepted? If Order Orchestration accepts the order, the generation process sends a status update indicating a status of Picked. The process finishes and the Order Orchestration record remains in Picking status until you confirm shipment of the pick slip or purchase order.

Note:

The designated store location cannot reject a ship-for-pickup order.

Sample message: See Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for a sample message and more information.

Fulfilling location in Order Administration vs. Order Orchestration:

• When order submitted to Order Orchestration:

  • originating / placed location = the OACS warehouse shipping the merchandise to the store location.

  • fulfilling / sourced location = the OACS warehouse shipping the merchandise to the store location.

  • pickup location = the store location the customer selected for store pickup.

• When store receives the merchandise or customer picks up the order: Once Order Administration receives a status inquiry response indicating that the store location has received the merchandise on the order, or that the customer has picked the order up, the store location is identified as the fulfilling location.

  • originating / placed location = the OACS warehouse shipping the merchandise to the store location.

  • fulfilling / sourced location = the OACS warehouse shipping the merchandise to the store location.

  • pickup location = the store location the customer selected for store pickup.

Excluded from brokered backorder processing: If the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to NEVER, backordered items on ship-for-pickup orders are not eligible for processing through the brokered backorder integration with Order Orchestration.

Creating ship-for-pickup orders for drop ship items: When you create a ship-for-pickup order for a drop ship item, Order Administration submits the order to Order Orchestration when you use Selecting Vendors for Drop Ship Processing (MDSP).

Note:

There is no warehouse associated with a drop ship item, so in this case Order Administration designates the OROB Default Location (K51) as the requesting location. If you are generating ship-for-pickup orders for drop ship items, you need to specify a valid Order Orchestration location in this system control value; otherwise, Order Orchestration returns an error indicating that the requesting location is invalid.

Documents for store receiving: In order to support store receiving, you can generate the Pick Message from Order Administration (CWPickOut) or the PO Download XML Message (CWPurchaseOrderOut). Each of these messages includes details on the order submitted to Order Orchestration, including the Order Orchestration request ID, the order number in the originating system, and the delivery type. See the Generic Pick Out API and the Generic Outbound Purchase Order API in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information.

Special Ship-for-Pickup Orders

In order to support processing special ship-for-pickup orders that originated in a retail location and then sent to Order Administration through the order API:

• If the order type matches the Order Type for Special Orders (L15), the Submit Order message specifies the e-commerce order number, rather than the Order Administration order number, as the order_id, so that the originating location can more easily identify and track the order.

• If the pay type matches the Pay Type for Special Orders (L16), the balance_due specified in the Submit Order message is the order total, indicating that the customer needs to pay for the order when picking it up. Otherwise, if the pay type on the order does not match this system control value, the Submit Order message does not specify a balance due, even if the order type matches the Order Type for Special Orders (L15).

See the Order Type for Special Orders (L15) and Pay Type for Special Orders (L16) system control values for more information.

If you use the Generic Pick In API (Shipments, Voids, and Backorders) to void a pick slip for a special ship-for-pickup order and the Cancel Reason (Pick In) (L86) system control value specifies a cancel reason code, or a backorder cancel reason is specified in the CWPickIn XML Message, Order Administration cancels the order using the specified cancel reason and sends a status update to Order Orchestration canceling the order.

Important:

To prevent inconsistent updates to Order Orchestration for special ship-for-pickup orders, do not process partial backorders for these orders through the Generic Pick In API (Shipments, Voids, and Backorders); confirm or void the entire pick slip.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Collect Payment for a Ship-for-Pickup Order at the Store?

You can use the Payment at POS for Ship for Pickup Orders (L60) system control value to indicate that the customer pays for a ship-for-pickup order when picking up the order at the store, rather than billing the order when you ship it to the store from the warehouse. In this case:

• The order must include only credit card payment methods; also, each pay type’s Card type must be set to Credit. No other card types, such as stored value cards, can be included.

• The payment method’s Suppress deposit and Suppress refund flags are set to Y.

• The payment method is authorized for $1.00 only during online authorization.

• Authorization is suppressed during pick slip generation.

• Order Administration sends the order total to Order Orchestration as the balance_due in the Submit Order message.

Note:

The above restrictions do not apply to ship-for-pickup orders whose order type matches the Order Type for Special Orders (L15).

Returns suppressed: Selecting the Payment at POS for Ship for Pickup Orders (L60) system control value suppresses most options for creating a return authorization, processing a return, and creating a refund. See that system control value for details.

Updates to a Ship-for-Pickup Order in Order Administration

Add an item? If you add an item to a ship-for-pickup order, or are able to ship a backordered item once you have generated the pick slip and created the ship-for-pickup order in Order Orchestration, the new item is not added to the original Order Orchestration record or to the order in Order Orchestration. Printing the pick slip for the new order line creates a new Order Orchestration record and a new order in Order Orchestration.

Voiding or reprinting a pick slip: Order Administration sends a status update to Order Orchestration if you void a pick slip for an order line on an existing ship-for-pickup order:

• Special ship-for-pickup orders: If the Cancel Reason (Pick In) (L86) system control value specifies a cancel reason or if a backorder cancellation reason code is specified in the CWPickIn XML Message, and you void the pick slip for a special ship-for-pickup order through the generic pick in API, Order Administration cancels the order or line and sends a cancellation to Order Orchestration, including the cancel reason from the system control value. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1). Also see Special Ship-for-Pickup Orders for background on these orders.

• Regular ship-for-pickup orders: If the Create Separate Picks for Ship for Pickup Orders (L89) system control value is selected and you void the pick slip for a regular (not special) ship-for-pickup order, Order Administration does not cancel the order or line, but it does send a cancellation to Order Orchestration. No cancel reason is included in this case. This status update occurs regardless of whether you use the generic pick in API to void the pick slip, or void it at an Order Administration screen.

If you then reprint the pick slip for a regular ship-for-pickup order in this situation, Order Administration submits a new order to Order Orchestration; however, if you cancel the order after voiding the pick slip, no update is sent to Order Orchestration.

Aside from the two scenarios described above, Order Administration does not send a status update to Order Orchestration when you void or reprint a pick slip.

Canceling a ship-for-pickup order: Aside from the two scenarios, described above, which generate status updates for voided pick slips, Order Administration sends a status update to Order Orchestration when you cancel the order or item. In most cases, this status update includes the cancel reason you enter:

• Cancel after voiding pick slip: If you cancel an item or the entire ship-for-pickup order in order maintenance after voiding the pick slip, and Order Administration has not already sent a status update when the pick slip was voided, it sends a status update that includes the cancel reason you enter. This situation can occur if, for example, you void a ship-for-pickup order through the Void/Reprint Picks menu option, or if you void a regular ship-for-pickup order with the Create Separate Picks for Ship for Pickup Orders (L89) system control value unselected.

• Cancel drop ship purchase order in purchase order maintenance: If you cancel a drop ship purchase order in purchase order maintenance, Order Administration sends a status update that includes the Auto Soldout Cancel Reason (C20), since you do not have an opportunity to enter a cancel reason in this case.

• Cancel drop ship purchase order sent to vendor through drop ship integration: To cancel items fulfilled through the drop ship integration, you need to use the Display P/O Drop Ship Screen in order inquiry. If you cancel a drop ship purchase order at this screen, and the purchase order is successfully canceled through the drop ship integration, it sends a status update that includes the cancel reason you enter.

Note:

• Canceling single item cancels entire order in Order Orchestration: If you do not split orders and the pick slip creating the order in Order Orchestration included multiple items, canceling a single item in Order Administration results in canceling the entire order in Order Orchestration. This situation might occur if the Create Separate Picks for Ship for Pickup Orders (L89) system control value is not selected.

• Canceling before order created in Order Orchestration: If you cancel the order before pick slip generation or drop ship purchase order generation, there is no need to notify Order Orchestration, since the order was never sent.

• Cancel after shipment confirmation? Once you have confirmed shipment, it is not possible to cancel the ship-for-pickup order in Order Orchestration.

Ship-for-Pickup Order Processing on or after Shipment

Confirm shipment: When you confirm shipment of the pick slip, Order Administration changes the status of the Order Orchestration record and sends a status update to Order Orchestration with a status of Intransit, indicating that the order is on its way.

Additional processing:

• When the assigned location sends a fulfillments request message to Order Orchestration to poll for newly assigned orders, it receives notification of the ship-for-pickup order.

  Note:

  The location assigned to a ship-for-pickup order cannot reject the order.

• The assigned store location sends the following additional status updates:

  • Received when the merchandise arrives at the store

  • Fulfilled (Order Administration status = Completed) when the customer picks up the order, or Partially fulfilled if the customer does not initially pick up the entire order

  Note:

  When Order Administration receives a status list inquiry response from Order Orchestration indicating that the merchandise was received at the store or that the customer has picked up the order, the fulfilling location on the Order Orchestration record in Order Administration changes from the warehouse shipping the order to the store location where the customer picks up the order.

How Order Administration checks for additional status updates: Once you confirm shipment of the ship-for-pickup order to the store location, Order Administration includes the order in a status list inquiry request message once a day to Order Orchestration to check on whether the order has been received or picked up. See Setting the Daily Status Inquiry Time Window (all versions) for more information.

Returning a ship-for-pickup order: Selecting the Payment at POS for Ship for Pickup Orders (L60) system control value suppresses most options for creating a return authorization, processing a return, and creating a refund. See that system control value for details.

Reviewing a Ship-for-Pickup Order in Order Inquiry

In addition to reviewing information through the Working with Order Broker (WOBR) menu option, you can also use order inquiry. Your options include:

• Identifying the Order Orchestration type: The Broker delivery type at the Display Order Properties Screen and the Display Order Broker Details Screen identifies a Ship for Pickup order.

• Broker detail and history: Use the Display Order Broker Details Screen to review Order Orchestration Detail and Order Orchestration History.

• Designated store: The Display Alternate Address Screen displays the store shipping address. You can advance to this screen by selecting the Ship To option from the header screen in order inquiry.

• Order history: The Display Order History Screen displays activity related to sending status updates to and from Order Orchestration, such as:

  • Ln#: 1 Selected for Fulfillment: Written for each line on a ship-for-pickup order printed on a pick slip and sent to Order Orchestration in the Submit Order Message.

  • Ln#: 1 In Transit shipment: Written for each printed line when you confirm shipment.

  • Ln#: 1 Accepted by Broker: Written when you receive the status inquiry request indicating that the location where the customer is picking up the ship-for-pickup order has been notified.

  • Ln#: 1 Cancel Acknowledged by Broker: Written when you receive the status update response message following the cancellation of a ship-for-pickup order. This situation occurs if you void the pick slip after initially notifying Order Orchestration about the order.

  • Ln#: 1 Store Received: Written when you receive the status inquiry response message indicating that the order merchandise has been received at the store where the customer will pick up the order. At this point, the fulfilling location on the Order Orchestration record in Order Administration changes from the warehouse shipping the merchandise to the store location where the customer picks up the order.

  • Ln#: 1 Customer Partial Pick Up: Written when you receive the status inquiry response message indicating that the customer has picked up some, but not all, of the merchandise on the order.

  • Ln#: 1 Shipped by Broker order: Written when you receive a status inquiry response message indicating that the customer has picked up the order in full.

If Order Orchestration returns an error: If Order Orchestration returns an error during pick slip generation, Order Administration writes Order Transaction History messages such as:

Submit Order Rejected/Order Held

Rsn:INVALID ITEM (SYSTEM PRODUCT), ITEM

(PEN BLUE ) DOES NO

T EXIST. PRODUCT NOT STOCKED IN REQU

If the error occurs as a result of Selecting Vendors for Drop Ship Processing (MDSP), the messages might also indicate that the pick slip or purchase order was created, for example:

DROP SHIP PO# 1234567 CREATED.

However, in this situation the process does not produce the pick slip or purchase order.

If you submit a drop ship order and the OROB Default Location (K51) system control value does not specify a valid location in Order Orchestration, Order Orchestration returns an error during drop ship processing. In this case, Order Administration writes Order Transaction History messages such as:

Submit Order Rejected/Order Held

Rsn:INVALID OR MISSING REQUESTING LOCATI

ON LOCATION CODE, (STORE_LOCATION.LO

CATION_CD) IS REQUIRED. 

Store Pickup Orders

Overview: You can create a store pickup order if the customer prefers to pick up an order from a retail location where the inventory is already available rather than waiting for a shipment from the warehouse. Unlike ship-for-pickup orders, store pickup orders do not require you to transfer the inventory from a warehouse or other store location; instead, the customer selects a location that already has the ordered quantity of all the items in stock.

In this topic:

• Store Pickup Order Creation Overview

• Merchandise Locator Search Window (Store Pickup)

• Store Pickup Search Results Screen

• Status Inquiry and Updates after Creation

• Notifying the Customer that the Store Pickup Order is Ready

• Store Pickup Order Fulfillment

• Creating a Store Pickup Order through the Order API

• Reviewing a Store Pickup Order in Order Inquiry

• Canceling a Store Pickup Order

• Troubleshooting Creation of Store Pickup Orders and Things to Note

Store Pickup Order Creation Overview

Store Pickup option: You can create a store pickup order by selecting the Store Pickup option at the Work with Order Lines Screen (Adding Items to the Order) after entering the items on the order. The Store Pickup option is available only if the Use Merchandise Locator (I38) system control value is selected and the Store Pickup Order Type (L33) system control value specifies an order type. Also, this option is available in order entry only, not in order maintenance.

Requirements: You cannot select the Store Pickup option if the order includes any items that:

• are not flagged OROB eligible

• are flagged for special handling or have the Gift wrap flag selected

• are held

• are sold out

Also, the order must:

• not include more than one ship-to

• not be a ship-for-pickup order

What if the order is held? Order Administration submits a store pickup order to Order Orchestration regardless of whether the order is held; however, if the order is held and the Payment at POS for Store Pickup (M16) system control value is unselected, Order Administration submits the order to Order Orchestration with the Under Review flag selected. This setting indicates that the order should not be picked up until the Under Review flag is cleared, because Order Administration needs to be able to collect payment, but enables the store associates with the opportunity to reserve the inventory and prepare the order in the meantime. When the order is released from hold, Order Administration sends the order status update message, indicating to clear the Under Review flag.

See the Payment at POS for Store Pickup (M16) system control value for a discussion.

Searching for locations: When you select the Store Pickup option on a qualifying order, you advance to the Merchandise Locator Search Window (Store Pickup) so that you can find a store location near the customer’s location where the items are available. Optionally, you can specify a different location or change the search radius. See the Merchandise Locator Search Window (Store Pickup) for more information.

Note:

The Order Orchestration Routing Engine supports merchandise locator searches only in the U.S. and Canada.

LocateItems request and response messages: Order Administration sends the LocateItems request message to Order Orchestration. This message specifies the items on the order, the customer’s location, and the search radius.

Selecting a location: After you complete the Merchandise Locator Search Window (Store Pickup), you advance to the Store Pickup Search Results Screen. This screen lists locations that:

• were included in the LocateItems response message, indicating that the location is flagged as Pickup available in Order Orchestration, it stocks the item(s) on the order, and

• have records in the Store Cross Reference table, set up through the Work with Store Cross Reference (WSCR) option.

See the Store Pickup Search Results Screen for more information.

When you select a location at this screen, Order Administration:

• flags all Order Detail lines with a Pickup type of SP

• updates the Pickup location ID and Location system ID with the selected location code and the System Code, if any, from the Store Cross Reference record; otherwise, from the Name in OROB for Point of Sale (L09).

• sets the Delivery type field in the Order Ship To table to P

Requirements to accept the order: When you accept the order, Order Administration verifies that:

• the order has a credit card payment method, and no other pay types

• all lines on the order are flagged for store pickup and do not include any special handling or gift wrap charges

Note:

If you have changed the quantity on an order line or added any new items to the order, you need to select the Store Pickup option again before you accept the order.

Also, the customer must have:

• an email address, and

• the opt-in/out flag for the email address set to O1 (all emails) or O2 (order-related emails).

The email address and opt-in/out setting are required so that Order Administration or Order Orchestration can notify the customer by email when the order is ready for pickup at the designated store location. See Store Pickup Notifications for more information on a notification you can have Order Administration generate; however, the Store Connect module uses a notification email generated by Order Orchestration. See the Order Orchestration online help for more information.

Updates at accept: At acceptance, Order Administration performs additional updates to order-related tables:

• Order Detail:

  • Drop ship flag set to D

  • Printed quantity set to the ordered quantity

  • Reserved quantity, Backorder quantity, and Backorder warehouse set to zero

• Order Ship To:

  • Freight and Freight balance, if any, set to zero and the Calculate freight flag set to N if the Calculate Freight for Store Pickup Orders (L32) system control value is unselected

• Order Header: Order type set to the Store Pickup Order Type (L33). If the Store Pickup Order Type (L33) is not flagged for online authorization, this change prevents Order Administration from sending the payment method out for authorization

• Order Ship To Address: creates a record using the information set up through the Work with Store Cross Reference (WSCR) option; however, if you entered a name or apartment/suite, or selected a permanent ship-to number, this information is retained

• Order Payment Method: If the Payment at POS for Store Pickup (M16) is:

  • selected:

    • the payment method is authorized for $1.00

    • the Suppress deposit flag set to Y, so that the deposit is not processed in Order Administration when the order is billed

    • the balance_due specified in the SubmitOrder message is equal to the order total

  • unselected:

    • the payment method is authorized for the full amount

    • the Suppress deposit flag is set to N, so that the deposit is processed in Order Administration when the order is billed

    • the balance_due specified in the SubmitOrder message is zero

Sending the SubmitOrder request to Order Orchestration: When you accept a store pickup order, Order Administration sends a SubmitOrder request to Order Orchestration. See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information.

When Order Administration receives the SubmitOrder response message from Order Orchestration, it sets the Order Orchestration record in Acknowledged status and writes an Order Transaction History message on the order: Submit Order Succeeded. This message indicates that the order was created successfully in Order Orchestration, not that the selected location has already accepted the order. The system also updates the line number(s) in the Order Orchestration and Order Orchestration History records.

What if the order is held? Order Administration submits a store pickup order to Order Orchestration regardless of whether the order is held; however, if the order is held and the Payment at POS for Store Pickup (M16) system control value is unselected, Order Administration submits the order to Order Orchestration with the Under Review flag selected. This setting indicates that the order should not be picked up until the Under Review flag is cleared, because Order Administration needs to be able to collect payment, but enables the store associates with the opportunity to reserve the inventory and prepare the order in the meantime.

If the order is not held, or if the Payment at POS for Store Pickup (M16) system control value is selected, Order Administration does not select the Under Review flag when submitting the order, so the order is eligible for pickup.

When a store pickup order is released from hold, Order Administration sends an update to Order Orchestration indicating to clear the Under Review flag. See the Order Update Request sample in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information.

Merchandise Locator Search Window (Store Pickup)

Purpose: Use this window to enter the search criteria when selecting a store location where the customer can pick up all the items on the order. See Store Pickup Orders for background.

How to display this screen: Select Store Pickup at the Work with Order Lines Screen (Adding Items to the Order) after entering the items on the order. The Store Pickup option is available only if:

• the Use Merchandise Locator (I38) system control value is selected and the Store Pickup Order Type (L33) system control value specifies an order type

• you are in order entry, and not order maintenance

• you are entering the first and only ship-to on the order

You cannot select the Store Pickup option if the order includes any items that:

• are not flagged OROB eligible

• have special handling instructions or have the Gift wrap flag selected

• are held (however, if the order itself is held after acceptance, Order Administration still submits it to Order Orchestration for fulfillment)

Also, the order must:

• include at least one item that is not sold out

• not be a ship-for-pickup order

Note:

This window is very similar to the Merchandise Locator Search Window (Searching for an Item) you use for informational merchandise locator searches for a single item. See Merchandise Locator API for background on merchandise locator searches.

Important:

Order Broker and Order Orchestration support merchandise locator searches only within the U.S. and Canada.

Field	Description
	NOTE The information at this window defaults from the sold-to customer address, or the last entered information if you are repeating a search for the same customer. The search radius you enter applies only to locations that use proximity rules.
Postal code	The customer’s U.S. zip or Canadian postal code, to serve as the central point for the search radius. For example, if the Search within field is set to 25 miles, the search includes stores within 25 miles of this postal code. NOTE: Your entry in this field is not validated against the Zip/City/State table. Alphanumeric, 10 positions; required if you do not enter a city and state.
Address	The customer’s street address, to serve as the central point for the search radius. Alphanumeric, 32 positions; optional.
City	The customer’s city, to serve as the central point for the search radius. Alphanumeric, 25 positions; required if you do not enter a postal code.
State	The customer’s U.S. state or Canadian province, to identify the location of the city. Alphanumeric, 2 positions; required if you do not enter a postal code.
Country	The customer’s country. The country defaults from the customer address if you advanced to this window from order entry or order maintenance; otherwise, it defaults from the Default Country for Customer Address (B17) system control value. Defined in and validated against the Country table; see Setting Up the Country Table (WCTY) for more information. Alphanumeric, 2 positions; required.
Search within	Indicates the search radius, in miles or kilometers, to search within for the selected item. The search radius defaults from the Default Search Within Radius (I40) system control value, but you can override it. NOTE: The distance unit of measure (miles or kilometers) specified with the Merchandise Locator Distance Measurement (I39) system control value is to the right. Numeric, 5 positions; required.

Completing this window:

• Optionally, override the postal code or the city and state to serve as the central point for the search radius.

• Optionally, override the Search within radius to a different distance.

• Click OK. Order Administration generates the LocateItems request message. When it receives the LocateItems response message, you advance to the Store Pickup Search Results Screen.

Troubleshooting: If you cannot display this window, or if the screen displays an error message after you attempt to search, see Troubleshooting Creation of Store Pickup Orders and Things to Note for help.

Store Pickup Search Results Screen

Purpose: Use this screen to select a store location for the customer to pick up all the items on the order.

Which locations listed? This screen lists locations that:

• Have records set up through the Work with Store Cross Reference (WSCR) option, and

• Were returned in the Locateitems response message from Order Orchestration, indicating that:

  • They are within the search radius specified at the Merchandise Locator Search Window (Store Pickup)

  • Have the requested quantity of all items on the order in stock

  • Are flagged in Order Orchestration as Pickup available

  • Were not eliminated from the search results due to probability rules in Order Orchestration

  • Were not eliminated from the search results because the number of eligible locations exceeded the Maximum No. Responses specified in Order Orchestration.

Note:

A distance of zero indicates that the location is not flagged to Use proximity locator in Order Orchestration. In this case, the location is always eligible to be included in the search results if it is also flagged as Pickup available, if it has the requested quantity of the items on the order, and if there is a Store Cross Reference record set up in Order Administration.

Troubleshooting:

• Only store locations that have Store Cross Reference records are eligible for display at this screen. See Work with Store Cross Reference (WSCR) for background.

• See Troubleshooting Creation of Store Pickup Orders and Things to Note for possible error messages.

Updates when you select a store location: When you select a location, Order Administration updates all Order Detail records:

• Sets the Pickup type for each item to SP

• Updates the Pickup location ID with the code of the selected location

• Updates the Location system ID with the System Code, if any, from the Store Cross Reference record; otherwise, from the Name in OROB for Point of Sale (L09)

For more information: See Store Pickup Orders for an overview, including details on information required before you can accept a store pickup order.

How to display this screen: Complete the Merchandise Locator Search Window (Store Pickup).

Note:

Although the information at this screen is from the location record in Order Orchestration, when you accept a store pickup order Order Administration uses the Store Cross Reference record to create the Order Ship To Address for the order.

Field	Description
Store	Select the store location where the customer would like to pick up the order. The store information consists of: Store code The code identifying the store location in Order Orchestration and in the Store Cross Reference table. Alphanumeric, 10 positions. Store name The name of the store location from Order Orchestration. If the name exceeds 35 positions, it is truncated. Alphanumeric, 35 positions. Street The street address of the store location from Order Orchestration. If the street address exceeds 40 positions, it is truncated. Alphanumeric, 40 positions. City The city of the store location from Order Orchestration. If the city name exceeds 35 positions, it is truncated. Alphanumeric, 35 positions. State The state of the store location from Order Orchestration. Alphanumeric, 2 positions. Postal code The postal code of the store location from Order Orchestration. Alphanumeric, 10 positions. Country The country of the store location from Order Orchestration. Alphanumeric, 3 positions. Phone number The phone number of the store location from Order Orchestration. If the phone number exceeds 14 positions it is truncated. Alphanumeric, 14 positions.
Distance	The number of miles or kilometers, based on the Merchandise Locator Distance Measurement (I39), from the search location. This distance might be approximate, depending on the actual criteria used to search (for example, postal code or city), and does not represent an actual driving distance. No distance is displayed if the location is not set up in Order Orchestration to use proximity rules. In this situation, the location is always considered to be within the specified search radius. Also, no distance is displayed if the store location and the search location are in the same zip or postal code. The distance is rounded down when determining whether to include the location in the search results. For example, if the Search radius is 10 miles, and the location is 10.84 miles away, the location is included in the results. The distance is shown if the location is shown. The location is shown when: Pickup qty > 0 and store flagged as pickup even though not ship for pickup Pick qty = 0, store not flagged as pickup available but store is flagged for ship for pickup Location is not shown if no inventory  and not flagged as ship for pickup. Numeric, 7 positions with a 2-place decimal.

Status Inquiry and Updates after Creation

Overview: Once Order Administration submits the order to Order Orchestration, it begins including the order in periodic status inquiry list requests to determine when:

• the selected store location polls Order Orchestration for new orders and is notified about the order

• the location accepts or rejects the order

• the customer picks up the order, either partially or completely

• potentially, the customer cancels the order at the store location

How often? The BROKER process in Working with Integration Layer Processes (IJCT) sends periodic status inquiry list request messages to Order Orchestration for store pickup orders:

• If the current status of the Order Orchestration record in Order Administration is Acknowledged, Polled, or Accepted, the process uses the Order Broker Status Update Interval (K10) to determine how often to request an update.

• If the current status is Partially Fulfilled, the process sends the message once a day. See Setting the Daily Status Inquiry Time Window (all versions) for background.

Updates based on status inquiry responses: Order Administration initially creates the Order Orchestration record in Acknowledged status, indicating that Order Orchestration has received notification of the order and assigned it a request ID. The following table summarizes the updates that take place in Order Administration based on the current status indicated in the response message from Order Orchestration.

Status in Update Response from OOCS	Status of Order Orchestration record in OACS	Additional Updates
Polled	Polled	None
Accepted	Accepted	None
Picked	Accepted	None
Partial Fulfill	Partially Fulfilled	None
Fulfilled	Completed	See Store Pickup Order Fulfillment.
Unfulfillable	Rejected	Order Administration cancels the order using the Cancel Reason (Rejected Store Pickup Orders) (G11) and writes Order Transaction History messages such as the following: Order was maintained Web cancel request processed. Ln#: 1 Rejected by Store Ln#: 2 Rejected by Store An Order Transaction History message such as the above is written for each line on the order.
Canceled	Canceled	See Canceling a Store Pickup Order.

Note:

If the status in Order Orchestration is Verified or Processed, Order Administration does not update the status of the Order Orchestration record.

Sample messages: See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Other ways to update store pickup orders? After you create a store pickup order, maintenance to the order is prohibited. The only possible update you can make within Order Administration is to cancel the order; see Canceling a Store Pickup Order.

Notifying the Customer that the Store Pickup Order is Ready

If the order is assigned to a Store Connect location, you can configure Order Orchestration to generate its own pickup notification email. See the Order Orchestration Web Services Guide on https://support.oracle.com (ID 2953017.1) or the Order Orchestration online help for more information.

Your point-of-sale system can use the CWEmailRequest message to request that Order Administration generate Store Pickup Notifications. The notification indicates that the customer’s order is ready for pickup in the designated store location.

See Store Pickup Confirmation Email Program (L48) and the Store Pickup Notification Sample and Contents for more information.

Note:

This program is not used for Store Connect. If the order is assigned to a Store Connect location, you can configure Order Orchestration to generate its own pickup notification email. See the Order Orchestration Web Services Guide on https://support.oracle.com (ID 2953017.1) or the Order Orchestration online help for more information.

Store Pickup Order Fulfillment

When Order Administration receives a status list response message from Order Orchestration indicating that a store pickup order is in Fulfilled status, it:

• Changes the status of the Order Orchestration record to Completed (X).

• Submits the order to the BILL_ASYNC job.

• Clears the Drop ship flag on the order details.

• Deactivates the payment method(s).

• If the Payment at POS for Store Pickup (M16) is selected, sets the Suppress deposit flag for the order payment method to Y, so that the deposit is not processed in Order Administration when the order is billed; otherwise, the Suppress deposit flag is set to N, so that the deposit is processed in Order Administration.

• Clears the hold reason(s), if any, on the order.

• Writes Order Transaction History messages such as:

Ln#1: Shipped by Broker

CC DEPOSIT BYPASSED ON INVOICE # 1234567

Pick# 0000000 Billed on Invoice# 1234567

For more information: See Fulfillment Process: After Order Creation and Status Updates for details on additional updates at fulfillment, including invoice creation.

Creating a Store Pickup Order through the Order API

Overview: You can create a store pickup through the order API by specifying:

• a delivery_type of P

• the store_code identifying the store location where the customer would like to pick up the order

Other requirements: Creating a store pickup order through the order API is subject to the same requirements described under Store Pickup Orders.

Freight calculation: The Calculate Freight for Store Pickup Orders (L32) system control value does not apply to the order API. To prevent freight from applying to a store pickup order, the CWOrderIn message can include the calc_frt attribute set to N; otherwise, normal freight calculation applies.

Ship-to address: As in interactive order entry, the order API uses the Store Cross Reference record to create the Order Ship To Address for the order. If the CWOrderIn message included any ship-to name and address information, only the name and apartment/suite number (and permanent ship-to number, if any) are retained on the order.

Note:

The order API does not prevent the creation of multiple shipping addresses for a store pickup order; however, you should avoid submitting such orders through the order API to prevent errors in order processing.

CWORDEROUT message: If the response_type in the CWOrderIn message indicates to return a detailed response, the CWORDEROUT response message includes the following information related to a store pickup order:

• ShipTo element:

  • delivery_type is Store Pickup

  • ship-to name and address is from the Store Cross Reference record for the selected store location

• Detail element:

  • pickup_type is SP

  • pickup_system_location is from the System Code, if any, for the Store Cross Reference record; otherwise, from the Name in OROB for Point of Sale (L09)

  • pickup_location is the selected location’s store code from Order Orchestration and the Store Cross Reference record

  • broker_status is Acknowledged if the SubmitOrder message was successfully processed by Order Orchestration; otherwise, the broker_status is not included

Errors: In addition to the normal edits that take place in the order API, the following errors can apply to store pickup orders:

• HDR errors:

  • Invalid Store Code = The store_code is invalid, or no store_code was specified. If the message specified an invalid store code that is not in the Store Cross Reference table, additional errors related to the ship-to address are included (such as Invalid Ship To Address, State Blank, City Blank, and so on)

  • Invalid Delivery Type = the delivery_type was not P (store pickup) or S (ship-for-pickup)

  • Email Missing/Ineligible = The customer does not have an email address, or the customer’s opt-in/out setting is not O1 (all emails) or O2 (order-related emails). The email address and opt-in/out setting are required so that Order Administration can generate the store pickup notification email when the order is ready for pickup at the designated store location. See Store Pickup Notifications for more information.

• DTLS errors:

  • Ineligible for Store Pick = The order does not meet the requirements for a store pickup order, such as an invalid pay type; see Store Pickup Order Creation Overview

  • Store Fulfillment Loc Msg = Included if there is no store_code specified

  • Store Fulfillment Subscription = Included if the order included a subscription item

  • Store Fulfillment Membership = Included if the order included a membership item

If there are any errors on the order, Order Administration does not submit it to Order Orchestration. You can use batch order entry to correct the errors and submit the order for store pickup.

Order type change: The order type does not change to the Store Pickup Order Type (L33) until after the order is submitted for online authorization.

For more information: See:

• Generic Order Interface (Order API)

• Order Creation Errors

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Reviewing a Store Pickup Order in Order Inquiry

Identifying a store pickup order in order inquiry: The following information identifies a store pickup order in order inquiry:

• Order properties: The Delivery type at the Display Order Properties Screen and the Display Order Broker Details Screen is Store Pickup.

• Order detail: The line is flagged with a status of SPU at the Order Inquiry Detail Screen, and the Printed quantity is the same as the ordered quantity. You can select D/S Status for a single line at the Order Inquiry Detail Screen to advance to the Display Order Broker Details Screen, where you can review details and history for the order line.

• Order type: The order Type on the Order Inquiry Header Screen matches the Order Type for Retail Pickup Orders Brokered to OROMS (K92).

• Order ship to address: The ship-to name and address at the Display Alternate Address Screen defaults from the Store Cross Reference record for the selected store location.

• Broker detail and history: Use the Display Order Broker Details Screen to review Order Broker Detail and Order Broker History.

Reviewing Order Transaction History messages: The following table provides sample Order Transaction History messages and their explanations. You can review these messages at the Display Order History Screen.

Order Transaction History Message(s)	Explanation
Submit Order Failed - OROB Unavailable	Communication with Order Orchestration is not available, or the Order Orchestration application is not active. Order Administration saves the information about the order in the Store Pickup tables, and attempts to submit the order to Order Orchestration the next time you start the BROKER_ORD process.
Submit Order Succeeded	Order Administration submitted the order to Order Orchestration.
Ln#: 1 Acknowledged by Broker	Order Orchestration created the order and responded with the request ID. NOTE: A similar message is included for each line on the order.
Ln#: 1 Accepted by Broker	Order Orchestration responded to a status inquiry and indicated that the selected location has accepted the order. NOTE: A similar message is included for each line on the order.
Store Pickup conf to [e-mail]	Order Administration generated the store pickup notification email to the customer, indicating that the order is ready for pickup at the designated store location. The email address may be truncated if the entire message exceeds 30 positions. See Store Pickup Notifications for more information.
Could not send Store Pickup Email	Order Administration could not generate the store pickup notification. Possible reasons are: no email address on the order (NOTE: The email address is stored in the Order Header Extended table, but is not displayed on any screen.) the opt-in/out setting is not O1 or O2 for the email address on the order If Order Administration could not generate the store pickup notification for any other reason (for example, if the order is closed or canceled), no Order Transaction History message is written. NOTE: This notification is not used by the Store Connect module. See Store Pickup Notifications for more information.
Ln#: 1 Customer Partial Pick Up	Order Orchestration responded to a status inquiry and indicated that the customer has picked up part of the order from the selected location. NOTE: A similar message is included for each line on the order. Order Orchestration does not indicate which line(s) have been picked up and which have not.
Ln#: 1 Shipped by Broker MANUAL AUTH# DETECTED - auth Pick# 0000000 Billed on Invoice# 1238008	Order Orchestration responded to a status inquiry and indicated that the customer has picked up the entire order from the selected location. NOTE: The first message line is included for each line on the order.
Order was maintained Web cancel request processed. Ln#: 1 Rejected by Store	Order Orchestration responded to a status inquiry and indicated that the selected location has rejected the order. In this situation, Order Administration cancels the order, using the Cancel Reason (Rejected Store Pickup Orders) (G11). NOTE: The last message line is included for each line on the order.
Submit Order Rejected/Order Not Canceled	Order Orchestration responded to a status inquiry and indicated that the selected location has rejected the order; however, the Cancel Reason (Rejected Store Pickup Orders) (G11) system control value is blank, so Order Administration could not cancel the order.
Order was maintained Web cancel request processed. Ln#: 1 Canceled by Store	Order Orchestration responded to a status inquiry and indicated that the order has been canceled at an external location, typically the location selected for pickup. In this situation, Order Administration cancels the order, using the Cancel Reason (Rejected Store Pickup Orders) (G11). NOTE: The last message line is included for each line on the order.
Order was maintained Ln#: 1 Cancel Acknowledged by Broker	You canceled the order in order maintenance, and the status update message was sent to and acknowledged by Order Orchestration. NOTE: The last message line is included for each line on the order.
Submit Order Rejected/Order Canceled Rsn:INVALID FULFILLING LOCATION CODE. LO CATION (10) DOES NOT EXIST FOR SYSTE M (SYSTEM01) Order was maintained Web cancel request processed.	Order Orchestration was not able to create the order, because the selected location was not set up correctly in Order Orchestration. In this situation, Order Administration cancels the order, using the Cancel Reason (Rejected Store Pickup Orders) (G11).
Submit Order Rejected/Order Canceled Rsn:Invalid or missing fulfillment system code system_cd) is required for a pickup request	Order Orchestration was not able to create the order, because the SubmitOrder request message from Order Administration to create the order did not specify a valid location associated with a valid system code in Order Orchestration. Check the System Code, if any, from the Store Cross Reference record, or the Name in OROB for Point of Sale (L09), and confirm that the code sent to Order Orchestration is a valid system code associated with the store location code.

You can also review information about the order through the Working with Order Broker (WOBR) option.

Canceling a Store Pickup Order

Canceling a store pickup order in order maintenance: You cannot maintain a store pickup order, although you can cancel it in order maintenance if you have authority under the Cancel Order Broker Lines (B19) secured feature:

• If you do not have authority under the secured feature, when you select a store pickup order for maintenance a pop-up window indicates: Not authorized to maintain brokered order.

• If you have authority under the secured feature, when you select a store pickup order for maintenance a pop-up window indicates: This is a Store Pickup order and can only be canceled!

  • If you click OK, you advance directly from this pop-up window to the Confirm Cancel window.

  • If you click OK at the Confirm Cancel window, you advance to the Enter Cancel Reason Window.

  • If you complete the Enter Cancel Reason window, Order Administration cancels the order.

Hold reason(s) removed: When you cancel a store pickup order, Order Administration removes the hold reason(s), if any, on the order.

Notification to Order Orchestration: After you cancel a store pickup order, Order Administration changes the Order Orchestration record’s status to Pending Cancel, and then to Canceled once the BROKER_ORD job has sent the status update message to Order Orchestration and received the response. The status update includes the cancel reason you entered at the Enter Cancel Reason window. When it processes the response, Order Administration writes Order Transaction History messages such as:

Order was maintained

Ln#: 1 Cancel Acknowledged by Broker

A line-specific message such as in the above sample is written for each line on the order.

See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for a sample.

Notification timing: The BROKER_ORD process in Working with Integration Layer Processes (IJCT) uses its Outbound delay time to determine how often to “wake up” and start evaluating Order Orchestration records. If it finds orders in Pending Cancel status, it generates the status update immediately and does not wait for the entire Order Broker Status Update Interval (K10).

Example: The Outbound delay time for the BROKER_ORD process is 60 seconds. When you start the process, it sends status updates for any orders in Pending Cancel status, then evaluates whether to send any other request messages based on the Order Broker Status Update Interval (K10). Once it has evaluated all orders in all companies, it then waits 60 seconds before restarting the process of checking for orders in Pending Cancel status and evaluating whether to send inquiry request messages for orders in other statuses.

Order Administration does not verify the pickup order’s current status in Order Orchestration before processing the cancellation.

Note:

Although the BROKER_ORD process generates the submit order requests (and cancellation requests, if needed), the BROKER process handles other requests to Order Orchestration.

Receiving a Store Pickup Cancellation from Order Orchestration

If the customer cancels the order, or an item on the order, at a retail location, Order Administration receives the cancel status update when it sends a periodic status inquiry list request and receives the response. In this situation, Order Administration cancels the order or item using the Cancel Reason (Rejected Store Pickup Orders) (G11); also, it writes Order Transaction History such as:

Order was maintained

Web cancel request processed.

Ln#: 1 Canceled by Store

A line-specific message such as in the above sample is written for each canceled line on the store pickup order.

Note:

• The Cancel Reason (Rejected Store Pickup Orders) (G11) system control value must specify a valid cancel reason in order to correctly cancel an order or item based on messages received from Order Orchestration.

• Canceling individual lines is supported only if the Use Split Order (L56) system control value is selected, and the corresponding preference is selected in Order Orchestration. See Order Orchestration Configuration and the Order Orchestration online help for background.

Troubleshooting Creation of Store Pickup Orders and Things to Note

Issue or Note	Explanation or Solution
Merchandise locator searching: errors
One or more pickup item(s) is not eligible for Store Pickup	Even though the item is flagged as OROB eligible, it is not a valid item in Order Orchestration. This situation could occur if, for example, you have not yet run Order Orchestration’s Product, Product Location, and Incremental Inventory Import Process since creating the item or flagging it as OROB eligible; or, There are no store locations within the search radius that have all the items on the order available in the requested quantities. Optionally, you can: expand the search radius use the Merchandise Locator option for individual order lines to determine the locations where each item is available, and the available quantities of each
Cannot identify customer location	The postal code or location specified at the search window were not found in the Order Orchestration proximity database.
Item XXXXXX is not eligible for store pickup	This item is not flagged as OROB eligible. If multiple items on the order are not flagged as OROB eligible, the error message lists just the first one on the order.
No Response or Web Service Failure	The Order Orchestration application is not active.
Merchandise locator searching: things to note
The item is listed as available in a particular location in Order Orchestration, but the location is not included at the search results screen	Can occur if: The number of locations where the item is available exceeds the Maximum No. Responses specified in Order Orchestration. The location is not flagged as Pickup available in Order Orchestration. there is no Store Cross Reference record set up in Order Administration through the Work with Store Cross Reference (WSCR) option. Note: The Merchandise Locator option for individual order lines does not require a Store Cross Reference record in order to include a location at its search results screen. As a result, if you use both options there is a possible discrepancy between the results listed at the Merchandise Locator Search Results Screen and those available for selection at the Store Pickup Search Results Screen.
Order acceptance: errors
Credit card pay method only is required for Store Pickup	The Work with Order/Recap screen displays this error if there are any payment methods on the order are not credit cards.
Item(s) on order not identified as Store Pickup - select Store Pickup again.	The Work with Order/Recap screen displays this error if any items have been added to the order since you selected a store location at the Store Pickup Search Results Screen. To correct, go back to the Work with Order Lines screen and select Store Pickup again.
Invalid email setup for Store Pickup order	There is no email address specified for the customer, or the associated opt-in/out setting is not O1 (all emails) or O2 (order-related emails). The email address and opt-in/out setting are required so that Order Administration can generate the store pickup notification email when the order is ready for pickup at the designated store location. See Store Pickup Notifications for more information.
Order creation and acceptance: things to note
If the Order Orchestration record is not created immediately after order acceptance	This situation can occur if communication with Order Orchestration is interrupted or if the Order Orchestration application is inactive. In this case, Order Administration creates a record in the Store Pickup tables to use as a trigger for each store pickup order that it needs to submit to Order Orchestration when the connection is restored. Order Administration also writes an Order Transaction History message such as Submit Order Failed - OROB Unavailable.
If Order Orchestration cannot create the order	If the selected store location was not created correctly in Order Orchestration--for example, if it was not assigned to the System Code, if any, for the Store Cross Reference record, or the Name in OROB for Point of Sale (L09)--then Order Orchestration responds to the SubmitOrder request indicating that it cannot create the order. In this case, Order Administration cancels the order using the Cancel Reason (Rejected Store Pickup Orders) (G11) and writes Order Transaction History messages such as the following: Submit Order Rejected/Order Canceled Rsn:INVALID FULFILLING LOCATION CODE. LO CATION (10) DOES NOT EXIST FOR SYSTE M (CWS) Order was maintained Web cancel request processed.
If the order is held	Order Administration uses its regular credit-checking routine at order acceptance of a store pickup order, and may put the order on hold. A held order status does not prevent Order Administration from submitting the store pickup order to Order Orchestration, although Order Administration does select the order’s Under Review flag if the order is held and the Payment at POS for Store Pickup (M16) system control value is unselected. However, Order Administration removes the hold reason(s), if any, when the order is canceled for any reason (cancellation in Order Administration or Order Orchestration, an error in Order Orchestration, or rejection by the selected store) or is fulfilled. If a store pickup order was submitted with the Under Review flag selected, and the order is subsequently released from hold, Order Administration sends Order Orchestration an order update message indicating to clear the Under Review flag. See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for a sample message.
Free gifts or promotional inserts	Once an order is flagged for store pickup, Order Administration does not add free gifts or promotional inserts when you accept the order. To prevent Order Administration from adding free gifts or promotional inserts, select the Store Pickup option before attempting repricing.
Batch order entry	When you work with store pickup orders in batch order entry, you might need to change or add individual order lines that are in error. After you do so, use the Store Pickup option and select a location where the customer can pick up the order.
Alternate Shipping Charges by Via Window still opens	Even if the Calculate Freight for Store Pickup Orders (L32) system control value is unselected, this window still opens in order entry. In this case, exit out of the window without making a selection.
Creating the Order Ship To Address record	Order Administration creates the Order Ship To Address record using the description and address from the Store Cross Reference record for the selected store.
Separate Order Orchestration record for each order line	There is a separate Order Orchestration record for each order line sent to Order Orchestration; however, the entire order has a single request ID, and creates a single order in Order Orchestration.
Entering a negative quantity	Although Order Administration does not prevent you from creating a store pickup order with a negative quantity, the order creates an error in Order Orchestration and cannot be processed normally. The error (Index out of range) is noted in Order Orchestration’s error log.
System control value setting requirements for order API	If the order API receives a store pickup order, but the required system control values are not set correctly, the API creates the order and ignores the store pickup information in the CWOrderIn messages. To create a store pickup order through the order API, as in interactive order entry, the Use Merchandise Locator (I38) system control value must be selected and the Store Pickup Order Type (L33) system control value must specify an order type.
After order creation: things to note
If the order remains open rather than canceled when the selected location rejects the order or if Order Orchestration cannot create the order	If you have not specified a Cancel Reason (Rejected Store Pickup Orders) (G11), then the system cannot cancel the order, and the order remains open if it cannot be fulfilled through Order Orchestration.
Maintenance prohibited	You cannot maintain a store pickup after creation except to cancel it (although you can use batch order entry to correct an order received through the order API if there are any errors). See Canceling a Store Pickup Order for more information.
Returns prohibited	You cannot process a return in Order Administration against a store pickup order.
Email notifications for store pickup orders	You can select the different types of email notifications to generate from Order Administration based on the Cancel Reason (Rejected Store Pickup Orders) (G11). The Email notification flag for this order type must be selected in order to generate the store pickup notification to the customer when the order is ready for pickup. Also, the opt-in/out setting for the email address on the order must be O1 (all emails) or O2 (order-related emails).
Skipped by Process Auto Soldouts	The Process Auto Soldouts program ignores lines on store pickup orders. See Processing Auto Soldout Cancellations (MASO),

Troubleshooting the Order Orchestration Integration

See the Order Orchestration Web Services Guide on https://support.oracle.com (ID 2953017.1) for information on possible errors returned by Order Orchestration and additional troubleshooting information.

See also:

• Order Orchestration Status Summary Table

• Things to Note About Brokered Backorders

• Things to Note about Retail Pickup (including Ship-for-Pickup) and Delivery Orders

• Troubleshooting Creation of Store Pickup Orders and Things to Note

• Order Orchestration Integration

• Reauthorization and Under Review Hold Scenarios for Orders Fulfilled through Order Orchestration

Credit card authorization reversals: Authorization reversals take place when the Order Orchestration status is:

• C (Closed): The request was canceled before submission to Order Orchestration.

• E (Error): Order Orchestration returned an error response.

• J (Rejected): The order was rejected by the pickup location. Reversal takes place only for a pickup order.

• U (Unfulfillable): Order Orchestration cannot fulfill the order or line.

• Y (Pending Cancel): A request to cancel the order or line has been sent to Order Orchestration.

• Z (Canceled): Order Orchestration has confirmed that the order or line was canceled.

For more information:

• See Order Orchestration Status Summary Table for more information on Order Orchestration statuses.

• Use the Order Broker Lines option at the Batch Job Statistics page in Modern View to check the total number of Order Broker lines in the currently selected company, broken out by current status.

Problem	Possible Explanation
No fulfilling location is displayed at the Work with Order Broker Screen	Is the Order Orchestration request’s status E (error), U (unfulfillable), C (Closed) or Z (canceled)? In this case, the order line will not be fulfilled through Order Orchestration.
The status of the Order Orchestration request is Closed, but there have not been any shipments	Order Administration changes the status of a brokered backorder request to C (closed) if you cancel it before it has been submitted to Order Orchestration (when its status is R (ready)).
A backordered order line is not being submitted to Order Orchestration for fulfillment	Check that the order is eligible under the Rules for Submitting Backorders to Order Orchestration Confirm that you have completed the Order Orchestration Configuration Confirm that the customer is not flagged to Bypass reservation Confirm that the item has the OROB eligible flag selected If the order was previously in held status and then released, use the BROKER periodic function or select the order for maintenance and then accept your maintenance session
I created a ship-for-pickup order, but it is not listed at the Work with Order Broker Screen or on the Order Inquiry screen in Order Orchestration	If the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to NEVER, Order Administration does not send ship-for-pickup orders to Order Orchestration until you generate the pick slip. See Ship-for-Pickup Orders for an overview.
Order Orchestration returned an error	The error is displayed at the Display Order Broker History Screen. An error of Null response from OROB indicates that the OROB Account (K49) system control value is not set correctly. An error of Invalid Sold To address, missing req indicates that the sold-to customer is missing the first and last name or the company name; a first and last name or a company name are required for the sold-to customer on all orders sent to Order Orchestration. An error of Duplicate Order/line (code 2040) indicates that the order or line was already created in Order Orchestration. This situation can occur if the Use Duplicate Order Checking option is selected in Order Orchestration and the order or line was already created there, but for some reason Order Administration did not receive or process the original response message. In this case, Order Administration puts the Order Orchestration record’s status to Acknowledged, and the order line continues processing normally. See the Order Orchestration Web Services Guide on My Oracle Support (ID 2953017.1) for a list of possible errors that Order Orchestration might return to a Submit Order request.
Will there be Order Orchestration records in error if the Order Orchestration application is not running?	If Order Administration includes orders in a status inquiry list request and does not receive a response from Order Orchestration, the Order Orchestration records remain in their current status.
Where are messages logged between Order Administration and Order Orchestration?	If specified in the XML Logging setting at the Event Logging screen in Order Orchestration, Order Orchestration logs the messages.
Retail pickup and delivery orders not created in Order Administration	If the Send Inventory by Warehouse to OROB (L06) system control value is selected, Order Administration does not send fulfillments requests to Order Orchestration unless an OROB location is specified for the warehouse.
Ship-for-pickup orders are not created	An OROB_MESSAGE_VERSION of 16.0 or higher is required to use the Ship-for-Pickup Orders integration with Order Orchestration. Note that this property cannot be set higher than 19.9 for integration with Order Broker 19.x, or higher than 21.1 for integration with Order Orchestration 22.2.301.0 or higher.
Status updates are not generated when ship-for-pickup orders are in transit	The Order Type for Retail Pickup Orders Brokered to OROMS (K92) and Order Type for Orders Brokered for Delivery (K91) system control values must be populated to generate the status update message when a ship-for-pickup order is in transit.
Order initially created in Order Administration in error status, then put on hold after error corrected	Canceled by originating system? If an order is initially created in Order Administration in error status and then corrected, Order Administration sends an inquiry request to Order Orchestration before changing the order’s status to open. If the response from Order Orchestration indicates that the originating system has canceled the order, Order Administration then puts the order on hold and writes an order transaction history message, such as: Order held - line[s] canceled in Order B.
Tax is not calculated correctly for the invoice on a fulfilling order, while it is calculated correctly on the originating order	Select the Tax on Freight (B14) system control value if this issue occurs.
Multiple invoices are created for the lines on a single order that was fulfilled on the same day	The invoice is consolidated for order lines that were previously in the same status and confirmed as fulfilled in the same status inquiry response from Order Orchestration, even if your company is not configured to consolidate invoices. Example:  A line on the order is set to fulfilled in Order Orchestration at 9:00, and the other line at 9:02: The two shipments create a single invoice if they are returned in the same status inquiry response. The two shipments create two separate invoices if Order Administration receives the update on the second line in a separate status inquiry response. NOTE: In Order Management System 21.0 or higher, or Order Administration, you cannot select the Consolidated Invoice system control value if it is not already selected. If the system control value is currently selected (set to Y) and you deselect it (change it to N or blank), you cannot then change it back to selected. The option to consolidate invoices will be removed at a later date. If the Invoice Ship For Pickup Order Once Intransit (M73) system control value is selected, the invoice is created after the status inquiry response indicates a ship-for-pickup order is in transit or received, as well as fulfilled.
An order received from Order Orchestration is created in error status because the Price Override Limit Percent (E55) was exceeded	This situation can occur if the order includes a free or low-priced item, such as through a BOGO promotion. A possible solution to prevent this error is to set the Order Broker Price Override (K95) to a price override reason code whose Override item offer price flag is selected.
Delivery orders are in G (Resend Fulfilled) status, or ship-for-pickup orders are in H (Resend Intransit) status	Orders can be in these statuses if the order status update request message, generated to set their statuses to Complete (delivery order) or Intransit (ship-for-pickup order), did not receive a response from Order Orchestration. This might occur if, for example, message authentication failed or communication is down. In this case, the BROKER_ORD job resends the request the next time it runs.

Reauthorization and Under Review Hold Scenarios for Orders Fulfilled through Order Orchestration

Checking status in pick slip generation: A retail pickup or delivery order is put on AU (Broker Order Under Review) hold when:

• Pick slip generation sends a status list request to Order Orchestration, and

• The response message indicates that the order is under review.

Checking if under review through the BROKER process: When the BROKER integration layer process sends the status list request to Order Orchestration and receives a response indicating that an order is not under review, it removes the AU hold, if any, on the order. However, if the response from Order Orchestration indicates that the order is now canceled, the order is put on hold using the Order Broker Hold Reason (Cancel) (L02). If that system control value is blank, the order remains on AU hold.

Note:

If there are other holds on the order, they are not automatically removed.

When an originating order is put on AR hold: When both an originating and fulfilling order exist, the holds applied work as follows:

• A ship-for-pickup order or brokered backorder that originated in Order Administration was assigned by Order Orchestration to Order Administration for fulfillment, and Order Administration created a new fulfilling order.

• The originating order’s initial authorization expired.

• The attempt to reauthorize the originating order through the REAUTH periodic function failed, and the originating order was put on AR hold.

In this case, the system:

• Applies the AU hold reason to the fulfilling order.

• Voids any pending pick slips that have expired authorizations. Also, writes an order transaction history record such as: Pick #### voided due to expired auth.

• Writes an order transaction history message such as SYS-HLD - BROKER ORDER UNDER REVIEW, where BROKER ORDER UNDER REVIEW is the description of the hold reason code.

• If the Generic Pick Out API is in use, generates a trigger for a CWPickout message indicating that the pick slip was voided.

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

Note:

Drop ship pick slips or purchase orders, including those fulfilled through supplier direct fulfillment in Order Orchestration, are not updated when the reauthorization fails. You need to monitor these orders separately.

If the reauthorization is declined after shipment through the fulfilling order: It is possible, based on the timing of the REAUTH job and billing, that the REAUTH job can attempt to reauthorize the originating order after the fulfilling order has made the shipment. In this case, the system still sends the order update to Order Orchestration indicating to put the order under review, even though the order may already be closed in Order Orchestration. If the order is already closed, no additional automatic updates take place.

Releasing Orders from AR or AU Holds

Restrictions: Orders on AR (Declined Credit Card Authorization) or AU (Broker Order Under Review) system holds can only be released under the following conditions:

• AR: You cannot release an order on AR system hold unless the order has a valid authorization for the balance of the order. Otherwise, you can cancel the order.

• AU: You cannot release an order on AU hold through a screen in Classic or Modern View. Instead, based on the response received from Order Orchestration through the BROKER integration layer process, the AU hold is removed automatically if the response indicates that the order is no longer under review. Also, the order can be canceled based on the response received through the BROKER process.

Tracking User, Authority, and Password Updates

Overview: Order Administration tracks updates to users, and user classes, and external payment service settings in the User Audit table, and tracks user password changes in the Password Audit table.

User Audit table: The User Audit table tracks activity that has taken place in creating or changing user records, user classes, and user authority. The table also tracks changes to external payment services. The activities that trigger updates to the User Audit table include:

• Creating, changing, or deleting a user in Work with Users (WUSR), including updates to:

  • Company authority

  • Menu option authority

  • Secured features

  • Tickler group assignment

• Creating, changing, or deleting a user classes in Work with User Classes (WUCL), including updates to:

  • Company authority

  • Menu option authority

  • Secured feature authority

  • Vendor authority

• Changes to user or user class authority for order hold reasons (WOHR)

• Changes to user or user class authority for return disposition value codes (WRDV)

• Creating, changing, copying, or deleting a secured feature (WSYS or NSEC)

• Updating a user’s email address (MUEE)

• Updating a user’s default menu (pressing F17 at a menu screen)

• Creating or changing information at the Work with External Service screen (WASV)

• Deleting an active procedure (MACX)

• Creating, changing, or deleting an inbound or outbound web service user or client ID, and password or client secret in Work with Web Service Authentication (WWSA)

• Generating a client, updating access, updating a client secret, or refreshing the applications displayed at the Manage External Application Access page in Modern View (MEAA)

Reporting: Use the Print User Security Audit Reports (PUSA) menu option to generate reports of the activity tracked in the User Audit and Password Audit tables. Note that not all activity tracked in the User Audit table is included in these reports.

Purging the audit tables: The PURGEUA periodic function (Program name = PFR0215) purges User Audit and Password Audit records based on date.

Use the Parameter field for the periodic function to specify the number of days old a User Audit or Password Audit record must be to be eligible for purge. If the Parameter is blank or 0, records must be 365 days old to be eligible for purge.

In this topic:

• User Audit Table Updates

• Fields Used by Updated Table (User Audit)

• Password Audit Table

• Print User Security Audit Reports (PUSA)

  • User Authority Change Report

  • Password Change Report

User Audit Table Updates

The updates to the User Audit table, based on updates to users, user classes, and secured features, are described below. See the Fields Used by Updated Table (User Audit) for a listing of the fields updated in the User Audit table for each updated source table.

Field	Attributes	Description
Common Fields		The following fields are populated for all records in the User Audit table.
Change date	Numeric, 7 positions (CYY/MM/DD format)	The date when the change occurred. Always populated.
Change time	Numeric, 6 positions (HHMMSS format)	The time when the change occurred. Always populated.
B/A	Alphanumeric, 1 position	Indicates whether the record reflects: A = The record after the activity. B = The record before the activity. Change: A change to an existing record creates both an A and a B audit record. Addition: Creation of a new record creates just an A audit record. Deletion: Deletion of an existing record creates just a B audit record. Always populated.
Action	Alphanumeric, 1 position	The type of action that took place: A = add C = change D = delete E = edit access (used when you add or delete access through the Manage External Application Access option in Modern View (MEAA)) R = refresh (used when you select the Refresh option at the Manage External Application Access page in Modern View (MEAA)) S = regenerate secret (used when you regenerate a client secret through the Manage External Application Access option in Modern View (MEAA)) Always populated. Note: Creating a new user results in audit records for the User and Users tables, as well as the User Extended table if you specify an email address. Additional table updates take place as you work with different types of user authorization, such as assigning authority to a company and then setting that company as the user’s default.
Updated table	Alphanumeric, 25 positions	The table updated by the activity. See the Fields Used by Updated Table (User Audit) for a listing, including the activities that create each type of audit record and the included fields. All fields populated: All fields that are populated in the updated table are populated in the audit record. For example, a user record includes a default company and a default output queue. If you make any change to the user record, the default company and default output queue are included in the before and after records, even if these settings have not changed. However, the User Authority Change Report includes fields only if they have been updated. Also, the report does not include all types of updates. Certain activities update multiple tables: For example, deleting a user also deletes the User Extended record, the Auth User Company record, and other dependent records. Always populated.
Updated by user	Alphanumeric, 10 positions	The ID of the user who performed the activity. Always populated.
Updated by user name	Alphanumeric, 30 positions	The name of the user who performed the activity at the time of the update. From the User record. Always populated.
Authority changed	Alphanumeric, 10 positions	The record affected by the activity. Possible authority entries: a user ID when the user is created, changed, or deleted, or when an external payment service is changed a user class when the user class is created, changed, or deleted a secured feature code when the company-level secured feature is created, changed, or deleted Always populated except for records created when the updated table is Webservice Users, Webserviceout, and INT Cloud App Client.
Auth type	Alphanumeric, 1 position	The authority type affected by the activity. Possible types: U = user ID (this code is also used for external auth service updates) C = user class F = secured feature Always populated except for records created when the updated table is Webservice Users, Webserviceout, and INT Cloud App Client.
Name/ description	Alphanumeric, 30 positions	The name of the user, user class, or secured feature related to the activity. Always populated except for records created when the updated table is Webservice Users, Webserviceout, and INT Cloud App Client. User name: Populated with a user name by a change related to the user, when the Updated Table is User, Users, User Extended, Auth User Company, Auth User Feature, Auth User Menu Option, User Field Authority, or User Tickler Group. In the case of an External Payment Service update, this is the user who performs the update. From: the User name set up through the User Control screen available through Advance Commands if the activity updates the Users table, even if the update took place through the Work with Users option. Fields in the Users table but also accessible through the Work with Users option include: Advanced commands All jobs authority Status Rank the Name set up through Work with Users for any other activity related to the user. User class: Populated with the user class name by a change related to the user class, when the Updated Table is User Class, Auth User Class Company, Auth User Class Feature, Auth User Class Option, User Class Field Auth, or User Class Vend Auth. In this case, the Name/description is the same as the User class description. Secured feature: Populated with the secured feature description, when the Updated Table is Secured Feature. In this case, the Name/description is the same as the Secured feature description.
Before/after changes	Alphanumeric, 512 positions	Lists the settings of any changed fields: Before record: Lists the affected field settings before the activity. After record: Lists the affected field settings after the activity. Example: You changed the default company for a user from 12: After: Default Company: 3 Before: Default Company: 12 This information is listed on the User Authority Change Report or on the generated spreadsheet file if the information’s length exceeds the available space on the report. A Before record is not created as the result of a Refresh in Manage External Application Access (MEAA). Instead, there is just an After record, such as After: IDCS Refresh Applications job is executed by: FIRST.LAST. Note that the user name may be truncated.
Additional Fields		Each remaining field in the User Audit table is populated only if the corresponding source table includes the same field, and it is populated in the source table. For example, only the User table includes the CTI user type field, so this field can be populated in the User Audit table only for an audit record of a User record that has a CTI user type specified.
Company	Numeric, 3 positions	The Company related to the update. Populated for the following tables by: User: Changing or deleting a user if a Default company was assigned. Not populated by adding a user, because you first need to assign company authority for a user before setting the default company. Auth User Company: Changing a user’s company authority, or deleting a user who had company authority. When you delete a user with authority to multiple companies, a separate audit record is created for each authorized company. Auth User Feature: Adding or changing secured feature authority for a user. User Class: Adding, deleting, or changing the default company for a user class. Auth User Class Company: Adding or deleting company authority for a user class. Auth User Class Feature: Adding, changing, or deleting secured feature authority for a user class. Auth User Class Vendor Auth: Deleting authority to a vendor for a user class. Secure Feature: Creating, changing, or deleting a secured feature at the company level. User Field Authority: Adding, changing, or deleting authority to a hold reason code or a return disposition value for a user. User Class Field Auth: Adding, changing, or deleting authority to a hold reason code or a return disposition value for a user class. External Auth Service: Updating any settings at the Work with External Authorization Service screen. Updates that are not specific to a company, such as creating or updating web service users, have the company set to 0.
The following fields are populated only for User table updates, not for web service user updates.
CTI user	Alphanumeric, 1 position	The CTI user setting for the created, changed, or deleted user. Possible settings: Y = CTI user N = User does not have fast path authority Populated only for User table updates.
CTI user type	Alphanumeric, 1 position	The CTI user type setting for the created, changed, or deleted user. Optional field. Possible types: 1 = Receive inbound only 2 = Initiate outbound only 3 = Inbound and outbound Populated only for User table updates.
CTI default screen	Alphanumeric, 1 position	The CTI default screen setting for the created, changed, or deleted user. Optional field. Possible settings: 1 = Always display CTI screen 2 = Display CTI screen with call Populated only for User table updates.
CTI default phone ext	Alphanumeric, 4 positions	The CTI telephone extension setting for the created, changed, or deleted user. Optional field. Populated only for User table updates.
User class	Alphanumeric, 10 positions	Populated for the following tables by: User: Creating, updating, or deleting a user with a User class assigned. Optional field. User Class: Creating, updating, or deleting a user class. Auth User Class Company: Changing the company authority for a user class, or deleting a user class. Auth User Class Feature: Deleting or changing the feature authority for a user class. Auth User Class Option: Changing user class menu option authority, or deleting a user class. User Class Vendor Auth: Deleting vendor authority for a user class. User Class Field Auth: Adding, changing, or deleting authority to a hold reason code or a return disposition value for a user class.
User class description	Alphanumeric, 30 positions	The Description of the created, changed, or deleted user class. Populated only for User Class table updates.
Default authority	Alphanumeric, 8 positions	Possible settings are: *ALLOW *EXCLUDE *DISPLAY (menu option authority only) Populated for the following tables by: User: Creating, changing, or deleting a user. User Field Authority: Adding, changing, or deleting authority to a hold reason code or a return disposition value for a user. Auth User Feature: Adding or changing secured feature authority for a user. Auth User Menu Option: Adding, changing, or deleting menu option authority for a user. User Class Field Authority: Adding, changing, or deleting authority to a hold reason code or a return disposition value for a user class. Auth User Class Option: Adding, changing, or deleting menu option authority for a user class. Auth User Class Feature: Adding or changing secured feature authority for a user class. Secure Feature: Changing the default authority for a secured feature at the company level.
Log use	Alphanumeric, 1 position	The Log use setting for the created, changed, or deleted user. Optional field. Possible settings: Y = Log use N or blank = Do not log use Populated only for User table updates.
Security adm	Alphanumeric, 1 position	The Security administrator setting for the created, changed, or deleted user. Optional field. Possible settings: Y = Security administrator N or blank = Not a security administrator Populated only for User table updates.
Allow fast path	Alphanumeric, 1 position	The Fast path setting for the created, changed, or deleted user. Optional field. Possible settings: Y = User has fast path authority N or blank = User does not have fast path authority Populated only for User table updates.
Output queue	Alphanumeric, 10 positions	The default Output queue for the created, changed, or deleted user. Optional field. Populated only for User table updates.
Menu	Alphanumeric, 10 positions	The Default menu setting for the created, changed, or deleted user. Optional field. Populated only for User or User Class table updates.
Language	Alphanumeric, 3 positions	The Language for the created, changed, or deleted user. Optional field. Populated only for User table updates.
E-mail address	Alphanumeric, 50 positions	The user’s Email address. Populated only for User Extended table updates.
Secured feature	Alphanumeric, 3 positions	The code identifying the secured feature. Populated for the following tables by: Auth User Feature: Adding or changing secured feature authority for a user. Auth User Class Feature: Adding or changing secured feature authority for a user class. Secured Feature: Adding, changing, or deleting a secured feature at the company level.
Secured feature desc	Alphanumeric, 40 positions	The description of the secured feature. Populated only for Secured Feature updates.
Tickler grp ID	Alphanumeric, 10 positions	The code identifying the tickler group added to or deleted from the user. Populated only for User Tickler Group updates for a user.
Vendor#	Numeric, 7 positions	The vendor whose authority was changed for the user class. Populated only for User Class/Vendor Auth updates.
CPG program	Alphanumeric, 10 positions	Not currently implemented.
Hold reason	Alphanumeric, 2 positions	The code identifying a: hold reason code if the User field auth type is HR, or return disposition value if the User field auth type is RD Populated for the following tables by: User Field Authority: Creating, changing, or deleting user authority to a hold reason code or a return disposition value. User Class Field Authority: Creating, changing, or deleting user class authority a hold reason code or a return disposition value.
User field auth type	Alphanumeric, 2 positions	The code identifying the type of user field changed. Possible values: HR = hold reason code RD = return disposition value Populated for the following tables by: User Field Authority: Creating, changing, or deleting user authority to a hold reason code or a return disposition value. User Class Field Authority: Creating, changing, or deleting user class authority a hold reason code or a return disposition value.
Menu option	Alphanumeric, 4 positions	The Fast path identifying a menu option. Populated for the following tables by: Auth User Menu Option: Adding, changing, or deleting menu option authority for a user. Auth User Class Option: Adding, changing, or deleting menu option authority for a user class.
UDF seq#	Numeric, 5 positions	Not currently implemented.
Use LDAP	Alphanumeric, 1 position	Indicates if the user is flagged for LDAP authentication. This setting is always set to N since LDAP authentication is not currently implemented. Populated only for User table updates.
Domain	Alphanumeric, 10 positions	The domain to use for LDAP authentication. Populated only for User table updates. Not currently implemented.
LDAP name	Alphanumeric, 50 positions	The user name that matches the network user ID for network authentication. Used only for LDAP authentication, which is not currently implemented. Populated only for User table updates.
Locale	Alphanumeric, 2 positions	The two-position code identifying the user’s locale. Possible locales: de = German en = English es = Spanish fr = French it = Italian
Date Format	Alphanumeric, 3 positions	The three-position code identifying the date format for the user. Possible date formats: DMY = DDMMYY format MDY = MMDDYY format YMD = YYMMDD format Note: The current date format at the time of the change is included in the Before and After entries for each user change.
Rank	Numeric, 1 position	The user’s authority rank. Set to: 1 = the user can see and edit all other users through the User Control option (admin-level user authority). If the All jobs flag is selected, the user also has access to other users’ documents and forms at the Document Management and Form Management screens. Note: Assign this authority only to those users whose responsibilities require it. any value from 2 to 9 = the user can use the User Control screen only to change his or her own password if IDCS or OCI IAM is not in use, and has access to the documents and forms of other users (through the My Docs and My Forms options) only if those users share the same rank assignment and the All jobs flag is selected. For example, a user assigned to rank 5 has access to the forms of other users who are also assigned to rank 5. Populated only for Users table updates made either through the Work with Users option, or the User Control screen available through Advanced Commands.
Advanced command	Alphanumeric, 1 position	Set to: Y = user should has authority to the Advanced Commands option through My Docs, My Forms, or My Jobs N = the user does not have authority to the Advanced Commands option through My Docs, My Forms, or My Jobs Populated only for Users table updates made either through the Work with Users option, or the User Control screen available through Advanced Commands.
Password expired	Alphanumeric, 10 positions	Indicates when the password for a user expires when IDCS or OCI IAM is not enabled. Valid values are: *NO = the password does not expire; for security reasons, this setting is not recommended. expiration date in MM/DD/YYYY format = If the expiration date is on or earlier than the current date, then the next time the user logs in Order Administration advances directly to the Password Expired screen. The user will need to change the password before it is possible to advance to another screen. Populated only for Users table updates through either the Work with Users option or the User Control screen available through Advanced Commands.
All jobs authority	Alphanumeric, 1 position	Indicates the user’s authority to other users’ submitted jobs: Y = the user can see and has authority to all other users’ jobs. Note: Assign this authority only to those users whose responsibilities require it. If this flag is selected and the User rank is: 1: the user has access to all other users’ documents and forms. 2 through 9: the user has access to the documents and forms of other users of the same rank. N = the user can see and has authority only to the jobs, documents, and forms associated with the user’s own user ID. Populated only for Users table updates made either through the Work with Users option, or the User Control screen available through Advanced Commands.
Status	Alphanumeric, 10 positions	Indicates if the user has access to Order Administration. Possible settings: *ENABLED = the user can use Order Administration. *DISABLED = the user cannot use Order Administration. Populated only for Users table updates made either through the Work with Users option, or the User Control screen available through Advanced Commands.
Job Name	Alphanumeric, 200 positions	The code identifying the job whose active procedure was deleted. Used only when the updated table is Active Procedure.
Job Number	Numeric, 19 positions	The number identifying the active procedure that was deleted. Used only when the updated table is Active Procedure.

Fields Used by Updated Table (User Audit)

Fields for all audit records: All records in the User Audit table use the following fields:

• Change date

• Change time

• B/A

• Action

• Updated table

• Updated by user

• Updated by user name

• Before/after changes

Additional fields for different types of audit records: Additional fields used for the different possible updated tables are listed below:

Table	Fields	Ways to Update/Sample Report Entries
User	Authority changed Auth type Company CTI user CTI user type CTI default screen CTI default phone ext User class Default authority Log use Security adm Allow fast path Menu Language Name/ description Use LDAP Domain LDAP name Locale Date Format Note: Optional fields, such as the Output queue, CTI settings, and User class, may be blank for the audit record.	Work with Users (WUSR): Create Change Note: The User Audit table is updated only if a change is made Delete Press F17 from a menu screen to make the current menu the default Sample entries on the User Authority Change Report: Before: Menu: HOME2 After: Menu: HOME
Users	Authority changed Auth type Name/ description from Users table Rank Advanced command Password expired All jobs authority Status	Work with Users (WUSR): Create Change Note: The User Audit table is updated only if a change is made Delete The User Control screen available through Advance Commands Sample entries on the User Authority Change Report: Before: Rank: 9 After: Rank: 1
User Extended	Authority changed Auth type E-mail address Name/ description from User table	Work with Users (WUSR): Create Change ( Note: The User Audit table is updated only if a change is made Delete Update Email Address Domain (MUEE) Sample entries on the User Authority Change Report: Before: Email Address: After: Email Address: <EMAIL_ADD>
Auth User Company	Authority changed Auth type Company Name/ description from User table	WUSR: Company auth (any change) Delete Sample entry on the User Authority Change Report: After: User: USER_ID Company Authority: <CMP_NO>
Auth User Feature	Authority changed Auth type Company Note: This is the company that was active when you changed the function authority, even if the user does not have authority to the company. Default authority Secured feature Name/ description from User table	WUSR: Feature auth (any change) Delete Sample entry on the User Authority Change Report: After: User: USER_ID  Feature: A01 Default Company: <CMP_NO> Default Authority: *ALLOW, where A01 identifies the secured feature, and the Default Company is the company where the feature authority was set
Auth User Menu Option	Authority changed Auth type Default authority Menu option Name/ description from User table	WUSR: Menu option auth (any change) Delete Sample entry on the User Authority Change Report: After: User: USER_ID Menu Option: DABJ Default Authority: *ALLOW
User Field Authority	Authority changed Auth type Company This is the company that was active when you changed the function authority, even if the user does not have authority to the company. Default authority Hold reason User field auth type Name/ description from User table	Work with Order Hold Reasons (WOHR): User release auth (any change) Work with Return Disposition Values (WRDV): User authority (any change) WUSR: Delete Sample entry on the User Authority Change Report: After: User: <USER_ID> Hold Reason: AT Type: HR Default Authority: *ALLOW
User Tickler Group	Authority changed Auth type Tickler grp ID Name/ description from User table	WUSR: Tickler group (assigning or deleting) Sample entry on the User Authority Change Report: After: User: <USER_ID> Tickler Group: BASIC
User Class	Authority changed Auth type Company User class Menu User class description Name/ description of the user class (same as the User class description) Note: Optional fields (the Output queue and Menu may be blank for the audit record.	Work with User Classes (WUCL): Create Change Note: The User Audit table is updated only if a change is made Delete Sample entries on the User Authority Change Report: Before: Default Company: 0 After: Default Company: 6
Auth User Class Company	Authority changed Auth type Company User class Name/ description of the user class	WUCL: Company auth (adding or removing) Sample entry on the User Authority Change Report: After: User Class: OE Company Authority: <CMP_NO>
Auth User Class Feature	Authority changed Auth type Company User class Default authority Secured feature Name/ description of the user class	WUCL: Feature auth (any change) Sample entry on the User Authority Change Report: After: User Class: CS2  Feature: A05 Default Company: <CMP_NO> Default Authority: *EXCLUDE, where A05 is the secured feature, and Company <CMP_NO> is the company where the feature was set
Auth User Class Option	Authority changed Auth type User class Default authority Menu option Name/ description of the user class	WUCL: Menu option auth (any change) Sample entry on the User Authority Change Report: After: User Class: CS2  Menu Option: DABJ Default Authority: *ALLOW
External Auth Service	Authority changed Company Name/ description of the user who performed the update	WASV: Enter or change any information at the Work with External Authorization Service Screen The Authentication User and encrypted Authentication Password are included if they were changed. The Auth Service code is always included. Sample entry on the User Authority Change Report: After: Auth Service: EXT Url: https://server.<HOSTNAME>.com:<PORT>/CC-REST/cc/Test User: authUser Password: <ENCRYPTED_PASSWORD>
User Class Field Auth	Authority changed Auth type Company This is the company that was active when you changed the function authority, even if the user does not have authority to the company. User class Default authority Hold reason User field auth type Name/ description of the user class	Work with Order Hold Reasons (WOHR): User release auth (any change) Work with Return Disposition Values (WRDV): User authority (any change) Sample entry on the User Authority Change Report: After: User Class: CS2  Hold Reason: DH Type: HR Default Authority: *ALLOW
User Class Vend Auth	Authority changed Auth type Company User class Vendor# Name/ description of the user class	WUCL: Vendor auth (*EXCLUDE, deletion only) Sample entry on the User Authority Change Report: Before: User Class: CS2 Company: <CMP_NO> Vendor: <VENDOR_NO>
Secured Feature	Authority changed Auth type Company Default authority Secured feature Secured feature desc Name/ description of the secured feature	Work with System Values/Features (WSYS): Secured features: Create Copy Change Note: The User Audit table is updated only if a change is made Delete Process New Secure Feature Values (NSEC) Sample entries on the User Authority Change Report: Before: Default Authority: *ALLOW After: Default Authority: *EXCLUDE
Active Procedure	Company Job Name Job Number	Purge Active Procedures Across Users (MACX): Select Delete for an active procedure. Note: You cannot delete an active procedure that is actually running on a server. Active Procedure records are not included in the User Authority Change Report (PUSA).
INT Cloud App Client	No additional fields updated.	Manage External Application Access (MEAA) in Modern View creates records for the following Action types: A: Generate a client R: Refresh S: Regenerate a client secret Sample Before/after changes entry: IDCS Refresh Applications job is executed by: FIRST.LAST.
Webservice Users	No additional fields updated.	Work with Web Service Authentication (WWSA) creates records for the following Action types: A: Add an inbound web service user D: Delete an inbound web service user Manage External Application Access (MEAA) in Modern View creates records for the following Action types: E: Edit web service access for a client S: Regenerate a client secret Sample Before/after changes entry: After: Webservice: CWPickOut User: FIRST.LAST
Webserviceout	No additional fields updated.	Work with Web Service Authentication (WWSA) creates records for the following Action types: A: Add an outbound web service user and password, or client ID and secret C: Change authentication type, password, or client secret for an outbound web service Sample Before/after changes entry: After: Webservice: Job Notification Only Client Secret is changed

Password Audit Table

Password changes are not tracked when the IDCS_ENABLED property is set to true. Once IDCS (Oracle Identity Cloud Service) or OCI IAM (Oracle Cloud Infrastructure Identity and Access Management) use is enabled, password tracking ends; however, password audit records created before IDCS or OCI IAM use was enabled remain in the table.

The information in the Password Audit table is listed below:

Field	Attributes	Description
Change date	Numeric, 7 positions (CYY/MM/DD format)	The date when the change occurred.
Change time	Numeric, 6 positions (HHMMSS format)	The time when the change occurred.
User ID of password	Alphanumeric, 10 positions	The user ID whose password was updated.
User name	Alphanumeric, 30 positions	The name of the user. From the Name set up through Work with Users.
Updated by user	Alphanumeric, 10 positions	The ID of the user who performed the activity.
Updated by user name	Alphanumeric, 30 positions	The name of the user who performed the activity at the time of the update. From the User record.

Translating Special Characters

Certain special characters cannot be passed in an attribute of an XML message except through the use of replacement text strings. For outbound XML messages, Order Administration replaces these with the text strings listed below. Similarly, for inbound messages, you can pass the special characters listed below by replacing them with the related text strings. For example, if the item description includes a double quote, Order Administration replaces it in the item_description attribute in the Detailed Order Response Message: Sample XML with ". Similarly, you can pass a single quote in the line_hyperlink attribute in the Inbound Order XML Message (CWORDERIN) by replacing it with '

For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

If an inbound message includes any of the special characters listed below without using the replacement text string, the system returns an error: Cannot Parse XML Message or Invalid XML Message.

Special Character	Description	Replacement Text String
’	single quote	'
"	double quote	"
	greater than	>
<	less than	&lt;
&	ampersand	&amp;

Other special characters (such as $ or !) can be passed in an attribute of an XML message without using replacement text strings.