11 System Operations
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 Management System and an external system.
Background Job Control (MBJC)
For information on: | See: |
---|---|
how to use the ASYNC (asynchronous) jobs, which process updates to tables related to transaction activity |
|
working with the CNTRL_ASYNC job reorganizing the queues |
Working with the CNTL_ASYNC Job |
the BILL_ASYNC job, which processes updates related to shipments and returns |
|
the EBO_ASYNC job, which processes updates related to changes in backordered items |
|
the ORDR_ASYNC job, which processes updates related to order entry and maintenance |
|
the OTHR_ASYNC job, which processes updates related to purchase order activity |
Purging Active Procedures (MACP)
Purpose: Use the Purge Active Procedures function to delete a user procedure that remains in an active status when the user is no longer in the application.
For example, if a terminal crashes when an operator is entering orders, the Active Procedures record for the user may not be deleted from the table. If a record exists in the Active Procedures table, the system thinks that the person is still using the application because the function was not exited properly.
If there are stranded Active Procedures records for any of the following functions, they must be deleted, otherwise the background ASYNC jobs cannot be ended:
-
Order Entry/Maintenance
-
Purchase Order Maintenance
-
Receiving
-
Confirmation
-
PC Manifest or the Generic Pick In API (Shipments, Voids, and Backorders)
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
When the ASYNC jobs are ended, the system checks the Active Procedures table to see if there are any active records for these applications. A pop-up window indicates the User ID and application that is still active. You should ask that the user exit the application. If the user is not in the application, delete the record from the Active Procedures table.
Note:
This function should not be used to delete Active Procedures records for users who are still using an application. If you delete Active Procedures records while a user is still in the application, the user job will not be ended; that user can still enter transactions in the application, but transaction records cannot be sent to the data queues for processing because the data queues are reorganized when the ASYNC jobs end. No back end table updates for that user's transactions will be posted, which will cause your data tables to be out of sync.Scheduling the active procedure purge: You can schedule the active procedure purge for the functions listed above using the PFR0121 Delete Stranded Active Procedures periodic function. The system deletes all active procedures for interactive jobs that are older than the number of hours defined in the periodic function’s Parameter field. If the Parameter field is blank, the default number of hours is 24.
Interrupting confirmation email generation: You can delete the active procedure related to generation of shipment and return confirmations (Type = SC) in order to interrupt the generation process. The system keeps track of the last email generated so that you can restart the generation process at a later time. See Stopping and Restarting Shipment and Return Confirmation Emails for an overview.
To see active procedures for all users in your environment: Use the Purge Active Procedures Across Users (MACX) menu option to display active procedures for all users and to purge selected procedures as needed.
In this topic:
-
Purge Active Procedures Screen (Selecting the User to Purge)
-
Purge User’s Active Procedures (Deleting an Active Procedure)
For more information: See Purge Active Procedures Across Users (MACX).
Purge Active Procedures Screen (Selecting the User to Purge)
Purpose: Use this screen to enter the User ID of the person whose record must be deleted from the Active Procedures table.
How to display this screen: Enter the Active Procedures Purge fast path name, MACP in the Fast path field at the top of any menu.
Field | Description |
---|---|
User |
The User ID of the person whose active procedure is being deleted. The User ID is validated against the User Profile table. Alphanumeric, 10 positions; required. |
Purge User’s Active Procedures (Deleting an Active Procedure)
Purpose: This screen displays the system procedures that are currently active for the selected user.
Note:
Important: Be sure that the user has exited the application before you delete an Active Procedures record. When you a delete a record, the system no longer recognizes that the user is in the application. If the user is still active in the application, the user job will not be ended when the record is deleted.How to display this screen: Enter a valid User ID at the Purge Active Procedures Screen (Selecting the User to Purge).
Screen Option | Procedure |
---|---|
Delete an active procedure |
Select Delete for the active procedure you want to delete. |
Purge Active Procedures Across Users (MACX)
Purpose: Use this option to display active procedures for all users in your environment and to purge active procedures as necessary if, for example, the job failed to end normally.
JOBCLN: The JOBCLN periodic function deletes each active procedure record for a job that is in END status, or that is not actually active . See Using the JOBCLN Function to Resolve Job Status Across Servers for a discussion.
Deleting an active procedure: Select an active procedure and click Delete to delete it.
Note:
-
You cannot delete an active procedure that is actually running on a server. Only active procedure records that are unrelated to active jobs are eligible for deletion.
-
When you delete an active procedure at this screen, it creates a User Audit record; however, no User Audit record is created if you attempt to delete an active procedure and the deletion does not succeed. See Tracking User, Authority, and Password Updates for more information on the User Audit table.
Purge Active Procedures Screen
How to display this screen: Enter MACX in the Fast path field at the top of any menu, or select Purge Procedures Across Users from a menu.
Field | Description |
---|---|
User |
The user ID of the person who started the active procedure. For the BILLUSR job, set to the ID of the default user. Alphanumeric, 10 positions; display-only. |
Workstation |
If the active procedure is a:
Alphanumeric, 10 positions; display-only. |
Job # |
A job number assigned to uniquely identify the active procedure. Numeric, 6 positions; display-only. |
Cmp (company) |
The number identifying the company where the active procedure was started. Set to zero for active procedures that are not restricted by company, such as the background jobs; however, set to 999 for certain jobs, including the PICK_OUT process, the BROKER process, and the BROKER_ORD process. See Working with Companies (WCMP) for more information on companies. Numeric, 3 positions; display-only. |
Type |
The type of active procedure. Possible types are described below under Active Procedure Types. Filtering based on the Type is supported only for Data Queue and Reorganize. Display-only. |
Program |
The name of the program that is active. Note: A program of PFR0100 is displayed for the BILLUPD periodic function runs, although that function uses a Class name rather than a Program name. Alphanumeric, 10 positions; display-only. |
Date |
The date when the user started the procedure. Numeric, 6 positions; display-only. |
Time |
The time when the user started the procedure. Numeric, 6 positions; display-only. |
Active Procedure Types
Some of the active procedure types displayed at this screen are described below.
Type | Description | Started When? |
---|---|---|
Data Queue |
data queue |
You create orders through Enter/Maintain Orders (OEOM); maintain purchase orders through Maintaining Purchase Orders (MPOE), receive purchase orders through Receiving Purchase Orders (PORC), and confirm shipments through Manually Confirming Shipments (MCON) |
BA |
billing async |
The BILL_ASYNC job starts. See Working with the BILL_ASYNC Job for more information. |
BB |
batch billing update |
The SUMVIA periodic function runs. |
BC |
batch customer conversion |
You run the batch customer import from Customer Engagement. See Customer Engagement Batch Customer and Sales Integration Process Flow for more information. |
BD |
batch deposits |
You submit auto deposits for processing. See Processing Auto Deposits (SDEP) for more information. |
BR |
Order Broker orders |
The BROKER_ORD job starts in Working with Integration Layer Processes (IJCT). See Order Broker Integration for background. |
BT |
batch tokenization update |
You run a batch tokenization update. See the Data Security and Encryption Guide on My Oracle Support (1988467.1). |
CD |
CDC async |
You run the CDC async job. See Working with Drop Ship Background Jobs (WPBJ) for more information. |
CL |
credits by LOB |
You submit line of business credits for processing. See Processing Credits by Line of Business (MCLB) for more information. |
CR |
catalog request |
You submit the catalog request upload for processing. See Working with the Catalog Request Interface (WCRU) for more information. |
CU |
set component upload |
You run the set component upload. See Importing Set Components (WCUP) for more information. |
DS |
drop ship processing |
You submit drop ship orders for processing. See Selecting Vendors for Drop Ship Processing (MDSP) for more information. |
KU |
PICK_OUT process |
You start the PICK_OUT process in Working with Integration Layer Processes (IJCT). |
IO |
INVOICE_OUT process |
You start the INVOICE_OUT process in Working with Integration Layer Processes (IJCT). |
LU |
line of business update |
You update statistics for your line of business order queue. See Displaying the Line of Business Order Queue Summary (DLOQ) for more information. |
MO |
membership order generation |
You generate membership orders through the Generating Membership Orders (EGMO) menu option. |
MS |
mass item substitution |
You select the Processing Item Substitutions (PSUB) menu option. |
OA |
online authorization |
See Performing Online Credit Card Authorizations for more information. |
OB |
Order Broker |
The BROKER job starts in Working with Integration Layer Processes (IJCT). See Order Broker Integration for background. |
PC |
PC manifesting |
Information will be provided at a later date. |
PG |
pick slip generation |
You generate pick slips. See Performing Pick Slip Generation for more information. |
QZ |
purge security risk periodic function |
You submit the SECRISK Periodic Function. |
RE |
REAUTH_JOB |
You submitted the REAUTH job. See Reauthorizing Expired Authorizations for more information. |
RI |
retail integration item upload |
You submitted the retail integration item upload. See Working with Retail Integration Item Upload (RIIU) for more information. |
RO |
RETURN_OUT process |
You start the RETURN_OUT process in Working with Integration Layer Processes (IJCT). |
RZ |
reorganize |
Information will be provided at a later date. |
SA |
batch SVC activation |
You submit stored value card activations for processing, if the Use Activation / Reversal Batch Processing (I50) system control value is selected. See Transmitting Activation and Reversal Transactions (SSVC) for more information. |
SB |
batch SVC balance inquiry |
The system submits stored value card balance inquiries in batch. See the Perform Balance Inquiry during Batch Authorizations (J19) system control value for more information. |
SC |
shipment and return confirmation email generation |
You use the Sending Internet Order Ship Confirmation (ESCF) option or the ECSHCNF periodic function. See Stopping and Restarting Shipment and Return Confirmation Emails for information on how to stop and restart the generation program. |
SI |
ship via/item summary inquiry |
You use the Ship Via/Item Inquiry (SVII) menu option. |
SP |
SKU purge |
You submit a SKU purge through the Purging SKUs (MPSK) menu option. |
SO |
process auto soldouts |
You use the Process Auto Soldouts menu option; see Processing Auto Soldout Cancellations (MASO) for more information. |
SR |
batch SVC reversal |
You process deposits that include stored value card reversals if the Perform Authorization Reversal during Deposit Processing (J20) system control value is selected. See Processing Auto Deposits (SDEP) for more information. |
SU |
supporting data upload |
You run the supporting data upload. See Importing Item-Related Supporting Data (SDUP) for more information. |
TH |
threshold monitor |
You start the THRESHMON background job. See Working with Threshold Values (WTHR) for more information. |
Working with Integration Layer Processes (IJCT)
Purpose: Use this menu option to work with the processes that transmit data between Order Management System and an external system, such as Order Broker.
Note:
The integration layer processes are not restricted by company; when you work with or change a process, it affects all companies.
Configuration: See Advanced Queuing for information on setting up queues.
In this topic:
Also, see the following for more information:
-
Integration Layer Processes and Web Services
-
Integration Layer Processes for a brief listing of integration layer processes and links to more information. Also, see each Process for a link to more information.
-
Troubleshooting XML Messages and Integration Layer Processes
-
Process Overview
As data is processed in Order Management System, the JMS provider sends messages to the integration layer processes for processing. Processes can be one-directional or bi-directional if a response is received (for an outbound process) or generated (for an inbound process).
All messages are processed in the sequence in which they arrive at the queue.
Inbound process structure: Underneath each inbound process at the Work with Integration Layer Process Screen are one or more process queues. Multiple process queues are useful for inbound messages, so that you can receive and process messages from more than one remote system. For example, you might receive inventory transactions from both a warehouse management system and a POS system.
When there are multiple process queues, each queue is an instance of the Inbound program for the process; however, each queue should have a unique Inbound job name so that you can identify and troubleshoot each process separately.
The # inbound sessions for each process queue can be one or more. For example, you might set the number of inbound sessions higher for the process queue that processes orders from your web storefront, to prevent delays; however, you might require only one inbound session for orders you receive from a remote order entry service, because you receive these orders at a scheduled time, and an immediate response is not required.

Inbound process example:
# | Step |
---|---|
1. |
A remote system sends a message to the Inbound queue specified for an integration layer process queue in Order Management System. |
2. |
The process:
|
3. |
Optionally, the process sends a response using the Outbound queue specified. |
Generic web service: As an alternative to sending messages directly to the inbound queue specified for each integration layer process queue, you can use the generic web service. In this situation, you send messages to the endpoint for the generic web service, which routes each message to the correct process queue and then routes the generated response. See the Generic Web Services for more information.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Outbound process structure: Underneath each outbound process at the Work with Integration Layer Process Screen are one or more outbound queues. Multiple outbound queues allow you to send outbound messages to more than one remote system. For example, you might send item information to your POS system and warehouse management system. If you define more than one outbound queue, the system creates a copy of the outbound message for each additional queue whose Enabled field is selected.
An outbound process requires an inbound session only when a response from the remote system is expected.

Outbound process example:
# | Step |
---|---|
1. |
Activity in Order Management System:
|
2. |
The remote system receives the message. |
3. |
Optionally, the remote system sends a response using the inbound queue specified. |
Message logging: See Order Management System Application Logs for information on the logs you can use to track XML messages.
XML Versions
Overview: As new elements and attributes are added to existing system-delivered XML messages processed through Integration Layer Job Control, each new version of a message is tagged with a version number. The first version of an XML message is always tagged as version 1.0, but if the next release of Order Management System adds any new attributes or elements to this XML message, this next version of the message is tagged as version 2.0.
Version compatibility: Each new attribute or element is always optional, or implied, so that the integration layer process can always process previous versions of the message.
XML version numbers vs. Order Management System release numbers: The XML version number is independent of the Order Management System release number. For example, version 2.0 of a message might be introduced in Order Management System release 4.0, while version 1.0 of another message might be introduced in Order Management System release 5.5.
About inbound XML messages: Since the integration layer processes can process any previous versions of the related inbound message, the highest version of an inbound XML message supported by an integration layer process is indicated by the Version in field at the Work with Integration Layer Process Screen. For example, if this field is set to 2.0, the integration layer process can process the message in version 1.0 and 2.0.
Not all integration layer processes receive inbound messages. The Version in field is blank for any integration layer processes that are outbound-only.
About outbound XML messages: You use the Select XML Message Version Screen to indicate which version of the outbound message the integration layer process should generate. For example, if version 1.0 and 2.0 are available for an outbound message, you could have the process generate either version. By default, the integration layer process generates version 1.0. Whichever version of the message you select will be sent to all process queues running under the integration layer process.
Outbound XML Version for EMAIL_OUT process: Version 13.0 is the current version of the CWEmailOut message. Earlier versions are not available.
Outbound XML Version for INVOIC_OUT process: Version 7.0 is the current version of the CWInvoiceOut message. Earlier versions are not available.
Outbound XML version for ITEM_OUT process: Version 1.0 of the CWItemOut message includes tags that are not currently supported. The version should be set to 2.0 for the ITEM_OUT process.
Outbound XML Version for ORDER_IN process: Version 12.0 is the current version of the CWOrderOut message. Earlier versions are not available.
Outbound XML version for PICK_OUT process: Versions 1.0 through 4.0 of the CWPickOut message include tags that are not currently supported The version should be set to 5.0 for the PICK_OUT process.
Outbound XML version for VENDOR_OUT process: Versions 1.0 of the CWVendorOut message includes tags that are not currently supported The version should be set to 2.0 for the VENDOR_OUT process.
Outbound XML version for SVC Reversal process: The SVC Reversal process (SVC_REVRSL) uses the outbound XML version defined for the SVC Activation process (SVC_OUT) to generate a stored value card authorization reversal request message. If you define an outbound XML version for the SVC Reversal process, the system ignores this version and continues to use the outbound XML version for the SVC Activation process. Typically, you would want to generate the same outbound message version for both stored value card activations and stored value card authorization reversals.
How does the system identify the current version of a message? The XML Message Version table lists the latest available version of each inbound and outbound XML message. This table is updated each time you apply a new upgrade to Order Management System.
Identifying when new attributes or elements were added to a message: Unless otherwise indicated in the XML layout, each element and attribute was included in version 1.0 of the message. See XML Messages for a listing of inbound and outbound messages processed through Working with Integration Layer Processes (IJCT), including links to the XML layouts.
Versions assigned to system-delivered messages only: Only system-delivered XML messages processed through integration layer processes support this version functionality. For example, e-commerce XML messages and unique XML messages do not support versions. See the Integration Layer Processes for a listing of system-delivered messages processed by the integration layer processes under Working with Integration Layer Processes (IJCT).
Imp guide romcgFor more information see the Web Services Guide on https://support.oracle.com My Oracle Support (ID 2149144.1).
Important:
You must select the latest available Outbound version for the EMAIL_OUT process in order for the email generation to work for any notification formats that use information added in versions greater than 1.0 (for example, backorder, soldout, and stored value card notifications). See Outbound Email API for more information.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Work with Integration Layer Process Screen
Purpose: Use this screen to review and work with integration layer processes.
Hidden processes? If a process is not listed at this screen, it might have had its Type changed to Hide Service. See Hiding an Integration Layer Process for more information.
How to display this screen: Enter IJCT in the Fast path field at the top of a menu or select Integration Layer Job Control from a menu.
Field | Description |
---|---|
Process |
A code for an integration layer process. Processes include:
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). Alphanumeric, 10 positions; optional. |
Description |
A description of the process. Alphanumeric, 45 positions; optional. |
Version in |
The latest version of the inbound XML message that the process is capable of processing. For example, if the Version in is 2.0, this indicates that the process works with version 1.0 or 2.0 of the inbound XML message. See XML Versions for an overview. This field is blank if the process does not process inbound XML messages. Numeric, 3 positions with a 1-place decimal; display-only. |
Version out |
The version of the outbound XML message that the process generates. You can select the outbound XML version at the Select XML Message Version Screen. See XML Versions for an overview. This field is blank if the process does not generate outbound XML messages. Numeric, 3 positions with a 1-place decimal; display-only. |
Type |
Indicates whether the process uses a JMS provider (advanced queuing) or a web service. Possible types are: MQ = the process uses a JMS provider, advanced queuing, to transmit and receive messages, or uses an Order Management System web service. See Advanced Queuing and Generic Web Services. WS = the process uses an external web service. If you have hidden a process, it is not listed on this screen. See Hiding an Integration Layer Process for more information. |
Status |
The status of the queue. Possible statuses are:
See Starting or Ending a Process. Note:
Alphanumeric, 9 positions; display-only. |
Active session |
The number of separate sessions that are active for all process queues. You might set up multiple sessions for each process queue of an inbound process to prevent delays in communication. Numeric, 5 positions; display-only. |
Start |
The date and time the process, or any of the process queues, was most recently started. The user ID of the person who started the process or any of its queues is also displayed. Date: numeric, 6 positions (in user date format); display-only. Time: numeric, 6 positions (HH:MM:SS format); display-only. User: alphanumeric, 10 positions; display-only. |
End |
The date and time the process, or any of the process queues, was most recently ended. The user ID of the person who ended the process or any of its queues is also displayed. Date: numeric, 6 positions (in user date format); display-only. Time: numeric, 6 positions (HH:MM:SS format); display-only. User: alphanumeric, 10 positions; display-only. |
Screen Option | Procedure |
---|---|
Create an integration layer queue |
Select Create to advance to the Integration Layer Process Screen (Create Mode). |
Change the settings for an integration layer process |
Select Change for a process to advance to the Integration Layer Process Screen (Change Mode). |
Delete an integration layer process |
Select Delete for a process to delete it. |
Review the details of an integration layer process |
Select Display for a process to advance to the Display Integration Layer Process Screen. You cannot change any information at this screen. See the Integration Layer Process Screen (Create Mode) for field descriptions. |
Start a process |
Select Start for a process that is in an Inactive status to start all process queues for the process. See Starting or Ending a Process. Note: This option is not available for the CC_TOKEN, MERCH_LOC, EMAIL_OUT, and TAX_INT jobs because they are interactive rather than batch processes. (The SVC_BALANC process also has this status if no companies have the Perform Balance Inquiry during Batch Authorizations (J19) system control value selected.) Also, this option is not necessary for some jobs, such as the ORDER_IN. See Integration Layer Processes for a listing of jobs that indicates whether it is necessary to start or stop the job. To schedule: You can use the STRIJCT periodic function to schedule the start of the integration layer process whose Process ID is defined in the Parameter field for the periodic function. . Troubleshooting: See Using the JOBCLN Function to Troubleshoot IJCT Jobs for information. |
End a process |
Select End for a process to end all process queues. See Starting or Ending a Process. Note: This option is not available for the CC_TOKEN, MERCH_LOC, EMAIL_OUT, and TAX_INT jobs because they are interactive rather than batch processes. (The SVC_BALANC process also has this status if no companies have the Perform Balance Inquiry during Batch Authorizations (J19) system control value selected.) Also, this option is not necessary for some jobs, such as the ORDER_IN. See Integration Layer Processes for a listing of jobs that indicates whether it is necessary to start or stop the job. To schedule: You can use the ENDIJCT End IJCT Process Passed periodic function to schedule the end of the integration layer process whose Process ID is defined in the Parameter field for the periodic function. Troubleshooting: See Using the JOBCLN Function to Troubleshoot IJCT Jobs for information. |
Work with the queues for a process |
Select Work with Queues for a process to advance to the Work with Integration Layer Process Queues Screen, where you can start, end, or work with individual process queues. Only processes whose Type is MQ use queues. |
Define trigger rules for an outbound process |
Select Trigger Rules for a process to advance to the Outbound Interface Trigger Rules Screen or the Select Trigger Rules File Window. This option is not available for processes that do not use trigger rules. |
Define XML inclusion rules for an outbound process |
Select XML Inclusion for a process to advance to the Outbound Interface XML Inclusion Screen. This option is available only for processes that use XML inclusion. |
Select the XML version to use for outbound messages |
Select Outbound XML Ver for a process to advance to the Select XML Message Version Screen. This option is not available for processes that do not generate outbound messages. Also, inclusion rules are not implemented for the MERCH_LOC process, which uses Order Broker’s Locate Items messages. See Merchandise Locator API for an overview. |
Work with background jobs |
Select Background Jobs to advance to the Work with Background Jobs Screen. |
Work with Drop Ship background jobs |
Select Drop Ship Jobs to advance to the Work with Drop Ship Background Jobs Screen. |
Integration Layer Process Screen (Create Mode)
Purpose: Use this screen to create an integration layer process. For example, you might create a new process similar to a system-delivered process in order to communicate with multiple authorization services.
How to display this screen: Select Create at the Work with Integration Layer Process Screen.
Field | Description |
---|---|
Process ID |
A code for the job that performs integration layer updates between Order Management System and an external system. See Work with Integration Layer Process Screen for a description of each. Alphanumeric, 10 positions; required. |
Description (unlabeled field next to Process ID) |
A description of the subsystem job that is used when the integration layer process is active. Alphanumeric, 45 positions; required. |
Status |
The current status of the integration layer job. Possible statuses are:
Note:
Alphanumeric, 9 positions; display-only. |
Communication type |
Indicates whether the process uses a JMS provider (advanced queuing) or a web service. Possible types are: Message Queue (default) = the process uses a JMS provider, advanced queuing, to transmit and receive messages, or the job uses an Order Management System web service. See Advanced Queuing and Generic Web Services. Web Service = the process uses a web service that is external to Order Management System. Hide Service = this process is not used and will be hidden from the Work with Integration Layer Process Screen once you accept your entries on this screen. See Hiding an Integration Layer Process for more information. Required. |
Inbound Processing: |
|
Inbound program |
For an inbound process, the name of the job that receives and interprets the XML message from an external system to Order Management System, and performs any additional processing in Order Management System. Alphanumeric, 10 positions; optional. |
Active session(s) |
The total number of active sessions from the Work with Integration Layer Process Queues Screen. Set to zero on the Create screen. Numeric, 3 positions; display-only. |
Inbound XML Msg/WSDL Doc Name |
Note: The only integration layer process that requires you to specify the name of a WSDL file in this field is the TAX_INT process. Other processes that use web services do not require you to specify a WSDL. Alphanumeric, 50 positions; optional. |
Outbound Processing: |
|
Outbound job name |
For an outbound process, the name of the job that generates the outbound XML message. Alphanumeric, 10 positions; optional. |
Outbound program |
For an outbound process, the name of the program that the job uses to build the XML message and send it to an external system. Alphanumeric, 10 positions; optional. |
Outbound delay time |
For an outbound process, this is the number of seconds to wait before checking the IL Outbound Trigger table for triggers in a ready (R) status. For outbound processes requiring additional configuration options, the system also uses the outbound delay time to determine the length of time to wait before performing a delete transaction, giving the system time to generate a delete download message. Note: For outbound processes that require additional configuration options, you must enter an outbound delay time. Numeric, 5 positions; optional. |
Outbound XML message |
The outbound message for the integration layer process to generate. Alphanumeric, 50 positions; optional. |
Integration Layer Process Screen (Change Mode)
To change: Select Change for an integration layer process at the Work with Integration Layer Process Screen to advance to the Integration Layer Process screen in Change mode. See the Integration Layer Process Screen (Create Mode) for field descriptions.
Starting or Ending a Process
Overview: You can start or stop the Integration Layer processes at the Work with Integration Layer Process Screen by selecting Start or End, if the process is not currently active.
When you select to start a process, the system first confirms that the process is not currently running on any server. If not, the system changes its status from Inactive to Starting to Active.
When you select to end a process, the system first confirms that the process is currently running on any server. If is currently running, the system changes its status from Active to Ending to Inactive. There may be a delay while the process completes processing all records that existed when the process began.
Note:
If you end a process while it is in the “resting period” defined in the Outbound Delay Time, the process does not check to see if it should be ending until the Outbound Delay Time is over. So if, for example, the Outbound Delay Time is 15 minutes and the resting period just started, then the process does not end for almost 15 minutes.
Ending an individual process queue: If you end an individual process queue for a process and another process queue is still active, the system updates the status of the integration layer process to Ending. The process will remain in an Ending status until you end the other active process queue(s) for the integration layer process.
For information on how to start or end individual process queues for a process, see the Work with Integration Layer Process Queues Screen.
Note:
If you have more than one enabled integration layer process queue, the system may update the Active session field for the integration layer process to 1, even though more than one session actually went active on the Job Management Screen and Work with Integration Layer Process Queues Screen. In this situation, stop the integration layer process again and restart it so that the number of Active sessions matches the number of sessions that have actually started.
Interactive processes: This option is not available for the CUSTOMER_IN, CUST_HIST, CUST_SRCH, CUSTOMER_IN, EMAIL_OUT, INV_INQUIRY, MERCH_LOC, ORDER_IN, RETURN_IN, TAX_INT, and WORKFLOW jobs because they are interactive rather than batch processes. The SVC_BALANC process also has this status if no companies have the Perform Balance Inquiry during Batch Authorizations (J19) system control value selected. Also, this option is not necessary for some jobs, such as the ORDER_IN. See Integration Layer Processes for a listing of jobs that indicates whether it is necessary to start or stop the job.
Scheduling when an integration layer process starts and stops: You can schedule a periodic function to start or stop an integration layer process at a particular time. 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.
Hiding an Integration Layer Process
Purpose: You can hide an unused integration layer process in order to simplify the information displayed at the Work with Integration Layer Process Screen.
Which processes are eligible to be hidden? You can hide a process only if:
-
its current status is Inactive or Interactive
-
it does not have any process queues set up through the Work with Integration Layer Process Queues Screen, or all existing process queues have the Enabled flag unselected
Before you hide a process: You should confirm that it is not a process that you are currently using or will need to use in the near future. For example, if you hide:
-
TAX_INT: You will not be able to use the integration with Vertex or AvaTax.
-
Outbound processes (such as ITEM_OUT, PO_OUT): Messages will not generated.
-
Inbound processes (such as INVTRAN_IN): Messages will not be received and processed. In the case of an interactive process, no response message will be generated.
-
EMAIL_OUT: You will not be able to send the CWEmailOut message for any template whose XML only? flag is selected; however, the system will continue to generate email notifications for email templates whose XML only? flag is not selected. See Working with E-Mail Notification Templates (WEMT) for more information.
Note:
If you have already configured the merchandise locator integration with Order Broker, this integration will continue to work after you hide the MERCH_LOC process.
Also, you should confirm that you do not have one of the Interface (INT) Periodic Functions to Start and Stop IJCT Jobs set up for a process that you are going to hide. If you do, the periodic function might start the process, even though it is hidden.
How to hide a process: At the Integration Layer Process Screen (Change Mode), change the Communication type to Hide Service.
How to show a hidden process: Once a process is hidden, you cannot show it again through an option at a screen in Order Management System. Instead, Oracle staff will need to query the Integration Layer Process table (MSILPR) and reset the ILP Communication type field from H to MQ (if the type was previously Message Queue) or WS (if the type was previously Web Service).
Note:
The JOBCLN periodic function does not update a job in H (hidden) status.
The BROKER, BROKER_ORD, MERCH_LOC, and TAX_INT processes use the Web Service type; the other processes use the Message Queue type.
Work with Integration Layer Process Queues Screen
Purpose: Use this screen to work with the process queues that run for each process displayed at the Work with Integration Layer Process Screen. Inbound processes might have multiple process queues if you receive messages from multiple remote systems; similarly, outbound processes might have multiple process queues if you broadcast messages to multiple remote systems. See Process Overview for more information on how processes relate to process queues.
It is not necessary to set up queues for a process that uses an external web service (Type at the Work with Integration Layer Process Queues Screen = WS).
Note:
You cannot create multiple process queues for the CUSTOMER_IN, CUST_HIST, CUST_SRCH, CUSTOMER_IN, EMAIL_OUT, INV_INQUIRY, MERCH_LOC, ORDER_IN, RETURN_IN, TAX_INT, and WORKFLOW processes. If you create multiple process queues for any of these processes, the system will only process messages for the queue with a sequence number of 1.
How to display this screen: Select Work with Queues for a process at the Work with Integration Layer Process Screen.
Field | Description |
---|---|
Process ID |
The process you selected at the Work with Integration Layer Process Screen. The description is to the right. Alphanumeric, 10 positions; display-only. |
Sequence |
A unique sequence number to identify a queue for a process. You cannot create multiple process queues for the CC_TOKEN, SVC_OUT, SVC_BALANC, SVC_REVRSL, MERCH_LOC, or EMAIL_OUT processes. If you create multiple process queues for any of these processes, the system only processes messages for the queue with a sequence number of 1. Numeric, 3 positions; optional. |
Description |
The description of the process queue. Alphanumeric, 30 positions; optional. |
Active sessions |
The number of inbound sessions that are currently active for each process queue. You might have more than one active session for a process queue to prevent delays in responses; for example, you might have multiple active sessions for the process queue that receives new orders from your web storefront. Note: Active sessions do not apply to outbound processing. Numeric, 5 positions; display-only. |
Start |
The date and time the process queue was most recently started. The user ID of the person who started the process queue is also displayed. Note: This field is not displayed for outbound queues. Date: numeric, 6 positions (in user date format); display-only. Time: numeric, 6 positions (HH:MM:SS format); display-only. User: alphanumeric, 10 positions; display-only. |
End |
The date and time the process queue was most recently ended. The user ID of the person who ended the process queue is also displayed. Note: This field is not displayed for outbound queues. Date: numeric, 6 positions (in user date format); display-only. Time: numeric, 6 positions (HH:MM:SS format); display-only. User: alphanumeric, 10 positions; display-only. |
Option | Procedure |
---|---|
Create a new process queue |
Select Create to create a new queue for the selected process. You advance to the Integration Layer Process Queue Screen in Create mode. Note: You cannot create multiple process queues for the CC Token Process, SVC Activation, SVC Balance Inquiry, SVC Reversal, MERCH_LOC, or EMAIL_OUT processes. |
Change a process queue |
Select Change for a process queue to work with it. You advance to the Integration Layer Process Queue Screen in Change mode. |
Delete a process queue |
Select Delete for a process queue to delete it. |
Display a process queue |
Select Display for a process queue to advance to the Integration Layer Process Queue Screen in Display mode; all fields will be display-only. |
Start a process queue |
Select Start for a process queue to start it. If none of the other process queues were currently active, the status of the process at the Work with Integration Layer Process Screen changes to Active. The Start date, time, and user indicated for the process are also updated. Note:
|
End a process queue |
Select End for a process queue to end it. If none of the other process queues were currently active, the status of the process at the Work with Integration Layer Process Screen changes to Inactive. The End date, time, and user indicated for the process are also updated. |
View status of a batch of messages in a queue |
Select View batch status for a process queue to advance to the Work with Integration Process Control Screen. |
Start all process queues for the process |
Select Start all to start all process queues for the selected process. The status of the process at the Work with Integration Layer Process Screen changes to Active. The Start date, time, and user indicated for the process are also updated. Note:
|
End all process queues for the process |
Select End all to end all process queues for the selected process. The status of the process at the Work with Integration Layer Process Screen changes to Inactive. The End date, time, and user indicated for the process are also updated. |
Starting or Stopping Process Queues
You can start or stop processes in two ways:
-
All existing process queues for a process:
-
At the Work with Integration Layer Process Screen: see Starting or Ending a Process.
-
At the Work with Integration Layer Process Queues Screen: see below.
-
-
Individual process queues for a process: At the Work with Integration Layer Process Queues Screen:
-
Starting a process queue: Select Start for a process queue to start it. If none of the other process queues were currently active, the status of the process at the Work with Integration Layer Process Screen changes to Active. The Start date, time, and user indicated for the process are also updated. Note: The Enabled flag for the process queue must be selected for you to be able to start it.
-
Ending a process queue: Select End for a process queue to end it. If none of the other process queues were currently active, the status of the process at the Work with Integration Layer Process Screen changes to Inactive. If one of the other process queues is currently active, the status of the process at the Work with Integration Layer Process Screen changes to Ending; the process will remain in an Ending status until you end the other active process queue(s) for the integration layer process.The End date, time, and user indicated for the process are also updated.
-
Note:
The BROKER_ORD job checks on whether it needs to end or to continue processing each time it has processed requests for all eligible companies and the Outbound Delay Time has passed.
Interactive processes: Starting and stopping a process queue is not available for the CUSTOMER_IN, CUST_HIST, CUST_SRCH, CUSTOMER_IN, EMAIL_OUT, INV_INQUIRY, MERCH_LOC, ORDER_IN, RETURN_IN, TAX_INT, and WORKFLOW jobs because they are interactive rather than batch processes. Also, this option is not necessary for some jobs, such as the ORDER_IN. See Integration Layer Processes for a listing of jobs that indicates whether it is necessary to start or stop the job.
System started: The system automatically starts a process queue for the SVC Activation, and SVC Reversal processes if a message is requested or received and the process is not currently running.
Starting or stopping all process queues for a process at the Work with Integration Layer Process Queues Screen:
-
Starting all process queues for a process: Select Start all to start all process queues for the selected process. The status of the process at the Work with Integration Layer Process Screen changes to Active. The Start date, time, and user indicated for the process are also updated. Note: Only process queues whose Enabled flag is selected will start.
-
Ending all process queues for a process: Select End all to end all process queues for the selected process. The status of the process at the Work with Integration Layer Process Screen changes to Inactive. The End date, time, and user indicated for the process are also updated.
Interactive processes: Starting and stopping a process queue is not available for the CUSTOMER_IN, CUST_HIST, CUST_SRCH, CUSTOMER_IN, EMAIL_OUT, INV_INQUIRY, MERCH_LOC, ORDER_IN, RETURN_IN, TAX_INT, and WORKFLOW jobs because they are interactive rather than batch processes. The SVC_BALANC process is also interactive if no companies have the Perform Balance Inquiry during Batch Authorizations (J19) system control value selected. Also, this option is not necessary for some jobs, such as the ORDER_IN. See Integration Layer Processes for a listing of jobs that indicates whether it is necessary to start or stop the job.
Which job queue? The integration layer jobs run automatically in the QSYSNOMAX job queue in order to avoid slowing down any other jobs that might be running in other job queues on the system.
Integration Layer Process Queue Screen
Purpose: Use this screen to create, change, or display a process queue for an integration layer process.
How to display this screen: At the Work with Integration Layer Process Queues Screen:
-
Select Create to advance to this screen in Create mode.
Note:
You cannot create multiple process queues for the SVC_OUT, SVC_BALANC, SVC_REVRSL, MERCH_LOC, or EMAIL_OUT processes.
-
Select Change for a process queue to advance to this screen in Change mode.
-
Select Display for a process queue to advance to this screen in Display mode. All fields will be display-only.
Field | Description |
---|---|
Process ID |
The Process ID for the selected process. The description of the process is to the right. Process ID: alphanumeric, 10 positions; display-only. Process description: alphanumeric, 45 positions; display-only. |
Description |
The description of the process queue to run for the integration layer process. For example, for an inbound process, you might use this field to indicate the source of the messages. Alphanumeric, 30 positions; required. |
Enabled |
Indicates whether the process queue can process messages. Valid values are:
Note: If this field is unselected for all process queues, you will not be able to start the process. For outbound processing, the system sends the outbound message to queues only if their Enabled field is selected. |
# inbound sessions |
The number of sessions to run under this process queue. You might run multiple sessions for process queues that require an immediate response, such as the process queue that receives new order messages from the web storefront. Multiple sessions are used only for inbound process queues; outbound processes should have this field set to 1 for their process queues. Note: If you leave this field blank, you will not be able to start the process queue. If this field is blank for all process queues for a process, you will not be able to start the process. Numeric, 5 positions; required. |
Wait time |
The number of seconds Order Management System waits for a response from an external system. Used only for two-way interfaces (outbound/inbound). If the message waits on the target queue longer than this number of seconds the message is automatically deleted. Numeric, 6 positions; optional. |
Inbound Processing: |
|
Active session (s) |
Indicates the number of sessions that are currently active for this process queue. Included in Change or Display mode only. Numeric, 5 positions; display-only. |
Inbound queue manager |
This field is currently implemented. Alphanumeric, 48 positions; optional. |
Inbound queue |
The queue in the queuing database where this process queue reads messages originating from the remote server or system. Required for inbound process queues. Alphanumeric, 48 positions; optional. |
Inbound XML message |
The name of the inbound XML message; informational only. Alphanumeric, 50 positions; optional. |
Inbound job name |
The name of the job that interprets the XML message from the external system to Order Management System. This is the Job Name listed on the Job Management screen, available through the My Jobs option. If there are multiple process queues for a process, each instance of the job should have a unique name. Required for inbound process queues. Alphanumeric, 10 positions; optional. |
Outbound Processing: |
|
Outbound queue manager |
This field is not currently implemented. Alphanumeric, 48 positions; optional. |
Outbound queue |
The queue to which this process queue sends messages for transmission to the remote server. Required for outbound process queues. Alphanumeric, 48 positions; optional. |
Outbound XML message |
The name of the outbound XML message; informational only. Alphanumeric, 50 positions; optional. |
Creating a Process Queue
Note:
You cannot create multiple process queues for the SVC_OUT, SVC_BALANC, SVC_REVRSL, MERCH_LOC, or EMAIL_OUT processes.
-
At the Work with Integration Layer Process Queues Screen, select Create to advance to this screen in Create mode.
-
Complete the Description and set the Enabled flag, and then any additional fields required for the process queue. Select OK to accept your entries.
Work with Integration Process Control Screen
Purpose: Use this screen to review the status of a batch of messages. This screen is useful if you need to troubleshoot the location of a batch message.
Each batch status represents a record in the Integration Process Control table. The system creates a record in the Integration Process Control table when the system sends or receives a batch of messages via an integration layer process.
Purging integration process control records: When one of the integration layer jobs listed above becomes active (from a user manually starting the job, through a periodic function, or through the job starting automatically), the system submits the ILPURGE job to determine if any of the records in the Integration Process Control table should be purged. If the integration process control record has an ILC date stamp that is over 7 days old, the system removes the record from the Integration Process Control table.
Purpose: Select View batch status for a process queue at the Work with Integration Layer Process Queues Screen.
Batch status records on this screen sort in descending date and time sequence.
Field | Description |
---|---|
Process |
The name and description of the batch integration layer process whose integration process control records you are reviewing. Code: alphanumeric, 10 positions; display-only. Description: alphanumeric, 45 positions; display-only. |
Queue Name |
A unique sequence number to identify a queue for a process, and the description of the process queue. Queue: numeric, 3 positions; display-only. Description: alphanumeric, 30 positions; display-only. |
Job |
The job name for the process associated with the integration process control record. For example, PICK_GEN indicates a integration process control record created for the Batch CC Authorization integration layer process; these records represent a batch of credit card authorizations sent to the authorization service. Alphanumeric, 10 positions; optional. |
Status |
The status of the integration process control record. Normal transmissions process through the following statuses: TRF, SNT, RCV, RIN, CMP. TRF Unknown status indicates the batch message is unknown and has not been transmitted. SNT Sent indicates the batch message transmission has been sent to the external system. RCV Received (IDC Server) indicates the batch message transmission has been received from the external system and all background processing for the batch is complete. A batch may remain in a received status if the associated job, such as pick slip generation, has timed out or moved on before the batch could be updated to Complete. No further action is required for a batch that remains in a Received status. RIN Receiving indicates the batch message transmission is in the process of being received. CMP Complete indicates the batch message has been completed. FLD Error (Sending) indicates the batch message transmission has failed. Note:
Status code: Alphanumeric, 3 positions; optional. Status description: Alphanumeric, 24 positions; display-only. |
Date |
The date the batch message transmission was sent to or received from an external system. Numeric, 6 positions (in user date format); display-only. |
Time |
The time the batch message transmission was sent to or received from an external system. Numeric, 6 positions (HH/MM/SS format); display-only. |
Reference ID |
The next available number from the Batch Auth File Trace Number number assignment value. Numeric, 16 positions; display-only. |
Screen Option | Procedure |
---|---|
Delete an integration process control record |
Select Delete for an integration process control record to delete it. |
Review an integration process control record |
Select Display for an integration process control record to advance to the Display Integration Process Control Screen. |
Change the status of an integration process control record that is not yet complete |
Select Change status for an integration process control record to advance to the Change Status window. You cannot change the status of an integration process control record that is in CMP complete status. |
Display Integration Process Control Screen
Purpose: Use this screen to review the details of an integration process control record. This screen is useful if you need to troubleshoot the location of a batch message.
How to display this screen: Select Display for an integration process control record at the Work with Integration Process Control Screen.
Field | Description |
---|---|
Process |
The name and description of the batch integration layer process whose integration process control records you are reviewing. Code: alphanumeric, 10 positions; display-only. Description: alphanumeric, 45 positions; display-only. |
Queue |
A unique sequence number to identify a queue for a process, and the description of the process queue. Queue: numeric, 3 positions; display-only. Description: alphanumeric, 30 positions; display-only. |
Job # |
The job number for the process associated with the integration process control record; this is the process that sent the batch message. Alphanumeric, 6 positions; display-only. |
Job name |
The job name for the process associated with the integration process control record. For example, PICK_GEN indicates an integration process control record created for the Batch CC Authorization integration layer process; these records represent a batch of credit card authorizations sent to the authorization service. Alphanumeric, 10 positions; display-only. |
User |
The user ID of the person who submitted the process associated with the batch messages. Alphanumeric, 10 positions; display-only. |
Status |
The status of the integration process control record. Normal transmissions process through the following statuses: TRF, SNT, RCV, RIN, CMP. TRF Unknown status indicates the batch message is unknown and has not been transmitted. SNT Sent indicates the batch message transmission has been sent to the external system. RCV Received (IDC Server) indicates the batch message transmission has been received from the external system and all background processing for the batch is complete. A batch may remain in a received status if the associated job, such as pick slip generation, has timed out or moved on before the batch could be updated to Complete. No further action is required for a batch that remains in a Received status. RIN Receiving indicates the batch message transmission is in the process of being received. CMP Complete indicates the batch message has been completed. FLD Error (Sending) indicates the batch message transmission has failed. Note: If the integration process control record is in a sent or error status, the system will continue to wait for a response for that record. You must resolve any errors before receiving the next transaction. Status code: Alphanumeric, 3 positions; optional. Status description: Alphanumeric, 24 positions; display-only. |
Date |
The date the batch message transmission was sent to or received from the external system. Numeric, 6 positions (in user date format); display-only. |
Time |
The time the batch message transmission was sent to or received from the external system. Numeric, 6 positions (HH/MM/SS format); display-only. |
Reference ID |
The next available number from the Batch Auth File Trace Number number assignment value. Numeric, 16 positions; display-only. |
Comment |
Informational error message regarding the batch message transmission, indicating a transmission error has occurred. Alphanumeric, 60 positions; display-only. |
Change Status Window (Integration Process Control)
Purpose: Use this window to change the status of an integration process control record. You might change the status of a record if you experienced communication problems and need to re-send or receive transactions.
You cannot change an integration process control record that is already in a CMP Complete status: Status Already Complete.
How to display this window: Select Change status for an integration layer process control record at the Work with Integration Layer Process Queues Screen.
To change: Select a status and click OK to update the integration process control record to that status.
-
Complete indicates the batch message has been completed.
-
Failed indicates the batch message transmission has failed.
-
Ready indicates the batch message is ready for transmission.
-
Received indicates the batch message transmission has been received from the external system.
-
Sent indicates the batch message transmission has been sent to the external system.
-
Transferred indicates the batch message has been transmitted.
Defining Outbound Interface Trigger Rules
Outbound interface trigger rules are the criteria a transaction must meet in order for the system to create an IL outbound trigger. For each outbound process, you can create trigger rules for certain tables. For example, you can create trigger rules for the Item table and SKU table to control the Item Outbound job. If you enter more than one criterion, the record must meet all of the criteria in order to generate a trigger.
Example: For the ITEM_OUT process, you can specify to create item download triggers for SKUed items in company 555 that are located in warehouse 20. To do this, for the Item table trigger rules, select a Test of Equal and enter 555 as the Value for the Company trigger field, and select a Test of Equal and enter ’Y’ as the Value for the Allow SKU’s trigger field. For the SKU table trigger rules, select a Test of Equal and enter 20 as the Value for the Warehouse trigger field.
Item table criteria | SKU table criteria | Results |
---|---|---|
The Company field must equal 27 or 555. The Allow SKUs field must equal ’Y’. |
The Warehouse field must equal 20. |
The system generates a SKU trigger only if the item/SKU being created, updated, or deleted is in company 27 or company 555 and the item is SKU’d and the SKU is located in warehouse 20. If the item/SKU does not meet all of the criteria, no trigger is created. |
You can create trigger rules for the following outbound processes.
For IL Process job: | you can create trigger rules for: | Example: |
---|---|---|
CUST_OUT |
Company, Customer class, Inactive?, and Country fields |
You can specify to create Customer Download messages only for active customers in the US and Canada. To do this:
|
ITEM_OUT |
Item (INITEM) SKU (INSKU) |
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:
See Item Outbound Trigger Rules. |
INVOIC_ OUT |
Invoice Header (OEINHD) Order Header (OEORDR) |
You can specify to only create invoice download triggers for debit invoices and not credit invoices. To do this, select a Test of Equal and enter I as the Value for the Invoice type trigger field. |
INV_ DOWNLD |
Item (INITEM) Item Warehouse (INIWRE) SKU (INSKU) Warehouse (INWRHS Item UPC (ITMUPC) |
You can specify to exclude drop ship items, non-inventory items, and membership items. To do this, select a Test of Equal and enter Y as the Value for the Drop ship item, Non-inventory, and Membership trigger fields. |
PICK_OUT |
Pick Control Header (FLPCTH) |
You can specify by company only. |
PO_OUT |
Purchase Order Header (POH) |
You can specify to only create purchase order download triggers for purchase orders that are created, closed, cancelled in company 12 and vendor 10001. To do this, select a Test of In and enter 12 as the Value for the Company trigger field and select a Test of Equal and enter 10001 as the Value for the Vendor trigger field. |
RETURN_OUT |
Order Header (OEORDR) |
You can specify to only create return authorization download triggers for return authorizations that are created, changed or deleted in company 7 or 555 and are associated with orders whose order type is W. To do this, select a Test of In and enter 7 555 as the Value for the Company trigger field, and select a Test of Equal and enter W as the Value for the Order Type trigger field. |
VENDOR_ OUT |
Vendor (POVEND) |
You can specify to create vendor download triggers only for companies 27 and 555 and vendor 202. To do this, select a Test of In and enter 27 555 as the Value for the Company trigger field, and select a Test of Equal and enter 202 as the Value for the Vendor # trigger field. |
Note:
Applying trigger rules for the BROKER job is not currently implemented.
Defining Trigger Rule Values
To create a trigger rule, select the fields in the table that should control trigger creation. For each trigger field, define:
-
a Test value: indicates how the system compares the record against the trigger rule criteria.
-
a Value: defines the trigger rule criterion.
Example: For the Company trigger field, select a Test of Equal and enter 555 as the Value field. This indicates the system creates IL outbound triggers only for company 555.
Field type: The T (type) field indicates if the value you enter must be numeric or alphanumeric.
-
N = the Value must be numeric.
-
A = The Value is alphanumeric.
Note:
-
Enter alphanumeric values between single quotes: for example, ’Y’.
-
When entering a list or range of alphanumeric values, separate each value with a space: for example, ’S F V’.
-
When entering a list or range of numeric values, separate each value with a comma: for example, 2,5,7.
-
If you select a Test value for a field you must also enter a Value, and vice versa.
-
The system does not validate that the value you enter for a trigger field is valid (if the field requires valid values) or is within the maximum field positions (for example, the Company field is 3 positions). Refer to your Database Listing to review field attributes for a table.
-
Fields that are in the table but are not included in the XML message are not included as a trigger field.
Test value | Description |
---|---|
blank |
A trigger rule is not specified for the field. |
Between (falls within a defined range) |
The field must fall within the trigger rule value range. For example, the Ship via must fall within 1 and 5. |
Equal |
The field must equal the trigger rule value. For example, the Company field must equal 555. |
Greater than |
The field must be greater than the trigger rule value. For example, the Cost field must be greater than 5.00. |
Greater than or equal |
The field must be greater than or equal to the trigger rule value. For example, the Cost field must be greater than or equal to 5.00. |
In (equal to a listed value) |
The field must match a trigger rule value. For example, the Company field must match 27, 409, or 555. |
Less than |
The field must be less than the trigger rule value. For example, the Cost field must be less than 500.00. |
Less than or equal |
The field must be less than or equal to the trigger rule value. For example, the Cost field must be less than or equal to 500.00. |
Not Between |
The field must not fall within the trigger rule value range. For example, the Postal code must not be between 96700 and 96899. |
Not Equal |
The field must not be equal to the trigger rule value. For example, the Company field must not be 25. |
Not In (not equal to a listed value) |
The field must not match a trigger rule value. For example, the Company field must not be 25 or 444. |
Select Trigger Rules File Window
Purpose: This window opens if you can define trigger rules for more than one table. If a process has only one table available for trigger rules, you advance directly to the Outbound Interface Trigger Rules Screen for this process.
How to display this window: Select Trigger Rules for an outbound process for which you can create trigger rules for more than one table.
Field | Description |
---|---|
Process |
The code and name of the process for which you are creating trigger rules. Alphanumeric, 10 positions; display-only. |
File name |
The table for which you are creating trigger rules. Select a table to advance to the Outbound Interface Trigger Rules Screen. Alphanumeric, 10 positions; optional. |
Outbound Interface Trigger Rules Screen
Purpose: Use this screen to define trigger rules for an outbound job.
The appearance of this screen varies based on the outbound process for which you are defining outbound trigger rules.
Using this screen: See Defining Outbound Interface Trigger Rules for a discussion.
How to display this screen:
-
Select Trigger Rules for an outbound process at the Work with Integration Layer Process Screen.
-
Select a table at the Select Trigger Rules File Window.
Field | Description |
---|---|
Process ID |
The code and name of the outbound process for which you are creating trigger rules. Alphanumeric, 10 positions; display-only. |
File name |
The table for which you are creating trigger rules. Alphanumeric, 10 positions; display-only. |
Field |
The field in the table for which you can create a trigger rule. When evaluating a record to determine whether to create an IL outbound trigger, the system compares the record’s field value against the trigger rule for the field. Alphanumeric, 15 positions; display-only. |
Test |
Indicates how the system compares the record against the trigger rule criteria. blank = A trigger rule is not specified for the field. Between (falls within a defined range) = The field must fall within the trigger rule value range. For example, the Ship via must fall within 1 and 5. Equal = The field must equal the trigger rule value. For example, the Company field must equal 555. Greater than = The field must be greater than the trigger rule value. For example, the Cost field must be greater than 5.00. Greater than or equal = The field must be greater than or equal to the trigger rule value. For example, the Cost field must be greater than or equal to 5.00. In (equal to a listed value) = The field must match a trigger rule value. For example, the Company field must match 27, 409, or 555. Less than = The field must be less than the trigger rule value. For example, the Cost field must be less than 500.00. Less than or equal = The field must be less than or equal to the trigger rule value. For example, the Cost field must be less than or equal to 500.00. Not Between = The field must not fall within the trigger rule value range. For example, the Postal code must not be between 96700 and 96899. Not Equal = The field must not be equal to the trigger rule value. For example, the Company field must not be 25. Not In (not equal to a listed value) = The field must not match a trigger rule value. For example, the Company field must not be 25 or 444. Alphanumeric, 5 positions; optional. |
Value |
Defines the trigger rule criterion. The system compares the trigger field value against the value of this field in each record.
When entering alphanumeric values, you must enter the value between single quotes; for example ’Y’. When entering a list or range of values, separate each value with a space; for example, 27 555 or ’S F V’. If you define a Value here, you must also select a Test value. Alphanumeric, 50 positions; optional. |
Type |
Indicates if the value you enter is numeric or alphanumeric. N = numeric A = alphanumeric Note: Enter alphanumeric values between single quotes; for example ’Y’. Alphanumeric, 1 position; display-only. |
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.
Remember: Parent elements are those elements that nest other elements; any elements nested underneath the parent element are its children.
Example: Some of the elements in the generic item download message are displayed below. In this example: Item is the parent of ItemInformation and ItemInformationDetail. ItemInformation is the parent of ItemInformationDetail and the child of Item. ItemInformationDetail is the child of ItemInformation and Item.
Item
SKU
UPC
Warehouse
ItemWarehouse
-
If you include the Item element, you can still exclude the SKU element. If you exclude the Item element, the SKU element and its children (UPC, Warehouse, and ItemWarehouse) are also excluded.
-
If you include the UPC element, the system automatically includes the SKU element. You can still exclude the Warehouse element.
-
If you exclude the Item element, the process still generates an “empty” message with just the top element information. For example, if you exclude the entire message for the INV_DOWNLD process, the resulting “empty” message would resemble:
<Message source="OROMS" target="cwi" type="CWInventoryDownload" date="02112006" time="10:38:10">
</Message>
This screen appears different based on the outbound process for which you are defining XML inclusion rules.
Important:
After you change XML inclusion rules, they do not take effect until after you restart the application.
You can define XML inclusion rules for the following outbound processes:
For IL Process job: | You can create XML inclusion rules for: |
---|---|
CUST_OUT |
parent and child elements included in the Customer Download XML Message (CWCustomerDownload). See Customer Outbound XML Inclusion For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
ITEM_OUT |
parent and child elements included in the Item Download XML Message (CWItemOut). See Item Outbound XML Inclusion. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
VENDOR_OUT |
parent and child elements included in the Vendor Download XML Message (CWVendorOut) See Vendor Outbound XML Inclusion. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
INVOIC_OUT |
parent and child elements included in the Invoice Download XML Message (CWInvoiceOut). See Invoice Outbound XML Inclusion. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
INV_DOWNLD |
parent and child elements included in the Inventory Download XML Message (CWInventoryDownload). See Inventory Download XML Inclusion.. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
PICK_OUT |
parent and child elements included in the Pick Message from Order Management System (CWPickOut). See Pick Out Processing. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
Note:
Although you can display XML inclusion options for the MERCH_LOC process, these options are not currently implemented.
When you first advance to the screen in your environment, all elements are included.
How to display this screen: Select XML inclusion for an outbound process at the Work with Integration Layer Process Screen.
Field | Description |
---|---|
Process ID |
The code and name of the outbound process for which you are creating XML inclusion rules. Alphanumeric, 10 positions; display-only. |
Include |
Indicates whether the element is included in the download XML message. selected = the element and its parent(s) are included in the XML message. unselected = the element and its children are not included in the XML message. Select Include for an element to include it and its parents in the generated XML messages. The system updates this field for the element and its parents to selected. Select Exclude for an element to exclude it and its children in the generated XML messages. The system updates this field for the element and its children to unselected. |
Element |
The name of an element tag to include or exclude in the download XML message. Alphanumeric, 30 positions; optional. |
Screen Option | Procedure |
---|---|
Include the element tag and its parents |
Select Include for an element. The Include field for the element and its parents updates to Y. |
Exclude the element tag and its children |
Select Exclude for an element. The Include field for the element and its children updates to N. |
Select XML Message Version Screen
Purpose: Use this screen to select the version of an outbound XML message to be generated by a system-delivered integration layer job. By default, each process generates version 1.0, but you can select a higher version if it is available. See XML Versions for an overview.
How to display this screen: Select Outbound XML Ver for a process at the Work with Integration Process Control Screen. This option is not available for processes that do not generate outbound XML messages.
Completing this screen: Select the XML version you would like to generate. Afterward, stop and restart the process at the Work with Integration Process Control Screen to have your change take effect.
Using the JOBCLN Function to Troubleshoot IJCT Jobs
Use the JOBCLN periodic function to resolve issues with the status of IJCT jobs. This periodic function updates IJCT job status as follows:
Note:
The JOBCLN function does not resolve issues with hidden jobs or with Interact jobs (CUSTOMER_IN, CUST_HIST, CUST_SRCH, CUSTOMER_IN, EMAIL_OUT, INV_INQUIRY, MERCH_LOC, ORDER_IN, RETURN_IN, TAX_INT, and WORKFLOW). Also, it does not resolve issues with the SVC_BALANC job unless there is at least one company that has Perform Balance Inquiry during Batch Authorizations (J19) selected.
For other IJCT jobs, the JOBCLN function does the following:
-
If job has neither an Inbound or Outbound program specified, set to INACTIVE if in any other status.
-
If the job is currently running (at least one process queue active):
-
If the status is INACTIVE, update to ACTIVE; otherwise, do not change status.
-
Reset the active session count if it is not correct.
-
If the job uses an active procedure (see Purge Active Procedures Across Users (MACX)) and there is currently no active procedure for the job, create it.
-
If the job is in END, FINISHED, or MSG at the Job Management (My Jobs) screen, update status to RUN and update Job History (Display Job History (DJHY)).
-
-
If the job does not have any process queues currently running:
-
If the status is ACTIVE, STARTING, or ENDING, update to INACTIVE.
-
Set the active session count to 0 if it is greater than 0.
-
If there is an active procedure, delete it.
-
If the job is in any status but END at the Job Management screen, update it to END and update Job History.
-
-
Deletes any existing END records for the job so that the job will remaining running when it is restarted.
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 Management System 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 Management System to the DMT system.
-
Using the Financial Data Interface describes how to extract information to the Financial Sales Download table.
Working with Periodic Functions (WPER)
Periodic functions are jobs that you need to run periodically, usually on a daily, monthly, or yearly basis. Periodic functions include reports listing or summarizing activity in a particular area of your business, reports providing current status information on your business, periodic resets, and aging operations.
Assign certain functions to your daily, monthly and yearly processing; a list of these functions appears in this topic. You can define your own programs and queues as periodic functions as well.
You use Working with Periodic Processes (WPPR) to define a group of periodic functions to run together within a periodic process and to schedule when the system executes the process. You cannot run a periodic function by itself.
Note:
Periodic functions and processes are not restricted by company; when you create a periodic function or process, it is defined across all companies.
For more information: See Periodic Functions Available to Schedule for a listing of functions.
In this topic:
Work with Periodic Functions Screen
How to display this screen: Enter WPER in the Fast path field at the top of any menu, or select Work with Periodic Functions from a menu.
Field | Description |
---|---|
Function |
The name of the periodic function. Alphanumeric, 7 positions; display-only. |
Description |
The description of the periodic function. Alphanumeric, 70 positions; optional. |
Applic (Application area code) |
The area of Order Management System (for example, Customer Service) where this function belongs. Use application areas to categorize similar system control values, secured features, and menu options as well as periodic functions. Alphanumeric, 3 positions; optional. |
System |
Indicates whether the periodic function is a system-level function, which was delivered with the software and cannot be changed or deleted. Valid values are:
Optional. |
Screen Option | Procedure |
---|---|
Change a periodic function |
Select Change for the function to advance to the Change Periodic Function Screen. You can change any information on this screen except for the function name. See the Create Periodic Function Screen for field descriptions. |
Delete a periodic function |
Select Delete for a function to delete it. Note: You cannot delete a function that is assigned to a periodic process. You must first remove the periodic function from the process before you can delete it. |
Display a periodic function |
Select Display for a function to advance to the Display Periodic Function Screen. You cannot change any information. See the Create Periodic Function Screen for field descriptions. |
Create a new periodic function |
Select Create to advance to the Create Periodic Function Screen. |
Create Periodic Function Screen
Purpose: Use this screen to create a function to include in periodic processing.
How to display this screen: Select Create at the Work with Periodic Functions Screen.
Field | Description |
---|---|
Function |
The name of the periodic function. You must define a function at this screen before you can assign it to a periodic process. Alphanumeric, 7 positions. Create screen: required. Change screen: display-only. |
Description |
The description of the periodic function. Alphanumeric, 70 positions; optional. |
Company parameter |
Select this field to indicate that a company parameter is required to execute the periodic process containing this periodic function. If you assign a function with this field selected to a periodic process, it updates the Company parameter field for the periodic process to selected, and you need to enter a company code at the First Execute Periodic Process Screen (Setting Parameters). Note: In order to run a periodic function without errors, you must select the Company parameter, even if the periodic function is designed to run across companies. Company codes are defined in and validated against the Company table. |
Appl area (Application area code) |
The area of Order Management System (for example, Customer Service) where this function belongs. Use application areas to categorize similar system control values, secured features, and menu options as well as periodic functions. Alphanumeric, 3 positions; required. |
Program name |
The name of the program to be called by the periodic function. Used only if no Class name is defined. You cannot define both a Program name and a Class name. Alphanumeric, 10 positions; required. |
Class name |
The name of the class to be called by the periodic function. Used only if no Program name is defined. You cannot defined both a Program name and a Class name. Currently, the Class name is used only for the following periodic functions:
Alphanumeric, 63 positions; required if no Program name is defined." |
Parameter |
A parameter required to execute the periodic function. See Periodic Functions Available to Schedule to review which periodic functions allow you to define an additional parameter. Alphanumeric, 256 positions; optional. |
Working with Periodic Processes (WPPR)
Periodic processes are jobs consisting of one or more periodic functions that run on a daily, weekly, monthly, or yearly basis.
See Periodic Functions Available to Schedule for examples of functions to assign to your daily, weekly, monthly and yearly processing.
Note:
Periodic functions and processes are not restricted by company; when you create a periodic function or process, it is defined across all companies.
Scheduling jobs: See Scheduling Jobs for information on how to schedule periodic processes.
Execute process through web service: You can also use the CWProcessIn message or the ProcessIn message to start a periodic process. See Using the CWProcessIn Message to Start a Periodic Process or Using the ProcessIn REST Message to Start a Periodic Process for more information.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Options: You can execute a periodic process or display its history from the Work with Periodic Process screen or through separate menu options. See Executing Periodic Processes (EPRO), for information on running a periodic process and Working with Periodic Process History (WPHS), for information on displaying the past records of a periodic process.
Generating a job notification: You can generate an outbound web service message to notify an external system when a periodic process is complete. See Using the Job Notification Outbound REST Message for more information.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Purging history: When a process completes, it automatically deletes any Process History Header records, and their associated Process History Detail records, for that process that are in completed or canceled status, and if the date for the detail records is older than the Periodic Process History Purge Days (L77). See that system control value for more information.
In this topic:
Work with Periodic Processes Screen
How to display this screen: Enter WPPR in the Fast path field at the top of any menu, or select Work with Periodic Process from a menu.
Field | Description |
---|---|
Process |
The name of the periodic process. Alphanumeric, 10 positions; optional. |
Description |
The description of the periodic process. Alphanumeric, 70 positions; optional. |
Appl Area (Application area) |
The area of Order Management System (for example, Order Entry) where this process belongs. Alphanumeric, 3 positions; optional. |
Type (Periodic process type list) |
Indicates the time period of the periodic process. Processes run on a daily, weekly, monthly or yearly basis. Informational-only. Valid values are:
Optional. |
Sys opt (System operation) |
Indicates whether the periodic process is a system-level process that cannot be changed or deleted. Valid values are:
|
Screen Option | Procedure |
---|---|
Change a periodic process |
Select Change for the process to advance to the Change Periodic Process Screen. You can change any information on this screen except the process name and company parameter. See the Create Periodic Process Screen for field descriptions. |
Delete a periodic process |
Select Delete for a process to delete it. Note: You cannot delete a periodic process if process history exists. You must first delete the history before you can delete the periodic process. |
Display a periodic process |
Select Display for a process to advance to the Display Periodic Process Screen. You cannot change any information. See Create Periodic Process Screen for field descriptions. |
Display the periodic functions within the periodic process |
Select Functions for a process to advance to the Work with Process Assignments Screen (Assigning Functions to a Periodic Process). |
Run a periodic process |
Select Execute for a process to advance to the First Execute Periodic Process Screen (Setting Parameters). |
Display the history of a periodic process |
Select History for a process to advance to the Work with Process History Screen. |
Create a new periodic process |
Select Create to advance to the Create Periodic Process Screen. |
Create Periodic Process Screen
Purpose: Use this screen to create a periodic process.
To assign functions to the periodic process, return to the Work with Periodic Process screen and select Functions for the process. See Work with Process Assignments Screen (Assigning Functions to a Periodic Process).
How to display this screen: Select Create at the Work with Periodic Processes Screen.
Field | Description |
---|---|
Process |
The name of the periodic process. Alphanumeric, 10 positions. Create screen: required. Change screen: display-only. |
Description |
The description of the periodic process. Alphanumeric, 70 positions; required. |
Type (Periodic process type list) |
Indicates the time period of the periodic process. Processes can be run on a daily, weekly, monthly or yearly basis. Informational-only. Valid values are:
Optional. |
Company parameter? |
This flag is included on the Change Periodic Process Screen and the Display Periodic Process Screen, and indicates whether any of the periodic functions added through the Work with Process Assignments Screen (Assigning Functions to a Periodic Process) require a company parameter. Possible settings are:
If this value is selected, the Company field at the First Execute Periodic Process Screen (Setting Parameters) is enterable and required; otherwise, the field is display-only. |
Appl area |
The area of Order Management System (for example, Order Entry) where this process belongs. Alphanumeric, 3 positions; required. |
Job queue |
The job queue where the system submits the periodic process. The job queue defaults to QBATCH. Alphanumeric, 10 positions; required. |
Work with Process Assignments Screen (Assigning Functions to a Periodic Process)
Purpose: Use this screen to assign periodic functions to a periodic process.
How to display this screen: Select Functions for a process at the Work with Periodic Processes Screen
Field | Description |
---|---|
Process |
The name of the periodic process. Alphanumeric, 10 positions; display-only. |
Description |
The description of the periodic process. Alphanumeric, 70 positions; display-only. |
Type |
Indicates the time period of the periodic process. Processes can be run on a daily, weekly, monthly or yearly basis. Informational-only.
Alphanumeric, display-only. |
Appl area |
The area of Order Management System (for example, Order Entry) where this application belongs. Alphanumeric, 3 positions; display-only. |
Seq # (Sequence Number) |
The position of the function within the periodic process. This number indicates the order in which the system executes the functions within the process. Numeric, 3 positions; required. |
Function |
The name of the periodic function. Periodic functions are validated against the Periodic Function table. Alphanumeric, 7 positions; required. |
Description |
The description of the periodic function. Alphanumeric, 70 positions; displays when correct information is entered in the required fields. |
Select |
Indicates whether to include the periodic function in the next execution. Valid values are:
Required. |
Screen Option | Procedure |
---|---|
Remove a periodic function from a periodic process |
Select Delete for a periodic function to advance to the Confirm Delete window. Select Delete to remove the periodic function from the periodic process; otherwise, select Exit to cancel. |
Executing Periodic Processes (EPRO)
Purpose: Use the Executing Periodic Processes function to select and set up the parameters of a process for its execution.
The parameters of the process contain:
-
the company where the execution takes place
-
the schedule parameters of when the system executes the periodic process
Note:
Periodic functions and processes are not restricted by company; when you create a periodic function or process, it is accessible to run across all companies.
In this topic:
Other ways to submit periodic processes: You can also execute a periodic process through:
-
Using the CWProcessIn Message to Start a Periodic Process
-
Using the ProcessIn REST Message to Start a Periodic Process
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Select Periodic Process to Execute Screen
How to display this screen: Enter EPRO in the Fast path field at the top of any menu, or select Execute Periodic Process from a menu.
Field | Description |
---|---|
Process |
The name of the periodic process you wish to run. Alphanumeric, 10 positions; required. |
Completing this screen:
-
Enter the name of a periodic process in the Process field and select OK.
-
You advance to the First Execute Periodic Process Screen (Setting Parameters). At this screen, you can define the schedule of when the system executes the periodic process.
First Execute Periodic Process Screen (Setting Parameters)
Purpose: Use this screen to set up the parameters of the process for execution.
How to display this screen:
-
Enter the process name in the Process field on the Select Periodic Process to Execute Screen.
-
Select Execute for a periodic process on the Work with Periodic Processes Screen.
Field | Description |
---|---|
Process |
The name of the periodic process. Alphanumeric, 10 positions; display-only. |
Description (unlabeled field to the right of the Process field) |
The description of the periodic process. Alphanumeric, 30 positions; display-only. |
Application area |
The area of Order Management System, for example Order Entry, where this process belongs. Alphanumeric, 3 positions; display-only. |
Type description (unlabeled field below the process description) |
Unlabeled field underneath the Description field. Indicates the time period of the periodic process. Processes run on a daily, weekly, monthly or yearly basis. Informational-only. Valid values are:
Display-only. |
Company |
The company where the process runs. You need to enter a company code even for periodic processes that run for all companies, for example, starting or stopping asyncs. The system ignores the company parameter for periodic functions in the process that do not require company. Alphanumeric, 3 positions; required. |
Job queue |
The job queue where the system submits the periodic process. The job queue defaults to *JOBD, indicating the system submits the periodic process to QBATCH. Note: If you wish to run the job in a designated queue, define that queue. Use the PICKGEN job queue when scheduling pick slip generation or deposits. Alphanumeric, 10 positions; required. |
Scheduling |
See Scheduling Jobs for more information on how to schedule a job. |
Frequency |
Indicates how often the system executes the periodic process. Valid values are:
Alphanumeric, required. |
Date |
The date when the system executes the periodic process. This field is required if you select Once for the Frequency. You can enter a date that is greater than or equal to today’s date. If you enter today’s date, the Time must be greater than the current time. Numeric, 6 positions (in user date format); required if Frequency is Once. |
Time |
The time, in military format, when the system executes the periodic process. If you enter today’s Date, the time must be greater than the current time. This field is required if you select Once, Daily, Weekly, Monthly, Month Start, or Month End for the Frequency. A time of 000000 indicates to run the process at midnight. Numeric, 6 position (HHMMSS, military format); required unless Frequency is Now. |
Day of week |
The day of the week when the system executes the periodic process. This field is required if you select Weekly for the Frequency. Valid values are:
Alphanumeric, 10 positions; required if Frequency is Weekly. |
Day of month |
The day of the month when the system executes the periodic process. This field is required if you select Monthly for the Frequency. Valid values are 0 - 31. Note: If you enter 31 as the day of the month, the system will only execute the periodic process on those months that contain 31 as a valid date. If you wish to execute the periodic process at the end of each month, select the MONTH END option for the Frequency. Numeric, required if Frequency is Monthly. |
Completing this screen:
# | Step |
---|---|
1. |
Enter a valid company code in the Company field. |
2. |
Enter a valid job queue in the Job queue field. If you leave this field set to *JOBQ, the system submits the periodic process to QBATCH. |
3. |
Select when to execute the periodic process using the Frequency field. See Periodic Process Scheduling Examples for examples of how to schedule a periodic process.
|
4. |
The Frequency field indicates which Scheduling fields are required, based on the frequency option you select:
|
5. |
If you enter a value in any of the Scheduling fields that is not required for the frequency you selected, the system ignores those entries when executing the periodic process. For example, if you select Now for the Frequency and also enter a value in the Weekly field, the system executes the periodic process immediately and ignores the value in the Weekly field. |
6. |
Select OK to advance to the Second Execute Periodic Process Screen (Selecting Functions). At this screen, you can select the functions within the process to execute.
|
Periodic Process Scheduling Examples
The table below provides examples of how to define a schedule for a periodic process.
Schedule | Procedure |
---|---|
Execute the periodic process immediately. |
Select Now for the Frequency. The system submits the job to the specified job queue for the user that executed the periodic process. Note: Because the process is executed immediately, the system does not add the periodic process to the job scheduler. |
Execute the periodic process tonight at 7 PM. Do not run the process any other night. Example: End asyncs tonight at 7 PM. |
|
Execute the periodic process today at 3 PM and tomorrow at 8 AM. Do not run the process at any other time. Example: Run a status report today at 3 PM and again tomorrow at 8 AM. |
Note: You need to create more than one schedule for the periodic process. First Schedule:
Second Schedule: |
Execute the periodic process every morning at 6 AM. Example: Start asyncs every morning at 6 AM. |
|
Execute the periodic process every morning, except Saturdays and Sundays, at 6 AM. Example: Start the asyncs every morning during the work week at 6 AM. |
Note: You need to create more than one schedule for the periodic process. First Schedule:
Second Schedule:
Third Schedule:
Fourth Schedule:
Fifth Schedule:
|
Run the periodic process every week on Mondays at 10 AM. Example: Run the weekly status reports every Monday at 10 AM. |
|
Run the periodic process every month on the 25th day of every month at 7 PM. Example: Run the monthly status reports on the 25th day of every month at 7 PM. |
|
Run the periodic process on the first day of every month at 8 AM. Example: Run the monthly status report on the first day of every month at 8 AM. |
|
Run the periodic process on the last day of every month at 9 PM. Example: Run the monthly status report on the last day of every month at 9 PM. |
Second Execute Periodic Process Screen (Selecting Functions)
Purpose: Use this screen to select the functions within the process you wish to run.
How to display this screen: Complete all the necessary fields on the first First Execute Periodic Process Screen (Setting Parameters).
Field | Description |
---|---|
Process |
The name of the periodic process. Alphanumeric, 10 positions; display-only. |
Description (Unlabeled field to the right of the Process field) |
The description of the periodic process. Alphanumeric, 30 positions; display-only. |
Application area |
The area of Order Management System, (for example, Order Entry) where this process belongs. Alphanumeric, 3 positions; display-only. |
Type description (unlabeled field below the process description) |
Indicates the time period of a periodic process. Processes run on a daily, weekly, monthly or yearly basis. Informational-only. Valid values are:
Display-only. |
Seq# |
The position of the function within the periodic process. This number indicates the order in which the system executes the functions within the process. Alphanumeric, 1 position; display-only. |
Function |
The name of the periodic function. Alphanumeric, 7 positions; display only. |
Description |
The description of the periodic function. Alphanumeric, 70 positions; display only. |
Select |
Indicates whether to include the periodic function in the execution. Valid values are:
Required. |
Screen Option | Procedure |
---|---|
Schedule the periodic process and save the job options |
Select Schedule. This option only displays if the periodic process is scheduled to run in the future (you selected any value other than Now in the Frequency field). The system adds the periodic process to the job scheduler and does not execute the periodic process until the specified time is reached. See Scheduling Jobs. |
Execute the periodic process and do not save the job options |
Select Execute. This option only displays if the periodic process is scheduled to run immediately (you selected Now in the Frequency field). Because the process runs immediately, the system does not add the process to the job scheduler. |
Execute the periodic process and save the job options |
Select Execute & Save Overrides. This option only displays if the periodic process is scheduled to run immediately (you selected Now in the Frequency field). Because the process runs immediately, the system does not add the process to the job scheduler. |
Working with Periodic Process History (WPHS)
Purpose: Use this function to review the processing information of a periodic process.
The records of a process contain:
-
the initiation date and time
-
the activation date and time
-
the process date and time
-
the list of functions that make up the process
-
the status of each function
Example: If a function within the process does not run as planned, the status function error is displayed next to the function.
Note:
Periodic functions and processes are not restricted by company; when you create a periodic function or process, it is defined across all companies.
In this topic:
For more information:
-
creating periodic functions: Working with Periodic Functions (WPER)
-
creating a periodic process and assigning functions to a process: Working with Periodic Processes (WPPR)
-
running a process: Executing Periodic Processes (EPRO)
-
a list of functions to include in your periodic processing and reviewing the periodic process job schedule: Scheduling Jobs
-
purging periodic process history in a completed status for all Order Management System companies prior to a specified date: Purge Periodic Process History (MPPR)
-
specifying the default number of days old a history record should be before it is eligible for purge: Periodic Process History Purge Days (L77)
Work with Process History Screen
How to display this screen:
-
Enter WPHS in the Fast path field at the top of any menu
-
Select Work with Process History from a menu
-
Select History for a periodic process on the Work with Process History Screen
The screen displays process history in alphanumeric order by process name, and in LIFO (last in, first out, or most recent to oldest) sequence for each process.
Field | Description |
---|---|
Process |
The name of the periodic process. When you advance to the screen from the Work with Process History Screen, only the process you select will display. Alphanumeric, 10 positions; optional (display-only from Work with Periodic Process screen). |
Description |
The description of the periodic process. Alphanumeric, 30 positions; display-only. |
Status |
The stage of the periodic process. Valid values are:
Optional (display-only from Work with Periodic Process screen). |
Init date (Initiation date) |
The date the periodic process was queued for processing. Numeric, 6 positions (in user date format); optional (display-only from Work with Periodic Process screen). |
Init time (Initiation time) |
The time the periodic process was queued for processing. Numeric, 6 positions (HHMMSS format); optional (display-only from Work with Periodic Process screen). |
Screen Option | Procedure |
---|---|
Display process history details |
Select Details for the process to advance to the Display Process History Details Screen. |
Update the status of a periodic process history record to completed |
Select Mark completed for the process to update the status to Completed. |
Display Process History Details Screen
Purpose: Use this screen to display the details of periodic process history.
How to display this screen: Select Details for a periodic process at the Work with Process History Screen.
Field | Description |
---|---|
Process |
The name of the periodic process displayed. Alphanumeric, 10 positions; display-only. |
Description |
The description of the periodic process. Alphanumeric, 30 positions; display-only. |
Status |
The stage of the periodic process. Valid values are:
Display-only. |
Initiation date |
The date when the periodic process was queued for processing. Numeric, 6 positions (in user date format); display-only. |
Activation date |
The date the periodic process began running, or was scheduled to begin running on the system. Valid values are: *CURRENT = the current day *MONTHSTR = the beginning of the month *MONTHEND = the end of the month *MON-*SUN = specific day of the week Alphanumeric, 10 positions (in user date format); display-only. |
Initiation time |
The time the periodic process was queued for processing. Numeric, 6 positions (HHMMSS format); display-only. |
Activation time |
The time the periodic process was actively running on the system. Valid values are: *CURRENT = the present time Alphanumeric, 10 positions (HHMMSS format); display-only. |
For each periodic function included in the process: |
|
Date |
The date the periodic function began processing on the system. Numeric, 6 positions (in user date format); optional. |
Time |
The time the periodic function began processing on the system. Numeric, 6 positions (HHMMSS format); optional. |
Function |
The name of the periodic function. Alphanumeric, 7 positions; display-only. |
Message |
Indicates the status of the job. Alphanumeric, 7 positions; display-only. |
Purge Periodic Process History (MPPR)
Purpose: Use this menu option to delete all Completed (P) or Canceled (C) Process History Header records, and their associated Process History Detail records, for all processes in all companies if the date for the detail record is older than the Purge history prior to initiate date specified.
If there are any Process History Detail records that are not associated with a Process History Header record, these detail records are also deleted.
Additional way to purge history: After a periodic process runs, it automatically purges history records that are older than the Periodic Process History Purge Days (L77). This automatic purge applies only to records for that periodic process. See the Periodic Process History Purge Days (L77) system control value for more information.
Determining the purge days across companies: The setting of the Purge history prior to initiate date defaults from the Periodic Process History Purge Days (L77) system control value. Because the Purge Periodic Process History option runs across all companies, it searches for a Periodic Process History Purge Days (L77) setting across companies numerically and uses the first system control value setting that is not zero. This search occurs regardless of the current company you are working in at the time you select the Purge Periodic Process History option.
Example: You are working in company 1, where the Periodic Process History Purge Days (L77) system control value is set to zero. In company 2, the system control value is set to 45. The purge function defaults a purge date that is 45 days earlier than the current date.
Reviewing history: You can review periodic process history using the Working with Periodic Process History (WPHS) menu option.
Purge Process History Screen
Use this screen to delete periodic process history in a completed or canceled status for all Order Management System companies prior to a specified date.
How to display this screen: Enter MPPR in the Fast path field or select Purge Periodic Process History from a menu.
Field | Description |
---|---|
Purge history detail prior to date |
The system defaults this date by subtracting the Periodic Process History Purge Days (L77) from the current date, but you can override this default. See above for a discussion. Numeric, 6 positions (in user date format); required. |
Completing this screen:
-
Optionally, override the Purge history prior to initiate date. The system calculates the default date by subtracting the Periodic Process History Purge Days (L77) from the current date, but you can override the default. See above for a discussion.
-
Select OK to validate your entry.
-
Select Accept to advance to the Confirm Accept window. Select OK to submit the PHST_PURGE job; otherwise, select Exit to cancel.
The PHST_PURGE job:
-
deletes records in the Process History Detail table whose PHH status is P (Completed) or C (Canceled), and whose PHH initiation date is earlier than the Purge history prior to initiate date.
-
deletes records in the Process History Header table which, after the action detailed above, no longer associate with any Process History Detail records.
-
deletes any additional Process History Detail records, for all companies, that are not associated with a Process History Header record.
Printing the Tax Jurisdiction Report (PTXJ)
Purpose: Run the Tax Jurisdiction Report to identify the dollars collected and credited for each tax jurisdiction for a specified invoice date range.
You can use the Working with Tax Jurisdiction (WTXJ) menu option to define tax jurisdictions. Tax Jurisdictions define postal code ranges for an area where a special tax structure exists. For example, tax jurisdictions exist for some counties in New York and New Jersey. Different tax rates apply for these areas, rather than the usual tax rate for the postal code or SCF. In addition, you can define tax jurisdictions within the United States only.
To generate the report:
# | Step |
---|---|
1. |
At the Print Tax Jurisdiction Report Screen, enter the invoice date range you wish to use to generate the Tax Jurisdiction Report. |
2. |
Select OK to validate your entries and then select Print Report. |
3. |
The system submits the TAX_JUR job to generate the Tax Jurisdiction Report. |
Determining the invoices to include on the report: The system uses the invoice date range you define on the Print Tax Jurisdiction Report Screen and the Invoice date in the Invoice Ship To table to determine which invoices to include on the report.
Determining the tax jurisdiction: The system uses the Invoice Address table to determine the ship to customer for the invoice. The system then compares the postal code defined for the ship to customer to the tax jurisdictions defined in Working with Tax Jurisdiction (WTXJ) to determine which tax jurisdiction is associated with the invoice.
UNKNOWN tax jurisdiction: Any tax amounts that are not associated with a tax jurisdiction print on the report under an UNKNOWN category.
Determining the tax: The system uses the Tax in the Invoice Ship To table to determine the tax to include on the report. Positive tax amounts accumulate in the Amount charged field on the report; negative tax amounts accumulate in the Amount credited field on the report. Note: The Tax field includes regular tax, GST, and PST amounts. The Tax field does not include VAT amounts.
Capture invoice address: In order to print the Tax Jurisdiction report, the Capture Addresses for Invoice (J24) system control value must be selected, indicating the system creates a record of the billing and shipping address in the Invoice Address table each time you bill a shipment.
Print Tax Jurisdiction Report Screen
Use this screen to specify the invoice date range to use to generate the Tax Jurisdiction Report and to submit the report.
How to display this screen: Enter PTXJ in the Fast path field at the top of any menu or select the Print Tax Jurisdiction report option from a menu.
Field | Description |
---|---|
Start date |
The start date for which you want to run the Tax Jurisdiction Report. The system uses the Invoice Ship To table to determine which invoices to include in the Tax Jurisdiction report. An error message displays if the Start date is a future date: Date must be on or before today’s date. Numeric, 6 positions (in user date format); required. |
End date |
The end date for which you want to run the Tax Jurisdiction Report. The system uses the Invoice Ship To table to determine which invoices to include in the Tax Jurisdiction report. An error message displays if the end date is a future date: Date must be on or before today’s date. An error message displays if the End date is earlier than the Start date: Starting date cannot be greater than Ending Date. Numeric, 6 positions (in user date format); required. |
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) decribes how to upload a file to a specified table in the Order Management System database.
Working with Default Options (WDFT)
Purpose: The Work with Default Options menu option lets you set up values for the system to retrieve automatically. For example, you might define default settings for the system to use when running a report or creating records in a table through a batch process. You can also define default values to pre-fill fields each time you advance to a particular screen.
Note:
The system will use the settings in the Default Options table only if the program is set up to do so.
In this topic:
Work with Program/Field Default Screen
Purpose: Use this screen to review the settings of default fields.
How to display this screen: Enter WDFT in the Fast path field at the top of any menu, or select Work with Default Options from a menu.
Field | Description |
---|---|
Program |
The program that uses the default setting. Alphanumeric, 10 positions; optional. |
Field name |
The name of the field to receive the default setting. Alphanumeric, 25 positions; optional. |
Default |
The default setting for the field to take. The attributes of the default vary, depending on the type of field. See Create Program/Field Default Screen. |
Screen Option | Procedure |
---|---|
Create a new default |
Select Create to advance to the Create Program/Field Default Screen. |
Change a default |
Select Change for a default option to advance to the Change Program/Field Default Screen. You can change only the field default. See the Create Program/Field Default Screen for field descriptions. |
Delete a default |
Select Delete for a default option to delete it. |
Display a default |
Select Display for a default option to advance to the Display Program/Field Default Screen. You cannot change any information at this screen. See the Create Program/Field Default Screen for field descriptions. |
Create Program/Field Default Screen
Purpose: Use this screen to create a new default option.Important:
The system does not validate that your entries on this screen are correct or appropriate. Also, your entries must be exact in order for the system to use the default value settings you create. For these reasons, you must take extreme care in setting up default options on this screen.
How to display this screen: Select Create at the Work with Program/Field Default Screen.
Field | Description |
---|---|
Program |
The program that will use the default option setting. Alphanumeric, 10 positions. Create screen: required Change screen: display-only. |
Field |
The name of the field that will take the default value you enter below. Alphanumeric, 25 positions; required. |
Change screen: the following fields are display-only. Create screen: only one of the following fields is also required: |
|
Status |
Valid values are: Selected Unselected |
Code |
Alphanumeric, 10 positions. |
Dollar |
Numeric, 13 positions with a 2-place decimal. |
Percentage |
Numeric, 5 positions with a 2-place decimal. |
Weight |
Numeric, 7 positions with a 3-place decimal. |
Sequence number |
Numeric, 6 positions. |
Number |
Numeric, 7 positions. |
Completing this screen: Complete the Program and Field fields and one of the remaining fields.
Consolidating Order Billing History (MOBH)
Purpose: Use the Consolidate Order Billing History menu option to consolidate records in the Order Billing History table up to a given date, to save space and eliminate unneeded information. You can “roll up” or consolidate records into summary records by indicating which key fields you would like to retain, and which you would like to blank out.
Example: You want to retain separate records by sold-to customer, but not ship-to customer. The total units and quantities of the ship-to customer records for each sold-to customer will be added or netted together, and then the individual ship-to customer records will be deleted. The resulting consolidated sold-to records will have the ship-to number fields set to zero.
The system flags each consolidated record in the table. You can consolidate any records only once.
When to run consolidation: You should run the consolidation at night, when there will not be any other activity that might update the Order Billing History table.
Reviewing consolidated records: When you review customer history through Work with Customers (fast path = WCST), any consolidated records are indicated as follows:
-
Consolidated items are flagged at the Customer Sold To Item History Screen (available by selecting Item History at a Create/Change/Display Customer screen, or selecting Item History for a customer at a selection screen)
-
The range of dates included in a consolidated record is indicated at the Display Customer Order History Screen (available by selecting Order History at a Create/Change/Display Customer screen, or selecting Order History for a customer at a selection screen)
-
The range of dates included in a consolidated record is indicated at the Order Billing History Detail Screen (available by selecting Display for an item at the Customer Sold To Item History screen or the Customer Sold To Order History screen)
Additional information: Working with Merge/Purge Sold-to Names (MMCS) ignores consolidated records that do not include the sold-to customer number.
In this topic:
Consolidate Order Billing History Screen
Each flagged option on this screen represents a key field in the Order Billing History table. In order to save separate order billing history records by a field, you must select it. For example, select the Customer flag to save separate order billing history for each sold-to customers; otherwise, the history will be consolidated across all sold-to customers in your company.
You must select at least one field.
How to display this screen: Enter MOBH in the Fast path field at the top of any menu or select Consolidate Order Billing History from a menu.
Note:
The system stores your entries on this screen in the Default Options table, to save data entry if you run the consolidation program periodically. The first time you use this screen, each yes/no flag will default to unselected, and the date field will be blank.
Field | Description |
---|---|
Consolidate transactions up to date |
Enter the last date for which order billing history should be consolidated. All order billing history records from this date or earlier that meet the selection criteria will be consolidated. Numeric, 6 positions (in user date format); required. |
Consolidate by: |
|
Customer |
This field indicates whether to consolidate order billing history by number of the sold-to customer on the order. Valid values are:
|
Ship to |
This field indicates whether to consolidate order billing history by customer ship-to number. Valid values are:
|
Item |
This field indicates whether to consolidate order billing history by item. Valid values are:
|
SKU |
This field indicates whether to consolidate order billing history by SKU. Valid values are:
|
Ship via |
This field indicates whether to consolidate order billing history by ship via. Valid values are:
|
Source |
This field indicates whether to consolidate order billing history by source code. Valid values are:
|
Offer |
This field indicates whether to consolidate order billing history by item. Valid values are:
|
Salesman |
This field indicates whether to consolidate order billing history by salesman. Valid values are:
|
Item class |
This field indicates whether to consolidate order billing history by item class. Valid values are:
|
Long SKU department |
This field indicates whether to consolidate order billing history by long SKU department. Valid values are:
|
Order# |
This field indicates whether to consolidate order billing history by order number. Valid values are:
|
Transaction code |
This field indicates whether to consolidate order billing history by transaction code. Valid values are:
Transaction codes for order billing history are:
|
Entity |
This field indicates whether to consolidate order billing history by entity. Valid values are:
|
Instructions:
-
Complete the Consolidate transactions up to date field and reset the flag for each selection option you would like to override.
-
Select Submit. The system submits the job CONSOL_OBH in held status. You must release this job to consolidate order billing history. Once released, the batch job consolidates order billing history based on your selection criteria, and produces the Order Billing History Consolidation Report.
Reset Allocation Quantities (MRPC)
Purpose: Use this option to reset the printed quantities for orders, as stored in the Order Detail, Reserved Order Line and the Item Location tables. The system uses the information in the Pick Control Detail and the Pick Location tables to determine the correct quantities.
Note:
To reduce the amount of time it takes to run this process, you should use Streamlined Pick Slip Generation (WSPS) to generate pick slips for as many orders as possible.
If there are inventory transaction errors: The system will not complete this reset if there are any inventory transaction errors. You must reprocess these transactions or delete the error records first. See Working with Inventory Transaction Errors (WITE).
Excluded from reset: The reset excludes any order lines that are:
-
printed on drop ship pick slips or purchase orders
-
brokered backordered lines being fulfilled through the Order Broker integration
-
store pickup lines being fulfilled through the Order Broker
See Order Broker Integration for information on fulfilling brokered backorders or store pickup orders through the Order Broker.
Scheduling: You can schedule when you want this reset to run using the RSTPICK periodic function.
Reset Pick Control Screen
How to display this screen: Enter MRPC in the Fast path field at the top of any menu, or select Reset Allocation Quantities from a menu.
Completing this screen:
# | Step |
---|---|
1. |
Select OK on the Reset Pick Control Screen. Select Confirm and then OK again to submit the Allocation Quantity Reset. |
2. |
The system submits the ALLOC_XCHK job and looks at the setting of the Inventory Sharing (A69) system control value.
|
3. |
If there are any inventory transaction errors, the job generates an error report indicating that the reset cannot take place until these errors are corrected; see Working with Inventory Transaction Errors (WITE). |
4. |
If there are no inventory transaction errors, the Allocation Quantity Reset:
|
|
Note:
See Order Broker Integration for information on fulfilling brokered backorders or store pickup orders through the Order Broker. |
Reset Reserve Quantity (MRQR)
Purpose: Use this option to reset the reserved quantity of items in inventory, as stored in the Item Warehouse table. The system uses the information in the Reserved Order Line table to determine the correct quantities of items currently reserved on open or held orders.
Scheduling the reset: You can also run this reset using the Daily Inventory Reset periodic function (program name MSR0698); see How to Schedule a Job.
If there are inventory transaction errors: The system will not complete this reset if there are any inventory transaction errors. You must reprocess these transactions or delete the error records first. See Working with Inventory Transaction Errors (WITE).
Reset Reserve Quantity Screen
Purpose: Enter MRQR in the Fast path field at the top of any menu, or select Reset Reserve Quantity from a menu.
Completing this screen:
# | Step |
---|---|
1. |
Select OK on the Reset Reserve Quantity Screen. Select Confirm and then OK again to submit the Reserve Quantity Reset. |
2. |
The system submits the RESET_RSRV job and looks at the setting of the Inventory Sharing (A69)
|
3. |
If there are any inventory transaction errors, the job generates an error report indicating that the reset cannot take place until these errors are corrected; see Working with Inventory Transaction Errors (WITE). |
4. |
If there are no inventory transaction errors, the Reserve Quantity Reset:
Note: If the Inventory Sharing (A69) system control value is selected, the reset does not generate a report. |
Reset Backorder Quantity (MRBO)
Purpose: Use this option to reset the backorder quantity of items in inventory, as stored in the Item Warehouse table.
Generation options: You can run the reset for all items in all warehouses, or for a specific item/SKU in a specific warehouse. You cannot specify a warehouse unless you also specify an item/SKU:
-
Update all Item Warehouse records:
-
If you leave the Warehouse, Item, and SKU fields blank, the job resets all Item Warehouse records and generates a report.
-
If you enter just the Warehouse, the screen displays an error; but if you submit the job anyway, it resets all Item Warehouse records and generates a report.
-
-
Update a single Item Warehouse record: Otherwise, if you specify a warehouse and item/SKU, the job immediately resets just that Item Warehouse and does not generate a report. Since the screen displays the current B/O qty if you enter the warehouse and item/SKU, you can compare this number with the Backorder quantity after you exit the screen.
Note:
If you specify a warehouse and the item code for a SKU’d item, you must also specify a SKU.
Inventory sharing? The setting of the Inventory Sharing (A69) system control value determines which program performs the backorder reset. If this system control value is:
-
selected: the system runs a batch job; also, it generates the Reset Audit Log for Item Warehouse unless you specify a warehouse and item/SKU. Note: If you are using inventory sharing, run the Item Warehouse Backorder Quantity Reset in the company where you actually maintain the inventory and then run the Item Warehouse Backorder Quantity Reset in the company(ies) that share the inventory.
-
unselected: the system runs the sp_reset_qty_backordered SQL stored procedure; also, it generates the Reset Audit Log for Quantity on Backorder unless you specify a warehouse and item/SKU.
Scheduling the reset: You can also run this reset using the Daily Inventory Reset periodic function (program name MSR0698); see Daily Inventory Reset.
Reset Item/Warehouse B/O Quantity Screen
How to display this screen: Enter MRBO in the Fast path field at the top of any menu, or select Reset Backorder Quantity from a menu.
Field | Description |
---|---|
Warehouse |
The warehouse whose backorder quantities you want to reset. Leave this field and the Item and SKU fields blank to reset all warehouses. See the discussion on generation options above for more information. Warehouse codes are defined in and validated against the Warehouse table. Numeric, 3 positions; optional. |
Item |
The item whose backorder quantity you want to reset. Leave this field and the Warehouse and SKU fields blank to reset all items. See the discussion on generation options above for more information. Item codes are defined in and validated against the Item table. Alphanumeric, 12 positions; optional. |
SKU |
The particular SKU of the item you want to reset. Required if you select a Warehouse and a SKU’d Item; otherwise, leave this field blank. See the discussion on generation options above for more information. Note: The SKU field appears as a single, 14-position field. Leave a space between each SKU element, or leave one or more additional spaces if a SKU element is shorter than the full 4 positions. Alphanumeric, 14 positions; required if you selected a SKU’d item. |
B/O qty Backorder quantity |
The backorder quantity of the selected item/SKU within the selected warehouse. If you specify a warehouse and item/SKU and select OK, this field displays the current backorder quantity for that Item Warehouse. See the discussion on generation options above for more information. Numeric, 7 positions; display-only. |
Completing this screen:
# | Step |
---|---|
1. |
Optionally, specify the warehouse and item/SKU whose backorder quantity you wish to reset. Select OK to validate your entries.Correct any errors and select OK again. Note:
|
2. |
Select Submit Reset to submit the RESETBOQTY job: Update to Item Warehouse Backorder quantity:
Update to Order Detail Open quantity: Open Quantity = (Quantity Ordered - Quantity Cancelled - Quantity Soldout - Quantity Shipped - Quantity Reserved) Report: The system uses the Inventory Sharing (A69) system control value to determine the reset program to use and the report to generate. If you are updating all Item Warehouse and the Inventory Sharing (A69) system control value is:
Note: When you specify a warehouse and item/SKU, the update to the specified Item Warehouse takes place interactively and no report is generated. |
Reset Item Warehouse Quantity on Hand (MRIW)
Purpose: Use this option to reset the quantity on-hand for each Item Warehouse record based on the total quantities on-hand for related Item Locations within the warehouse.
Example: The Item Warehouse record indicates that the current on-hand quantity for item AB100 in warehouse 10 is 100. There are two item location records for AB100 in warehouse 10: A010101, with a current on-hand quantity of 15; and BULK, with a current on-hand quantity of 100. This reset adds the on-hand quantities for the two item locations and resets the on-hand quantity for the Item Warehouse to 115 (100 + 15).
Scheduling the reset: You can also run this reset using the Reset On Hand Quantity periodic function (program name PFR0093); see How to Schedule a Job.
Reset On Hand Quantity Screen
How to display this screen: Enter MRIW in the Fast path field at the top of any menu, or select Reset Item Warehouse Quantity On Hand from a menu.
Completing this screen:
# | Step |
---|---|
1. |
Select OK on the Reset On Hand Quantity Screen. Select Confirm and then OK again to submit the Item Warehouse Quantity On Hand Reset. |
2. |
The system submits the RESET_ONHD job and calls the sp_reset_qty_on_hand SQL stored procedure to perform the Item Warehouse Quantity On Hand Reset. |
3. |
The reset:
Note: The reset takes place regardless of whether there are any Inventory Transaction Errors. |
Reset SKU Open Order Quantity (MRSO)
Purpose: Use this menu option to reset the following fields in the SKU table based on the current open orders for the SKU:
-
SKU open quantity: the total number of units remaining to be shipped for all open order detail lines, including any quantity reserved and backordered, on open, held, or suspended orders, but excluding drop-ship items and future orders. The Display Item/Warehouse Information Screen displays this field as SKU: Open.
-
On hold quantity: the total number of units on held orders, excluding drop-ship items and future orders.
-
Quantity order drop ship: the total number of units on open, held, or suspended orders waiting to be drop-shipped, including future orders for drop-ship items. The Display Item/Warehouse Information Screen displays this field as Open D/S.
-
Future quantity: the total number of units on open, held, or suspended orders that have the Future order flag set to Y
Scheduling the reset: You can also run this reset using the Daily Inventory Reset periodic function (program name MSR0698); see How to Schedule a Job.
Quotes: Because the system does not reserve inventory for items on quotes, the Reset SKU Open Order Quantity process does not include quotes; see Entering Pre-Order Quotes for an overview.
Reset SKU Open Order Quantity Screen
How to display this screen: Enter MRSO in the Fast path field at the top of any menu, or select Reset SKU Open Order Quantity from a menu.
Completing this screen:
# | Step |
---|---|
1. |
Select OK on the Reset SKU Open Order Quantity Screen. Select Confirm and then OK again to submit the reset. |
2. |
The system submits the RSET_SKUOO job and calls the sp_reset_qty_quantities SQL stored procedure to perform the SKU Open Order Quantity Reset. |
3. |
Regardless of whether there are any inventory transaction errors, the SKU Open Order Quantity Reset:
The Order Detail open quantity is calculated as: Quantity Open = (Quantity Ordered - Quantity Cancelled - Quantity Soldout - Quantity Shipped) Note:
|
Unlocking a Stranded Order or Batch (MULO)
Purpose: Use this menu option to clear the locked status of a stranded order or order batch so that you can work with it.
Why are orders and batches locked? Order Management System locks an order or batch when a user or process is working with the order, so that another user or process cannot update the order or batch at the same time.
What does the lock consist of? When a user is entering an order or selects an order for maintenance, or when a function is updating an order, Order Management System locks the order by entering the user’s login ID or the function name in the User field in the Order Header table. Similarly, Order Management System locks an order batch by entering the user’s login ID in the Entry user field in the Order Batch table.
How does an order or batch become stranded? Typically, an order or batch becomes stranded when a user is working with it and the session ends unexpectedly, such as when the workstation shuts down. In this situation, the system does not have an opportunity to clear the user ID from the order or order batch record. Similarly, an order or batch can become stranded if a process that is currently updating the record ends abnormally.
How can you tell when an order or batch is locked?
-
Order: You can tell that an order is locked if the system displays the Warning: Order Locked window when you attempt to maintain it. This window indicates the name of the user or process using the order, based on the current entry in the User field in the Order Header table.
-
Batch: You can tell that a batch is locked if a user ID is displayed in the In use by field at the Work with Error Orders Batches Screen. An error message displays if you try to access the batch: Order Batch is locked by user JJONES.
If a locked order is part of a locked batch: You must first unlock the batch, and then unlock the order.
Note:
The option to unlock an order is also available in Modern View.
Unlock Order or Batch Screen
How to display this screen: You can display this screen by entering MULO in the Fast path field at the top of any menu, or by selecting Unlock Order or Batch from a menu.
Field | Description |
---|---|
Order # |
To unlock a stranded order, enter the order number here. You can enter either an order number or a batch number. Numeric, 8 positions; optional. |
Batch # |
To unlock a stranded batch, enter the batch number here. If your entry in the Order # field was created as part of a batch, the batch number defaults here. You cannot enter both an order number and a batch number. If a batch number has defaulted from the entry of a previous order number, you must clear this field before entering another order number. Numeric, 5 positions; optional. |
Order status |
The current status of the order. Displayed for orders only. Possible statuses are:
Alphanumeric, 1 position; display-only. |
Batch date |
The date when the batch was created. Displayed only if you enter a batch number, not if a batch number defaults because it is associated with the entered order number. Displayed for batches only. Numeric, 6 positions (in user date format); display-only. |
Order date |
The effective date of the order for the purposes of aging and backorder analysis. When you enter an order, the current date defaults, but you can override it. Displayed for orders only. Numeric, 6 positions (in user date format); display-only. |
Locked by (order) |
The user ID or process name that was updating the order at the time it became stranded. Displayed for orders only. Alphanumeric, 10 positions; display-only. |
Entered date |
The date when the order was created. Displayed for orders only. Numeric, 6 positions (in user date format); display-only. |
Entered time |
The time when the order was created. Displayed for orders only. Numeric, 6 positions (HH:MM:SS format); display-only. |
Workstation |
The ID of the workstation where the user was working when creating the order, or the name of the process that created the order; for example, the workstation is E-COMMERCE for orders created through the Generic Order Interface (Order API). Displayed for orders only. Alphanumeric, 10 positions; display-only. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
Entered by |
The user ID of the person who entered the order, or the name of the process that created the order. For orders created through the generic order API, this is either the entered_by_user specified in the Inbound Order XML Message (CWORDERIN), or your default user if the entered_by_user is not specified. Displayed for orders only. Alphanumeric, 10 positions; display-only. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
Locked by (batch) |
The user ID or process name that was working with the batch at the time that it became stranded. Displayed for batches only. Alphanumeric, 10 positions; display-only. |
Customer # |
A unique number to identify the customer who placed the order (sold-to customer). Displayed for orders only. Numeric, 9 positions; display-only. |
Customer name (unlabeled field below the customer number) |
The name of the sold-to customer. Displayed for orders only. Alphanumeric, 41 positions; display-only. |
Unlocking a batch: Enter the batch number and click OK to display information about the batch and confirm that your entry is correct; if so, select Proceed with Unlock to unlock the batch. The system clears the Entry user field from the Order Batch table, and the batch is now available to be maintained by another user.
Unlocking an order: Enter the order number and click OK to display information about the order and confirm that your entry was correct; if so, select Proceed with Unlock to unlock the order. The system:
-
Clears the User field from the Order Header table.
-
Removes any pick slip preparation from the order and then reevaluates the order for pick slip preparation; see Preparing Orders for Pick Slip Generation.
-
Makes the order available for maintenance by another user. If the order is in an error or suspended status, you must maintain the order in its associated order batch.
Note:
If your initial entry is not correct, exit the screen and then re-enter to clear the information from your previous entries from displaying.
Resetting the Order Billing History Table (ROBH)
Purpose: Use the Reset Order Billing History file menu option to rebuild Order Billing History records for an order using the records in the Order Detail table.
When to run the reset: You should reset Order Billing History at night, when there will not be any activity that might update the Order Billing History table.
Instructions:
-
On the Recover Order Billing History File Screen, use the Starting order # and Ending order # fields to enter an order number or range of orders whose Order Billing History you wish to recreate.
-
Select OK.
-
Select Confirm to submit the OBH_RESET job in a held status.
-
On the Work with Submitted Jobs screen, release the OBH_RESET job from hold to begin the process of rebuilding Order Billing History for the orders you specified.
The OBH_RESET job:
-
Deletes all of the Order Billing History records for the specified orders.
-
Rebuilds the Order Billing History records for the specified orders, using the associated records in the following tables:
-
Order Detail
-
Order Ship To
-
Source
-
Division
-
Order Header Extended
-
Item
-
SKU
-
Recovers maintenance transactions from the Order Line History table.
-
Recovers billing transactions from the Invoice Detail table.
You can review Order Billing History for a customer on the Order Billing History Detail Screen.
Quotes: The Reset Order Billing History process does not include records in the order tables that are associated with a quote; see Entering Pre-Order Quotes for an overview.
Recover Order Billing History File Screen
Use this screen to define the order number or range of orders whose Order Billing History you wish to recreate, based on the records in the Order Detail table.
How to display this screen: Enter ROBH in the Fast path field at the top of a menu or select Reset Order Billing History File from a menu.
Field | Description |
---|---|
Starting order # |
The starting order number in the range whose Order Billing History you wish to recreate, based on the records in the Order Detail table. Numeric, 8 positions; required. |
Ending order # |
The ending order number in the range whose Order Billing History you wish to recreate, based on the records in the Order Detail table. Numeric, 8 positions; required. |
Resetting Customer Sold to Amount on Order (RONO)
Purpose: Use this menu option to reset the On order amount field in the Customer Sold To Order History table so that it matches the amount of any existing open orders for the customer.
You can review the On order amount on the Display Customer Order History Screen. The on order amount is the total value of all open, unshipped orders for a customer, including charges for merchandise, freight, tax, special handling, and shipping. The system subtracts the amount of a cancelled item or order from this field. The on order amount does not include the amount of soldout items on the order.
When should I run a reset? You should only perform a Customer Sold To $ On Order reset if you suspect the On order amount for a sold to customer is incorrect. For example:
-
an On order amount exists for a sold to customer that does not have any open orders.
-
a negative On order amount exists for a sold to customer.
-
an On order amount of 1.00 or less exists for a sold to customer.
Note:
Before you run this reset, you should end all background async jobs so that the On order amount is not changed while the reset job recalculates the On order amount.
Scheduling the reset: You can also run this reset using the Reset Customer Sold To Amount On Order periodic function (program name CSRSTONORD); see How to Schedule a Job.
Quotes: Because the system does not update the Customer Sold To $ On Order for quotes, the Reset Customer Sold To $ On Order process does not include quotes; see Entering Pre-Order Quotes for an overview.
To reset the sold to on order amount: Enter RONO in the Fast path field or select Reset Customer Sold To $ On Order from a menu. The system submits the RESET_CST job. This job:
# | Step |
---|---|
1. |
Calls the sp_reset_customer_on_order SQL stored procedure to perform the Customer Sold To $ On Order Reset. |
2. |
Retrieves all customers from the Customer Sold To Order History table by company code. |
3. |
For each customer sold to, accumulates the total open balances for Order Ship To records, excluding any Order Ship To records associated with an Order Header status of A, C, X, E, P, or S:
|
4. |
Calculates a grand total by accumulating the total balances. |
5. |
Compares the grand total to the COH On Order $ field in the Customer Sold To Order History table.
|
Note:
-
Because the Reset Customer Sold To $ On Order process retrieves all customers from the Customer Sold To Order History table, this job may take awhile to complete.
-
The Reset Customer Sold To $ On Order process does not reset the Order Header status to closed.
Unlock Purchase Order (MUPO)
Purpose: Use this option to unlock purchase orders so that you can work with or receive it.
About locked purchase orders: A purchase order is locked if the In use USR user field in the Purchase Order Header table is not blank. This situation might occur if, for example, a user’s browser window closed during purchase order maintenance. Until you unlock the purchase order, you cannot work with it.
If the purchase order has no detail lines: When you unlock a purchase order that does not have any detail lines, the system deletes the purchase order.
On-order reset: You can also use this menu option to reset the on-order quantity for all Item Warehouse records based on the:
-
unreceived quantities on open or held purchase orders
-
quantities received into suspense or to a pending putaway warehouse
The on-order reset is also available as a periodic function. See the Reset On-Order PO Quantity Periodic Function for more information.
Unlock Purchase Order Screen
How to display this screen: Enter MUPO in the Fast path field at the top of any menu, or select Unlock Purchase Order from a menu.
Field | Description |
---|---|
PO# |
Enter a valid number identifying a purchase order that is currently locked. You cannot prompt on this field. Numeric, 7 positions; required. |
When you enter the number of a locked purchase order, the screen displays the following information: |
|
Status |
The purchase order’s current status. Possible statuses are:
Alphanumeric, 1 position; display-only. |
Entered by |
The ID that identifies the user who entered the order. Alphanumeric, 10 positions; display-only. |
In use by |
The ID that identifies the user who was working with the purchase order when it was locked. Alphanumeric, 10 positions; display-only. |
Vendor |
The name or description of the vendor with whom you placed the purchase order. From the Vendor record; see Working with Vendors (WVEN) for more information. Alphanumeric, 30 positions; display-only. |
Completing this screen:
-
Enter a number identifying a purchase order that is currently locked. If your entry is valid, the remaining fields on the screen display information about the purchase order, and a message indicates if the purchase order will be unlocked or deleted:
-
Click OK to unlock PO = there is at least one purchase order detail line; the purchase order will be unlocked
-
Click OK to delete PO with no details = there are no detail lines for the purchase order; the purchase order will be deleted
-
Click OK.
Updates: The system:
-
Clears the In use USR user field in the Purchase Order Header table
-
If the purchase order does not have any complete detail lines, the system deletes the purchase order header and other related records, such as messages, overrides, estimated charges, and FOB addresses.
Additional updates not processed automatically: Unlocking a purchase order does not submit (or resubmit) the purchase order to the OTHR_ASYNC job. As a result, there is no automatic mechanism to update tables such as Vendor History based on activity that occurred during the creation or maintenance session that resulted in the lock.
Triggering updates:
-
You can process additional updates through related jobs such as the on-order reset available at this screen.
-
A reset is not available for certain tables, such as Vendor History. For example, if you added a new detail line in maintenance and then the browser window closed unexpectedly, locking the purchase order before you accepted your changes, the information about the new detail line is not reflected in Vendor History when you unlock the purchase order. To trigger these updates, you can select the purchase order for maintenance and then accept the maintenance session without making any changes. The purchase order is then submitted to the OTHR_ASYNC job and the related updates take place, as described in Updates During Background Processing.
Option | Procedure |
---|---|
Submit the on-order reset |
Select Reset On Order to run the on-order reset program. This program runs interactively and resets the on-order quantity for all Item Warehouse records in your company based on the current unreceived quantities on all open or held purchase orders, and any purchase orders received into suspense or to a pending putaway warehouse location. |
Working with File Uploads (WUPL)
Purpose: Use this menu option to upload a file to a specified table in the Order Management System database.
For more information: See Working with File Imports.
Work with File Upload Screen
Purpose: Use this screen to process a file upload.
RMFCS integration: You cannot use this screen to upload a file for the Oracle Retail Merchandising Foundation Cloud Service (RMFCS) and Oracle Retail Pricing Cloud Service (RPCS) Integration. See Data Flow from RMFCS and RPCS to Order Management System for a process overview. However, you can review uploads from RMFCS on this screen.
How to display this screen: Enter WUPL in the Fast path field at the top of any menu or select Work with File Uploads from a menu.
When you first advance to this screen, processed file uploads display on the screen in descending date sequence.
Column sort: You can sort on any column except Date on this screen by clicking the column name. An arrow pointing up displays next to the field when the values for the field display in ascending sequence; an arrow pointing down displays next to the field when the values for the field display in descending sequence.
Field | Description |
---|---|
File Name |
The file to upload to the Order Management System database. Select Browse to locate and select the file to upload. Required. |
File Type |
The type of upload to perform. Valid values are:
See Available File Uploads for more information about each upload. Note: You cannot use this screen to upload item or offer information from RMFCS; however, completed RMFCS imports are listed at this screen. See Oracle Retail Merchandising Foundation Cloud Service (RMFCS) and Oracle Retail Pricing Cloud Service (RPCS) Integration for background. Required. |
An upload history record displays for each file upload that you have begun processing by populating the staging table, or completed processing: |
|
Date |
The date and time when the file upload occurred. A record is written regardless of whether the upload was submitted from the screen or through a periodic function that submitted the file data for processing. Enter a full or partial date and time to review upload history records whose date contains your entry. Optional. |
Status |
The status of the file upload.
Enter a full or partial status to review upload history records whose status contains your entry. Alphanumeric, 10 positions; optional. |
File Type |
The type of file processed. Valid values are:
Enter a full or partial file type to review upload history records whose file type contains your entry. See Available File Uploads for more information about each upload. Note: You cannot use this screen to upload item or offer information from RMFCS; however, you can use this screen to review RMFCS imports. These uploads are listed with a file type of RIIUPP. See Oracle Retail Merchandising Foundation Cloud Service (RMFCS) and Oracle Retail Pricing Cloud Service (RPCS) Integration for background. Alphanumeric, 15 positions; optional. |
File Name |
The name of the file that was uploaded. A file path is displayed if the file was uploaded through the screen, rather than through the File Storage API. Enter a full or partial file name to review upload history records whose file name contains your entry. Alphanumeric, 256 positions; optional. |
User |
The user ID of the user that performed the file upload. A user ID of ADMIN is listed if the upload was processed through the File Storage API. Enter a full or partial user ID to review upload history records whose file name contains your entry. Alphanumeric, 10 positions; optional. |
Screen Option | Procedure |
---|---|
Process a file upload |
Use the Browse button to select a file for upload, and then select the File Type. See File Upload Process for more information. |
Delete an upload history record |
Select Delete for an upload history record. At the Are you sure you want to delete the upload history? window, select Yes to delete it; otherwise, select No to cancel. You can also use the PURGEUH Purge Upload History Table periodic function (program name PFR0126) to purge all upload history records that are older than the number of days defined in the Parameter field. |
Review the error message associated with an upload history record that is in an Error status |
Select View Error to display a window that contains a description of the error that occurred during processing. The window is blank if no error occurred. |
Refresh the information on the screen |
Select Refresh Page. |
Work with Authorization Services (WASV)
For information on: | See: |
---|---|
how the credit card authorization service works, including an overview of the available processing options |
|
setting up the authorization services that your company uses |
|
setting up authorization service countries to cross-reference your country codes to the country codes used by the service bureau. You can also indicate whether the service bureau performs address verification for the country. |
|
setting up the vendor paytype codes you use to cross-reference your payment codes to the codes used by the authorization service |
|
setting up the vendor response codes that your authorization service uses to indicate whether a credit card is approved or declined, including how to automatically place orders on hold based on the response code |
|
setting up merchant ID overrides for different entities within your company |
|
setting up the cross references between your company’s currency codes and those used by the authorization service |
Setting Up Authorization Services
Topics in this part: The following topics describe the functions available to define the credit card authorization services that your company uses.
-
Using the Credit Card Authorization Interface describes how the credit card authorization interface works, provides a brief overview of the available processing options, and shows you how to locate the function. This topic also describes a recovery program that you can run to retransmit or receive an Authorization table.
-
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 service bureau. You can also indicate whether the service bureau 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 service bureau.
-
Defining Vendor Response Codes shows you how to define the codes your service bureau 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 Countries describes how to set up cross references for your company's currency codes and the codes used by a service bureau.
-
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.
-
Processing Authorizations and Deposits using an Integration Layer Process explains how to communicate with the service bureau to process authorizations and deposits via an integration layer process.
For more information see the Web Services Guide on https://support.oracle.com My Oracle Support (ID 2149144.1).
-
PayPal Direct Connection Integration provides an overview of the PayPal integration using a direct connection to PayPal, which allows you to use PayPal as a method of payment on web orders and send the deposit transaction directly to PayPal.
-
Processing Authorizations and Deposits Using Point-to-Point Communication explains how to communicate with the service bureau to process authorizations and deposits via a direct connection.
-
External Payment Service for information on a RESTful web service that provides an interface from Order Management System for sending credit card and stored value card transactions and receiving responses.
-
CyberSource Point-to-Point Integration for information on processing authorization and deposit transactions with Cybersource using point-to-point communication.
Reprocess Authorizations Screen (RPAA)
Purpose: Run this recovery program if an error occurs when transmitting an Authorization (either sending or receiving) or if you responded to an error with a C (to cancel the transmission) and there are stranded records in the Credit Card Authorization Transaction table (CCAT00).
This procedure enables you to resend all records that have not been sent or received and process the authorizations.
Note:
When you reprocess authorizations, the system sends all authorization transactions that exist in the CC Authorization Transaction file to the authorization service, regardless if the order is a drop ship order or regular order.
Selecting this option: Enter RPAA in the Fast path field at the top of any menu screen or select the Reprocess Authorizations option from a menu.
Retransmitting Authorizations
Select the Transmit/Receive/Process Authorizations option at the Reprocess Authorizations Screen (RPAA) if you need to retransmit Authorizations.
This option resends all records in the CC Authorization Transaction table (CCAT00) that have not been sent, regardless if the order is a regular order or drop ship order. These records have a status of *RDY in this table.
Records successfully sent have a status of *SENT.
Note:
You can use the Reset Transmission Status Screen to reset records in the Credit Card Authorization Transaction table (CCAT00) from a *SENT status to a *RDY status.
The Enter Pick Options window opens when you select this option. This window gives you the same options you can select at Pick Slip Generation run-time.
Field | Description |
---|---|
Combine customer picks |
Indicates whether the system will combine multiple orders for a single customer. For example, if the customer has two 1-item orders that can fit into one box, under normal cubing rules, the system would split them into two pick slips because they belong to different orders. Using this feature, however, the system combines them into a single pick slip. Valid values are:
|
Complete orders only? |
Indicates whether the system will ship orders that have been completely filled. Valid values are:
|
Perform best way |
This field is not currently implemented; leave this field unselected. |
Override ship via |
Allows you to replace the ship via code on the pick slip and ship all orders with this shipper. Enter a valid shipper code here, if you want all shippable orders being authorized by this service bureau to ship by this carrier. Ship via codes are defined in and validated against the Ship Via table. Numeric, 2 positions; optional. |
Receiving Authorizations
Select the Receive/Process Authorizations option at the Reprocess Authorizations Screen (RPAA) if you need to receive the Authorizations from the service bureau and process the authorizations.
Records successfully received have a status of *RCVD and have pick slips if authorized or no AVS hold or card identification hold. Also, an Authorization History record is created when creating the Pick Control Header and Detail records and is updated when the authorization or decline is received. When an authorization is received, the Authorization History record is updated with the authorization code, authorization date, and authorization amount.
If an authorization is declined, no pick slips print and the Authorization History record is updated with the decline code.
The Enter Pick Options window displays when you select this option.
Complete this window as needed.
The Select Authorization Service window opens. Select Select Request for the service bureau that you are receiving authorizations from. The REPROCESS job is submitted and the following reports are produced:
-
Address Verification Response List (if the service bureau provides AVS)
By default, the REPROCESS job is submitted to the PICKGEN job queue at the Job Management Screen rather than the QBATCH job queue.
Address verification: If the service bureau provides AVS (address verification service), it evaluates the billing address on the credit card to ensure that it is valid. If not, the credit card charge may be authorized, but the order may be placed on hold, based on the response code for the authorization service. This gives you the opportunity to contact the customer and obtain the correct address. For example, the order is placed on hold if the customer's address is correct, but the zip code is incorrect. Once you contact the customer and update the zip code, you may take the order off of hold through the Release Held Orders function.
Credit card identification: If the service bureaus also provides credit card identification (CID, CVV2, or CVC2), it evaluates the card identification number on the credit card to ensure that the credit card data from the transaction matches the data stored by the service bureau for that card. If not, the credit card charge may be authorized, but the order may be placed on hold, based on the response code for the service bureau. Once you verify credit card ownership, you can take the order off of hold through the Release Held Orders (ERHO) menu option. See Credit Card Security Service (CID, CVV2, CVC2).
The credit card authorization is captured in the Authorization History table. The order will not be resent for authorization as long as the authorization is valid (based on the number of days in the Reauthorization days field in the Pay Type table).
Reprocess Drop Ship Authorizations Screen (RPDS)
Purpose: Run this recovery program if an error occurs when transmitting Authorizations (either sending or receiving) for a drop ship order or if you responded to an error with a C (to cancel the transmission) and there are stranded records in the Credit Card Authorization Transaction table (CCAT00) for drop ship orders.
This procedure enables you to resend all records that have not been sent or received and process the authorizations.
Note:
When you reprocess drop ship authorizations, the system sends all authorization transactions that exist in the CC Authorization Transaction table to the service bureau, regardless if the order is a drop ship order or regular order.
Selecting this option: Enter RPDS in the Fast path field at the top of any menu screen or select the Reprocess Drop Ship Authorizations option from a menu.
Retransmitting Authorizations
Select Transmit/Receive/Process Authorizations if you need to retransmit Authorizations.
This option resends all records in the CC Authorization Transaction table (CCAT00) that have not been sent, regardless if the order is a drop ship order or regular order. These records have a status of *RDY in this table.
Records successfully sent have a status of *SENT.
The Enter Drop Ship Options Window opens when you select this opti
Enter Drop Ship Options Window
This window gives you the same options you can select during Drop Ship Processing.
Field | Description |
---|---|
Print drop ship purchase orders |
Indicates whether to print drop ship purchase orders. Valid values:
Note: Drop ship purchase orders print only if:
The system also prints a Drop Ship Pick Slip/Invoice for the drop ship purchase order. The system also creates pick download triggers (File code of PCH) in the IL Outbound Trigger table when you generate a drop ship pick (invoice) if the Create Generic Pick Download Triggers (I31) system control value is selected. The PICK_OUT process in Working with Integration Layer Processes (IJCT) generates the Pick Message from Order Management System (CWPickOut) for each of these trigger records. Required. |
Fax picks to vendors |
Indicates whether the drop ship pick slips or invoices should be faxed to the vendor instead of printed. This option is not currently implemented. |
Receiving Authorizations
Select Receive/Process Authorizations at the Reprocess Drop Ship Authorizations Screen (RPDS) if you need to receive the Authorizations from the service bureau and process the authorizations.
Overview: When you receive authorizations, records successfully received have a status of *RCVD and have drop ship output (pick slip or purchase order) if authorized or no AVS hold or card identification hold. When an authorization is approved, the Authorization History record is updated with the authorization code, authorization date, and authorization amount.
If an authorization is declined, no drop ship output (pick slip or purchase order) prints and the Authorization History record is updated with the decline code.
When you select the Receive/Reprocess Authorizations option:
-
The Enter Drop Ship Options window opens; see above for more information.
-
After you complete this window, you advance to the Select Auth Service window. Select the service bureau that you are receiving an authorization file from to submit the REPROC_DS job and produce the following reports:
-
Address Verification Response List (if the service bureau provides AVS)
-
Drop Ship Purchase Order List (if the drop ship output is purchase orders)
-
Drop Ship Pick Slip/Invoice (the system generates a drop ship pick slip/invoice when the drop ship output is pick slips or purchase order)
-
Purchase Order (if the drop ship output is purchase orders)
Address verification: If the service bureau provides AVS (address verification service), it evaluates the billing address on the credit card to ensure that it is valid. If not, the credit card charge may be authorized, but the order may be placed on hold, based on the response code for the authorization service. This gives you the opportunity to contact the customer and obtain the correct address. For example, the order is placed on hold if the customer's address is correct, but the zip code is incorrect. Once you contact the customer and update the zip code, you may take the order off of hold through the Release Held Orders (ERHO) menu option. See Address Verification Service (AVS).
Credit card identification: If the service bureaus also provides credit card identification (CID, CVV2, or CVC2), it evaluates the card identification number on the credit card to ensure that the credit card data from the transaction matches the data stored by the authorization service for that card. If not, the credit card charge may be authorized, but the order may be placed on hold, based on the response code for the authorization service. Once you verify credit card ownership, you can take the order off of hold through Release Held Orders. See Credit Card Security Service (CID, CVV2, CVC2).
The credit card authorization is captured in the Authorization History table. The order will not be resent for authorization as long as the authorization is valid (based on the number of days in the Reauthorization days field in the Pay Type table).
Working with Required Responses (WREQ)
Note:
This menu option is no longer used.
Purpose: Use this menu option to respond to Order Management System jobs that require user intervention in order to proceed.
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 and authorization reversal)
-
Batch Authorization
-
Batch Deposit
Required Response Processing
When a job requires user intervention, Order Management System:
-
Generates a Response Required Email, indicating a job requires user intervention.
-
Creates a record in the Response Required (MSRREQ) table. You can review the records in the Response Required table at the Work with Required Responses Screen.
-
Creates a message in the RESP.log indicating a job requires user intervention.
-
Order Management System waits 60 seconds for a user response.
-
After 60 seconds, Order Management System reviews the Response Required table to determine if a user responded to the response required message.
If a user responds: A user can respond to a job that requires user intervention at the Reply To Message Screen. If a user responds to a response required message, Order Management System:
-
uses the response to proceed with the job.
-
deletes the record from the Response Required table.
-
creates a message in the RESP.log, indicating a user responded to the response required message.
If a user does not respond: If a user does not respond to a response required message, Order Management System looks at the RESPONSE_RETRIES property in Working with Admin Properties (CPRP) to determine the number of times it should look for a response for the job. Order Management System compares the Sent date and time to the Last polled date and time to determine if the number of times has been reached.
If the number of times to look for a user response has not been reached, Order Management System:
-
updates the Last polled date and time in the Response Required table with the last polled date and time.
-
After every fifth attempt, writes a message to the RESP.log, indicating a user response had not yet been received.
-
goes back to sleep for another 60 seconds.
If the number of times to look for a user response has been reached, Order Management System:
-
deletes the record in the Response Required table.
-
uses a default response in order to proceed with the job. For example:
-
the default response for a transmission job in a receive status is R (Resend).
-
the default response for a transmission job in a sent status is C (Cancel).
Note:
-
For the batch authorization job, the status of each record in the CC Authorization Transaction table remains in its current status so that you can use the Reprocess Authorizations Screen (RPAA) to recover the response.
-
For the batch deposit job, the status of each record in the CC Deposit Transaction table remains in its current status so that you can use the Receive option in Processing Auto Deposits (SDEP) to recover the response.
-
sends a Response Required Email, indicating the default response was used for the job.
-
writes a message to the RESP.log, indicating the default response was used.
If a user deletes the response required message: If a user deletes a response required message at the Work with Required Responses Screen, the system:
-
uses a default response in order to proceed with the job. For example:
-
the default response for a transmission job in a sent status is C (Cancel).
-
the default response for a transmission job in a receive status is R (Resend).
-
sends a Response Required Email, indicating the default response was used for the job.
-
writes a message to the RESP.log, indicating the default response was used.
Response Required Email
This email is generated when a Order Management System job requires a user response in order to proceed.
The RESPONSE_EMAILS setting in the Notify Properties defines the email address(es) that receive this email.
Order Management System generates an email when:
-
A job initially requires user intervention.
-
A user does not respond to the response required message and the default response was used.
Sample first email:
From: cwjava@example.com
Subject: Process Authorizations
Response required for job. Please go to WREQ to view the error and enter a response.
Sample second email:
From: cwjava@example.com
To: Eleanor Johnson
Subject: Process Authorizations
No response received after 5 attempts, default used.
Contents:
-
From: The mail.from setting in the Email Properties file.
-
To: The user name for the RESPONSE_EMAILS property in Working with Admin Properties (CPRP).
-
Subject: Process, followed by the job name. For example, Process Authorizations.
-
Body:
-
First email: Response required for job. Please go to WREQ to view the error and enter a response.
-
Second email: No response received after 5 attempts, default used.
RESP.log
Order Management System writes messages to the RESP.log file when a job requires user intervention.
Location: /domain/conf/OMSFiles/Logs/RESP/, where domain is the WebLogic domain directory for Order Management System on the application server.
Message | Written When |
---|---|
Deposits - Response required for job. E-Mail sent to:email1@cware.com; email2@cware.com |
Order Management System generates a Response Required email, indicating a job requires user intervention. In this example, Deposits is the job name and email@cware.com is the email address to receive the Response Required email. |
Deposits - Received R response from BMIRANDA |
A user responded to a response required message at the Reply To Message Screen. In this example, Deposits is the job name and BMIRANDA is the user that responded to the job. |
Deposits - No response after 5 attempts, will retry |
Order Management System reviewed the Response Required table five times to determine if a user responded to the response required message. In this example, Deposits is the job name. |
Deposits - No response after 10 attempts, will retry |
Order Management System reviewed the Response Required table ten times to determine if a user responded to the response required message. In this example, Deposits is the job name. |
Deposits - No response received, default response used |
The number of times to look for a response in the Response Required table has been reached without a response from a user. Order Management System uses the default response for the job. In this example, Deposits is the job name. |
Deposits - Response Required entry not found, default response used |
A user deleted a response required message at the Work with Required Responses Screen. Order Management System uses the default response for the job. In this example, Deposits is the job name. |
Work with Required Responses Screen
Use this screen to review the jobs that require user intervention in order to proceed.
Note:
This screen is not company or user specific; all jobs that require user intervention display on the screen, regardless of the company where the job was submitted or the user that submitted the job.
How to display this screen: Enter WREQ in the Fast path field or select Work with Required Responses from a menu.
Field | Description |
---|---|
Message |
Indicates the reason a job requires user intervention. For example, if transmission errors occur for a batch authorization: Error occurred during authorization transmission Alphanumeric, 75 positions; display-only. |
Job |
The name of the job that requires user intervention. Valid values are:
Display-only. |
Sent |
The date and time a Response Required Email was sent to the user, indicating a job requires a user response. Alphanumeric, 50 positions (YYYY.MM.DD HH:MM:SS format); display-only. |
Last polled |
The date and time Order Management System last reviewed the response required message to determine if a response was received from a user. Alphanumeric, 50 positions (YYYY.MM.DD HH:MM:SS format); display-only. |
Screen Option | Procedure |
---|---|
Reply to a response required message |
Select Change for a response required message to advance to the Reply To Message Screen. |
Delete a response required message |
Select Delete for a response required message to advance to the Confirm Delete window. At this window, select Delete to delete it. When you delete a response required message, Order Management System:
|
Reply To Message Screen
Purpose: Use this screen to reply to a job that requires user intervention.
An error message indicates if a job used the default reply while you were on this screen: Update not accepted - record has been changed by another user since it was displayed.
How to display this screen: Select Change for a job on the Work with Required Responses Screen.
Field | Description |
---|---|
Message text |
Indicates the reason a job requires user intervention. For example, if transmission errors occur for a batch authorization: Error occurred during authorization transmission Alphanumeric, 75 positions; display-only. |
Enter reply |
Enter your response to the job. The Choices field provides a list of valid responses. Alphanumeric, 1 position; required. |
Choices |
The valid responses you can enter for a job that requires user intervention. Valid values are:
Alphanumeric, 1 position; display-only. |
Job name |
The name of the job that requires user intervention. Valid values are:
Alphanumeric, 50 positions; display-only. |
Message sent |
The date and time a Response Required Email was sent to the user, indicating a job requires user intervention. Alphanumeric, 50 positions (YYYY.MM.DD HH:MM:SS format); display-only. |
Notify Properties
In order to respond to Order Management System 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 jobs require user intervention?
-
Stored Value Card (activation, balance inquiry or authorization reversal)
-
Authorization (batch only, for all card types)
-
Deposit
Property Name | Description |
---|---|
RESPONSE_RETRIES |
The number of times Order Management System 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 Management System 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: email1@add.com;email2@add.co |
Reset Authorizations (RSAA)
Purpose: Use this menu option to reset records in the Credit Card Authorization Transaction table (CCAT00) from a *SENT status to a *RDY status so that they can be resent to the authorization service.
This menu option is useful as a recovery program if an error occurs when transmitting an Authorization to the service bureau or if you responded to an error with a C (to cancel the transmission) and there are stranded records in the Credit Card Authorization Transaction table.
Once the records are reset to a *RDY status, you can use the Reprocess Authorizations Screen (RPAA) to resend all records in the Credit Card Authorization Transaction table that have not been sent and process the authorizations.
Reset Transmission Status Screen
Use this screen to select the authorization service whose records in a *SENT status in the Credit Card Authorization Transaction table you wish to reset to a *RDY status.
To reset the transmission status:
# | Step |
---|---|
1. |
Confirm with the service bureau whether the authorization transmission was received.
|
2. |
At the Reset Transmission Status screen, enter a valid authorization service in the Select authorization service field. |
3. |
Select OK. The system:
|
4. |
Use the Transmit/Receive/Process Authorizations option in Reprocess Authorizations Screen (RPAA) to resend all records in the Credit Card Authorization Transaction table that have not been sent or received and process the authorizations. |
Field | Description |
---|---|
Select authorization service |
Select the authorization service whose records in a *SENT status in the Credit Card Authorization Transaction table you wish to reset to a *RDY status. Required. |
Performing Batch Authorization (SATH)
Purpose: Use this menu option to receive authorizations for credit cards that did not receive an authorization during order entry. This menu option sends credit cards up for authorization in a batch by the associated ship via. The system looks at the ship via defined on the order header to determine which credit cards are sent to the service bureau for authorization.
You may wish to use this menu option if:
-
communication failures occurred when you tried to authorize the credit card during order entry or order maintenance.
-
the credit card received an authorization during order entry, but not for the entire dollar amount associated with the card.
-
the credit card received a declined authorization during order entry.
-
the credit card was approved in order entry or order maintenance, but the authorization has expired.
-
the credit card was approved in order entry or order maintenance, but the card failed AVS verification or card security identification (CID, CVV2, CVC2); see Address Verification Service (AVS) and Credit Card Security Service (CID, CVV2, CVC2)
Note:
You must authorize credit cards prior to generating pick slips if the Batch/online field for the service bureau is set to I (online only). You can perform online credit card authorization during order entry when you select Accept to accept the order, during order maintenance at the Enter Payment Methods Screen in Order Maintenance, or using this menu option.
Periodic function: The AUTHALL Authorize All Open Orders periodic function (program name PFR0131) allows you to use the job scheduler to schedule when you wish to process the Batch Authorization Program (SATH).
In this topic:
Batch Authorization Process
When you select Accept at the Batch Authorization Selection screen, the system submits the Get Online Authorization program.
# | Step |
---|---|
1. |
The system determines the orders eligible for authorization, checking for Void Authorizations, the available authorized amount from Authorization History, and any existing picks with valid authorizations.
|
2. |
The system performs the same steps as in order entry to determine if an order is eligible for online authorization and the information that is updated; see Receiving a Credit Card Authorization During Order Entry. Note: The system does not display the Select Authorization Response Option Window when you authorize credit cards using batch authorization. |
3. |
The system prints the Online Credit Card Authorization Listing for credit cards that received a declined authorization. |
For more information: See Processing Authorizations and Deposits using an Integration Layer Process for more information on communicating with a service bureau via an integration layer job.
Batch Authorization Selection Screen
Purpose: Use this screen to select the ship vias associated with the credit cards you wish to send for authorization.
How to display this screen: Enter SATH in the Fast path field at the top of a menu or select Batch Authorization Program from a menu.
Field | Description |
---|---|
Ship via |
A code for the ship via associated with the orders that contain credit cards you wish to send for authorization. Ship via codes are defined in and validated against the Ship Via table. Numeric, eight 3-position fields; optional. |
Screen Option | Procedure |
---|---|
Submit the batch authorization program |
Select Accept. See Batch Authorization Process. A message indicates that the job has been submitted: BATCH_AUTH submitted |
Printing the Online Credit Card Authorization List (PATL)
Purpose: Use the screen to select the criteria you wish to use to print the Online Authorization Listing. This report lists credit cards that have been authorized using the online credit card authorization process. See Performing Online Credit Card Authorizations for an overview and required setup.
You can use this report to review credit cards that have been authorized, declined, authorized but not used, or sent for authorization for a specific date range.
The system looks at records in the Authorization History table and the Online Authorization table to determine what information prints on this report.
Note:
You can print a similar report for credits cards that are authorized during pick slip generation; see Credit Card Authorization Listing.
In this topic:
Authorization Listing Screen
How to display this screen: Enter PATL in the Fast path field at the top of a menu or select Print Credit Card Authorization List from a menu.
Field | Description |
---|---|
Authorization date range |
The authorization date range you wish to use to generate the Authorization Listing. The system only prints authorizations that have been received for this specific date range. Enter a beginning date in the first field and enter an ending date in the second field. If you do not enter an ending date in the second field, the system defaults the beginning date, indicating the report will print for this date only. A message displays if you enter a beginning date that is greater than the ending date: From Date must be less than To Date A message displays if you enter a future date in the starting date or ending date: Date entered must not be greater than today’s date Numeric, two 6 position fields (in user date format); beginning date required, ending date optional. |
Status (Authorization status) |
A code that indicates the status of the credit card authorization. Valid values are: blank = the credit card has not yet been sent for authorization Authorized = the credit card has been authorized Declined = the credit card has been declined Authd but not used = the credit card has been authorized, but the authorization has not been used Sent for authorization = the credit card has been sent to the authorization service for authorization If you enter a status, the system prints the Authorization Listing only for authorizations that contain this status. If you do not enter a status, the system prints the Authorization Listing for all eligible authorizations, regardless of status. Authorization status codes are defined in and validated against the Authorization Status table. Optional. |
Held orders |
Indicates whether authorizations on held orders print on the Authorization Listing. The system uses the Status field on the order header to determine if an order is held. Selected = Authorizations for held orders print on the Authorization Listing. Unselected = Authorizations for held orders do not print on the Authorization Listing. This report only displays authorizations for open orders. |
Report sorts |
Determines the sort on the Authorization Listing. Pay Type/Auth Date/Status = The Authorization Listing sorts in pay type/authorization date/status order. Status/Pay Type/Credit Card # = The Authorization Listing sorts in status/pay type/credit card number order. Numeric, 1 positions; required. |
Response code |
The authorization response you wish to use to generate the Authorization Listing. If you enter a response code, the system only prints authorizations that received this response. Note: If you enter a response that does not match the Status (Authorization status), nothing prints on this report. For example, if you enter D (declined) in the Status field and enter a response code of 100 (approve), nothing prints on the report because approved responses would never be put in a declined status. Vendor response codes are defined in and validated against the CC Vendor Response table; see Defining Vendor Response Codes. Alphanumeric, six 10 position fields; optional. |
Screen Option | Procedure |
---|---|
Accept the criteria you defined and generate the Authorization Listing |
Select Accept. The system displays a submit job message at the bottom of the screen indicating the Online Credit Card Authorization Listing has been submitted. |
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 Prestige Credit Card Deposits (MPSP)
Purpose: When you use Processing Auto Deposits (SDEP), the system processes deposits and credit card credits in your local currency interactively with your deposit service. You have the option, however, of processing deposits and credits in foreign currencies separately to capture the currency conversion rate at the time of billing. To do so, you must use a deposit service defined as Prestige (authorization service code = PRE) in the Authorization Service table.
The system writes the invoice information on foreign currencies using the separate process to the Credit Card Deposit Prestige table (CCCDPP). You then extract invoice records from this table to send to the deposit service.
Credit card encryption: Credit card encryption allows you to encrypt the credit card number in the Order Management System database to provide additional security of credit card data. If you use credit card encryption, the credit card number in the Credit Card Deposit Prestige table will not be encrypted because the information in this table is extracted to an external system. See the Data Security and Encryption Guide on My Oracle Support (1988467.1) for an overview.
You must use the Purge Prestige Credit Card Deposits function to purge the processed records from the Credit Card Deposit Prestige table.
For more information: See Defining Authorization Services (WASV).
In this topic:
Purge Credit Card Deposits Prestige Screen
How to display this screen: Enter MPSP in the Fast path field at the top of any menu or select Purge Prestige Credit Card Deposits from a menu.
Field | Description |
---|---|
Start date |
The beginning date of the records to purge from the Credit Card Deposit Prestige table. This is the date you used the Process Auto Deposits to create the deposit or credit card credit record in the table. The purge will include transactions processed on that date and later. Numeric, 6 positions (in user date format); required. |
End date |
The ending date of the records to purge from the Credit Card Deposit Prestige table. This is the date you used the Process Auto Deposits function to create the deposit or credit card credit record in the table. The purge will include transactions processed on that date and earlier. Numeric, 6 positions (in user date format); required. |
Screen Option | Procedure |
---|---|
Purge records |
Select Accept. |
Purging Orders (MPOR)
Purpose: Use the Purge Orders screen to purge closed and canceled orders that have been inactive for a given period.
Which orders are purged? In addition to being closed or cancelled, the order must:
-
not have had any activity for the Order Purge Days (C62) defined in the System Control table. For example, if the order purge days is 365, a closed or canceled order will be eligible for purging if the order has not been entered, shipped, or maintained for one year. The system checks the Order date from the Order Header table and the dates from the Order Transaction History table for the most recent activity.
-
not have any pending returns or refunds.
Additional purge option: You can also use the PURGEOR periodic function. This function also uses the rules described above to determine whether an order is eligible for purge.
Purged Order List? If you use the PURGEOR periodic function and set the function’s Parameter to Y, the submitted job also produces the Purged Order List when you use the Purge Orders Screen (MPOR).
Purging an individual order: To purge an individual order, use the Purge Orders by Order Number (MORP) option. With this option, you can delete an order even if there has been activity more recently than the Order Purge Days (C62).
Updated tables: See the Order-Related Tables for a listing of the tables purged through the Purge Orders Screen (MPOR), the Purge Orders by Order Number (MORP) option, or the PURGEOR periodic function.
The system does not delete the customer's order, item, or correspondence history; you can review this information through the Work with Customers function.
Note:
When you purge orders through the Purge Orders screen or the PURGEOR periodic function, the system does not create records in the Deleted Order Table.
In this topic:
For more information: See:
-
How to Schedule a Job for information on scheduling a periodic process that includes the PURGEOR periodic function
-
Working with Periodic Functions (WPER) for information on setting up periodic functions
-
Purge Orders by Order Number (MORP) for information on the screen you can use to purge individual orders
Purge Orders Screen (MPOR)
How to display this screen: Enter MPOR in the Fast path field at the top of any menu or select Purge Orders from a menu.
Field | Description |
---|---|
Purge date |
The system subtracts the Order purge days from this date to calculate a cutoff date for purging orders. For example, if the purge date is 9/30, and the order purge days are 30, the system subtracts 30 days from 9/30 to arrive at a cutoff date of 8/31. Closed and canceled orders that have not been entered, shipped, or updated in any way since the cutoff date will be purged. See the discussion above under Purging Orders (MPOR) for more information. The system defaults the current date into this field; however, you can override it with an earlier date. Numeric, 6 positions (in user date format); required. |
Order purge days (Highlighted number in the narrative on the center of the screen) |
The number of days an order must have been inactive since the purge date to be eligible for purging. From the Order Purge Days (C62) system control value. Numeric, 7 positions; display-only. |
Completing this screen: Optionally, enter an earlier date in the Purge date field and click OK, then select Accept. The system submits the ORDER_PURG job and returns you to the previous screen. This job purges all orders inactive since the calculated cutoff date (Purge date - Order purge days).
Note:
This job does not update the Deleted Order Table.
Order-Related Tables
Purpose: The system purges records in the following order-related tables when you use the PURGEOR periodic function, the Purging Orders (MPOR) option, or the Purge Orders by Order Number (MORP) option.
Table Name | System Name |
---|---|
AA Void |
AAVOID |
Authorization History |
AUTHHS |
Auto Soldout |
CSAUSO |
Backorder Cancellation Pending |
BOCANP |
Carton Contents |
CartonContents |
CC Deposit History |
CCDPHI |
Correspondence History Note: The associated record in this table and in the Correspondence History Detail table are not deleted; however, the system deletes the order number. The correspondence history is still available for review by inquiring on the customer(s) on the order. |
MSCOHS |
Customer Sold To Promotion |
OECSPR |
Drop Ship Pending |
FLDSPN |
Drop Ship Work |
DRPSHW |
Expected Ship Date |
CSEXSD |
Invoice Address |
OEINAD |
Invoice Cross Reference |
FLINXR |
Invoice Currency |
MSINCU |
Invoice Detail |
OEINDT |
Invoice Detail Charge |
INIDCP |
Invoice Detail Cost |
INIVCP |
Invoice Detail Pay Method |
CSINDP |
Invoice Header |
OEINHD |
Invoice Payment Method |
CSINVP |
Invoice Ship To |
OEINSH |
Manifest |
FLMANF |
Narvar Export Errors |
INT_NARVAR_EXPORT_ERROR |
On Line Authorization |
CCOLAT |
Order Additional Charge |
OEOADC |
Order Broker |
oeorbk |
Order Broker History |
oeorbh |
Order Coupon Discount |
OEOCDP |
Order Cross Reference |
OEORXR |
Order Detail |
OEORDT |
Order Detail Coupon |
OECPDC |
Order Detail Deal Audit |
OEDDAU |
Order Discount Audit |
OEODIS |
Order Free Gift |
FREGFT |
Order Header |
OEORDR |
Order Header Extended |
OEOHEP |
Order Header User Field |
OEORHU |
Order I/T Line |
CSIOTL |
Order Line History |
OEOLHS |
Order Line Message |
OELNMS |
Order Message |
OEOMSG |
Order Payment History |
OEPAYH |
Order Payment Method |
OEPAYM |
Order Promotion |
OEORPR |
Order Ship To |
OEORST |
Order Ship To Address |
OEOSTA |
Order Shipment Details |
ORDER_SHIPMENT_DETAILS |
Order Special Format |
OESHFM |
Order Special Handling |
OESHIN |
Order Transaction History |
OEOTHI |
P/O Detail D/S Order |
PODTDS |
Pick Slip Gen Sel Order |
PSGORD |
RA Detail |
CSRADT |
RA Exch Payment Method |
CSRAPM |
RA Exchange Item |
CSRAXI |
RA Header |
CSRAHD |
Refund |
CSRFND |
Refund Message |
CSRMFF |
Return Notifications |
OERSCP |
Refund Print |
CSRFPT |
Refund Print Detail |
CSRDTP |
Reserved Order Line |
FLRSOL |
Sold Out Notification |
SONTFY |
Stored Value Card |
OESVCD |
Tax Exception |
OETXEX |
Tickler |
MSTKLR |
Tickler History |
MSTKHS |
Variable Set Order Hold |
VSHOLD |
WMS Carton Header Detail |
WMCAHD |
Purging Suspended Orders (PSOR)
Purpose: Use the Purge Suspended Orders menu option to remove orders in a suspended or error status from the system.
You might have orders in suspended or error status due to error or malfunction; for example, if you were entering an order when your terminal froze or a program halted, the order would remain in suspended status. You would never be able to process such an order normally (as distinguished from a suspended order batch, which you can process normally by accepting the batch).
By purging the orders in suspended or error status from the system, you reduce the reserved or backordered items from the orders.
The Purge Suspended Orders menu option purges orders only if they are not part of a batch, and if they were entered before the current date. You can purge orders by date range or select a specific order to purge.
Note:
You cannot use this option to purge a quote.
Purge Suspended Orders Screen
How to display this screen: Enter PSOR in the Fast path field at the top of any menu or select Purge Suspended Orders from a menu.
Field | Description |
---|---|
Enter order# |
Enter an order number in this field to purge an order individually, rather than by date range. The order whose number you enter must be in a suspended or error status, not part of an order batch, and not a quote; otherwise, the screen displays an error message. Numeric, 8 positions; optional. |
Starting/ending dates |
Enter the beginning and ending order entry dates that indicate the period for which you would like to purge orders. in suspended or error status. The starting date you enter must be earlier than or the same as the ending date; also, you cannot enter an ending date that is later than or the same as the current date. Numeric, 6 positions (in user date format); required if you do not enter an order number. |
If you are purging by order number: The system purges the order interactively and produces the Rejected Batch Listing.
If you are purging by date range: The system submits the job PURG_SUSP. This job purges all eligible orders within the date range you entered.
As a result of purging the orders, the related inventory information (SKU open, reserved, and Backorder quantities for any items on the orders) are reduced at this time.
Deleted Order table: The job writes a record in the Deleted Order Table for each purged order.
Purging SKUs (MPSK)
Purpose: Use Purge SKUs to remove items or SKUs based on item status from the system, and to print the Purged SKU List.
The system uses the SKU Purge Days (F11) system control value to determine how long an item/SKU must have been inactive (an order has not been entered for the item/SKU) to be eligible for purging. For example, if you define 365 as the SKU purge days, a SKU will be eligible for purging if the last order date on the SKU record is older than one year.
The system will not delete an item/SKU if the following records exist:
-
the on hand quantity, On order quantity or Backorder quantity is greater than 0 in the Item Warehouse table (fast path = WWHS)
-
an order detail line exists for the item/SKU
-
an open or closed purchase order detail line exists for the item/SKU
SKU Purge Screen
How to display this screen: Enter MPSK in the Fast path field at the top of any menu or select Purge SKUs from a menu.
Field | Description |
---|---|
Purge SKUs with no orders for xxx days |
The number of days to retain SKUs that are not on any existing order. This number defaults from the SKU Purge Days (F11) system control value. Numeric, 7 positions; display-only. |
Select status codes for SKUs to be purged |
The item status of the items and SKUs you wish to purge. Item status codes are defined in and validated against Work with Item Status (fast path = WIST). Alphanumeric, five 1 position fields; one field required. |
Print only do not update |
Indicates whether you wish to purge the items and SKUs that meet the selection criteria or print the SKU Purged List report only. Valid values are: Selected (default) = Print the SKU Purged List only. Unselected = Print the SKU Purged List and purge the items and SKUs that display on the report. |
When you select Submit to process the SKU Purge, the system also prints the Purged SKU List, which lists each item/SKU that is available to purge.
The system purges an item that contains SKUs if all of the SKUs are available to purge.
Purge Inventory Transaction History (MITH)
Purpose: Use this option to purge records in the Item Transaction History table that are older than the number of days specified in the Inventory Transaction History Retention Days (A24) system control value.
Purge Inventory Transactions Screen
How to display this screen: Enter MITH in the Fast path field at the top of any menu, or select Purge Inventory Transaction History at a menu.
Completing this screen: This screen indicates the numeric code and description of the company where the records will be purged. Click OK to submit the PURGE_ITH job, which purges the records.
System control value required: If the Inventory Transaction History Retention Days (A24) system control value is blank, the system displays an error message. You need to use this system control value to specify a number of days in order to run the purge.
For more information: For background on inventory transactions, see Display Inventory Transaction History (DITH).
Purge Purchase Order (MPOP)
Purpose: Use this option to purge canceled and/or completed records in the following tables:
-
PO Detail
-
PO Detail Audit
-
PO Detail Estimated Charges
-
PO Detail Hold
-
PO Detail Messages
-
PO Detail Noninventory
-
PO Header
-
PO Header Audit
-
PO Message
-
PO Receipt Header
-
PO Suspense
Purge dates: Records are eligible for purging if the date they were canceled or received is older than number of days specified in the # of Days Before PO Purge (A58) system control value.
Report: This option also generates the Purchase Order Purge Listing listing the purchase orders deleted through the purge.
Purchase Order Purge Selection Screen
How to display this screen: Enter MPOP in the Fast path field at the top of any menu, or select Purge Purchase Order from a menu.
Completing this screen:
-
Select the Purge completed orders flag to delete purchase orders that are completed; otherwise, leave this flag unselected.
-
Select the Purge cancelled orders flag to delete purchase orders that are canceled; otherwise, leave this flag unselected.
Note:
You must select either completed or canceled purchase orders for purge at this screen.
-
Leave the Purge report field set to Detail (default) to print the Purchase Order Purge Listing with information on purchase order detail lines, or change the setting to Summary to print the summary version.
-
Select Accept to submit the PO_PURGE job. This job purges the records based on your screen selections and the setting of the # of Days Before PO Purge (A58) system control value, and generates the Purchase Order Purge Listing.
For more information: For background on purchase orders, see Maintaining Purchase Orders (MPOE) and Purchase Order Inquiry (MPOI).
Purge Empty Item Locations (PITL)
Purpose: Use this option to purge Item Location records that have zero:
-
on-hand quantity
-
pending transaction quantity
-
printed quantity
You need to specify the warehouse where empty item locations should be deleted. In addition, the prompt screen allows you to specify the number of days since placement date. For example, if you specify 45 days, only item locations whose placement dates were more than 45 days ago and which match all the other criteria will be deleted.
Even if the purge deletes the item location record, it is possible that the item/SKU has this warehouse and location identified in the SKU table as the “primary primary” location. The record in the SKU table is not cleared by this purge.
Note:
Ordinarily, the system automatically deletes all item locations when the above quantities are zero, except in the case of primary locations.
Purge Empty Item Locations Screen
How to display this screen: Enter PITL in the Fast path field at the top of any menu, or select Purge Empty Item Locations from a menu.
Completing this screen:
-
Enter the 3-position warehouse number where the item locations should be deleted. This entry is required.
-
Enter the number of days required since placement date for an item location to be eligible for deletion. For example, if you enter 45, and an empty item location has a placement date of 50 days ago, it is eligible for deletion.
-
Select Accept to submit the PURGITL job.
Purge Order Billing History (POBH)
Purpose: Use this option to purge Order Billing History records on or earlier than a specified date.
Purge Order Billing History Screen
How to display this screen: Enter POBH in the Fast path field at the top of any menu, or select Purge Order Billing History from a menu.
Completing this screen:
-
Use the Purge transactions up to field to indicate the latest date to purge in the Order Billing History table.
-
Select Submit and then click OK at the confirmation window to submit the PURGE_OBH job and generate the Order Billing History Purge report.
Note:
The job is submitted in held status; you will need to release it in order to perform the purge and generate the report.
For more information: For background on Order Billing History, see Order Billing History Detail Screen.
Purge Orders by Order Number (MORP)
Purpose: Use this option to purge individual orders.
Purge an Order Screen
How to display this screen: Enter MORP in the Fast path field at the top of any menu, or select Purge Orders by Order Number from a menu.
Purging an order: Enter the order number to purge and select the Confirm flag to purge the order.
Eligible to purge? The system displays an error message after you select the Confirm flag if the order is ineligible for purge. An order is eligible for purge if it is suspended, canceled, or closed and there are no pending transactions or activity, such as refunds. For example, an order might be ineligible for purge for any of the following reasons:
-
Order Header not found (Indicates that the order number you entered does not exist.)
-
Open R/A for order
-
Order Status is Open
-
Open refund for order
-
Order status is Held
-
Order status is Quote
-
Order status is Error
Updates: If the order is eligible to purge, the system deletes the Order Header and records in all related tables, and displays a message indicating that the order has been purged. See Order-Related Tables for a list. It also writes a record in the Deleted Order Table. The Process indicated is Individual Order Purge.
Purging suspended orders: You can also use the Purging Suspended Orders (PSOR) option to purge suspended orders.
Purging all eligible orders: See Purging Orders (MPOR) for information on submitting a job to purge all eligible orders.
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.
Working with Flexible Payment Options (WFPO)
Purpose: Use the Work with Flexible Payment Options menu option to set up and work with deferred or installment pay plans. This menu option also allows you to review a pay plan's order and shipment history.
Note:
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 Pay type 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 creates the EXC Net Billing for Exchanges flexible payment option for use during Credit Card Net Exchange Billing if 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.
For more information:
-
An overview of how pay plans work: Deferred/Installment Billing Overview
-
Setting up your company if you will be using pay plans: Deferred/Installment Billing Setup
In this topic:
Work with Flexible Payment Option Screen
How to display this screen: Enter WFPO in the Fast path field at the top of any menu, or select Work with Flexible Payment Option from a menu.
Field | Description |
---|---|
Code |
The code representing a deferred or installment pay plan. EXC flexible payment option: The system delivers the EXC Net Billing for Exchanges flexible payment option to use during Credit Card Net Exchange Billing if the Use CC Net Exchange Billing (M23) system control value is selected. You cannot change or delete the EXC flexible payment option; however, if this flexible payment option exists and then you deselect the system control value, this flexible payment option is automatically deleted. Credit Card Net Exchange Billing for processing details. Alphanumeric, 5 positions; optional. |
Type |
The type of pay plan. Valid values are: D = deferred billing I = installment Alphanumeric, 1 position; optional. |
Description |
The description of the pay plan. Alphanumeric, 40 positions; optional. |
Start date |
The date when the pay plan first becomes available to apply to orders. Does not apply to the EXC flexible payment option. Numeric, 6 positions (in user date format); display-only. |
End date |
The date when the pay plan is no longer available to apply to orders. Does not apply to the EXC flexible payment option. Numeric, 6 positions (in user date format); display-only). |
Select Option | Procedure |
---|---|
Create a new pay plan |
Select Create to advance to the Create Flexible Payment Option Screen. |
Change a pay plan |
Select Change for a pay plan to advance to the Change Flexible Payment Option Screen. At this screen, you can change any fields but the Payment code. See the Create Flexible Payment Option Screen for field descriptions. Note: You cannot change the EXC Net Billing for Exchanges flexible payment option; see Credit Card Net Exchange Billing for processing details and more information. |
Delete a pay plan |
Select Delete for a pay plan to display the Delete Confirmation prompt. You can delete a pay plan only if it is not used on any orders currently in your company. Note: You cannot delete the EXC Net Billing for Exchanges flexible payment option; see Credit Card Net Exchange Billing for processing details and more information. |
Display a pay plan |
Select Display for a pay plan to advance to the Display Flexible Payment Option Screen. You cannot change any information at this screen. See the Create Flexible Payment Option Screen for field descriptions. |
Display history for a pay plan |
Select History for a pay plan to advance to the Display Payment Option History Screen. |
Create Flexible Payment Option Screen
Purpose: Use this screen to create a new pay plan.
How to display this screen: Select Create at the Work with Flexible Payment Option Screen.
Field | Description |
---|---|
FPO payment code |
The code to identify the deferred or installment pay plan. Alphanumeric, 5 positions. Create screen: required. Change screen: display-only. |
Description |
The description of the deferred or installment pay plan. Alphanumeric, 40 positions; required. |
Type |
The type of pay plan. Valid values are: Deferred = Defer depositing the amount the customer owes for an order shipment for a specified period of time or until a specific date. Installment = Deposit the amount the customer owes for an order shipment in a specified number of equal installments. Required. |
Start (Start date) |
The first date when new orders will be eligible for the pay plan. When evaluating whether an order is eligible for a pay plan, the system checks the original order date, even if you are attempting to add a pay plan in order maintenance on a later date. Example: 7/25: You enter an order for an item that is currently backordered. 8/20: The customer calls to request a pay plan. The pay plan start date is 8/15. Result: The order is ineligible for the pay plan based on the pay plan start date (8/15) and order date (7/25). This date must be earlier than or the same as the end date. Numeric, 6 positions (in user date format); required. |
End (End date) |
The date when new orders will no longer be eligible for the pay plan. Eligibility is based on the original order date, not the current date, when you add a pay plan in order maintenance. Example: 7/25: You enter an order for an item that is currently backordered. 8/20: The customer calls to request a pay plan. The pay plan end date is 7/31. Result: The order is eligible for the pay plan based on the pay plan end date (7/31) and order date (7/25). This date must be later than or the same as the start date. Numeric, 6 positions (in user date format); required. |
Expiration date |
The date when you will no longer defer processing deposits for the pay plan. Example: 7/25: You enter an order for deferral of payment for 60 days based on invoice date. The item is currently backordered. The pay plan has an ending date of 7/31, and an expiration date of9/30. 8/15: You ship and bill the order. Result: Since the deferred date (60 days past the invoice date of 8/15, or 10/14) would be past the expiration date of 9/30, the deposit will not be deferred, but will be available for processing immediately. The system determines when the pay plan has expired as follows: |
|
Deferral: You can enter an expiration date only if you use the # of days for deferral field rather than the Fixed deferral date. To determine whether to apply the deferral, the system adds the number of days for deferral to the order's invoice date (if the Based on field is set to I) or the order date (if the Based on field is set to O). If the result is later than the Expiration date, the deposit is not deferred and is eligible for processing immediately after billing. You cannot enter an expiration date that is sooner than the pay plan End date; otherwise, the following error message indicates: Invalid Expiration Date Installment: To determine whether to apply the installment, the system compares the order's invoice date with the expiration date. If the Invoice date is later than or the same as the Expiration date, the deposit is not broken out into installments, but the entire amount is eligible for processing immediately after billing. Numeric, 6 positions (in user date format); required unless you enter a Fixed deferral date for a deferral pay plan. |
View in OE/OM |
This field indicates whether this pay play displays in order entry or order maintenance when you prompt (click on the arrow) in the pay plan field. You can still apply the pay plan by typing in the code, even if it does not display; also, the plan can be auto-applied regardless of whether it is viewable. Valid values are: Selected = pay plan is viewable in order entry/maintenance Unselected = pay plan is not viewable in order entry/maintenance |
Restrict to entity |
Enter an entity code in this field to restrict the pay plan to orders whose source code points to this entity. The source code is associated with an entity through its division. The source code on the order header determines the entity. Leave this field blank to make orders eligible for the pay plan regardless of entity. Entity codes are defined in and validated against the Entity table. See Working with Entities (WENT) and Working with Flexible Payment Options (WFPO). Numeric, 3 positions; optional. |
Auth full amount (Authorize full amount) |
This field indicates whether to authorize the full pickable amount of the order when generating the initial authorization at pick slip generation. Valid values are: Selected = authorize full pickable amount Unselected = do not authorize full pickable amount. If you deselect this field, the amount authorized at pick slip generation is: Deferred: $1.00 is authorized at pick slip generation. Installment: The amount of the first installment is authorized at pick slip generation. See Processing Auto Deposits (SDEP) for an overview of the authorization process for pay plan orders. |
Merchant ID message |
A short message to pass to the deposit service. This message appears on the customer's credit card statement. The message is concatenated with additional information into a 14- or 18-position message, formatted as follows: DBA industry code (3 positions): taken from the first 3 positions of the Industry format code for the authorization service Merchant ID message (11 positions) Installment description (4 positions): for installment pay plans, this consists of a description of which installment was deposited, for example, 1of 4. With this description, the entire message for an installment plan is 18 positions. For deferred pay plans, the entire message ends after the merchant ID message, producing a 14-position message. Alphanumeric, 11 positions; optional. |
Ship complete |
This field indicates whether to override the Ship complete flag setting on an order that uses this pay plan to selected. You might use this field to prevent pay plan orders from having multiple invoice dates, thus multiplying the number of deposits. Example: If an order uses a pay plan of four installments, and you fulfill the order in three separate shipments because of backorders, you would need to process 12 deposits to complete the pay plan. Valid values are: Selected = force orders with this pay plan to ship complete Unselected = do not force orders with this pay plan to ship complete You might also select the Consolidated Invoice (B49) system control value to simplify pay plan processing; see Deferred/Installment Billing Setup. Note: In Order Management System 21.0 or higher, 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. |
Display summary |
This field controls whether the Display Payment Plan Summary Screen displays automatically when you add this payment plan to an order. This screen includes projected deposit dates and amounts for the order. Valid values are: Selected = display the summary screen Unselected = do not display the summary screen You can also display the summary screen in order entry by selecting Pay Plan Summary for the pay type at the Enter Payment Method Screen. |
Auto apply |
This field indicates the method the system should use when determining which pay plan(s) apply to an order in order entry. Valid values are: Auto apply = apply this pay plan to an order if the order qualifies, without prompting the operator. If a pay plan is set to apply automatically, it overrides the regular hierarchy of pay plan selection. No auto apply = apply this pay plan to a qualifying order only when the operator selects it. Prompt = force a window to pop up in order entry displaying all available pay plans if the order qualifies for the pay plan. You should select the View in OE/OM field if you set this field to 3. Note: To simplify pay plan selection in order entry, you should use the same setting in this field for all of your pay plans. See Assigning a Payment Plan to the Order for a discussion of how the system determines which pay plan(s) an order qualifies for. Numeric, 1 position; required. |
Validate CC expiration date |
This field is not currently implemented. |
Pick message |
Three lines of message text to appear on the pick slip. Messages appear only if your pick slip printing program supports them. Alphanumeric, 60 positions each; optional. |
Use the following fields to set up a deferral pay plan: |
|
# of days for deferral |
This field indicates the number of days to defer processing the deposit for a shipment. If you enter a number in this field, you must also specify whether to base the calculation on order date or invoice date; see the field description below. Example: No payments for 60 days from shipment. You can also base a deferral on a fixed date; see Fixed deferral date, below. You cannot use this field for an installment pay plan. Numeric, 3 positions; required for a deferral pay plan if you do not enter a fixed date. |
Based on |
This field indicates whether to base the deferral interval on the date you enter the order, or the date you ship and bill it. Valid values are: Order Dt = base deferral on original order date. If you base the deferral on original order date, it is possible for the deposit to be eligible for processing immediately after billing. For example, if you defer payment for 30 days from order date, and you do not ship for 30 days or more after the order date, the deposit will be eligible for processing immediately. Invoice Dt = base deferral on invoice (billing) date. The system uses this field to calculate the deposit date only for deferred pay plans that use the # of days for deferral to calculate deposit date. You cannot use this field for an installment pay plan. Required for a deferral pay plan if you enter a # of days for deferral. |
Fixed deferral date |
This field indicates the fixed date to use for a deferral pay plan. If you select a fixed deferral date for a pay plan, all orders using this pay plan will be eligible for deposit on this date regardless of when they are entered or billed. Example: No payment till February 1 when you order from our holiday book. If you complete this field, you cannot complete the # of days for deferral or Based on fields. Also, you cannot use this field for an installment pay plan. Numeric, 6 positions (in user date format); required for a deferral pay plan if you do not enter a # of days for deferral. |
Use the following fields to set up an installment pay plan: |
|
# of installments (Number of installments) |
The number of installments required to pay off the invoice balance. Example: Four easy payments. The system divides the invoice total into this number of equal installments. If the total does not divide equally, the last installment(s) will include the additional balance. You must complete either the Interval or the Fixed installment day field to indicate when the installments will be due. You cannot use this field for a deferral pay plan. Numeric, 2 positions; required for an installment pay plan. |
Interval |
The number of days between installments. The shortest interval you can set is 30 days. The installment date is based on the date you bill the shipment. Example: Set this field to 30 and the # of installments to 3 to have deposits eligible for processing 30, 60, and 90 days after billing. You can also base the installment dates on a fixed day of the month; see Fixed installment day below. You cannot use this field for a deferral pay plan. Numeric, 3 positions; required for an installment pay plan if you do not complete the Fixed installment day. |
Fixed installment day |
The day of the month to process the deposits for an installment pay plan. The first deposit is eligible for processing on the first occurrence of this date after shipment. Example: If you set this field to 15, and you confirm shipment of the order on any date from August 16 to September 15, the deposit will be eligible for processing on September 15. You can also base the installment dates on a number of days between installments; see Interval above. You cannot use this field for a deferral pay plan. Numeric, 2 positions; required for an installment pay plan if you do not complete the Interval field. |
Use the following fields to restrict orders which can use the pay plan. An order must meet all of the specified criteria for the pay plan to qualify: |
|
Offer |
Enter an offer code to restrict the pay plan to orders for this offer. The offer is based on the source code on the order header. If you leave this field blank, the pay plan will not be restricted by offer. Offer codes are defined in and validated against the Offer table; see Working with Offers (WOFR). Alphanumeric, 3 positions; optional. |
Minimum amt (Minimum amount) |
Enter a minimum order merchandise total to restrict the pay plan to orders who meet or exceed this total. For a multi-recipient order, the merchandise total against all recipients is compared with this minimum to determine eligibility. If you leave this field blank, the pay plan will not be restricted by merchandise total. Numeric, 13 positions with a 2-place decimal; optional. |
Pay type |
Enter a pay type code to restrict the pay plan to orders that use this pay type. If you leave this field blank, the pay plan will not be restricted by pay type. Pay type codes are defined in and validated against the Pay Type table; see Working with Pay Types (WPAY). Numeric, 2 positions; optional. |
Item |
Enter an item code to restrict the pay plan to orders that include this item. The order can also include additional items. You can enter the base item code only. If the item has SKUs, you cannot restrict the pay plan to specific SKUs. If you leave this field blank, the pay plan will not be restricted by item. Item codes are defined in and validated against the Item table; see Performing Initial Item Entry (MITM). Alphanumeric, 12 positions; optional. |
Display Payment Option History Screen
Purpose: Use this screen to review order activity history for a pay plan.
How to display this screen: Select History for a pay plan at the Work with Flexible Payment Option Screen.
Note:
The Update Demand for Order Maintenance Transactions (C72) system control value controls when several of these fields update.
Field | Description |
---|---|
Code |
The code representing a deferred or installment pay plan. Alphanumeric, 5 positions; display-only. |
Type |
The type of pay plan. Valid values are: D = deferred billing I = installment Alphanumeric, 1 position; display-only. |
Description |
The description of the pay plan. Alphanumeric, 40 positions; optional. |
Start date |
The date when the pay plan first becomes available to apply to orders. Numeric, 6 positions (in user date format); display-only. |
End date |
The date when the pay plan is no longer available to apply to orders. Numeric, 6 positions (in user date format); display-only). |
# of orders |
The total number of orders for the pay plan. This total increases when you:
This total decreases when you cancel an item and use a cancel reason whose Reduce demand? field is unselected. See Establishing Cancel Reason Codes (WCNR). Numeric, 7 positions; display-only. |
# of shipments |
The total number of shipments made for this pay plan. This total increases when you confirm shipments for any orders using the pay plan, including orders that were not originally entered for the pay plan and were changed in order maintenance. Numeric, 7 positions; display-only. |
$ ordered (Dollars ordered) |
The dollar merchandise total, excluding any order charges such as freight, tax, and handling, of all orders entered for the pay plan. This total increases when you:
This total decreases when you cancel an item and use a cancel reason whose Reduce demand? field is unselected. See Establishing Cancel Reason Codes (WCNR). Numeric, 13 positions with a 2-place decimal; display-only. |
$ shipped (Dollars shipped) |
The dollar merchandise total, excluding additional order charges such as freight, tax, and handling, of shipments made for the pay plan. This total increases when you confirm shipments for any orders using the pay plan, including orders that were not originally entered for the pay plan and were changed in order maintenance. Numeric, 13 positions with a 2-place decimal; display-only. |
# of cancels |
The total number of items or orders canceled for the pay plan. This total increases when you process a cancellation for any orders using the pay plan, including orders that were not originally entered for the pay plan and were changed in order maintenance, through:
Orders you cancel due to credit card decline through Working with Credit Card Cancellations (WCCC) do not update this total. Numeric, 7 positions; display-only. |
# of returns |
The total number of items or orders returned or exchanged for the pay plan. This total increases when you process a return or exchange for an order with the pay plan, including orders that were not originally entered for the pay plan and were changed in order maintenance. Numeric, 7 positions; display-only. |
$ cancelled (Dollars canceled) |
The dollar merchandise total, excluding additional order charges such as freight, tax, and handling, of cancellations made for the pay plan. This total increases when you process any sort of cancellation for an order using the pay plan, including orders that were not originally entered for the pay plan and were changed in order maintenance, through:
Orders you cancel due to credit card decline through Working with Credit Card Cancellations (WCCC) do not update this total. Numeric, 13 positions with a 2-place decimal; display-only. |
$ returned (Dollars returned) |
The dollar merchandise total, excluding additional order charges such as freight, tax, and handling, of returns or exchanges made for the pay plan. This total increases when you process any sort of return or exchange for an order using the pay plan, including orders that were not originally entered for the pay plan and were changed in order maintenance. Numeric, 13 positions with a 2-place decimal; display-only. |
# of sold outs |
The total number of items or orders sold out for the pay plan. This total increases when sell out an item on an order with the pay plan, including orders that were not originally entered for the pay plan and were changed in order maintenance, through selecting Sell Out for the item in order entry or order maintenance or Processing Auto Soldout Cancellations (MASO). Numeric, 7 positions; display-only. |
$ sold out (Dollars sold out) |
The dollar merchandise total, excluding additional order charges such as freight, tax, and handling, of sellouts made for the pay plan. This total increases when you process any sort of sellout for an order using the pay plan, including orders that were not originally entered for the pay plan and were changed in order maintenance, through
Numeric, 13 positions with a 2-place decimal; display-only. |
Processing Deposits
Topics in this part:
-
Processing Auto Deposits (SDEP) describes the Submit Auto Deposits menu option.
-
Resubmitting Rejected Deposits (SRDP) 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.
Processing Auto Deposits (SDEP)
Purpose: Use the Submit Auto Deposits function to:
-
transmit credit card invoice information to a deposit service once you have shipped and billed the orders.
-
transmit credit card credit information once you have processed returns or credits.
When you process deposits for deferred or installment pay plan orders, there is typically an interval between the time you bill the orders and the time you process the deposit(s), based on the pay plan agreement; see Deferred or Installment Pay Plans vs. Regular (Non-Pay Plan) Orders.
Suppressing deposits: You can suppress deposit processing for orders you receive through the Generic Order Interface (Order API). In this situation, the order is not included when you process deposits. See Suppressing Deposits and Refunds for an overview.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Tracking records evaluated and processed: The DEP_UPDATE (deposits) job tracks the total number of records and evaluated in the Job History table. See Display Job History (DJHY) for background.
In this topic:
Deposit Setup
In order to send information to a deposit service with the Submit Auto Deposits function, you must first:
-
Define the deposit service using the Defining Authorization Services (WASV) menu option.
-
Select the deposit service for each credit card payment type in the Working with Pay Types (WPAY) menu option.
-
Pick, ship, confirm and bill the orders; see Performing Pick Slip Generation and Confirming and Billing Shipments.
-
For refunds, you must first process the credit card credits with the Processing Refunds (MREF) menu option.
Increasing maximum threads: To enhance the performance of deposit processing, if needed, set the DEPOSIT_MAX_THREADS property in Working with Admin Properties (CPRP) to a higher number. You can enter any positive integer. This property defaults to 1.
For more information:
-
Processing Deposits for the steps the system performs to process deposits.
-
defining a deposit service: Defining Authorization Services (WASV)
-
setting up deferred or installment pay plans: Deferred/Installment Billing Overview
-
resubmitting unconfirmed or rejected transactions: Resubmitting Rejected Deposits (SRDP)
-
purging the Credit Card Deposit Prestige table: Purging Prestige Credit Card Deposits (MPSP)
-
defining payment types: Working with Pay Types (WPAY)
-
defining currency codes: Working with Currency (WCUR)
-
defining country codes: Setting Up the Country Table (WCTY)
-
processing refunds: Processing Refunds (MREF)
-
working with Order Entry or General Usage system control values: Setting Up Order Entry Values and Setting Up General Usage Values
Scheduling Deposits
You can use the SCHDDEP periodic function (program name PFR0090) to send deposits. See Scheduling Jobs for an overview and setup information.
The Parameter field allows you to generate deposit transactions for a specific authorization service and/or define the maximum number of deposits to process for purchases. Note that this setting does not apply to refund transactions.
Note:
You can define a Purchases transactions to generate number in the Parameter field only if the Preload Deposits (L78) system control value is unselected.
If you do not define any parameters, the system uses the same settings as if you used the Auto Deposit Screen with all the default settings selected.
You need to specify a company when you set up the periodic process.
When you run the periodic process or submit deposits through the Submit Auto Deposits (SDEP) option, it starts a job named AUTO_DEP123, where 123 is the company number. The job selects records from the Invoice Payment Method table that have not yet been processed for deposit or credit, and whose deposit release date is the current date or earlier. The periodic process continues to run into the AUTO_DEP job finishes.
You can review the submitted AUTO_DEP job at the Job Management Screen. See Processing Deposits for more information
Additional things to note about the SCHDDEP function:
-
To run the function for multiple companies at the same time, you can select a different job queue for each periodic process that includes the SCHDDEP periodic function.
-
Each instance of the job creates its own active procedure, displayed in Purge Active Procedures Across Users (MACX) with a Type of BD.
-
If the AUTO_DEP job is inactive for 15 minutes but the active procedure still exists, you can use the JOBCLN periodic function to delete the active procedure, and then you can restart the job.
-
You cannot currently delete the AUTO_DEP job after it goes into Finished or Error status at the Job Management Screen screen. Also, job history records for this job are not purged based on the JOB_HISTORY_PURGE_ DAYS specified in Working with Admin Properties (CPRP).
-
The Display Active Batch Jobs (DABJ) option does not display the Last Program for the SCHDDEP job.
Multi-Currency, Alternate Currency, and Prestige Process
The following system control values govern the way your company handles foreign currencies when you process deposits.
System Control Value | Description |
---|---|
Multi-Currency |
Select the Multi Currency by Offer (E03) system control value to segregate orders based on the currency associated with the offer. If you use multi currency by offer, you will be required to specify currency at many points throughout the system, such as when you process refunds or print various reports. If you have this system control value selected, you do not need to have the Track Invoice Currency (D68) field selected, unless you also want to use the Invoice Currency table to record the exchange rate when an order bills; however, this is necessary only if you use Prestige as a deposit service. |
Prestige Process |
Select the Track Invoice Currency (D68) system control value to use the separate deposit process for foreign currency (the “Prestige” process) described below. The customer's currency is determined by the country where he or she resides. If you are processing deposits in foreign currencies separately, and you want to track the currency exchange rates at the time of (Prestige) billing, you may also need to:
Foreign currency transactions that use the separate process are not confirmed interactively through Process Auto Deposits. Instead, the system writes these records to the Credit Card Deposit Prestige table (CCCDPP). You must extract the contents of this table for transmission to the deposit service. Periodically, you must also purge the contents of this table through Purging Prestige Credit Card Deposits (MPSP). |
Auto Deposit Screen
Purpose: Use this screen to send and receive deposit and credit card credit information to and from a deposit service.
Selecting service bureaus for deposit: Select the Select Auth Service option to advance to the Select Auth Service for Deposit Screen, where you can select the service bureau(s) for which you wish to run deposits. By default, all service bureaus are selected for deposit.
Types of transactions selected: All eligible transactions, regardless of whether they are for orders with deferred or installment pay plans or for regular (non-pay plan) orders, will be processed. See Deferred or Installment Pay Plans vs. Regular (Non-Pay Plan) Orders for more information on pay plans.
How to display this screen: Enter SDEP in the Fast path field at the top of any menu or select Submit Auto Deposit from a menu.
Note:
Important: You will receive an error message when you try to advance to the Auto Deposit screen if the Use Auto Authorization Interface (C14) system control value is not selected: Info: Auto Authorization is not currently enabled. This system control value must be selected in order to send deposits to the service bureau for confirmation.
Field | Description |
---|---|
Send or receive |
Send Deposits is selected by default, specifying that you are sending information to the deposit service for settlement. You cannot change this option. Required. |
Purchases |
Use these fields to indicate the number or dollar amount of purchases to process. Note: The Purchases fields are display only if the Preload Deposits (L78) system control value is selected. |
Transactions to generate (for purchases) |
Enter the maximum number of deposits to process for purchases. Each transaction represents an invoice for a shipment or an installment payment using a credit card. Selecting transactions: If you enter a number, the system selects transactions for the service bureau(s) selected for deposit in ascending numeric order (lowest to highest) by order number, then invoice number, until it reaches the number of transactions you specify. See the description of the Amount to generate field, below, for more information on how the system selects transactions. Deposit release date: The transaction must have a deposit release date earlier than or the same as today's date to be eligible for processing. See Deposit Release Date. Leave this field blank to process all eligible deposits for purchases. Numeric, 7 positions; display-only if Preload Deposits (L78) is selected, otherwise, optional. |
Amount to generate (for purchases) |
Enter the maximum total dollar amount of all deposits to process for purchases. Selecting transactions: If you enter an amount, the system continues selecting transactions for the service bureau(s) selected for deposit in ascending order number sequence as described above, and stops before it would exceed this amount. However, if it would exceed the maximum amount by selecting the orders in exact sequence, it will skip one or more orders as necessary. Example: You enter a maximum amount to generate of $100 The following orders are currently eligible for deposit: order # / amount 100 / $50 101 / $30 102 / $30 103 / $15 104 / $10 Result: The system selects orders 100,101, and 103 for deposit. It skips order 102 because its order total of $30 would cause the total amount to exceed the maximum of $100 ($50 + $30 +$30 = $110). Also, it stops after including order 103, because it cannot add another order without exceeding the maximum. If you complete both this field and the Transactions to generate field, the system will restrict the deposits processed to within both limits. Leave this field blank to process deposits regardless of the total dollar amount. Numeric, 13 positions with a 2-place decimal; display-only if Preload Deposits (L78) is selected, otherwise, optional. |
Returns |
Use these fields to indicate the number or dollar amount of return credits to process: |
Transactions to generate (for returns) |
Enter the maximum number of deposits to process for returns. Each transaction represents a credit invoice to process against the customer's credit card. Selecting transactions: If you enter a number, the system selects transactions for the service bureau(s) selected for deposit in ascending numeric order (lowest to highest) by order number, then invoice number, until it reaches the number of transactions you specify. See the description of the Amount to generate field, below, for more information on how the system selects transactions. Deposit release date: The transaction must have a deposit release date earlier than or the same as today's date to be eligible for processing. See Deposit Release Date. Leave this field blank to process all eligible deposits for returns. See Netting Credits for Pay Plan Orders. Numeric, 7 positions; optional. |
Amount to generate |
Enter the maximum total dollar amount of all credit transactions to process. Selecting transactions: If you enter an amount, the system continues selecting transactions for the service bureau(s) selected for deposit in ascending order number sequence as described above, and stops before it exceeds this amount. Example: You enter a maximum amount to generate of $100 The following returns are currently eligible for credit deposit processing: order # / amount 100 / $50- 101 / $30- 102 / $30- Result: The system selects orders 100 and 101 for credit deposit. Then it stops after including order 103, because it cannot add another order without exceeding the maximum. If you complete both this field and the Transactions to generate field, the system will restrict the credit deposits processed to within both limits. Leave this field blank to process credit deposits regardless of the total dollar amount. Numeric, 13 positions with a 2-place decimal; optional. |
Screen Option | Procedure |
---|---|
Select which service bureau(s) you wish to select for the deposit run |
Select Select Auth Service to advance to the Select Auth Service for Deposit Screen, where you can select the service bureau(s) for which you wish to run deposits. By default, all service bureaus are selected for deposit. |
Send deposits to a deposit service |
Select OK at the Auto Deposit Screen to start a job named AUTO_DEP123, where 123 is the company number. This job selects records from the Invoice Payment Method table for the service bureau(s) selected for deposit that have not yet been processed for deposit or credit, and whose deposit release date is the current date or earlier.. You can review the submitted AUTO_DEP job at the Job Management Screen. See Processing Deposits for more information. Once you submit the deposit run, the system updates the Selected field for each service bureau on the Select Auth Service for Deposit Screen to YES, indicating all service bureaus are selected for the next deposit run, unless you deselect them. |
Select Auth Service for Deposit Screen
Use this screen to select the service bureau(s) for which you wish to run deposits. By default, all service bureaus are selected for deposit.
Once you run deposits, the system updates the Selected field on this screen to YES, indicating all service bureaus are selected for the next deposit run, unless you deselect them.
How to display this screen: Select Select Auth Service on the Auto Deposit Screen.
Field | Description |
---|---|
Description |
The name of a service bureau in Defining Authorization Services (WASV). Authorization services are defined in and validated against the Authorization Services table. Enter a valid description and select OK to display the service bureau that matches your entry. Selecting and Unselecting a Service Bureau When you first advance to this screen, all service bureaus are selected for the next deposit run.
Alphanumeric, 30 positions; optional. |
Sel Selected? |
Indicates whether the service bureau is selected for the deposit run.
|
Processing Deposits
The system creates records in the Invoice Payment Method table when you bill the orders and uses the Invoice Payment Method table to create records in the CC Deposit Transaction table to be used by the deposit process.
Note:
The system creates a record in the CC Deposit Transaction table only for pay types that have a deposit service defined.
Preload Deposits?
The setting of the Preload Deposits (L78) system control value determines whether billing or deposits creates records in the CC Deposit Transaction table and CC Deposit History table, based on the records in the Invoice Payment Method table.
Preload Deposit Process
If the Preload Deposits (L78) system control value is 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.
In addition:
-
If you use the CyberSource Point-to-Point Integration, the Customer Engagement Stored Value Card Integration, or the External Payment Service, the system sends the deposit transaction to the service bureau during billing. You still need to use Processing Auto Deposits (SDEP) to process credit deposits and perform the Batch Deposit Updates. Also, you will need to use the Resubmitting Rejected Deposits (SRDP) menu option to resubmit any deposits that were not completely processed during billing and deposits.
-
For all other service bureaus, the system sends the deposit transaction to the service bureau when you submit deposits using the Processing Auto Deposits (SDEP) menu option.
Note:
-
The system does not perform preload deposit processing for the deposit service defined in the Deposit Service for Conditional Deposits (L13) system control value. In this situation, the system uses the regular deposit process.
-
If you select the Preload Deposits (L78) system control value, you cannot use Consolidated Invoice (B49).
Important:
In Order Management System 21.0 or higher, 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.
Regular Deposit Process
If the Preload Deposits (L78) system control value is unselected, the deposit process creates records in the CC Deposit Transaction table and CC Deposit History table, prior to sending out the deposit transactions.
CC Deposit Transaction Table
Preload Deposits (L78) selected | Preload Deposits (L78) unselected |
---|---|
Cybersource, Oracle Retail Customer Engagement Service Bureau, or External Payment Service During billing:
During deposits:
Any Other Service Bureau During billing: The Status is *RDY, indicating the deposit transaction is ready to be submitted for processing. During deposits:
|
All Service Bureaus During billing: The system does not create a record in the CC Deposit Transaction table. During deposits:
|
CC Deposit History Table
Preload Deposits (L78) selected | Preload Deposits (L78) unselected |
---|---|
All Service Bureaus During billing:
During deposits: Updates Deposit status to C Confirmed. |
All Service Bureaus The system does not create a record in the CC Deposit History table. During deposits: The system creates a record in the CC Deposit History table, based on the information in the Invoice Payment Method and CC Deposit Transaction tables. |
Sending Deposits
The system transmits each record to the deposit service specified in the Pay Type table and confirms each deposit when the confirmation is received interactively from the deposit service.
Once the system receives the deposit response from the deposit service and updates the CC Deposit Transaction table, in order to free up the PICKGEN job queue, the system submits the DEP_UPDATE job to the QSYSNOMAX job queue to process the remaining updates; see Batch Deposit Updates.
Credit card encryption: Credit card encryption allows you to encrypt the credit card number in the Order Management System database to provide additional security of credit card data. If you use credit card encryption, the system decrypts the credit card number before sending it to the deposit service. See the Data Security and Encryption Guide on My Oracle Support (1988467.1) for an overview.
Tokenization: Credit card tokenization allows you to replace the credit card number in the Order Management System database with a token provided by the authorization service. In this situation, the system sends the token rather than the actual credit card number to the deposit service. See Credit Card Tokenization in the Data Security and Encryption Guide on My Oracle Support (1988467.1).
Depositing against multiple authorizations: When you process deposits for an order containing multiple authorizations, the system looks to process the deposit against an unexpired authorization whose amount equals the deposit amount. If an unexpired authorization amount does not equal the deposit amount, the system processes the deposit against the unexpired authorization with the highest dollar amount.
If one of the authorizations for a shipment on the order has expired: If the order includes an authorized shipment and another shipment whose authorization has expired, the expired amount is authorized, and the full amount is deposited.
Example: Item 1 on an order was authorized for 10.00 and the pick slip generated, but the authorization has since expired. A pick slip is generated for item 2 for 15.00, and the amount authorized at this time is 15.00. During deposit processing, the 10.00 is authorized, and 25.00 is deposited.
Credit card net exchange billing: If a credit invoice and debit invoice are flagged for net billing, the system nets the credit invoice amount against the debit invoice amount to determine the remaining amount to deposit; see Credit Card Net Exchange Billing for processing details.
Authorization number: The original authorization number authorizing the shipment at pick slip generation is retained by the system. This is the number that displays in order inquiry for a pay plan order, even after you receive a full authorization for the amount of the deposit.
Maximum threads: To enhance performance, set the DEPOSIT_MAX_THREADS property in Working with Admin Properties (CPRP) to a higher number. If the property is empty, missing, or not set to an integer, a setting of 1 defaults, and a warning message is written to the APP.log and the CWDIRECT.log indicating that a setting of 1 was used.
Troubleshooting: When the logging level is set to debug, detailed messages are written to the app.log during deposit processing. You can use these entries to help troubleshoot any issues with deposit processing. See Logs for background.
Batch Deposit Updates
The DEP_UPDATE job performs updates in the following order.
Table | Update |
---|---|
Invoice Payment Method |
The system updates the Invoice Payment Method record with the amount deposited. Deposit date: The system updates the deposit created date to the date when the DEP_UPDATE job is processed if the deposit created date was for an earlier date. This may occur if the billing date was earlier than the deposit date. |
Card Security Data |
If not already cleared, the system removes card security data from the Order Payment Method table and On Line Authorization table. Also, the system creates an order transaction history message indicating the security information has been cleared. |
CC Deposit History |
The system updates the CC Deposit History record with the response code received from the Deposit service. You can review deposit history in Order Inquiry; see Display Deposit History Screen and Display Deposit History Detail Screen. Deposit date: The system updates the deposit date to the date when the DEP_UPDATE job is processed if the deposit date was for an earlier date. This may occur if the billing date was earlier than the deposit date. If the deposit date in this table does not match the date when the DEP_UPDATE job is processed, the system updates the deposit date to the current date. |
Order Payment History |
The system creates an Order Payment History record. You can review order payment history in Order Inquiry; see Display Order Payment History Screen. |
Deposit Reports |
The system produces the following reports for each deposit service:
|
CC Deposit Transaction |
The system deletes the associated records in the CC Deposit Transaction table. |
Foreign Currency Deposit Process (Prestige)
If the payment types for the invoice records are set up for foreign currency processing, the system does not communicate with a deposit service at this time. Instead, the system writes the records to the Credit Card Deposit Prestige table (CCCDPP). You can extract the records from this table for transmission to a deposit service at a later time.
The system produces the Unconfirmed Deposits Listing Report for the foreign transactions. However, since it considers each transaction written to the Credit Card Deposit Prestige table as “confirmed,” it does not produce an Unconfirmed Deposits Listing Report for these transactions.
You will need to purge the Credit Card Deposit Prestige table through Purging Prestige Credit Card Deposits (MPSP).
Void Unused Authorization After Initial Deposit
If the deposit amount for a credit card deposit is less than the original amount authorized, the system looks at the setting of the Void auth at deposit field for the service bureau to determine how to process the deposit.
If the Void auth at deposit field for the service bureau is selected, the system automatically voids the remaining balance against a credit card authorization that has been partially deposited. If there are multiple authorizations for the order, the system will not void the other authorizations. The system uses both the authorization transaction ID and, if necessary, the authorization number to determine the authorization history record to be voided.
Note:
If a deposit run contains two deposits against the same authorization transaction and the Void auth at deposit field for the service bureau is selected, the system voids the remaining authorization amount after the first deposit in the run is processed. This allows the second deposit transaction to go out to the service bureau as a conditional deposit.
Example 1: In this example, the Void auth at deposit field for the service bureau is selected.
During order entry, you process an online authorization for an order for $50.00. When you review Authorization History for the order:
-
Status = A Authorized
-
Amount submitted = $50.00
-
Amount available = $50.00
During order maintenance, you cancel an item on the order. The order total reduces to $40.00. You ship and confirm the order. When you review Authorization History for the order:
-
Status = A Authorized
-
Amount submitted = $50.00
-
Amount available = $10.00
-
Amount deposited = $40.00
When you submit deposits, the deposit amount is $40.00. Because the Void auth at deposit field for the service bureau is selected and the deposit amount ($40.00) is less than the authorization amount ($50.00), the system voids the remaining authorization amount ($10.00). When you review Authorization History for the order:
-
Status = V Voided
-
Amount submitted = $50.00
-
Amount available =.00
-
Amount deposited = $40.00
Example 2: In this example, the Void auth at deposit field for the service bureau is unselected.
During order entry, you process an online authorization for an order for $50.00. When you review Authorization History for the order:
-
Status = A Authorized
-
Amount submitted = $50.00
-
Amount available = $50.00
During order maintenance, you cancel an item on the order. The order total reduces to $40.00. You ship and confirm the order. When you review Authorization History for the order:
-
Status = A Authorized
-
Amount submitted = $50.00
-
Amount available = $10.00
-
Amount deposited = $40.00
When you submit deposits, the deposit amount is $40.00. Because the Void auth at deposit field for the service bureau is unselected and the deposit amount ($40.00) is less than the authorization amount ($50.00), the system retains the remaining authorization amount ($10.00). When you review Authorization History for the order:
-
Status = A Authorized
-
Amount submitted = $50.00
-
Amount available = $10.00
-
Amount deposited = $40.00
Capture Sequence and Count Sent to CyberSource
The CyberSource Debit Deposit Request (ccCaptureService) XML Message indicates the capture sequence and total capture count if:
-
The Void auth at deposit flag for the authorization service is unselected, and
-
The entire order does not ship and bill at once, based on the fact that it’s a debit invoice for less than the authorization amount.
Capture count and sequence examples: Examples of how the ccCapture_sequence and ccCapture_totalCount would be populated in the deposit request message:
Scenario | ccCapture_sequence | ccCapture_totalCount |
---|---|---|
First deposit for the order. The number of deposits is not known, indicated by a total count of 99. |
1 |
99 |
Second deposit for the order. The number of deposits is not known, indicated by a total count of 99. |
2 |
99 |
Final deposit for the order. The capture sequence and total count were previously set to 2 and 99. The sequence increments by 1, and the total count is set to match the sequence. |
3 |
3 |
Final deposit for the order, and the capture sequence and total count were not previously sent. Note: In this case, the tags are not passed in the message. |
1 |
1 |
Larger number of deposits? If the number of deposits for the order is 98 or higher, the sequence number sent in the deposit request remains at 98, and the total count remains at 99 until the final deposit is submitted. At that point, the sequence number is set to 99.
Note that the Authorization History table tracks the actual sequence number and count.
Scenarios in which the ccCapture_sequence and ccCapture_totalCount are not sent in the deposit request message: In the following scenarios, the sequence and total count are still tracked in the Authorization History record, but not included in the deposit request message:
-
The tax rate increases, causing the invoice total to exceed the authorization amount. In this scenario, the original Authorization History record is voided, triggering a reversal. A new Authorization History record is created during deposit processing for the full invoice amount.
-
There were multiple authorizations, but the products shipped together and generated a single invoice. In this scenario, the original Authorization History records are voided, triggering a Reversal. A new Authorization History record is created during deposit processing for the full amount. The authorization amount and deposit amount will be equal on the new Authorization History record, so it is considered the final deposit.
-
The order is closed and the deposit request was already sent, but then an additional charge was added to the order and express-billed. A new Authorization History record is created for the additional charge amount.
-
The order is closed but the deposit request was not yet sent, and then an additional charge is added to the order and express-billed. A new Authorization History record is created for the additional charge amount. Both are submitted for deposit and considered final deposits.
The capture sequence and total capture count are not included for the CyberSource Authorization and Deposit Request (ccAuthService and ccCaptureService) XML Message, only for the deposit request.
Multiple Capture Sequence and Final Capture Sent to External Payment Service
The deposit request for credit cards and stored value cards sent through the External Payment Service indicates the capture sequence whether this is the final capture for account situations when:
-
The Void auth at deposit flag for the authorization service is unselected, and
-
The entire order does not ship and bill at once, based on the fact that it’s a debit invoice for less than the authorization amount.
Otherwise, if the Void auth at deposit flag is selected, the deposit request indicates a multiple capture sequence of 0, and the finalCapture tag is empty.
Capture count and sequence examples: Examples of how the multipleCaptureSequence and finalCapture would be populated in the deposit request message:
Scenario | multipleCaptureSequence | finalCapture |
---|---|---|
Void auth at deposit is selected |
0 |
empty |
Void auth at deposit is not selected and:
|
1 |
Y |
Void auth at deposit is not selected and:
|
1 |
N |
Void auth at deposit is not selected and:
|
2 |
Y |
Important:
Your end payment processor, such as Paymentech or VisaNet, must support split shipments for you to set the Void auth at deposit flag to N.
Error if deposit is greater than authorization (additional scenario for a stored value card): The External Payment Service returns the error DEPOSIT_GREATER_THAN_AUTH in a situation such as the following for a stored value card:
-
The Void auth at deposit flag is unselected.
-
An additional item with a higher price is added to the order after the initial authorization, and an additional authorization is obtained for this second item during pick slip generation; however, the additional authorization is based on the authorization required for the second item minus the current authorization amount, but not the full authorization amount that will be required for both items. For example:
-
ITEM01 is 25.00 and shipping is 10.00: 35.00 authorized.
-
ITEM02 is 50.00 and the 10.00 shipping billed when ITEM02 ships first: 60.00 authorization required.
-
When pick slip generation runs for ITEM02, additional 25.00 authorized (60.00 required - 35.00 already authorized).
-
-
The second item ships before the first item on the order, and the deposit amount exceeds the amount of the first authorization because of the second item’s higher price. Order Management System submits the largest existing authorization amount, which is 35.00. As a result, during deposit processing through the External Payment Service, Order Management System receives the DEPOSIT_GREATER_THAN_AUTH error based on the specified deposit amount of 60.00.
-
n this case, when Order Management System receives the error response, it submits two deposit requests:
-
One for the 35.00 authorization amount.
-
One for the 25.00 authorization amount.
Each request specifies the related authorization number, and a multipleCaptureSequence of 1 and a finalCapture of Y, because each request is for a separate authorization amount.
-
-
When the original 25.00 item is in stock, Order Management System obtains a new authorization for 25.00. Then when that item ships, Order Management System submits another deposit request for 25.00, which also specifies a multipleCaptureSequence of 1 and a finalCapture of Y for the additional authorization.
Deferred or Installment Pay Plans vs. Regular (Non-Pay Plan) Orders
Overview: You can use flexible payment options to set up deferred or installment pay plans for your customers. Unlike regular deposits, deferred or installment deposits are not eligible for processing immediately after confirmation of shipment and creation of the invoice; instead, the system assigns a pay plan deposit with a deposit release date based on the deferral or installment agreement.
Example: Deferral pay plan: “no payment for 60 days” or “no payment till February 1" Installment pay plan: “4 easy payments”
You can use deferred or installment pay plans only if the Deferred and Installment Billing (F51) system control value is selected. See Deferred/Installment Billing Overview for an overview of deferred and installment billing and information on setting up pay plans in your company.
Deposit Release Date
The deposit release date indicates when the deposit is eligible for processing.
Type of Order | Deposit Release Date |
---|---|
regular (non-pay plan) |
same as invoice date: deposit is eligible for processing immediately after billing |
deferral pay plan |
can be either a fixed date ("no payment till February 1") or based on a specific interval ("no payment for 60 days") if based on a specific interval, can be calculated based on either order date or invoice date |
installment pay plan |
first deposit release date can be either the next time a fixed date occurs ("installments due the first of the month") or after a fixed interval from time of shipment |
To review the deposit release date: The deposit release date is stored in the Invoice Pay Method table. You can review this information in order inquiry by selecting Invoices to advance to the Display Invoices screen, then selecting Invoice Pay Sum to advance to the Invoice Pay Summary Screen.
Authorizing Deposits
Unlike regular deposits, a deferred or installment deposit may not already have a current, valid authorization from the time of pick slip generation, so you need to obtain an authorization when you process deposits.
Overview: When you generate pick slips for a regular (non-pay plan) order, you authorize the pickable amount of the order, because you expect to confirm shipment and process the deposit shortly after. However, after you obtain an initial authorization for an order using a pay plan, there may be a considerable delay before you process the deposit or deposits. For this reason, it may be necessary to authorize the deposit amount as part of deposit processing.
Authorization at pick slip generation:
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 |
Note:
Even if the Authorize full amount field for the pay plan is selected, the system still re-authorizes the installment amount when you process the subsequent deposit(s) for the pay plan order.
Action codes: The system uses action codes to indicate to the deposit service whether the deposit requires an authorization. When processing deposits, the system sends the deposit service an action code of:
-
B (Conditional Deposit) if you need both an authorization and a deposit. The system sends a code of B for:
-
all pay plan deposits (regardless of how the Authorize full amount field for the pay plan is set) except for the first deposit of an installment plan, when a D code is sent instead.
-
any regular (non-pay plan) deposit sent to the deposit service whose authorization has expired. You can review the authorization expiration date at the Authorization History Details Window. Additionally, the system creates a new authorization history record for the new authorization number. The system assigns a Status of M (Mismatch Auth/Deposit) to authorization history records created during deposit processing.
Note:
Conditional deposit is not supported for stored value cards.
-
-
D (Regular Deposit) if you need to process the deposit only and do not require an authorization. The system sends a code of D for all regular (non-pay plan) deposits as long as there is an authorization code for the invoice pay method and the authorization has not expired.
Type of deposit | Action code |
---|---|
regular (non-pay plan) |
D Note: The system sends an action code of B for any regular deposit sent to the deposit service whose authorization has expired. |
first payment of an installment pay plan |
D |
subsequent payments of an installment pay plan |
B |
deferred billing pay plan |
B |
credit (refund) |
R |
It is possible to have a pay plan order where the deposit release date is the same as the invoice date. For example, if you set up a deferred pay plan based on order date, and shipment of the order is delayed due to a backorder, the order could be eligible for deposit as soon as you confirm shipment. In this situation, the deposit will still be sent with an action code of B, because typically you have not yet received an authorization for the amount of the deposit.
Force Deposit
You can choose to “force the deposit” when an authorization for a deferred or installment pay plan is rejected. Forcing the deposit means that the system performs all the same updates in your company as if the deposit was authorized and processed.
To force pay plan deposits, you must select the Force deposit for FPO field for the vendor response code. The system checks the setting of this field only when a deposit for a pay plan is rejected. See below for more information.
You are responsible for making any necessary arrangements with the deposit service if you plan to force deposits.
When is a pay plan deposit forced? The system forces a deposit when:
-
the deposit is for a deferred or installment pay plan, and
-
the deposit is sent out with an action code of B, and
-
the response code sent from the service is not an approval (100 = approval), and
-
the Force deposit for FPO field for the vendor response code is selected.
When is a regular (non-pay plan) deposit forced? Additionally, regular (non-pay plan) deposits are always forced because you received an authorization when you generated the pick slip, except under the following circumstances:
-
The action code on the deposit is D or R and
-
You are using an authorization service that allows forced deposits and
-
The Vendor Response code is not an approval (100 = approval) and
-
The regular deposit is returned from the authorization service with an authorization number of NOTDEP.
Netting Credits for Pay Plan Orders
The Net Credit Card Credits for Deferred and Installment Billing (F55) control value controls how refund credits are deposited for deferred or installment pay plans.
Overview: The system does not process a credit card credit against an installment or deferred billing order before the deposit itself has been processed. This rule is important to ensure that you do not credit the customer's credit card before it had actually been charged. The logic governing how to comply with this rule varies depending on whether the order uses a deferred or installment pay plan and on whether you net credit card credits.
The table describes how and when credits are eligible for deposit processing in different scenarios. In each scenario, it is assumed that the following has already occurred:
-
the order has a deferred or installment pay plan
-
shipment has taken place
-
the refund has been processed through the Process Refunds menu option (fast path = MREF)
Type of Pay Plan | Net Credits? | Result |
---|---|---|
deferred |
Unselected |
The credit has a deposit release date that is the same date as the debit. The credit deposit is eligible for processing after the purchase deposit is processed. Example:
|
deferred |
Selected |
The credit has a deposit release date that is the same date as the debit. When you process deposits, the net amount of the deposit only is processed. Example:
|
installment |
Unselected |
The credit has a deposit release date that is the same as the date you created it; however, the credit deposit is eligible for processing after the total debit deposits meet or exceed the credit invoice amount. Example:
|
installment |
Selected |
The credit has a deposit release date that is the same as the date you created it. When you process deposits, the remaining installment amounts are reduced by the total credit amount. Example:
|
Merchant ID Messages
You can specify a message to appear on the customer's credit card statement when you process a deposit for a pay plan. The message is concatenated with additional information into a 14- or 18-position message, formatted as follows:
-
DBA industry code (3 positions): taken from the first 3 positions of the Industry format code for the authorization service
-
Merchant ID message (11 positions): taken from the Merchant ID message field for the pay plan
-
Installment description (4 positions): for installment pay plans, this consists of a description of which installment was deposited, for example, 1of 4. With this description, the entire message for an installment plan is 18 positions. For deferred pay plans, the entire message ends after the merchant ID message, producing a 14-position message.
Updates for Installment Pay Plans
When you process a deposit for an installment pay plan, the system updates the following fields for the invoice pay method:
-
Intervals remaining: reduced by one.
-
Total amount deposited: increased by the deposit amount.
-
Deposit release date:
-
if the installment plan uses an interval, the deposit release date is calculated by adding the interval number of days to the current date.
-
If the installment plan uses a fixed billing date, the deposit release date is changed to the next occurrence of the billing date.
-
-
Deposit created date: This field is updated with the current date only when you deposit the last installment payment.
You can review the invoice pay method information in order inquiry. See Reviewing Deposits in Order Inquiry.
Rejected Deposits for Pay Plan Orders
Unauthorized or unconfirmed deposits display on the Unconfirmed Deposits Listing Report. Additionally, you can use the Resubmit Rejected Deposits Screen to review, work with, or resubmit any deposits that were not fully processed through the Submit Auto Deposit menu option.
Holding orders: When a deposit is rejected for a deferred or installment pay plan, orders for the same customer and/or using the same credit card number are put on hold. See Holding Pay Plan Orders.
Installments: Additionally, when a deposit is rejected for an installment pay plan, the next installment date is changed to 999999.
Non-pay plan orders: Unconfirmed regular (non-pay plan) orders still appear on the Unconfirmed Deposit Listing and are available through the Resubmit Rejected Deposits Screen.
Holding Pay Plan Orders
When a deposit for a deferred or installment pay plan is rejected, the system puts any open orders for the same customer or the same credit card number on hold, as follows:
-
same sold to customer: order goes on SB hold
-
same credit card number: order goes on CB hold
If an order matches both the customer and the credit card number, it goes on CB hold.
Note:
You must set up these hold reason codes in your company. See Establishing Order Hold Reason Codes (WOHR).
Order history message: The system also writes a message to order history when it puts the related order an hold, for example:
8/10/06 H CB Hold. Rejected deposit on 4778/3282 114.84 SAMPLENAME
In the above example, the 4778/3282 refers to the order number and invoice number of the deposit that was rejected, and the 114.84 refers to the rejected deposit amount.
See Reviewing Financial Information on an Order for more information on reviewing information in order inquiry.
For more information:
-
See Rejected Deposits for Pay Plan Orders for more information on how the system handles deposits that are not forced.
-
See Deferred/Installment Billing Overview for more information on the necessary setup to use deferred or installment pay plans.
-
See Defining Vendor Response Codes for more information on setting up a response code to force deposit.
Stored Value Card Deposits
When processing a deposit for a stored value card, the system uses the action code D to process the deposit. Conditional deposit (B) is not supported for stored value cards.
Multiple authorizations: If there are multiple authorizations for the order and the deposit amount is greater than the remaining amount for each authorization on the order, the system will send the first authorization number for the deposit record. However, once the deposit response is received, the system will deposit both authorizations. For example, if you have 2 authorizations for 20.00 and the deposit amount is 40.00, the system will send the first authorization number for the deposit record, but will deposit both authorizations once a response is received.
If the stored value card cannot cover the entire deposit amount: If the balance on the stored value card cannot cover the entire deposit amount, the system will reject the entire deposit amount.
Stored value card credits: 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.
If the deposit amount is less than the original authorization amount: If the deposit amount is less than the original amount authorized:
-
External Payment Service: The Void auth at deposit flag, set up through Defining Authorization Services (WASV), indicates how to process the deposit. See Multiple Capture Sequence and Final Capture Sent to External Payment Service for a discussion.
-
Other authorization services: The Retain Unused Stored Value Card Authorization After Deposit (J21) system control value indicates how to process the deposit.
-
If the Retain Unused Stored Value Card Authorization After Deposit (J21) system control value is selected, the system will 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 will retain the remaining 10.00 on the authorization.
-
If the Retain Unused Stored Value Card Authorization After Deposit (J21) system control value is unselected, the system will 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 will void the remaining 10.00 on the authorization. If there are multiple authorizations for the order, the system will not void the other authorizations.
-
Stored value card authorization reversals during deposits: 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. For example, if the original authorization amount is 50.00, but the deposit amount is 30.00, the system will deposit 30.00 and reimburse 20.00 to the stored value card. See Authorization Reversal Process During Deposits for more information.
Sending deposits for the same order and authorization number as Conditional: For the deposit service defined in the Deposit Service for Conditional Deposits (L13) system control value, the system sends subsequent debit deposits (transaction type Purchase action code D) for the same order number and authorization code as a Conditional Deposit (transaction type Conditional, action code B) rather than a Regular Deposit (transaction type Purchase action code D). See this system control value for examples. Note: To use this system control value, the Retain Unused Stored Value Card Authorization After Deposit (J21) system control value must be selected and the Perform Authorization Reversal during Deposit Processing (J20) system control value must be unselected.
Reviewing Deposits in Order Inquiry
You can use order inquiry to review the deposit status of credit card payment methods for both pay plan and regular (non-pay plan) orders.
Screen | Use for: | To advance to in order inquiry: |
---|---|---|
Invoice Pay Summary |
|
select Invoices, then Invoice Pay Sum |
Display Invoice Pay Method |
|
select Display for an invoice at the Invoice Pay Summary screen |
Change Invoice Pay Method |
|
select Change for an invoice at the Invoice Pay Summary screen Note: This screen is also available through Resubmitting Rejected Deposits (SRDP). |
Display Deposit History |
|
select Deposit History for an invoice at the Invoice Pay Summary screen Note: This screen is also available through Resubmitting Rejected Deposits (SRDP). |
Display Order Payment History |
|
select Payment History for an invoice at the Invoice Pay Summary screen Note: This screen is also available from the Display Order Payment Methods screen in order inquiry (select Payments) |
See Reviewing Financial Information on an Order for more information on reviewing invoice and deposit activity in order inquiry.
Resubmitting Rejected Deposits (SRDP)
Purpose: Use the Resubmit Rejected Deposits function to resubmit deposits and credit card credits that were not completely processed through the Process Auto Deposits function.
Overview: When you use the Process Auto Deposits function to transmit credit card deposit information to a deposit service for settlement, the deposit service normally confirms each deposit and credit. If a transaction is not confirmed because, for instance, the line was dropped, or the deposit service rejected the deposit, the system flags the record in the Invoice Payment Method table.
You can use the Resubmit Rejected Deposit function to select records you want to resubmit, and change their status so that they are eligible to be processed the next time you run Process Auto Deposits. You can also use this menu option to:
-
review or change the Invoice Payment Method
-
delete the deposit
-
confirm or reject the deposit
-
advance to order inquiry
-
review deposit history
-
write off the amount of the deposit
Forced deposits: Deferred or installment deposits that were rejected but flagged for “force deposit” are not available in Resubmit Rejected Deposits, because the system performs all updates as if the deposit service confirmed the deposit. Regular (non-pay plan) deposits are typically forced, although sometimes they are unconfirmed for other reasons. See Force Deposit.
Note:
You cannot use the Resubmit Rejected Deposits function to resubmit transactions that you have set up to use the separate process for foreign currency. Process Auto Deposits writes the foreign currency records to a separate table, rather than receiving settlement information interactively from the deposit service.
Suppressing deposits: You can suppress deposit processing for orders you receive through the Generic Order Interface (Order API). In this situation, the order is not included when you reprocess deposits. See Suppressing Deposits and Refunds for an overview.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Resubmitting rejected deposits through CyberSource: The Supports Auth Resubmission flag in Defining Authorization Services (WASV) controls whether resubmitting rejected deposits is enabled for the authorization service. See Subsequent Authorization Requests to CyberSource for information on how rejected deposits are resubmitted to CyberSource.
Modern View: You can also use the Manage Rejected Deposits option in Modern View.
More information: See Processing Auto Deposits (SDEP) for more information on the Process Auto Deposits function, the separate process for foreign currency deposit processing, and an overview of how deferred or installment pay plans differ from regular (non-pay plan) deposits.
In this topic:
Resubmit Rejected Deposits Screen
How to display this screen: Enter SRDP in the Fast path field at the top of any menu, or select Resubmit Rejected Deposits from a menu.
Field | Description |
---|---|
Rcds pending (Records pending) |
The total quantity of unconfirmed deposits that you have flagged to resubmit, confirm, delete, or write off. When you select Accept, the confirmations, deletions, and writeoffs will take place; deposits flagged for resubmission will eligible for processing the next time you process deposits. You can flag a total of 100 deposit records at a time. Numeric, 3 positions; display-only, updated by the system. |
Maximum |
The maximum number of deposits that you can resubmit, confirm, delete or write off at one time. Numeric, 3 positions; display-only. |
Rel date (Deposit release date) |
The date when the deposit is eligible for processing. Deferred or installment pay plans typically have a deposit release date (or dates) later than the invoice date. Regular (non-pay plan) invoices have a deposit release date that is the same as the invoice date. You can change the deposit release date at the Change Invoice Pay Method Screen, available by selecting Change for the deposit. See Deposit Release Date. Numeric, 6 positions (in user date format); optional. |
Order # |
A unique number to identify the order. Numeric, 8 positions; optional. |
Invoice |
A unique number to identify the invoice for the shipment or credit. Numeric, 7 positions; optional. |
Pay Mth (Payment option type) |
The type of pay plan on the order. Valid values are: D = deferred billing I = installment billing Blank = no pay plan; invoice amount eligible for deposit immediately after billing Alphanumeric, 1 position; optional. |
Total dollars |
The dollar amount of the unconfirmed deposit for the credit card. Positive amounts represent deposits, while negative amounts represent credit card credits. Numeric, 20 positions with a 2-place decimal; display-only. |
Reject reason |
The response code received from the deposit service. See Defining Vendor Response Codes. Alphanumeric, 10 positions; display-only. |
Action (Unlabeled field to the right of the reject reason) |
The action you have selected to perform for the deposit. Valid values are: *CONFIRM = You selected Confirm for the deposit to confirm that it was processed and perform all related updates in the system. *DELETE = You selected Delete for the deposit to delete it, making it ineligible for subsequent deposit processing. *RESUBMIT = You selected Resubmit for the deposit to make it eligible for processing the next time you process deposits. *WRITE OFF = You selected Write-Off for the deposit to write it off. When update takes place: The system does not perform any of these updates to deposits unless you select Accept to accept your entries at this screen. However, any transactions you enter at the Change Invoice Pay Method screen (available by selecting Change for the deposit) take place interactively. To cancel an update: You can select Reject Request for a deposit to prevent it from being deleted, resubmitted, or written off when you select Accept to accept your entries. However, you cannot prevent a deposit flagged for confirmation from being processed unless you exit the screen without selecting Accept. See Confirming, Resubmitting, Deleting, or Writing Off an Unconfirmed Deposit for more information on the updates you can perform at the Resubmit Rejected Deposits screen. See Change Invoice Pay Method Screen for more information on the updates you can perform at the Change Invoice Pay Method Screen. Alphanumeric, 11 positions; display-only. |
Screen Option | Procedure |
---|---|
Change information about an invoice payment method |
Select Change for an unconfirmed deposit to advance to the Change Invoice Pay Method Screen. Note: If you do not have access to the Restrict Access to Credit Card Numbers in OI and OM (A88) secured feature or the Change Invoice Payment Information (A82) secured feature, the system displays an error message when you try to change the credit card on an invoice payment method: You are not authorized to change Credit Card #. |
Delete the unconfirmed deposit and prevent the invoice from being resubmitted for deposit |
Select Delete for an unconfirmed deposit to delete the deposit. See Confirming, Resubmitting, Deleting, or Writing Off an Unconfirmed Deposit. |
Display information about an invoice payment method |
Select Display for an unconfirmed deposit to advance to the Order Number Screen (Viewing by Order Number). |
Process all the same updates for the deposit as if it had been confirmed through the Process Deposits function |
Select Confirm for an unconfirmed deposit to flag the deposit for confirmation. See Confirming, Resubmitting, Deleting, or Writing Off an Unconfirmed Deposit. |
Resubmit the deposit for processing |
Select Resubmit for an unconfirmed deposit to flag the deposit for processing the next time you process deposits. See Confirming, Resubmitting, Deleting, or Writing Off an Unconfirmed Deposit. |
"Unflag" a deposit for resubmission, deletion, or writeoff |
Select Reject Request for an unconfirmed deposit that you have flagged for resubmission, deletion, or writeoff to “unflag” it. See Confirming, Resubmitting, Deleting, or Writing Off an Unconfirmed Deposit. |
Advance to order inquiry |
Select Order Inquiry for an unconfirmed deposit to advance to order inquiry. See Using the Order Inquiry Scan Screens (OIOM). |
Review deposit history for an order |
Select Deposit History for an unconfirmed deposit to advance to the Display Deposit History Screen. |
Write off a deposit |
Select Write-off for an unconfirmed deposit to delete the deposit. See Confirming, Resubmitting, Deleting, or Writing Off an Unconfirmed Deposit. |
Exit the screen without processing updates |
Select Exit. See Confirming, Resubmitting, Deleting, or Writing Off an Unconfirmed Deposit. |
Display unconfirmed deposits in order number sequence |
Select View by Order#. See Order Number Screen (Viewing by Order Number). |
Resubmit rejected deposits by date range, and optionally, response code |
Select Resubmit Batch to advance to the Resubmit Rejected Deposits by Batch Screen. |
Process updates for all flagged deposits |
Select Accept. See Confirming, Resubmitting, Deleting, or Writing Off an Unconfirmed Deposit. |
Confirming, Resubmitting, Deleting, or Writing Off an Unconfirmed Deposit
Description | To Flag the Deposit: | To Cancel: |
---|---|---|
Confirm: processes all the same updates for the deposit as when it is processed automatically by Processing Auto Deposits (SDEP). You might use this option when you did not receive a confirmation through Process Deposits, but the deposit service indicates that the deposit was confirmed. |
Select Confirm for each deposit or credit transaction you want to confirm. *CONFIRM displays next to each record you select. |
Select Exit to exit the Resubmit Rejected Deposits Screen without selecting Accept to process. |
Delete: changes the Deposit created date for the Invoice Pay Method to 88/88/88 and deletes the deposit from the Resubmit Rejected Deposits Screen. The invoice will not be eligible for resubmission to the deposit service. |
Select Delete for each deposit or credit transaction you want to delete. * DELETE displays next to each record you select. |
Select Reject Request for the deposit. |
Resubmit: makes the deposit eligible for processing the next time you run Process Deposits, provided the deposit release date has not been changed to a future date. |
Select Resubmit for each deposit or credit transaction you want to resubmit. * RESUBMITTED displays next to each record you select. |
Select Reject Request for the deposit. |
Write off: similar to deleting, writing off changes the Deposit created date for the Invoice Pay Method to 88/88/88, deletes the deposit from the Resubmit Rejected Deposits Screen, and prevents the invoice from being resubmitted to the deposit. |
Select Write-off for each deposit or credit transaction you want to write off. * WRITE OFF displays next to each record you select. |
Select Reject Request for the deposit. |
To process: Select Accept to process the requests. The system updates the records in the Invoice Payment table for each record you selected as described above.
Important:
You can select only 100 transactions at a time to process unless you use the Resubmit Rejected Deposits by Batch Screen.
See Processing Auto Deposits (SDEP).
Note:
You can also resubmit or delete a deposit, or write it off in full or up to a specified amount, at the Change Invoice Pay Method Screen (available by selecting Change for the deposit). However, these updates take place interactively and you cannot undo them.
Resubmit Rejected Deposits by Batch Screen
Purpose: Use this screen to resubmit rejected deposits for a specified date range, and optionally, response code.
How to display this screen: Select Resubmit Batch on the Resubmit Rejected Deposits Screen.
Field | Description |
---|---|
Deposit start date |
The beginning credit card deposit history date for the deposit date range of the rejected deposits you wish to resubmit for processing. Note that this date may differ from the deposit release date or the invoice date. Numeric, 6 positions (in user date format); Required. |
Deposit end date |
The ending credit card deposit history date for the deposit date range of the rejected deposits you wish to resubmit for processing. Note that this date may differ from the deposit release date or the invoice date. Numeric, 6 positions (in user date format); Required. |
Response code |
The repose code assigned to the rejected deposit. |
To resubmit:
-
Use the Deposit start date and Deposit end date fields to define the deposit date range for the rejected deposits you wish to resubmit for processing.
-
Optionally, enter a Response code to limit the rejected deposits in the date range to only those deposits with the specified response code.
-
Select Submit. The system processes all unconfirmed deposits in the CC Deposit History table for the specified date range and response code, performing the following updates:
-
Invoice Payment Method: Clears the deposit date and reverses the pending deposit amount.
-
CC Deposit History: updates the status to R Resubmitted.
-
Order Payment History: creates a record with the text Resubmit deposit $99999.99, where 9999.99 is the deposit amount.
-
Writes a message similar to the following to the TRACE log if its logging level is set to DEBUG: Deposit will be resubmitted for (Co#/Ord#/Inv#): 9.0/102718/18155.0.
-
When you return to the Resubmit Rejected Deposits Screen, the orders associated with the deposits that were processed no longer display on the screen.
Order Number Screen (Viewing by Order Number)
How to display this screen: Select View by Order# at the Resubmit Rejected Deposits Screen to change the sort of the deposit records to ascending order number sequence.
Select View by Date to change back to viewing deposits in deposit release date sequence.
Printing the Deposit History Summary (PDHS)
Purpose: Use the Deposit History Summary report to review the total deposits processed by date. This report breaks out the totals by pay type, and includes debit and credit subtotals for regular deposits, deferred billing, and installments.
The Deposit History Summary report includes only deposits that were actually processed, not rejected or unconfirmed deposits.
Deposit History Summary Screen
Purpose: Use this screen to select the dates to include on the Deposit History Summary Report and to print the report.
How to display this screen: Enter PDHS in the Fast path field at the top of any menu or select Print Deposit History Summary from a menu.
Field | Description |
---|---|
Start date |
The first date to include on the report. The current date defaults. Numeric, 6 positions (in user date format); required. |
End date |
The last date to include on the report. The current date defaults. Numeric, 6 positions (in user date format); required. |
Screen Option | Procedure |
---|---|
Generate the Deposit History Summary Report |
Select Submit. |
Printing the Credit Card Deposit Schedule (PCCD)
Purpose: Use the Credit Card Deposit Schedule to review the credit card deposits you can expect to process through deferred or installment payment plans for a given period. This report:
-
lists each order or order shipment with pending deposits
-
provides totals by type of payment plan, pay type, and date
-
breaks out credits and debits
Summary report: This menu option also produces the Credit Card Deposit Schedule Summary. This report summarizes the projected deposits by omitting the order-level information.
Credit Card Deposit Schedule Screen
How to display this screen: Enter PCCD in the Fast path field at the top of any menu or select Print Credit Card Deposit Schedule from a menu.
Field | Description |
---|---|
Start date |
The first expected deposit date to include on the report. The current date defaults. Numeric, 6 positions (in user date format); required. |
End date |
The last expected deposit date to include on the report. The current date defaults. Numeric, 6 positions (in user date format); required. |
Print detail |
Indicates whether to print the Credit Card Deposit Schedule. Valid values are: Selected (default) = print the Credit Card Deposit Schedule Unselected = do not print the Credit Card Deposit Schedule |
Print summary |
Indicates whether to print the Credit Card Deposit Schedule Summary. Valid values are: Selected (default) = print the Credit Card Deposit Schedule Summary Unselected = do not print the Credit Card Deposit Schedule Summary |
Screen Option | Procedure |
---|---|
Generate the Credit Card Deposit Schedule and the Credit Card Deposit Schedule Summary reports |
Select Submit. |
Printing the Pending Payment Plan Deposits (PPPD)
Purpose: Use the Pending Payment Plan Deposits Report to review the payment plan orders with pending deposits for a range of invoice dates. This report includes detail information, such as the pay plan on the order. This report does not include regular (non-pay plan) deposits, which are eligible for processing immediately after billing.
See Deferred/Installment Billing Overview for more information on installment or deferred pay plans.
Pending Payment Plan Deposit Report Screen
How to display this screen: Enter PPPD in the Fast path field at the top of any menu, or select Print Pending Pay Plan Report from a menu.
Field | Description |
---|---|
Start date |
The first invoice date to include on the report. This is the date when you confirmed shipment of the order. The current date defaults. Numeric, 6 positions (in user date format); required. |
End date |
The last invoice date to include on the report. The current date defaults. Numeric, 6 positions (in user date format); required. |
Screen Option | Procedure |
---|---|
Generate the Pending Payment Plan Deposits Report |
Select Submit. |
Printing the Deposit History Detail Report (PDHD)
Purpose: Use the Deposit History Detail report to review 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.
Print Deposit History Detail Screen
Purpose: Use this screen to select the dates to include on the Deposit History Detail Report and to print the report. You can also specify to include only those deposit transactions for a specific:
How to display this screen: Enter PDHD in the Fast path field at the top of any menu or select Print Deposit History Detail Report from a menu.
Field | Description |
---|---|
Start Date |
The first date for the deposits to include on the report. The system uses the Deposit date in the Deposit History table to determine which deposit transactions to include on the report. Numeric, 6 positions (in user date format); required. |
End Date |
The last date for the deposits to include on the report. The system uses the Deposit date in the Deposit History table to determine which deposit transactions to include on the report. Numeric, 6 positions (in user date format); required. |
Auth Service |
The authorization service that was used for the deposits to include on the report. The system uses the Authorization code in the Deposit History table to determine the deposit transactions to include on the report. Authorization service codes are defined in and validated against the Authorization Service table; see Defining Authorization Services (WASV). Alphanumeric, 3 positions; optional. |
Pay Type |
The pay type that was deposited against. The system uses the Pay type in the Deposit History table to determine which deposit transactions to include on the report. Pay type codes are defined in and validated against the Pay Type table; see Working with Pay Types (WPAY). Numeric, 2 positions; optional. |
Status |
The status of the deposits to include on the report. The system uses the Status in the Deposit History table to determine which deposit transactions to include on the report. Valid statuses are:
Optional. |
Screen Option | Procedure |
---|---|
Generate the Deposit History Detail Report |
Enter information in the fields on the Print Deposit History Detail Screen and select Print Report. The system submits the CC_DEP_DTL job and returns you to the menu screen. |
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 Web Services Guide on https://support.oracle.com My Oracle Support (ID 2149144.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 Management System for the e-commerce interface, and specifies additional documentation detailing setup requirements for communicating and for the web storefront.
-
Downloading E-Commerce Static Tables (ESTF) describes the process you use to extract infrequently changed information to staging files for subsequent download to 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.
Working with Batch Order Maintenance Transactions (WBOM)
Purpose: Use this menu option to work with errors resulting from order cancel requests from the web storefront.
About order cancel requests from the web: You can enable your customers to submit cancel requests from the web storefront if you use the e-commerce interface. Each cancel request on the web storefront generates a message to Order Management System indicating whether to cancel the order or a specific order line. Occasionally, the system cannot process the request. For example, the customer might attempt to cancel an order line that has recently shipped.
Typically, you would first check the status of the order using the Generic Customer History API to determine the details of the order you wish to cancel.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Cancel request: The request specifies the order ship-to or order lines you wish to cancel.
Cancel response: The response message merely indicates that the request was received; a subsequent email confirmation indicates whether the cancellation request was successful.
Fixing errors: When there is an error, you might choose to complete the requested transaction yourself; or you might need to contact the customer for further information if the desired transaction is not clear. However, you cannot edit and resubmit the maintenance requests through the Batch Order Maintenance menu option. Once you have resolved the request through research, order maintenance, or customer contact, you should delete the related error record.
What if the order includes a membership item? If the cancel request attempts to cancel a membership item, the order cancellation process does not automatically cancel the customer membership created by the membership item. You need to use Working with Customer Memberships (WWCM) in order to cancel the customer membership.See Membership Overview for background on customer memberships.
What if the order includes an order line assigned to the Order Broker? If the cancel request attempts to cancel a brokered backorder, the request goes into error status with an error of Order Has Picks Open. You need to use order maintenance or cancel option in Work with Order Broker to cancel the order line. See Brokered Backorders for an overview.
What if the order is a retail pickup or delivery order received from the Order Broker? If the cancel request is for a retail pickup or delivery order, the process sends a status update to the Order Broker indicating that the order is canceled. The Order Broker does not attempt to find another location to fulfill the order. See Retail Pickup (including Ship-for-Pickup) or Delivery Orders for an overview.
What if the order is a store pickup order? You cannot cancel a store pickup order through the CWCancel message. See Store Pickup Orders for background or store pickup orders.
In this topic:
-
E-Commerce Cancel Request Message (CWCancel) See the Web Services Guide on My Oracle Support (ID 2149144.1
E-Commerce Cancel Setup
The CWServiceIn web service allows an external system to post the E-Commerce Cancel Request Message (CWCancel) directly to Order Management System and receive responses without the need of any queues.
See the Web Services Guide on My Oracle Support (ID 2149144.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.
You can use the CWServiceIn web service as a RESTful web service.
Setup for the CWServiceIn RESTful Web Service
You POST the E-Commerce Cancel Request Message (CWCancel) to the web service’s URL, or endpoint, of the RESTful service. The web service routes the messages sent to the endpoint and dispatches them to the E-Commerce Cancel process. When the E-Commerce Cancel process generates a response, the CWServiceIn web service routes the response. See the Web Services Guide on My Oracle Support (ID 2149144.1
Message type: The type attribute in the inbound message identifies the Order Management System process, so the CWServiceIn web service can route the message appropriately. The correct type for the E-Commerce Cancel Request Message (CWCancel) is CWCancel.
Determine the endpoint: The individual URL for the CWServiceIn RESTful service uses the following format: http://server:port/SerenadeSeam/sxrs/application/CWServiceIn, where server:port identifies the application server where the RESTful service is located and CWServiceIn is the name of the web service to call.
Sample Inbound Message using RESTful Web Service
A sample E-Commerce Cancel Request Message (CWCancel) when using a RESTful web service is presented below.
<Message xsi:noNamespaceSchemaLocation="file:///c:/SVN/Serenade%205.5/XML/SampleXML/CWCancel/1.0/CWCancel.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" type="CWCancel" target="OROMS" source="WEB">
<Cancel order_reason="5" cancel_type="O" ship_to="1" order_id="855" company_code="1"/>
<Lines>
<Line reason="0" qty="1" line_number="1"/>
</Lines>
</Message>
E-Commerce Cancel Process: When is an Order Eligible for Cancellation through the E-Commerce Interface?
In order to be fully or partially canceled through the e-commerce interface, the order must:
-
have originated on the web storefront. If an order originated on the web, the Internet order field on the Order Header table is set to I.
-
be in an open (O) or held (H) status
-
have no pick slips printed
-
not be assigned to the Order Broker for fulfillment
Also, you will not be able to complete cancellation of the order or order line if the order is in use. The system determines that an order is “in use” if the User field on the Order Header table is not blank; for example, the system populates this field when you are maintaining an order, and clears it when you are done with maintenance.
What if the order includes a membership item? If the cancel request includes a membership item, the order cancellation process does not automatically cancel the customer membership created by the membership item. You need to use Working with Customer Memberships (WWCM) in order to cancel the customer membership.See Membership Overview for background on customer memberships.
What if the order includes an order line assigned to the Order Broker? If the cancel request attempts to cancel an order line that is assigned to the Order Broker for fulfillment, the request goes into error status with an error of Order Has Picks Open. You need to use order maintenance or the Working with Order Broker (WOBR) option to cancel the order line. See Order Broker Integration for an overview.
Order Inquiry/Maintenance Message Flow
Order inquiry and maintenance through the e-commerce interface use the following messages:
Message | Direction | Purpose |
---|---|---|
To check status: |
||
Customer History Request XML Message (CWCustHistIn) For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
web storefront to Order Management System |
Inquires on the status of the order. |
Detailed Order Inquiry Response XML Message (CWORDEROUT) For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
Order Management System to web storefront |
Provides information on the order header and detail. |
To cancel: |
||
E-Commerce Cancel Request Message (CWCancel) See the Web Services Guide on My Oracle Support (ID 2149144.1 |
web storefront to Order Management System |
Attempts to cancel:
This message also indicates the reason for the cancellation. See E-Commerce Cancellation Transactions. |
Processing the Request
In response to a cancellation request from the web storefront, the system:
-
Locks the order: The system sets the User field on the Order Header table to E-COMMERCE to prevent another user or process from attempting to update the order at the same time.
-
Creates batch order maintenance error records: The system uses these records, if necessary, to track any errors in the cancellation request. See Work with Batch OM Transactions Screen.
-
Edit: Next, the system checks whether there are any errors for the request.
-
If there are no errors, the system:
-
processes the requested update(s) to the order.
-
deletes the batch order maintenance error records.
-
unlocks the order.
-
-
If there are errors, the system:
-
updates the batch order maintenance error record with one or more error codes. See Display Batch OM Errors Screen.
-
depending on customer preference, sends the customer an email indicating that the cancellation attempt was not successful. See Emails for E-Commerce Cancels.
-
writes an order history message indicating that the attempt to update the order was not successful and that an email was generated. See Order History Messages.
-
places the order on hold if there is a hold reason specified in the Hold Reason for Failed E-Commerce Maintenance Transactions (H11) system control value.
-
produces the E-Commerce Order Maintenance Errors Report.
-
unlocks the order.
-
You can use the Work with Batch OM Transactions Screen to review any cancel requests that are in error.
Note:
If there are any errors in the request, none of the requested changes will be processed until the errors are corrected and the edit resubmitted.
E-Commerce Cancellation Transactions
Required for each cancel request:
-
Company_code: three positions, alphanumeric; for example, company 7 is indicated by 007
-
Order_id: order number
-
Ship_to: the number identifying the shipping address on the order; for example, an order with a single shipping address has a ship-to number of 001
-
Cancel_type:
-
O (default) = order
-
L = line
-
Whole order, single ship-to: The Cancel_type must be O and the Order_reason must specify a valid cancel reason code for the order.
Note:
If there are multiple shipping addresses, the cancel request for each ship-to must be sent separately.
Single item, reducing quantity or canceling the entire order line: the Cancel_type must be L and the following information is also required:
-
Line_number: the order line number to be cancelled or have its quantity reduced
-
Qty: the total quantity to cancel
-
Reason: the valid cancel reason code
Emails for E-Commerce Cancels
Cancellation email: The ORDR_ASYNC job generates an order or order line cancellation email to the customer if:
-
the cancellation attempt is successful, and
-
you have specified an:
-
Order Line Cancellation Email Program (K79), if no shipments have occurred, or
-
-
the cancel reason code you use does not match the Cancel Reason Code to Suppress Email (L08), and
-
the customer is eligible to receive email notifications; see When Does the System Generate an Email Notification?
See the Order Cancellation Confirmation Email Sample and Contents and the Order Line Cancellation Confirmation Email Sample and Contents for more information.
If the cancellation attempt is unsuccessful, the system generates the maintenance failure email if:
-
you have specified a Order Maintenance Confirmation E-Mail Program (H12), and
-
the customer is eligible to receive email notifications; see When Does the System Generate an Email Notification?
See the Order Cancellation Confirmation Email Sample and Contents for more information.
The system selects the order cancellation, order line cancellation, or maintenance failure email template as appropriate. See Work with E-Mail Template Screen. If the system sends an email, this information is noted in the order history message.
Order History Messages
The system writes the following message to order history if the cancellation request fails:Web cancel request failed.
If the cancel request is successful:
Web maintenance request processed.
If the system generates an email notification (see Emails for E-Commerce Cancels), it writes a message such as one of the the following:
Ord Can Conf to user@example.com.
or
Ord Can Fail to user@example.com
You can review order history messages at the Display Order History Screen. The system assigns the default user ID, DEFAULTUSR, to the order history messages.
Work with Batch OM Transactions Screen
Purpose: Use this screen to review any errors that have resulted when customers attempt to cancel orders from the web storefront. Also, you can use this screen to delete error records once you have resolved the errors, as the system does not delete them automatically.
Fixing errors: You might choose to complete the requested transaction yourself; or you might need to contact the customer for further information if the desired transaction is not clear. However, you cannot edit and resubmit the cancellation requests through this menu option.
For more information: See E-Commerce Cancel Process.
How to display this screen: Enter WBOM in the Fast path field at the top of any menu, or select Work with Batch OM Transactions from a menu.
Field | Description |
---|---|
Order number |
An order that a customer has attempted to cancel from the web storefront. Numeric, 8 positions; optional. |
St# (Ship-to number) |
This number indicates the order ship-to address that the customer attempted to cancel. Numeric, 3 positions; optional. |
Activity |
The type of transaction that the customer attempted to perform. Valid values are:
This field is blank if the cancel request message from the web storefront did not specify a valid cancel type code. Display-only. |
Screen Option | Procedure |
---|---|
Delete a batch order maintenance error record |
Select Delete for an error record to delete it. The system does not delete errors automatically, so typically you will delete errors as you resolve them. |
Display a cancel request in error |
Select Display for an error record to display the header-level information for the cancel request. You advance to the Display Batch OM Transactions Screen (Header). If the request includes serious errors, you will not be able to review the error record; instead, the system displays a message such as the following: Order 5493-7 is invalid -- cannot display. Print list to see errors. |
Display the error message(s) for a cancel request |
Select Errors for an error record to review the error message(s) for the cancel request. You advance to the Display Batch OM Errors Screen. |
Advance to standard order inquiry |
Select Order Inquiry for an error record to advance to Order Inquiry Header Screen or the Order Inquiry Detail Screen for the related order, depending on the setting of the Default Version for Order Inquiry (C34) system control value. |
Print a listing of all batch order maintenance errors in your company |
Select Error List to print the E-Commerce Order Maintenance Errors Report, including all errors in your company. |
Display Batch OM Transactions Screen (Header)
Purpose: Use this screen to review the header-level information that was included in the cancel request from the web storefront that was in error, so that you can determine the transaction that the customer was attempting to process.
Note: If the request includes serious errors, you will not be able to review the error record; instead, the system displays a message such as the following: Order 5493-7 is invalid -- cannot display. Print list to see errors.
You can use the Display Batch OM Errors Screen to review the errors.
How to display this screen: Select Display for a cancellation error at the Work with Batch OM Transactions Screen.
Field | Description |
---|---|
Order number |
An order that a customer has attempted to cancel from the web storefront. The order ship-to address is separated from the order number by a hyphen. Order number: numeric, 8 positions; display-only. Ship-to number: numeric, 3 positions; display-only. |
Activity |
The type of transaction that the customer attempted to perform. Valid values are:
This field is blank if the cancel request message from the web storefront did not specify a valid cancel type. Display-only. |
Cancel reason |
The cancel reason code to use when cancelling the order. This information is included only for an order-level cancel request. You can download cancel reasons to the web storefront through the Downloading E-Commerce Static Tables (ESTF) menu option. Numeric, 2 positions; display-only. |
Screen Option | Procedure |
---|---|
Select a detail line transaction from the cancel request for review |
Select Details to advance to the Display Batch OM Transactions Screen (Detail) if the cancel request was a line cancel. |
Display the error message(s) for this cancel request |
Select Errors to advance to the Display Batch OM Errors Screen. |
Advance to standard order inquiry |
Select Order Inquiry for an error record to advance to Order Inquiry Header Screen or the Order Inquiry Detail Screen for the related order, depending on the setting of the Default Version for Order Inquiry (C34) system control value. |
Print a listing of the errors for this cancel request |
Select Error List to print the E-Commerce Order Maintenance Errors Report, including all errors for this cancel request only. |
Display Batch OM Transactions Screen (Detail)
Purpose: Use this screen to select a detail line for review if a cancel request in error included order line-level information. Line-level information could include either canceling a particular line or reducing the quantity.
If the request was to cancel the order, there will not be any detail information on this screen.
How to display this screen: Select Details at the Display Batch OM Transactions Screen (Header).
Field | Description |
---|---|
Order number |
An order that a customer has attempted to cancel from the web storefront. The order ship-to address is separated from the order number by a hyphen. Order number: numeric, 8 positions; display-only. Ship-to number: numeric, 3 positions; display-only. |
Action |
The action that the customer has attempted to perform against the order detail line. The only valid value is: Line cancellation = Reduce the quantity of the order detail line or cancel it entirely Display-only. |
Line number |
The order detail line number to be cancelled. Numeric, 3 positions; display-only. |
Cnr (Cancel reason code) |
The cancel reason code specified in the cancel request to describe why the customer wants to cancel or reduce the quantity of the order detail line. This information is included only for a detail-level cancel request. You can download cancel reasons to the web storefront through the Downloading E-Commerce Static Tables (ESTF) menu option. Numeric, 2 positions; display-only. |
Qty |
The quantity of the item that the customer has attempted to cancel. Numeric, 3 positions; display-only. |
Item |
The item that the customer has attempted to cancel. The system determines which item the customer has selected by the order detail line (when working with an existing order detail line) or the short SKU number (when adding a new item to the order). The short SKU number is stored in the SKU table. If the request does not specify a valid short SKU, the item and SKU information listed on this screen may be inconsistent; for example, even if the item code is valid, the SKU information may not represent a valid SKU for the item. Alphanumeric, 12 positions; display-only. |
SKU |
The item’s unique characteristics, such as its color and size. Alphanumeric, three 4-position fields; display-only. |
Screen Option | Procedure |
---|---|
Select a detail transaction in error to review |
Select Display Display Batch OM Detail Screen. |
Review header information for the maintenance or cancel request |
Select Header to advance to the Display Batch OM Transactions Screen (Header). |
Display the error message(s) for the maintenance or cancel request |
Select Errors to advance to the Display Batch OM Errors Screen. |
Advance to standard order inquiry |
Select Order Inquiry for an error record to advance to Order Inquiry Header Screen or the Order Inquiry Detail Screen for the related order, depending on the setting of the Default Version for Order Inquiry (C34) system control value. |
Print a listing of the errors for this maintenance or cancel request |
Select Error List to print the E-Commerce Order Maintenance Errors Report, including all errors for this cancel request only. |
Display Batch OM Detail Screen
Purpose: Use this screen to review detail information on a cancel line request from the web storefront that is in error.
How to display this screen: Select Display for a detail line at the Display Batch OM Transactions Screen (Detail).
Field | Description |
---|---|
Order number |
The order and line number that a customer has attempted to cancel from the web storefront. The order ship-to address is separated from the order number by a hyphen, and the order line number follows: order number - ship-to number - order line number Order number: numeric, 8 positions; display-only. Ship-to number: numeric, 3 positions; display-only. Order line number: numeric, 3 positions; display-only. |
Activity |
The action that the customer has attempted to perform against the order detail line. The only valid value is: Line cancellation = Reduce the quantity of the order detail line or cancel it entirely Display-only. |
Item/SKU |
The item that the customer has attempted to cancel. The system determines which item the customer has selected by the order detail line (when working with an existing order detail line) or the short SKU number (when adding a new item to the order). The short SKU number is stored in the SKU table. Alphanumeric, 12 positions; display-only. |
Quantity |
The quantity of the item that the customer has attempted to cancel. Numeric, 3 positions; display-only. |
Cancel reason |
The cancel reason code specified in the cancel request to describe why the customer wants to cancel or reduce the quantity of the order detail line. This information is included only for a detail-level cancel request. You can download cancel reasons to the web storefront through the Downloading E-Commerce Static Tables (ESTF) menu option. Numeric, 2 positions; display-only. |
Display Batch OM Errors Screen
Purpose: Use this screen to review the errors that have prevented a cancel request from being processed.
How to display this screen: Select Errors for an error record at the Work with Batch OM Transactions Screen, or select Errors at the Display Batch OM Transactions Screen (Header) or the Display Batch OM Transactions Screen (Detail).
Field | Description |
---|---|
Order number |
An order that a customer has attempted to cancel from the web storefront. The order ship-to number is separated from the order number by a hyphen. Order number: numeric, 8 positions; display-only. Ship-to number: numeric, 3 positions; display-only. |
Line number |
The order detail number associated with the error. This field is blank if the error is associated with header-level information, or if the system could not determine which line number was involved. Numeric, 3 positions; display-only. |
Error description |
The description of the error that prevented the cancel request from being processed. See Batch Order Cancel Errors. Alphanumeric, 25 positions; display-only. |
Notes |
For certain errors, this field displays the description of the error that prevented the maintenance or cancel request from being processed. If the error is the result of an item on the order that already existed and was not part of the maintenance or cancel request, the message is: Error from a line that was not maintained. |
Screen Option | Procedure |
---|---|
Print a listing of the errors for this cancel request |
Select Error List to print the E-Commerce Order Maintenance Errors Report, including all errors for this cancel request only. |
Batch Order Cancel Errors
Error Message | Occurs When: |
---|---|
Detail Errors |
|
Invalid Order Detail |
The order line number specified in the cancel request does not exist on the order. |
Line is not Open |
The order line has a status of X (closed). |
Pick Exists for Line |
There is currently a printed pick slip for the order line. |
Cpn Item Required |
The order line specified for cancellation is required for an order-level coupon. See Working with Coupon Promotions (WCPR) for more information on coupons. Note: Although the error is retained for review, the system does cancel the order line and does not automatically remove the coupon from the order. |
Order Tot < Cpn Requires |
The cancel request has reduced the order total below the minimum required for a coupon on the order. See Working with Coupon Promotions (WCPR) for more information on coupons. Note:
|
Invalid Transactions |
The cancel type is missing or invalid. |
Header Errors |
|
Order Has Picks Open |
Any order detail lines on the order have pick slips printed or are assigned to the Order Broker for fulfillment. |
Order In Use |
The order is locked from update because a user is maintaining it, or another process on the system is updating it. Use Unlocking a Stranded Order or Batch (MULO) to unlock the order. |
Order Not Open or Held |
The order status is not open (blank) or held (H). |
Invalid Cancel Quantity |
The quantity specified in the cancel request exceeds the quantity eligible for cancellation for the order detail line. |
Invalid Cancel Reason |
The cancel reason is not valid, as defined through Establishing Cancel Reason Codes (WCNR). |
Invalid Order Ship To |
|
Downloading E-Commerce Static Tables (ESTF)
Purpose: Use the Download E-Commerce Static Tables option to download information that does not change frequently to the web storefront. The information is actually extracted to staging tables on your system; from there, it is available for download to the storefront.
The static information download includes:
-
company
-
SKU heading descriptions
-
countries
-
states
-
pay types
-
special handling format, details and responses
-
shipping methods
-
SCF/ship via combinations
-
return reasons
-
cancel reasons
-
SCF/state combinations
-
promotions
-
coupon promotions
-
coupon restrictions, including coupon and item restriction types)
-
coupon requirements, including item, source, and offer requirements
You can download all static information at once, or selected types as needed.
Note:
-
The Get Orders from E-Commerce (G35) system control value must be selected in order for you to run the e-commerce static tables download.
-
Clear the records from each target table before running the extract to make sure that you capture the most up-to-date information from Order Management System, as the extract process does not always write updated information in the extract table if there is already an existing record.
In this topic:
E-Commerce Download Overview: Types of Downloads
To improve response time on the web storefront, you can download key information from Order Management System so that it is available to internet customers. As a result, only information related specifically to the customer's order, catalog request, or inquiry needs to be communicated interactively between Order Management System and the web storefront. The information requiring download falls into three main groups:
-
Static: information such as company, payment or shipping methods, or states, rarely requiring update. You use the Download E-Commerce Static Tables option, described in this topic.
-
Frequent: information, such as item availability levels, that may require update. See the periodic functions described below.
Periodic Functions Related to E-Commerce
Download Process
Item long SKU style number: ECOMINV (program name ECR0389) and ECOMNEW (program name ECR0390). ECOMINV extracts all items that contain a long SKU style number to the EC SKU Retail Xref table and EComm SKU Extract table. ECOMNEW extracts new items that contain a long SKU style number to the EC SKU Retail Xref table and EComm SKU Extract table
For each of the e-commerce-related downloads, the system adjusts the records for null values (a formatting requirement for the web database).
Typically, the services on the web storefront that import information clear the records out of the extract tables.
Deleting information: There is no way to have information that you delete in Order Management System be automatically deleted on the web storefront as well. You must delete any unneeded information separately in Order Management System and on the web storefront once it has been downloaded. However, you can remove offers, items, and SKUs from the two e-commerce trigger tables to prevent future updates from being downloaded automatically.
For more information: On mapping of Order Management System tables and fields to the web storefront schema: see the Order Management System E-Commerce Integration manual.
Process E-Commerce Downloads Screen
How to display this screen: Enter ESTF in the Fast path field at the top of any menu, or select Download E-Commerce Static Tables from a menu.
All records in each related table for your company will be selected for download, unless noted otherwise in the field descriptions below.
Note:
The Get Orders from E-Commerce (G35) system control value must be selected in order for you to run the e-commerce static tables download.
Field | Description |
---|---|
Country |
Select this field to extract information from the Country table to the staging table; otherwise, deselect this field. See Setting Up the Country Table (WCTY) for more information. |
State |
Select this field to extract information from the State table to the staging table; otherwise, deselect this field. See Setting Up the Country Table (WCTY) for more information. |
Payment type |
Select this field to extract credit card payment types (payment category 2) to the EC Payment Type table; otherwise, deselect this field. You can use this information on the web storefront to enable customers to select a valid payment method. If the Download Prepaid Payment Types to E-Commerce (I69) system control value is selected, the system also extracts prepaid payment types (payment category 1 cash/check) to the EC Payment Type table. See Working with Pay Types (WPAY) for more information on setting up pay types. |
Personalization |
Select this field to extract custom special handling information to the staging table; otherwise, deselect this field. The information that is downloaded includes special handling formats (both active and inactive), and their related details and valid responses, so that customer can specify special handling options on the web storefront. See Establishing Custom Special Handling Formats (WSHF) for more information. |
SCF/ship via |
Select this field to extract information from the SCF/Ship Via table to the staging table; otherwise, deselect this field. This information is used to validate that the shipper selected for an order entered on the web storefront is valid for the destination address. SCF/ship via combinations for express-bill ship vias are not included in the download. Only SCF/ship via combinations for valid e-commerce ship vias will be included in the download. A ship via is a valid e-commerce shipper only if the Download to E-Commerce field at the Create Ship Via (1 of 2) Screen or the Change Ship Via (1 of 2) screen is set to selected. See Working with Ship Via Codes (WVIA) for more information on setting up ship via codes, and see Working with SCF/Ship Via Values (WSHV) for more information on SCF/ship via combinations. |
Shipping method |
Select this field to extract information from the Ship Via table to the staging table; otherwise, deselect this field. You can use this list of shippers to enable customers to select a shipment method at the web storefront. Express-bill ship vias (the Billing code field is set to Express Bill) are excluded from the download. To exclude certain ship vias from the download, you can deselect the Download to E-Commerce field at the Create Ship Via (1 of 2) Screen or the Change Ship Via (1 of 2) screen is set to selected. See Working with Ship Via Codes (WVIA) for more information on setting up ship via codes. |
Holiday dates |
Leave this field unselected. |
Return reasons |
Select this field to extract information from the Return Reason table to the staging table; otherwise, deselect this field. This information is used if you enable customers to create return authorizations at the web storefront. See Establishing Return Reason Codes (WRTR) for more information on setting up return reasons, or see Introducing Return Authorizations (WRTA) for an overview on return authorizations. |
Cancel reasons |
Select this field to extract information from the Cancel Reason table to the staging table; otherwise, deselect this field. This information is used if you enable customers to cancel orders at the web storefront. See Working with Batch Order Maintenance Transactions (WBOM) for more information on processing cancellations from the web storefront, or see Establishing Cancel Reason Codes (WCNR) for more information on setting up cancel reasons. Note: Only cancel reason codes whose Reduce demand fields are unselected are selected for download. |
SCF/State |
Select this field to extract information from the SCF table and SCF Extended table to the staging table; otherwise, deselect this field. This information is used to validate that the state selected for a customer’s address entered on the web storefront is valid for the destination address. See Working with SCF Codes (WSCF) for more information on SCF/state combinations. |
Promotions |
Select this field to extract information from the Promotions table to the staging table; otherwise, deselect this field. This information is available to validate a promotion code entered on the web storefront, typically if entry of a promotion code is required based on the Allow Manual Entry of Promotion Code (I63)Allow Manual Entry of Promotion Code system control value. If the system control value is unselected, the system applies eligible promotions automatically to the order. See Working with Promotions (WPRO) for more information on promotions. |
Coupon promotions |
Select this field to extract information from the Coupon Promotion table to the staging table; otherwise, deselect this field. This information is available to validate each coupon promotion that you use to offer percentage or dollar discounts to customers on the web storefront. See Working with Coupon Promotions (WCPR) for more information on coupon promotions. |
Coupon restrictions: coupon |
Select this field to extract information from the Coupon Restrictions table to the staging table; otherwise, deselect this field. This information is available to prevent customers on the web storefront from using two coupons whose use on the same order is restricted. See the Work with Coupon Restriction Screen for more information on coupon restrictions. |
Coupon restrictions: item |
Select this field to extract information from the Coupon Item Restriction table to the staging table; otherwise, deselect this field. This information is available to prevent customers on the web storefront from applying a percentage coupon discounts against restricted items. See the Work with Coupon Item Restriction Screen for more information on coupon item restrictions. |
Coupon requirements: item |
Select this field to extract information from the Coupon Item table to the staging table; otherwise, deselect this field. This information is available to validate that customers on the web storefront include any required item(s) on an order when they use coupons with an item requirement. See the Work with Coupon Item Requirement Screen for more information on coupon item requirements. |
Coupon requirements: source |
Select this field to extract information from the Coupon Source Requirement table to the staging table; otherwise, deselect this field. This information is available to validate that customers on the web storefront are using the correct source code on an order when they use coupons with a source requirement. See the Work with Coupon Source Requirement Screen for more information on coupon source requirements. |
Coupon requirements: offer |
Select this field to extract information from the Coupon Offer Requirement table to the staging table; otherwise, deselect this field. This information is available to validate that customers on the web storefront are using the correct offer on an order when they use coupons with an offer requirement. See the Work with Coupon Offer Requirement Screen for more information on coupon offer requirements. |
Instructions:
-
Deselect any field not required for download.
-
2Select OK. The system submits the job ECOMM_LOAD, which downloads the selected information to the extract tables. See Static Table Download Summary for a detailed list of download information.
Static Table Download Summary
Purpose: This table provides a summary of the tables and fields included in the static table download, and how they map to the e-commerce staging tables.
Order Management System Table | Select at Process E-Commerce Download Screen | Staging Table | Additional Information |
---|---|---|---|
Company (MSCOMP) |
Any selection |
EC Company (EXCOMP) |
Also triggers download of split SKU information from the System Control table as follows: Split SKU Element Column Headings (A52, A53, A54) SKU Element Description 1 (G37) SKU Element Description 2 (G38) |
Country (MSCNTY) |
Country |
EC Country (EXCNTY) |
|
State (MSSTAT) |
State |
EC State (EXSTAT) |
|
Pay Type (OEPAYT) |
Payment type |
EC Pay Type (EXPAYT) |
The system only includes pay types defined as payment category 2 (credit card) for download. If the Download Prepaid Payment Types to E-Commerce (I69) system control value is selected, the system also includes prepaid pay types defined as payment category 1 (cash/check) for download. |
Promotions (OEPROM) |
Promotions |
EC Promotions Extract (ECPROX) |
Typically used only if the Allow Manual Entry of Promotion Code (I63) system control value is selected. See Working with Promotions (WPRO) for more information on promotions. |
Special Format (MSSHFD) |
Personalization |
EC Personalization (EXPERS) |
Both active and inactive formats are selected for download |
Special Format Details (MSSFDT) |
Personalization |
EC Personalization Details (EXPRSD) |
|
Special Format Responses (MSSFVR) |
Personalization |
EC Personalization Values (EXPRSV) |
|
SCF Ship Via (SCFVIA) |
SCF/Ship Via |
EC SCF/Ship Via (EXSCFS) |
|
Ship Via (MSSHPV) |
Shipping method |
EC Shipping Method (EXSHIP) |
|
E-Comm Holiday Arrival Date (ECHOLI) |
Holiday dates |
EC Holiday Arrival Date (EXHOLI) |
Not currently implemented. |
Return Reason (OERTRS) |
Return reasons |
EC Return Reason (EXRTRS) |
See Establishing Return Reason Codes (WRTR) and Introducing Return Authorizations (WRTA). |
Cancel Reason (CSCANR) |
Cancel reasons |
EC Cancel Reason (EXCNRS) |
See Working with Batch Order Maintenance Transactions (WBOM) and Establishing Cancel Reason Codes (WCNR). |
SCF (MSSCF), SCF Extended (MSSCFE) |
SCF/State |
EC SCF State (EXSCST) |
|
Coupon Promotions (OECPCP) |
Coupon Promotions |
EC Coupon Promotions (EXCPCP) |
|
Coupon Restrictions (OECPCR) |
Coupon Restrictions: Coupon |
EC Coupon Restrictions (EXCPCR) |
|
Coupon Item Restrictions (OECPIR) |
Coupon Restrictions: Item |
EC Coupon Item Restrictions (EXCPIR) |
|
Coupon Item (OECPIT) |
Coupon Requirements: Item |
EC Coupon Item (EXCPIT) |
|
Coupon Source Code Requirement (OECPSR) |
Coupon Requirements: Source |
EC Coupon Source Requirement (EXCPSR) |
|
Coupon Offer Requirement (OECPOR) |
Coupon Requirements: Offer |
EC Coupon Offer Requirement (EXCPOR) |
Downloading E-Commerce Offer Files (EOFR)
Purpose: Use the Download E-Commerce Offer Files menu option to select offer, source, and item-related information for download to the web storefront. Typically, this type of information changes periodically.
You can download all three types of information at once, or selected types as needed.
Type of download: The setting of the Generate E-Commerce Offer Tables (M29) system control value defines the output of the e-commerce offer download.
-
If this system control value is selected, the e-commerce offer download (EOFR) populates the E-Commerce Offer Staging tables; see Offer-Related Table Extract Summary.
-
If this system control value is unselected, the e-commerce offer download (EOFR) generates the E-Commerce Product Web XML File (ProductWeb).
File storage API exports enabled? If the Generate E-Commerce Offer Tables (M29) system control value is unselected and the FILE_STORAGE_EXPORTS_ENABLED property is set to true, the e-commerce offer download creates a zip file in the OMS-ECOMMERCE container of the FILE_STORAGE table. The zip file contains the E-Commerce Product Web XML File (ProductWeb). You can use the file storage API to download the file. See the File Storage API for background. Otherwise, if the file storage API is not enabled for exports, the file is created in the ECOMMERCE_DIRECTORY_PATH in Working with Admin Properties (CPRP) defines the location on the application server where the system downloads the E-Commerce Product Web XML file.
Additional downloads: Other downloads available for the e-commerce interface are:
-
static tables
-
item availability and item changes
For more information: See:
-
Downloading E-Commerce Static Tables (ESTF) for an overview of the download process related to the e-commerce interface, including the additional downloads.
-
the E-Commerce Integration Manual for information on the storefront database schema.
In this topic:
Process E-Commerce Downloads Screen
How to display this screen: Enter EOFR in the Fast path field at the top of any menu, or select Download E-Commerce Offer Tables from a menu.
Note:
All records in each related table for your company will be selected for download, unless noted otherwise in the field descriptions.
Field | Description |
---|---|
Offers |
Indicates whether to include the selected offer information in the e-commerce offer download for subsequent transfer to the web storefront. Only the offer(s) you enter at this screen will be included. Valid values are: Selected (default) = download the selected offer(s). Unselected = do not download the offer(s). |
Sources |
Indicates whether to include source codes associated with the selected offer in the e-commerce offer download for subsequent transfer to the web storefront. Only source codes associated with the offer you enter at the From offer field will be included. Valid values are: Selected (default) = include source codes associated with the selected offer. Unselected = do not include source codes. |
All items |
Indicates whether to include all items, SKUs, and all other related offer information in the e-commerce offer download for subsequent transfer to the web storefront. All items related to the offer(s) you enter at this screen will be included. Valid values are: Selected (default) = include item-related information for all items associated with the selected offer(s). Unselected = do not include item-related information for all items. Select either this field or the New items field, but not both. If you select both fields, the following message displays: Either All Items or New Items can be processed but not both. |
New items |
Indicates whether to include only new items in the e-commerce offer download for subsequent transfer to the web storefront. Only items related to the offer(s) you enter at this screen and which have not previously been extracted will be selected. Valid values are: Selected = The e-commerce offer download includes item-related information for only new items associated with the selected offer(s); only items which have not been previously extracted are included in the download. When you submit the download, the system updates the Ecommerce Extract Date field in the Item Offer table with the date of the extract; the system uses this field to determine whether the item has previously been included in an e-commerce offer download. Unselected (default) = do restrict extract of item-related information to only new items. Select either this field or the All items field, but not both. If you select both fields, the following message displays: Either All Items or New Items can be processed but not both. |
Future prices |
Indicates whether to include the latest future price for an item or SKU in the selected offer(s), or the most current price that is not in the future. Valid values are: Selected = include the latest future prices for items and SKUs in the selected offer(s). Future prices are those whose Effective dates are later than the current date. If there are no future prices for an item or SKU, the job includes the latest current price (the most current price whose Effective date is not in the future). Unselected (default) = include the most current price for items and SKUs in the selected offer(s), as long as the prices’ Effective dates are not later than the current date. If there are no prices for an item or SKU except for future prices, the job does not include the item or SKU in the extract. |
All SKU offers |
Indicates whether to include all SKU Offers and SKU Prices, regardless of whether they are different from the Item offer and Item Price. Valid values are: Selected = include all existing SKU Offer and SKU Price information, even if it is identical to the corresponding Item Offer and Item Price information. Unselected (default) = include SKU Offer and SKU Price information only if it differs from the Item Offer and Item Price information:
Note: The SKU Price is included only if the regular price differs from the Item Price. If the Associate price alone differs, then the SKU Price record is not selected for extract.
|
Offer |
Enter one or more offers to download to the web storefront. As you enter each offer, its description, start date, and end date are displayed below. You must specify at least one offer. Only the offer(s) you enter and tables associated with the selected offer(s) will be included in the extract. Offer codes are defined in and validated against the Offer table. See Working with Offers (WOFR). Alphanumeric, 3 positions; required. |
Description |
The description of an offer you have specified for download to the web storefront. Alphanumeric, 30 positions; display-only. |
Start date |
The first date when the selected offer is effective for processing orders. From the Offer date range specified for the offer. Numeric, 6 positions (in user date format); display-only. |
End date |
The last date when the selected offer is effective for processing orders. From the Offer date range specified for the offer. Numeric, 6 positions (in user date format); display-only. |
Instructions:
# | Step |
---|---|
1. |
Optionally reset any of the fields to exclude related information from selection. Note: Select either the All items field or the New items field. You cannot select both fields. |
2. |
Use the Offer field to specify at least one offer to include in the extract. The system validates each entry, and displays the offer’s description and effective dates below after each. |
3. |
Select OK. The system validates your entries and highlights any fields you need to correct. Correct any fields and select OK again. |
4. |
Select Submit to submit the extract. The system displays the following message: E-Commerce download submitted to batch. Also, the system submits the job ECOMM_OFR, which extracts the selected information for download. |
5. |
The setting of the Generate E-Commerce Offer Tables (M29) system control value defines the output of the e-commerce offer download.
|
Offer-Related Table Extract Summary
Purpose: This table provides a summary of the tables and fields included in the offer table extract, and how they map to the e-commerce staging tables. The system populates these tables when you submit the e-commerce offer download and the Generate E-Commerce Offer Tables (M29) system control value is selected.
Information included: The e-commerce offer download adds new information to the staging tables if the tables have not been cleared since the last download; it does not update records once they are extracted to the staging tables. However, once the records are downloaded to the web storefront and cleared from the staging tables, changes to existing records are eligible to be extracted to the staging tables and passed to the storefront.
Removing items and offers:
All SKUs included? SKU-level information is included in the extract only if there is a SKU Offer and SKU Price record. For example, you can use the Creating Item/SKU Offers (MISO) menu option to create SKU Offers and SKU Prices for an item when you add it to a new offer. SKU-level offer and price information is included in the extract if you select the All SKU offers option when generating the extract; otherwise, SKU Offers are included only when they differ from the item-level information, such as a special handling or price that differs from the Item Offer or Item Price setting.
Future prices? The Future prices field on the Process E-Commerce Downloads screen controls whether to download the most current prices whose Effective dates are not in the future, or the latest prices whose Effective dates are later than the current date. If you would like to download both current and future prices, you can run the download job twice, resetting this field as needed.
Example: AB100 BLUE LRGE has the following prices set up for the selected offer(s):
Date | Quantity | Price |
---|---|---|
1/1 |
1 |
10.00 |
1/1 |
5 |
9.00 |
1/10 |
1 |
10.50 |
2/1 |
1 |
8.50 |
2/1 |
5 |
7.50 |
3/1 |
1 |
7.00 |
3/1 |
5 |
6.99 |
1. The current date is 1/15. If you run the extract job with the Future prices field unselected, the job selects the following prices: |
||
1/1 |
5 |
9.00 (most recent price for this quantity not greater than current date) |
1/10 |
1 |
10.50 (most recent price for this quantity not greater than the current date) |
2. The current date is 1/15. If you run the extract job with the Future prices field selected, the job selects the following prices: |
||
3/1 |
1 |
7.00 (latest future price for this quantity) |
3/1 |
5 |
6.99 (latest future price for this quantity) |
Note:
-
Item or SKU prices are included in the following extract tables (see Offer-Related Table Extract Summary for more information):
-
EC Item Breakpoint (EXIPRC): includes single-unit and multi-unit prices at the item level
-
EC Offer Item Link (EXIOFL): includes single-unit prices at the item level
-
EC Offer SKU Link (EXSOFL): includes single-unit prices at the SKU level
-
EC SKU Breakpoint (EXSPRC): includes single-unit and multi-unit prices at the SKU level
-
-
If you run the extract job with the Future prices field selected, but there is no future price for the item or SKU, the job extracts the most recent price instead.
-
If you run the extract job with the Future prices field unselected, but there is no current price for an item or SKU and just a future price, the extract omits the item or SKU prices from the extract, with the exception of the EC Offer Item Link table; this table includes a record for the item with a price of 0.
Note:
Clear the records from each target table before running the extract to make sure that you capture the most up-to-date information from Order Management System, as the extract process does not always write updated information in the extract table if there is already an existing record.
Selection for download: All item-related information (such as hazard codes and e-commerce categories) are selected for download only if they are assigned to items that are selected for download.
OROMS Table | Staging Table | Fields | Additional Information |
---|---|---|---|
If you select the Offer field at the Process E-Commerce Downloads screen: |
|||
Offer (MSOFFR) |
EC Offer (EXOFFR) |
Company code Offer code Description Start date End date |
Only the offer(s) you indicate at the screen is/are selected. |
If you select the Sources field at the Process E-Commerce Downloads screen: |
|||
Source (MSSRC) |
EC Source (EXSRCE) |
Company code Source code Source code description Discount percentage Offer |
|
If you select the Items or New Items field at the Process E-Commerce Downloads screen: |
|||
Long SKU Class (INLSKC) OR Retail Class (INRTCP) |
EC Class (EXCLAS) |
Company code Long SKU department code Long SKU class code Long SKU class description |
A long SKU class is selected for download only if it is assigned to an item selected for download, and the item is also assigned a long SKU department. The same long SKU class can be downloaded multiple times, if it is paired with different long SKU departments. See Working with Long SKU Classes (WLSC). Note: If you select the Use Retail Integration (H26) system control value, the interface uses the Retail Class table to populate the EC Class table. |
Item Coordinate (INITCO) |
EC Cross-Sell (EXCSEL) |
Company code Item code Cross-sell item code Cross-sell description Coordinate sequence Coordinate type |
An item coordinate is selected for download only if the primary item (Note: not necessarily the coordinate item) is selected for download. Also, only the first 50 positions of the item coordinate description (a 70-position field) is included in the Cross-sell description. |
Long SKU Department (INLSKD) |
EC Department (EXDEPT) |
Company code Long SKU department code Long SKU department description |
|
Shipper/Item (OESHIM) |
EC Extra Shipping (EXSCIT) |
Company code Ship via code Item code Extra shipping charge |
|
Hazard (INHZRD) |
EC Hazard (EXHAZA) |
Company code Hazard code Hazard description |
|
Item (INITEM) |
EC Item (EXITEM) |
Company code Item code Item description Height Length Width Selling quantity Shipping weight Unit of measure code Vendor number Second language description SKU? (0=N, 1=Y) Active on web? (0=N, 1=Y) Long SKU department Long SKU class Long SKU category Hazard code User fields 1 through 4 Status |
Each non-SKU’d item associated with a selected offer(s) (that is, there is an item/offer assignment) is selected for download. SKU’d items are also included in the selection if they have item/offer assignments. See the Create Item Screen for field descriptions. Note: The Active on web? flag is not currently used. |
Item Offer (INIOFR) |
EC Item (EXITEM) |
Allow gift wrap? (0=N, 1=Y) |
See the Create Item Offer Screen. |
SKU (INSKU) |
EC Item (EXITEM) |
List price |
The Original price in the EC Item table is from the highest List price for all SKUs. |
Item Price (INIPRC) |
EC Item Breakpoint (EXIPRC) |
Company code Offer code Item code Breakpoint quantity Price |
You set up a price breakpoint for a quantity of 1 when you create an item/offer assignment and specify a price. You can also specify additional price breakpoints for larger quantities. The extract includes the latest current or future price (based on the Future prices field), for each item-level quantity breakpoint. See:
Assigning Items/SKUs to Offers for information on working with item/offer assignment, including working with quantity price breaks |
Item Offer (INIOFR) |
EC Offer Item Link (EXIOFL) |
Company code Offer code Item code Price (single unit) Special handling price Item alias Gift wrap price Custom special handling format code |
The extract includes the latest current or future price (based on the Future prices field), for each single-unit item-level price. See:
|
SKU Offer (INSKOF) |
EC Offer SKU Link (EXSOFL) |
Company code Offer code Item code Short SKU Price (single-unit) Special handling price Gift wrap price Custom special handling format code |
A SKU/offer is selected for download only if the special handling or gift wrap information differs from the item/offer, or if you select the All SKU offers option when generating the extract. The extract includes the latest current or future price (based on the Future prices field), for each single-unit SKU-level price. See:
Note: The Short SKU is stored in the SKU table and is a 7-position number used to identify SKUs and items. You can view the short SKU on display screens in Work with Items (MITM) and Inventory Inquiry (DINI). See Create Item (Base Information) Screen. |
SKU (INSKU) |
EC SKU (EXSKU) |
Company code Item code Short SKU (assigned by the system at SKU creation) SKU code SKU description SKU element 1 through 3 SKU element 1 through 3 description Restrict orders? (0=N, 1=Y) User fields 1 through 5 Soldout control code Status UPC codes (first two) |
A SKU is selected for download only if it has a SKU/offer selected for download (because it differs from the item/offer, as described above). Non-SKU’d items are also selected for download in this table. Note: The Short SKU is stored in the SKU table and is a 7-position number used to identify SKUs and items. You can view the short SKU on display screens in Work with Items (MITM) and Inventory Inquiry (DINI). See the Create Item (Base Information) Screen or the Create SKU 1 of 2 (With Overrides) Screen and the Create SKU 2 of 2 (With Overrides) Screen. |
SKU Price (INSPRC) |
EC SKU Breakpoint (EXSPRC) |
Company code Offer code Item code Short SKU (assigned by the system at SKU creation) Breakpoint quantity Price |
A SKU price is selected for download only if the SKU-level offer price differs from the Item Offer price, or if you select the All SKU offers option when generating the extract). The extract includes the latest current or future price (based on the Future prices field), for each SKU-level quantity breakpoint. See:
Assigning Items/SKUs to Offers for information on working with item/offer assignment, including working with quantity price breaks |
Keyword (INKWDP) |
EC Keyword (EXKEYW) |
Company code Item code Keyword |
|
Page Letter Alias (INPLAL) |
EC Alias Item (EXITMA) |
Company code Item code Offer Alias item |
Order Management System includes all item aliases for an item for the offer selected in the e-commerce download. |
Item Ship Via Override (INISVO) |
EC Item Ship Via Override (EXISVO) |
Company code Item number Shipping code |
Order Management System only populates this table if records exist in the Item Ship Via Override table for an item. See Working with Item Ship Via Overrides. |
E-Commerce Product Web XML File (ProductWeb)
Purpose: The E-Commerce Product Web XML file (ProductWeb) contains item offer information for the offers selected to download on the Process E-Commerce Downloads Screen. The system generates this file when Downloading E-Commerce Offer Files (EOFR) if the Generate E-Commerce Offer Tables (M29) system control value is unselected.Depending on whether the file storage API is enabled for exports:
-
If file storage API exports enabled: If the FILE_STORAGE_EXPORTS_ENABLED property is set to true, the e-commerce offer download creates a zip file in the OMS-ECOMMERCE container of the FILE_STORAGE table. The zip file contains the E-Commerce Product Web XML File (ProductWeb). You can use the file storage API to download the file. See the File Storage API for background.
-
If file storage API exports not enabled: Otherwise, if the file storage API is not enabled for exports, the file is created in the ECOMMERCE_DIRECTORY_PATH in Working with Admin Properties (CPRP) defines the location on the application server where the system downloads the E-Commerce Product Web XML file. An example of the directory is /domain/conf/OMSFiles/WebData/, where domain is the WebLogic domain directory for Order Management System. Note: If an ECOMMERCE_DIRECTORY_PATH is not valid or is blank, or the specified folder does not exist, the system does not generate the ProductWeb file and writes an error message to the Application log.
Name of file: The name of the file is ProductWeb_999_YYMMDDHHMMSS.xml, where 999 is the company code where you submitted the e-commerce offer download and YYMMDDHHMMSS is the date and time when the download occurred. When the file storage API is enabled, the file is saved in a zip file with the same name except for the .zip extension.
XML version: The ECOMMERCE_PRODUCT_XML_VERSION in Working with Customer Properties (PROP) defines the XML version of the ProductWeb XML file.
ECommerce extract date:For each item offer included in the ProductWeb XML file, the system updates the ECommerce Extract Date field in the Item Offer table with the date when the e-commerce offer download was submitted. The system uses this date if you select to include only new items in the e-commerce offer download to determine which items are new and which items have previously been downloaded.
Application log: The system writes any messages related to the e-commerce offer download to the Application Log.
Active procedure: The system creates an active procedure while the ProductWeb file is generated; once the e-commerce offer download process completes, the system clears the active procedure.
Sample message: See Sample E-Commerce Product Web XML Message (ProductWeb) for a sample message.
Note:
The system includes all tags in the file, even if the tag is blank.
Attribute Name | Type | Length | Comments |
---|---|---|---|
Header |
|||
CompanyCode |
numeric |
3 |
The code for the company where the e-commerce download was submitted. |
Offer |
The offers selected to download on the Process E-Commerce Downloads Screen. |
||
Offer |
alpha |
3 |
A code for the offer included in the e-commerce download. From Offer Number in the Offer table. |
OfferDescription |
alpha |
30 |
A description of the offer. From Offer Description in the Offer table. |
Currency |
alpha |
3 |
The currency for orders you process for this offer. From Ofr Currency Code in the Offer table. |
StartDate |
numeric |
8 |
The start date, in MMDDYYYY format, for the prices you define for this offer. Orders entered prior to the start date and after the end date will not use these prices. From Start Date in the Offer table. |
EndDate |
numeric |
8 |
The end date, in MMDDYYYY format, for the prices you define for this offer. Orders entered prior to the start date and after the end date will not use these prices. From Offer Stop Date in the Offer table. |
SourceCode |
The source codes selected to download on the Process E-Commerce Downloads Screen. |
||
SourceCode |
alpha |
9 |
The source code associated with the offer. From Src Source Code in the Source table. |
SrcDescription |
alpha |
30 |
A description of the source code. From Src Description in the Source table. |
DisPercentage |
numeric |
5.2 |
A discount for orders assigned to this source code. This discount does not apply to orders with a Use Item Cost, No Charge, or No Charge/No Cost pricing method, or to order lines with a price override reason code applied. This discount is applied in addition to any discounts resulting from other pricing methods. The discount is calculated during Order Entry or Order Maintenance. This discount applies only to items with a Y in the Discountable field in the Item or SKU table. From Src Discount in the Source table. |
Offer |
alpha |
3 |
A code for the offer associated with the source code. From Offer Number in the Source table. |
Item |
The items defined for the offer.
|
||
ItemNumber |
alpha |
12 |
A code for an item defined in the offer. From Itm Number in the Item table. |
Description |
alpha |
40 |
A description of the item. From Description in the Item table. |
AllowSKUs |
alpha |
1 |
Indicates whether the item is available in various styles, such as color, size, etc. Valid values are: Y = This item has SKUs associated with it. N = There are no SKUs associated with this item. From Allow SKUs in the Item table. |
Height |
numeric |
3 |
The height measurement for an item. The Height, Length, and Width values determine the cubic volume of an item. From Item Height in the Item table. |
Length |
numeric |
3 |
The length measurement for an item. The Height, Length, and Width values determine the cubic volume of an item. From Item Length in the Item table. |
Width |
numeric |
3 |
The width measurement for an item. The Height, Length, and Width values determine the cubic volume of an item. From Width in the Item table. |
SellQty |
numeric |
5 |
The selling quantity defines the required order quantity (or multiple of) for this item. For example, an item may be stocked in single units, but must be sold in quantities of 6 (or 12, or 18, etc.). From Selling Qty in the Item table. |
ShipWeight |
numeric |
7.3 |
The actual shipping weight of the item. From Ship Weight in the Item table. |
UnitOfMeasure |
alpha |
3 |
A standard by which an item is sold. Typical units of measure include:
From Unit Of Measure in the Item table. |
VendorNumber |
numeric |
7 |
A user-defined code that represents the vendor or supplier of an item. From Vendor # in the Item table. |
DescSecondLanguage |
alpha |
40 |
From Itm Second Language Desc in the Item table. |
Department |
numeric |
4 |
A code used to group items into departments for reporting purposes. From LSD Department in the Item table. |
DepartmentDesc |
alpha |
30 |
A description of the long SKU department. From Description in the Long SKU Department table. |
Class |
numeric |
4 |
A code you can use to group items into classes for reporting purposes. From Item Class in the Item table. |
ClassDesc |
alpha |
30 |
A description of the item class. From Item Class Description in the Item Class table. |
HazardCode |
numeric |
2 |
A code used to categorize the item as a hazardous material that requires special storage and handling. From Haz Code in the Item table. |
HazardDesc |
alpha |
40 |
A description of the hazard code. From Description in the Hazard table. |
ItemStatus |
alpha |
1 |
A code that represents an item’s status, such as discontinued or active. From Item Status in the Item table. |
Discountable |
alpha |
1 |
Determines whether the item is eligible for a discount percent during order entry. Y = The item is eligible for a percent discount. N = The item is not eligible for a percent discount. From the Itm Allow P Discount field in the Item table. |
NonInventory |
alpha |
1 |
Indicates whether inventory levels are maintained for the item. Valid values are: Y = This is a non-inventory item. N = This is a regular item that will be tracked. From Non-inventory in the Item table. |
SVCType |
alpha |
1 |
A code that indicates the item is a stored value card, and whether the stored value card is a physical or virtual card. blank = The item is not a stored value card. P = The item is a physical stored value card. E = The item is a physical stored value card and, as soon as the stored value card is processed through billing, the system sends an email notification to the recipient card holder, notifying the customer that a stored value card has been purchased and is in the process of being delivered. V = The item is a virtual (non-physical) stored value card. From Itm SVC Type in the Item table. |
DropShip |
alpha |
1 |
Indicates whether you ship the item from your warehouse, or have your vendor ship it to the customer directly. Y (drop ship) = When a customer orders the item, you order the item from your vendor and the vendor ships it directly to your customer. N (non-drop ship) = You ship the item from your warehouse. From Drop Ship Item in the Item table. |
Oversize |
alpha |
1 |
Determines whether the item is considered an oversized item. Y = The item is oversized. N = The item is not oversized. From Itm Oversize Flag in the Item table. |
ShipAlone |
alpha |
1 |
Indicates how to ship the item. S = The item must ship by itself, and each unit prints on its own pick slip. blank = The item can ship with other items. From Ship Alone in the Item table. |
Set |
alpha |
1 |
Indicates whether the item is a set item. Y = the item is a set item (the Kit type for the item is Set). N = the item is not a set item. From Kit type in the Item table. |
OROBEligible |
alpha |
1 |
Y = Include this item when you send item and inventory information to Oracle Retail Order Broker; also, the item is eligible to be sent to the Order Broker on brokered backorders, store pickup, or ship-for-pickup orders. N = Do not include this item when you send item and inventory information to Oracle Retail Order Broker; also, the item is not eligible to be sent to the Order Broker on brokered backorders, store pickup, or ship-for-pickup orders. |
UserField1 |
alpha |
10 |
A user-defined field for the item. From User Field 1 in the Item table. |
UserField2 |
alpha |
10 |
A user-defined field for the item. From User Field 2 in the Item table. |
UserField3 |
alpha |
10 |
A user-defined field for the item. From User Field 3 in the Item table. |
UserField4 |
alpha |
10 |
A user-defined field for the item. From User Field 4 in the Item table. |
ItemOffer |
One or more offers is included for each item. |
||
ItemOffer |
alpha |
3 |
A code that represents the offer where the item is advertised. From Offer Number in the Item Offer table. |
ItemPrice |
numeric |
13.2 |
The standard price for the item in the offer. From Standard Price in the Item Offer table. |
EffectiveDate |
numeric |
7 |
The date the price becomes valid for the item offer, in MMDDYYYY format. From Effective Date in the Item Price table. |
GiftWrap |
alpha |
1 |
Indicates if gift wrapping is available for the item in the offer. Y = The item can be gift wrapped. N = The item cannot be gift wrapped in this offer. From Gift Wrap Flag in the Item Offer table. |
GiftWrapPrice |
numeric |
13.2 |
The price in the offer for gift wrapping the item. From Gift Wrap Price in the Item Offer table. |
PersonalizationPrice |
numeric |
13.2 |
The price to charge the customer for special handling. From S H Price in the Item Offer table. |
PersonalizationCode |
alpha |
1 |
Indicates if the item is eligible for special handling in the offer. Y = The item is eligible for special handling in the offer. N = The item is not eligible for special handling in the offer. From Special Handling in the Item Offer table. |
FreightExempt |
alpha |
1 |
Indicates whether the item is exempt from freight in this offer. Y = The item is exempt from freight; a record exists in the Freight Exempt file for this item and offer. N = The item is not exempt from freight in this offer. |
ItemPrice |
If Future prices is selected on the Process E-Commerce Downloads Screen, the system includes the most current item price for each quantity (price with an effective date equal to or earlier than the current date) and all future prices (prices with an effective date greater than the current date). If Future prices is unselected on the Process E-Commerce Downloads Screen, the system includes the most current price for each quantity (price with an effective date equal to or earlier than the current date). Example: An item contains the following prices: qty 1, 12/01/15, 90.00 (past price) qty 1, 12/08/15, 80.00 (most current price for a quantity of 1) qty 1, 12/10/15, 75.00 (future price) qty 2, 12/01/15, 80.00 (past price) qty 2, 12/08/15, 70.00 (mist current price for a quantity of 2) qty 2, 12/10/15, 65.00 (future price)
If Future prices is selected, the system includes the following prices: qty 1, 12/08/15, 80.00 (most current price for a quantity of 1) qty 1, 12/10/15, 75.00 (future price) qty 2, 12/08/15, 70.00 (mist current price for a quantity of 2) qty 2, 12/10/15, 65.00 (future price)
If Future prices is unselected, the system includes the following prices: qty 1, 12/08/15, 80.00 (most current price for a quantity of 1) qty 2, 12/08/15, 70.00 (mist current price for a quantity of 2) |
||
Qty |
numeric |
7 |
The quantity of the item that the customer must order to receive the price. From Qty in the Item Price table. |
Price |
numeric |
13.2 |
The price at which the item is sold. From Price in the Item Price table. |
EffectiveDate |
numeric |
8 |
The date, in MMDDYYYY format, the price or quantity break discount becomes valid. From Effective Date in the Item Price table. |
ItemAlias |
|||
AliasNumber |
alpha |
12 |
The alternate item code for the actual item. From ECA Alias Item in the EC Alias Item table. |
SKU |
At least one SKU element is included for each item since information is included at the SKU level even for non-SKUed items. |
||
ShortSKU |
numeric |
7 |
The short SKU number defined for the SKU, used to identify the SKU. From Short SKU in the SKU table. |
SKUCode |
alpha |
14 |
The SKU code for the item, such as style, color, and/or size. The system separates each SKU code with a single space, for example: RED SML WMNS. From SKU Code in the SKU table. |
SKUDescription |
alpha |
40 |
A description of the SKU. From Description in the SKU table. |
SKUElement1Code |
alpha |
4 |
A code representing a SKU element, such as blue (color) or small (size). From SEO Code in the SKU table. |
SKUElement1Desc |
alpha |
10 |
A description of the SKU element, such as navy blue. From Element 1 Desc in the SKU Element 1 table. |
SKUElement2Code |
alpha |
4 |
A code representing a SKU element, such as blue (color) or small (size). From SEW Code in the SKU table. |
SKUElement2Desc |
alpha |
10 |
A description of the SKU element, such as navy blue. From Element 2 Desc in the SKU Element 2 table. |
SKUElement3Code |
alpha |
4 |
A code representing a SKU element, such as blue (color) or small (size). From Set Code in the SKU table. |
SKUElement3Desc |
alpha |
10 |
A description of the SKU element, such as navy blue. From Element 3 Desc in the SKU Element 3 table. |
ItemSKU |
alpha |
27 |
The item number and SKU codes using the full field lengths, separated by a space. The system does not include any extra space at the end; for example, if the SKU code for item REGULAR is RED, the ItemSKU is REGULAR RED. Item number is 12 positions. SKU code is 14 positions. |
RestrictOrders |
alpha |
1 |
Defines whether you can accept an order for the SKU and whether demand is captured. Y = you cannot accept an order for the item/SKU. N or blank = you can accept an order for the item/SKU. From Restrict Orders in the SKU table. |
RetailReference |
numeric |
15 |
The retail reference number assigned to the SKU. From Retail Reference # in the SKU table. |
Category |
alpha |
4 |
A code assigned to the SKU to classify and group like items for use in item relationships and compatibility. From SKU ITC Category in the SKU table. |
SKUStatus |
alpha |
1 |
The status of the item, such as discontinued. From SKU IST Item Status in the SKU table. |
SoldOutCode |
alpha |
2 |
The soldout control code specified for the SKU. From SLC Code in the SKU table. |
SoldOutType |
alpha |
1 |
Indicates whether the system sells out the SKU immediately. 1 = Sell out immediately, regardless of available on-hand stock. 2 = Include on order quantity in the soldout calculation. 3 = Exclude on order quantity in the soldout calculation. From Status in the Soldout Control table. |
SKUCost |
numeric |
13.4 |
The cost of the SKU, based on the costing method defined in the Costing Method (A25) system control value. If set to STANDARD, from the SKU Standard Cost in the SKU table. If set to AVERAGE, from the SKU Average Cost in the SKU table. If set to FIFO, from the SKU FIFO Cost in the SKU table. |
SKUOriginalPrice |
numeric |
13.2 |
The original price for the SKU. From List Price in the SKU table. |
UserField1 |
alpha |
10 |
A user-defined field for the SKU. From User Field 1 in the SKU table. |
UserField2 |
alpha |
10 |
A user-defined field for the SKU. From User Field 2 in the SKU table. |
UserField3 |
alpha |
10 |
A user-defined field for the SKU. From User Field 3 in the SKU table. |
UserField4 |
alpha |
5 |
A user-defined field for the SKU. From User Field 4 in the SKU table. |
UserField5 |
alpha |
5 |
A user-defined field for the SKU. From User Field 5 in the SKU table. |
SKUOffer |
All SKU offers defined for the offers selected for e-commerce download are included, regardless of whether the information differs from the item offer or not. |
||
SKUOffer |
alpha |
3 |
A code that represents the offer where the SKU is advertised. From Offer Number in the SKU Offer table. |
SKUPrice |
numeric |
13.2 |
The price at which the SKU is sold in the offer. From Price in the SKU Price table. |
EffectiveDate |
numeric |
7 |
The date the price becomes valid, in MMDDYYYY format. From Effective Date in the SKU Price table. |
GiftWrap |
alpha |
1 |
Indicates if the SKU is eligible for gift wrap. Y = The SKU is eligible for gift wrap. N = The SKU is not eligible for gift wrap. From Gift Wrap Flag in the SKU Offer table. |
GiftWrapCost |
numeric |
13.2 |
The price for gift wrapping the SKU. From Gift Wrap Price in the SKU Offer table. |
PersonalizationPrice |
numeric |
13.2 |
The price to charge the customer for special handling. From S H Price in the SKU Offer table. |
PersonalizationCode |
alpha |
1 |
Indicates if the SKU is eligible for any type of special handling in the offer. Y = The SKU is eligible for special handling. N = The SKU is not eligible for special handling. From Special Handling Flag in the SKU Offer table. |
SKUPrice |
One or more SKU prices are included for each SKU offer. |
||
Qty |
numeric |
7 |
The quantity of the SKU the customer must order to receive the discounted price. From Qty in the SKU Price table. |
Price |
numeric |
13.2 |
The price at which the SKU is sold in the offer. From Price in the SKU Price table. |
EffectiveDate |
numeric |
7 |
The date the price or quantity break becomes valid, in MMDDYYYY format. From Effective Date in the SKU Price table. |
UPCCode |
|||
UPCCode |
alpha |
14 |
The UPC code defined for the SKU. From UPC in the Item UPC table. |
SetComponent |
Included only if ECI SET is Y for the item. |
||
SKUCode |
alpha |
14 |
The SKU associated with the set component. From SKU Code in the Set Detail table. |
SetQty |
numeric |
5 |
The number of units of the item to include in one set. From Qty in the Set Details table. |
SetCompItemNumber |
alpha |
12 |
A component item of the set item. From Set Comp Item Number in the Set Details table. |
SetCompSKUCode |
alpha |
14 |
The SKU of the component item. From Set Comp SKU Code in the Set Details table. |
CrossSellCoordinate |
Included only if a record exists in the Cross-Sell table for the item. |
||
CrossSellItem |
alpha |
12 |
The related item coordinated to the primary item for cross-selling purposes. From ICN Coordinate Item in the Item Coordinate table. |
CrossSellDesc |
alpha |
70 |
The persuasive or descriptive message to display for the coordinate item. From ICN Message in the Item Coordinate table. |
CoordinateSequence |
numeric |
3 |
The sequence number assigned to the item coordinate type, indicating the sequence in which the Display Coordinate Items window displays coordinate items assigned to this type in order entry. From ICN Sequence in the Item Coordinate table. |
CoordinateType |
alpha |
2 |
A code representing a type of item coordinate, such as mandatory or optional. From ICN Coordinate Type in the Item Coordinate table. |
Keyword |
Included only if a record exists in the Keyword table for the item. |
||
Keyword |
alpha |
20 |
The word you wish to include or exclude as a keyword, based on the keyword type. From KWD Keyword Exclusion in the Keyword table. |
ShipViaOverride |
Included only if a record exists in the Item Ship Via Override table for the item. |
||
ShippingCode |
numeric |
2 |
The code for a shipper you can select as a ship via override for the item. Ship via codes are defined in and validated against the Ship Via table. From Via Ship Via Code in the Item Ship Via Override table. |
ExtraShipping |
Included only if a record exists in the Shipper Item table for the item. |
||
ExtraShippingCode |
alpha |
12 |
The code for the item associated with the extra shipping cost. From Via Ship Via Code in the Shipper Item table. |
ExtraShippingCost |
numeric |
13.2 |
The extra charge that is added to orders for this item. From SIT Extra Charge in the Shipper Item table. |
Sample E-Commerce Product Web XML Message (ProductWeb)
A sample of the E-Commerce Product Web XML message (ProductWeb) is presented below.
<?xml version="1.0" encoding="UTF-8"?>
<Header CompanyCode="7">
<Offers>
<Offer EndDate="07312019" StartDate="07012015" Currency="" OfferDescription="MAIN OFFER" Offer="OFR"/>
</Offers>
<SourceCodes>
<SourceCode Offer="OFR" DiscPercentage="5.00" SrcDescription="MAIN SOURCE" SourceCode="SOURCE"/>
</SourceCodes>
<Items>
<Item UserField4="USERFIELD4" UserField3="USERFIELD3" UserField2="USERFIELD2" UserField1="USERFIELD1" OROBEligible="Y" Set="N" ShipAlone="" NonInventory="N" Oversize="N" DropShip="N" SVCType="" Discountable="Y" ItemStatus="1" HazardDesc="1 HAZARD CODE" HazardCode="1" ClassDesc="1 ITEM CLASS" Class="1" DepartmentDesc="7777 LONG SKU DEPARTMENT" Department="7777" DescSecondLanguage="ITEM SECOND LANGUAGE DESCRIPTION" VendorNumber="7" UnitOfMeasure="EA" ShipWeight="5.000" SellQty="3" Width="6" Length="24" Height="12" AllowSKUs="N" Description="ITEM DESCRIPTION" ItemNumber="ITEM">
<ItemOffers>
<ItemOffer FreightExempt="N" PersonalizationCode="MO" PersonalizationPrice="5.00" GiftWrapPrice="5.00" GiftWrap="Y" EffectiveDate="12012015" ItemPrice="90.00" ItemOffer="OFR">
<ItemPrices>
<ItemPrice EffectiveDate="12012015" Price="90.00" Qty="1"/>
<ItemPrice EffectiveDate="12012015" Price="75.00" Qty="2"/>
<ItemPrice EffectiveDate="12102015" Price="80.00" Qty="1"/>
</ItemPrices>
<ItemAliases>
<ItemAlias AliasNumber="AITEM"/>
</ItemAliases>
</ItemOffer>
</ItemOffers>
<SKUs>
<SKU UserField4="USER4" UserField3="USERFIELD3" UserField2="USERFIELD2" UserField1="USERFIELD1" UserField5="USER5" SkuOriginalPrice="100.00" SkuCost="40.00" SoldOutType="" SoldOutCode="" SkuStatus="" RetailReference="12012015" RestrictOrders="N" ItemSku="ITEM" SkuElement3Desc="" SkuElement3Code="" SkuElement2Desc="" SkuElement2Code="" SkuElement1Desc="" SkuElement1Code="" SkuDescription="" Category="ICAT" SkuCode="" ShortSku="115">
<SKUOffers/>
<UPCCodes>
<UPCCode code="12011510"/>
</UPCCodes>
</SKU>
</SKUs>
<CrossSellCoordinates>
<CrossSellCoordinate CoordinateType="" CoordinateSequence="0" CrossSellDesc="Item Coordinate Message for primary item ITEM and coordinate item SKU" CrossSellItem="SKU"/>
</CrossSellCoordinates>
<Keywords>
<Keyword Keyword="DESCRIPTION"/>
<Keyword Keyword="ITEM"/>
</Keywords>
<ShipViaOverrides>
<ShipViaOverride ShippingCode="1"/>
</ShipViaOverrides>
<ExtraShippings>
<ExtraShipping ExtraShippingCost="5.00" ExtraShippingCode="1"/>
</ExtraShippings>
</Item>
<Item UserField4="" UserField3="" UserField2="" UserField1="" OROBEligible="Y" Set="Y" ShipAlone="" NonInventory="N" Oversize="N" DropShip="N" SVCType="" Discountable="Y" ItemStatus="" HazardDesc="" HazardCode="0" ClassDesc="" Class="" DepartmentDesc="" Department="0" DescSecondLanguage="SET SECOND LANGUAGE DESCRIPTION" VendorNumber="0" UnitOfMeasure="EA" ShipWeight="0.000" SellQty="0" Width="0" Length="0" Height="0" AllowSKUs="N" Description="SET ITEM" ItemNumber="SET">
<ItemOffers>
<ItemOffer FreightExempt="N" PersonalizationCode="" PersonalizationPrice="0.00" GiftWrapPrice="0.00" GiftWrap="N" EffectiveDate="11242015" ItemPrice="100.00" ItemOffer="OFR">
<ItemPrices>
<ItemPrice EffectiveDate="11242015" Price="100.00" Qty="1"/>
</ItemPrices>
<ItemAliases/>
</ItemOffer>
</ItemOffers>
<SKUs>
<SKU UserField4="" UserField3="" UserField2="" UserField1="" UserField5="" SkuOriginalPrice="0.00" SkuCost="0.00" SoldOutType="" SoldOutCode="" SkuStatus="" RetailReference="0" RestrictOrders="N" ItemSku="SET" SkuElement3Desc="" SkuElement3Code="" SkuElement2Desc="" SkuElement2Code="" SkuElement1Desc="" SkuElement1Code="" SkuDescription="" Category="" SkuCode="" ShortSku="7">
<SKUOffers/>
</SKU>
</SKUs>
<SetComponents>
<SetComponent SkuCode="" SetCompSkuCode="" SetCompItemNumber="SETCOMP1" SetQty="1"/>
<SetComponent SkuCode="" SetCompSkuCode="RED" SetCompItemNumber="SETCOMP2SKU" SetQty="1"/>
</SetComponents>
<CrossSellCoordinates/>
<Keywords>
<Keyword Keyword="ITEM"/>
<Keyword Keyword="SET"/>
</Keywords>
<ShipViaOverrides/>
<ExtraShippings/>
</Item>
<Item UserField4="USERFIELD4" UserField3="USERFIELD3" UserField2="USERFIELD2" UserField1="USERFIELD1" OROBEligible="Y" Set="N" ShipAlone="" NonInventory="N" Oversize="N" DropShip="N" SVCType="" Discountable="Y" ItemStatus="1" HazardDesc="" HazardCode="0" ClassDesc="1 ITEM CLASS" Class="1" DepartmentDesc="7777 LONG SKU DEPARTMENT" Department="7777" DescSecondLanguage="" VendorNumber="7" UnitOfMeasure="EA" ShipWeight="5.000" SellQty="1" Width="12" Length="12" Height="12" AllowSKUs="Y" Description="SKU ITEM DESCRIPTION" ItemNumber="SKU">
<ItemOffers>
<ItemOffer FreightExempt="N" PersonalizationCode="" PersonalizationPrice="0.00" GiftWrapPrice="0.00" GiftWrap="N" EffectiveDate="10202015" ItemPrice="50.00" ItemOffer="OFR">
<ItemPrices>
<ItemPrice EffectiveDate="10202015" Price="50.00" Qty="1"/>
</ItemPrices>
<ItemAliases/>
</ItemOffer>
</ItemOffers>
<SKUs>
<SKU UserField4="USER4" UserField3="USERFIELD3" UserField2="USERFIELD2" UserField1="USERFIELD1" UserField5="USER5" SkuOriginalPrice="150.00" SkuCost="45.00" SoldOutType="" SoldOutCode="" SkuStatus="" RetailReference="0" RestrictOrders="N" ItemSku="SKU RED" SkuElement3Desc="" SkuElement3Code="" SkuElement2Desc="" SkuElement2Code="" SkuElement1Desc="BERRY RED" SkuElement1Code="RED" SkuDescription="RED SKU" Category="ICAT" SkuCode="RED" ShortSku="5">
<SKUOffers>
<SKUOffer PersonalizationCode="MO" PersonalizationPrice="5.00" GiftWrap="Y" EffectiveDate="12012015" GiftWrapCost="5.00" SkuPrice="100.00" SkuOffer="OFR">
<SKUPrices>
<SKUPrice EffectiveDate="12012015" Price="100.00" Qty="1"/>
<SKUPrice EffectiveDate="12052015" Price="70.00" Qty="2"/>
<SKUPrice EffectiveDate="12102015" Price="70.00" Qty="1"/>
</SKUPrices>
</SKUOffer>
</SKUOffers>
<UPCCodes>
<UPCCode code="12011511"/>
</UPCCodes>
</SKU>
<SKU UserField4="" UserField3="" UserField2="" UserField1="" UserField5="" SkuOriginalPrice="0.00" SkuCost="0.00" SoldOutType="" SoldOutCode="" SkuStatus="" RetailReference="0" RestrictOrders="N" ItemSku="SKU BLUE SML WMNS" SkuElement3Desc="WOMENS" SkuElement3Code="WMNS" SkuElement2Desc="SMALL" SkuElement2Code="SML" SkuElement1Desc="DENIM BLUE" SkuElement1Code="BLUE" SkuDescription="BLUE SML WMNS SKU DESCRIPTION" Category="" SkuCode="BLUE SML WMNS" ShortSku="118">
<SKUOffers/>
</SKU>
<SKU UserField4="" UserField3="" UserField2="" UserField1="" UserField5="" SkuOriginalPrice="0.00" SkuCost="0.00" SoldOutType="" SoldOutCode="" SkuStatus="" RetailReference="0" RestrictOrders="N" ItemSku="SKU GRN SML WMNS" SkuElement3Desc="WOMENS" SkuElement3Code="WMNS" SkuElement2Desc="SMALL" SkuElement2Code="SML" SkuElement1Desc="JADE GREEN" SkuElement1Code="GRN" SkuDescription="GRN SML WMSN SKU DESCRIPTION" Category="" SkuCode="GRN SML WMNS" ShortSku="119">
<SKUOffers/>
</SKU>
<SKU UserField4="" UserField3="" UserField2="" UserField1="" UserField5="" SkuOriginalPrice="0.00" SkuCost="0.00" SoldOutType="" SoldOutCode="" SkuStatus="" RetailReference="0" RestrictOrders="N" ItemSku="SKU RED SML WMNS" SkuElement3Desc="WOMENS" SkuElement3Code="WMNS" SkuElement2Desc="SMALL" SkuElement2Code="SML" SkuElement1Desc="BERRY RED" SkuElement1Code="RED" SkuDescription="RED SML WMNS SKU DESCRIPTION" Category="" SkuCode="RED SML WMNS" ShortSku="117">
<SKUOffers/>
</SKU>
<SKU UserField4="" UserField3="" UserField2="" UserField1="" UserField5="" SkuOriginalPrice="0.00" SkuCost="0.00" SoldOutType="" SoldOutCode="" SkuStatus="" RetailReference="0" RestrictOrders="N" ItemSku="SKU YELW SML WMNS" SkuElement3Desc="WOMENS" SkuElement3Code="WMNS" SkuElement2Desc="SMALL" SkuElement2Code="SML" SkuElement1Desc="SUN YELLOW" SkuElement1Code="YELW" SkuDescription="YELW SML WMNS SKU DESCRIPTION" Category="" SkuCode="YELW SML WMNS" ShortSku="120">
<SKUOffers/>
</SKU>
</SKUs>
<CrossSellCoordinates/>
<Keywords>
<Keyword Keyword="DESCRIPTION"/>
<Keyword Keyword="ITEM"/>
<Keyword Keyword="SKU"/>
</Keywords>
<ShipViaOverrides/>
<ExtraShippings>
<ExtraShipping ExtraShippingCost="5.00" ExtraShippingCode="1"/>
</ExtraShippings>
</Item>
</Items>
</Header>
Working with E-Mail Notification Templates (WEMT)
Purpose: Use this menu option to work with the default text to include when you send email notifications:
-
first, second, and continue backorder notices
-
credit card credit acknowledgments
-
Contact us” requests
-
credit card decline notifications
-
loyalty membership activations and deactivations
-
Oracle Retail Customer Engagement loyalty registration notices
-
membership cancellation notifications
-
order confirmations
-
purchase orders
-
return confirmations
-
shipment confirmations
-
soldout notifications
-
store pickup notifications
-
stored value card notifications
-
quote confirmations
-
order cancellation confirmations
-
order line cancellation confirmations
-
cancellation attempt failure notices
The system automatically creates templates for each of the above at the company level, but the templates are blank until you specify the text for each email.
General email setup: See Email Generation Setup for more information on how to configure Order Management System for email generation.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Email formats: Most of the system-generated emails are in HTML format; however, the purchase order and loyalty activation/deactivate notices are in simple text. See HTML Format Notification Samples and Contents and Simple Format Notification Sample for examples.
Outbound email API: You can specify generation of a generic outbound XML message, rather than an actual email, for all notifications except the loyalty activation/deactivation and purchase orders. The customer service emails use the simple text format, and the purchase order form is attached to a plain-text email.
The XML message includes additional information that is not included in the standard email notice. You might choose to generate the XML message so that you can use the information to produce a reformatted HTML email that includes promotional content. See Outbound Email API for an overview.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
In this topic:
For more information: See:
-
Setup overview: Email Generation Setup provides an overview on setup, a listing of related system control values, and troubleshooting information.
-
Which text template? Email Text Templates describes the hierarchy that controls which text template to use for notifications.
-
Which “from” email address? “From” Email Address" describes the hierarchy that controls how to determine the “from” email address to use for emails.
-
Actual email or CWEmailOut? HTML Email or Outbound Email XML Message? describes the hierarchy that controls whether to generate an actual email or the Outbound Email XML Message (CWEmailOut).
-
Controlling individual notification types by order type: Generate Notifications? describes how to control the generation of different types of notifications for an order type.
-
Settings and overrides by order type: Establishing Order Types (WOTY) describes setup options by order type.
-
Settings and overrides by entity or entity/order type: Working with Entities (WENT) describes setup options by entity and entity/order type.
-
Outbound Email API describes the CWEmailOut message generation and contents, and includes a sample of each notification type.
-
Testing email generation: Testing Email Generation (UEML)
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Summary of Customer Correspondence
The table below provides a summary of the customer correspondence generated by the system. See Work with E-Mail Template Screen for a listing of the information included in each type of generated email notice.
Generated Output | Generated Through: | Subject Line | Contents |
---|---|---|---|
Backorder 1st, 2nd, or Continue Notice |
|||
email (HTML format), XML, or printed |
Backorder - order#:99999999 |
||
“Contact us” notice |
|||
email (HTML format) or XML |
Selecting the Send Contact Us Email option at the Display More Options Screen in order entry, inquiry, or maintenance. This option is available only if:
Note: You can generate this email regardless of the setting of the Email notification flag for the order type. |
Contact Us - Order#:99999999 |
|
Credit Card Credit Acknowledgement |
|||
email (HTML format) XML, or printed |
Processing Refunds (MREF) and Processing Refunds by Order Number (MRFO)
|
Credit Ack. - Order #99999999 |
See Credit Card Credit Acknowledgement Email Sample and Contents. |
Credit Card Decline Notice |
|||
email (HTML format) or XML |
Streamlined Pick Slip Generation (WSPS) and the REAUTH periodic function (see REAUTH Processing) |
Credit Card Decline - Order #99999999 |
|
Loyalty Activate Notice and Loyalty Deactivate Notice |
|||
email only |
BILL_ASYNC and ORDR_ASYNC processes in Using the ASYNC Jobs (MBJC) |
Loyalty Activation or Loyalty Deactivation Note: The word “Loyalty” is replaced with the value in the Alternate Customer Number Label Description (H95) system control value, if any. |
|
Oracle Retail Customer Engagement Loyalty Registration Notification |
|||
email (HTML format) or XML |
Registering a Customer in the Customer Engagement Loyalty Program |
Loyalty Registration Notification |
See Oracle Retail Customer Engagement Loyalty Registration Notification Sample and Contents. |
Maintenance Failure |
|||
email (HTML format) or XML |
Cancellation Request Failure - Order #999999 |
||
Membership Cancellation |
|||
email (HTML format) or XML |
cancelling a customer membership through the Working with Customer Memberships (WWCM) |
Membership Cancellation |
See Membership Cancellation Notification Sample and Contents. |
Quote Confirmation |
|||
email (HTML format) or XML |
Select the Email Quote option on the Print/Email Quote Window |
Quote Confirmation - Quote # 99999999 |
|
Order Cancellation Confirmation |
|||
email (HTML format) or XML |
ORDR_ASYNC process in Using the ASYNC Jobs (MBJC) |
Order Cancellation - Order# 99999999 |
See Order Cancellation Confirmation Email Sample and Contents. |
Order Confirmation |
|||
email (HTML format) or XML |
|
Order Confirmation - Order# 99999999 |
|
Order Line Cancellation Confirmation |
|||
email (HTML format) or XML |
ORDR_ASYNC process in Using the ASYNC Jobs (MBJC) |
Order Line Cancellation - Order# 99999999 |
See Order Line Cancellation Confirmation Email Sample and Contents. |
Return Confirmation |
|||
email (HTML format) or XML |
|
Return Conf. - Order #99999999 |
|
Shipment Confirmation |
|||
email (HTML format) or XML |
|
Ship Conf. - Order #99999999 |
|
Soldout Notification |
|||
email (HTML format) XML, or printed |
Soldout - Order #99999999 |
||
Store Pickup Notification Note: Order Broker’s Store Connect module does not use this notification email; instead, you can use Order Broker to generate a notification to the customer. |
|||
email (HTML format) or XML |
Order Ready for Pickup - Order# 99999999 |
See Store Pickup Notification Sample and Contents. |
|
Stored Value Card Notification |
|||
email (HTML format) or XML |
SVC_OUT process in Working with Integration Layer Processes (IJCT) |
Stored Value Card Notification |
|
Gift Acknowledgement |
|||
printed only |
Pick slip generation or billing, depending on the setting of the Automatic Generation of Gift Acknowledgement (B92) system control value |
N/A |
See Gift Acknowledgement. |
Pick Slips |
|||
printed only |
N/A |
See Pick Slip. |
|
Drop Ship Pick Slips |
|||
printed only |
N/A |
||
Refund Checks |
|||
printed only |
N/A |
See Refund Check. |
When Does the System Generate an Email Notification?
Order Confirmation Emails
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
An order is eligible for an order confirmation email or Outbound Email XML Message (CWEmailOut) if:
-
the order is not a quote, and
-
the Email notification flag for the order type is selected, and,
-
the Send email flag for the Order Confirmation is selected for the order type at the Order Type Email Selection Screen, and
-
the customer’s Opt-in/out setting (see Determining the Opt-in/out Setting) is O1 or O2, and
-
the customer has an Email address; and,
-
the order includes one or more lines with a positive quantity, and
-
the order includes lines other than a soldout item, or the Exclude S/O on order confirmation is unselected, and
-
the E-Mail Order Confirmations for All Orders (H51) is selected, or
-
the order type matches the E-Commerce Order Type (G42).
-
Note:
-
If you delete the email address and the Suppress Email Address Search (J09) system control value is selected, the system does not generate order-related emails for the order. See that system control value for more information.
-
The system does not confirm that the customer’s email address is a valid, existing address.
-
The XML only? flag for the Order Confirmation template used (at either the entity or company level) controls whether you generate an actual email notification or the Outbound Email XML Message (CWEmailOut).
-
To generate an actual email (rather than the Outbound Email XML Message (CWEmailOut)), you need to have the Order Acknowledgement Program (G50) system control value set to OrdConf or to the name of your unique HTML-based email program. To generate the Outbound Email XML Message (CWEmailOut), you have to set the system control value to any value, but it cannot be blank.
-
If the Suppress Order Confirmations for Orders in Error (K09) system control value is unselected and there are any errors on the order, the generated email might not be formatted correctly. For example, if there is not sufficient valid information for the shipping address on the order, this name and address are omitted from the generated email.
-
If the order includes multiple shipping addresses, the system generates a separate confirmation for each ship-to.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
For more information: See Email Setup within Order Management System for more information on the hierarchies that control the email text template and “from” email address for the order confirmation email, and that determine whether to generate the Outbound Email XML Message (CWEmailOut) or an actual email.

Generated when? The order confirmation email or Outbound Email XML Message (CWEmailOut) is generated automatically when the order is created, either through interactive order entry or the order API (order API orders); however, if an order created through the order API is in error and the Suppress Order Confirmations for Orders in Error (K09) system control value is selected, the order confirmation is not generated until you correct any errors and accept and process the corrected order batch.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
If you enter the order through interactive order entry, the confirmation is not generated while the order is still suspended in a batch. Once you accept the order, the system generates the confirmation.
For more information: See the Order Confirmation Email Sample and Contents.
Shipment and Return Confirmation Emails
The system generates a shipment or return confirmation email or Outbound Email XML Message (CWEmailOut) only if:
-
the Email notification flag for the order type is selected, and,
-
the Send email flag for the notification type is selected at the Order Type Email Selection Screen, and
-
the customer’s Opt-in/out setting (see Determining the Opt-in/out Setting) is O1 or O2, and,
-
the customer has an Email address, and,
-
the E-Mail Shipment Confirmations for All Orders (H52) system control value is selected, or,
-
the order type matches the Return Disposition Code to Exclude in ORCE Sales Feed (M22), or
-
the Internet order field in the Order Header table is set to I
-
-
for return confirmations, the return disposition code for the return does not match the return disposition code defined in the Return Disposition Code to Exclude in ORCE Sales Feed (M22) system control value and the Suppress refund field in the Order Payment Method table is N or blank.
Note:
-
If you delete the email address and the Suppress Email Address Search (J09) system control value is selected, the system does not generate order-related emails for the order. See that system control value for more information.
-
The system does not confirm that the customer’s email address is a valid, existing address.
-
The XML only? flag for the Shipment or Return Confirmation template used (at either the entity or company level) controls whether you generate an actual email notification or the Outbound Email XML Message (CWEmailOut).
-
To generate an actual shipment confirmation email (rather than the Outbound Email XML Message (CWEmailOut)), you need to have the Shipment Confirmation Program (G51) system control value set to ShpConf or to the name of your unique HTML-based email program.
-
Similarly, to generate an actual return confirmation email, you need to set the Return Confirmation E-Mail Program (H53) system control value to RtnConf or to the name of your unique HTML-based email program.
-
To generate the Outbound Email XML Message (CWEmailOut), you have to set the system control value to any value, but it cannot be blank.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
-
There is a separate shipment confirmation email for each invoice for the order billed on a given date.

You can generate shipment and return confirmation emails or the Outbound Email XML Message (CWEmailOut) through:
-
billing if the Send Shipment Confirmation from Billing (L98) system control value is selected
-
the ECSHCNF periodic function; see Working with Periodic Functions (WPER)
-
If you do not consolidate invoices, the system keeps track of the shipment and return confirmation emails that it has generated by invoice number and date so that you can stop and restart email generation for a single date without risk of generating a duplicate email to a customer. See Stopping and Restarting Shipment and Return Confirmation Emails for an overview and more background.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
For more information: See the Shipment Confirmation Email Sample and Contents and Return Confirmation Email Sample and Contents.
Stored Value Card Notification Emails
The system generates a stored value card notification or outbound XML message when the SVC_OUT job processes an approved stored value card activation request if:-
The SVC type field for the stored value card item is E or V.
-
An email address is defined for the stored value card recipient. The system uses the Stored Value Card Email Hierarchy to determine the email address 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 program name. The base program is SVCNOTF.
The system does not look at the Email notification setting for the order type to determine whether to generate an email.
The system does not look at the Email notification setting for the order type to determine whether to generate an email.
Note:
-
The system generates this email notification regardless of the setting of the Suppress Email Address Search (J09) system control value.
-
The XML only flag for the Stored Value Card notification template used (at either the entity or company level) controls whether you generate an actual email notification or the Outbound Email XML Message (CWEmailOut).
-
To generate an actual stored value card confirmation email (rather than the Outbound Email XML Message (CWEmailOut)Outbound Email XML Message (CWEmailOut)), you need to have the Stored Value Card Email Notification Program (I30) system control value set to SVCNOTF or to the name of your unique HTML-based email program. To generate the Outbound Email XML Message (CWEmailOut), you have to set the system control value to any value, but it cannot be blank.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Important:
The outbound XML version specified for the EMAIL_OUT process in Working with Integration Layer Processes (IJCT) must be set to at least 4.0 in order to generate email or XML stored value card notifications.
For more information: See Stored Value Card Notification Email for more detail
Quote Confirmation Emails
A pre-order quote is eligible for a quote confirmation email or Outbound Email XML Message (CWEmailOut) if:
-
the Status of the order is Quote.
-
the customer or order has an Email address; and,
-
the Quote Confirmation Email Program (K74) system control value contains a valid email program. The base email program for quote confirmations is QUOCONF.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
In addition, for quotes entered through the order API:
-
the quote passes web order validation, and
-
the Quote field and Email notification field for the order type are selected, and,
-
the customer’s Opt-in/out setting (see Determining the Opt-in/out Setting) is O1 or O2
For quotes entered through interactive order entry, the system does not look at the Email notification setting for the order type or at the customer’s Opt in/out setting to determine whether to generate the Quote confirmation.
Note:
-
The system does not confirm that the customer’s email address is a valid, existing address.
-
The XML only? flag for the Quote Confirmation template used (at either the entity or company level) controls whether you generate an actual email notification or the Outbound Email XML Message (CWEmailOut).
-
To generate an actual email (rather than the Outbound Email XML Message (CWEmailOut)), you need to have the Quote Confirmation Email Program (K74) system control value set to QUOCONF or to the name of your unique HTML-based email program. To generate the Outbound Email XML Message (CWEmailOut), you have to set the system control value to any value, but it cannot be blank.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Generated when? The quote confirmation email or Outbound Email XML Message (CWEmailOut) is generated when you select the Email Quote option on the Print/Email Quote Window.
The system does not look at the Email notification setting for the order type to determine whether to generate a quote confirmation.
For more information: See the Quote Confirmation Email Sample and Contents.
Membership Cancellations
Generated when? If the Membership Cancellation Email Program (K77) system control value specifies a valid program name, the system generates membership cancellation emails when you cancel a customer membership through Working with Customer Memberships (WWCM). These emails are not generated when you cancel the membership item through order maintenance.
Which entity? The membership’s Default source indicates the entity associated with the customer membership for the purposes of determining the email template text.
Loyalty memberships: Email confirmations are also generated for loyalty memberships if you cancel them rather than deactivating them or having the system deactivate them automatically due to order cancellations or returns. Since loyalty memberships are not associated with a specific order or source code, they cannot use an entity-level template, and instead they always use the template set up through the Work with E-Mail Template Screen. Also, since loyalty memberships do not actually generate orders, both the sold-to and ship-to customer indicated in the email identify the customer possessing the loyalty membership.
Customer note: The system writes a customer note, such as Memship Cancel Conf to ejohnson@example.com, when it generates the membership cancellation email or XML message. The user ID associated with the customer note indicates the person who canceled the membership. The note is written even if the email might not actually be deliverable to the customer (for example, if there is a problem with the customer’s email address). Also, the note is written for the sold-to customer, even if the notification email was sent to a recipient.
Determining the email address: The email is sent to the email address of the customer ultimately receiving the membership orders, such as the recipient customer or a permanent ship-to address, provided there is a valid email address for that address and the opt-in/out setting is O1 or O2. If there is no alternate shipping address, the email is sent to the customer purchasing the membership. If the customer’s opt-in/out setting is O1 or O2 but there is no email address specified, the system writes a message to the APP.log, indicating that the email address is unresolved. See Logs for more information.
The system does look at the Email notification setting for the order type originating the membership, or assigned to generated orders, to determine whether to generate an email.
For more information: See the Membership Cancellation Notification Sample and Contents.
Purchase Order Emails
Generated when? Emailing the purchase order instead of printing it is available when:
-
the Email Purchase Order (K80) system control value is selected, and
-
the vendor’s Email P/O flag is selected, and
-
the vendor has a valid Email address.
-
Which menu options support emailing the purchase order? If the above conditions are true, you can email purchase orders through the Print PO Selection Screen screen in Printing Purchase Orders (MPRP), and through the Print P/O Window in purchase order maintenance and inquiry.
Note:
You cannot email purchase orders through Selecting Vendors for Drop Ship Processing (MDSP).
Separate emails: The system always generates a separate email for each purchase order, even if you select a range of date or purchase orders through Printing Purchase Orders (MPRP).
Which print program is used? In most cases, the .PDF attached to the email is generated with the PO Print Program (C64);; however, if you are using Printing Purchase Orders (MPRP) and print by purchase order number sequence, the PO Print Program for PO Print in PO Sequence (C76) is used.
Email template: The text in the email is derived from the Purchase Order template set up through the Change E-Mail Template Screen in Working with E-Mail Notification Templates (WEMT). Things to note about the Purchase Order template:
-
Unlike other email templates, this template is not available at the entity level, since the purchase order is not related to a specific entity.
-
The generated email is plain text, with the purchase included as a .PDF attachment. The XML only flag is not available for this template, and you cannot generate the Outbound Email XML Message (CWEmailOut).
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
-
Because the Purchase Order email does not include any details, you would not normally enter the Text to print below items. If you do so, this text appears several lines below the Text to print above items in the generated email.
-
The “from” email address is derived from the company (see Working with Companies (WCMP). If no email address specified for the company, the “from” email address is from the from.email specified through Email Properties.
-
The subject of the email is Purchase Order - PO # 1234567, where 1234567 is the purchase order number.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Store Pickup Notifications
The store pickup notification email indicates that a customer’s order is ready for pickup at the selected store. The system generates the store pickup notification when it receives the CWEmailRequest message for an external system, where the order has been assigned, provided that:
-
the Email notification field for the order type is selected, and
-
the Opt-in/out setting (see Determining the Opt-in/out Setting) for the email address on the order is O1 or O2, and
-
there is a valid email generation program specified for the Store Pickup Confirmation Email Program (L48) system control value.
For more information: See:
-
Store Pickup Orders for an overview on store pickup orders
-
the Store Pickup Confirmation Email Program (L48) and the Email Request Message (CWEmailRequest) for information on when the system generates the notification
-
Store Pickup Notification Sample and Contents for a sample email
Note:
Order Broker’s Store Connect module does not use this notification email; instead, you can use Order Broker to generate a notification to the customer.
Oracle Retail Customer Engagement Loyalty Registration Notifications
The Oracle Retail Customer Engagement loyalty registration notification email indicates that a customer has successfully registered in the Oracle Retail Customer Engagement Loyalty program. The system generates the Oracle Retail Customer Engagement loyalty registration notification when a loyalty card is assigned to a customer while Registering a Customer in the Customer Engagement Loyalty Program, provided that:
-
the Opt-in/out setting (see Determining the Opt-in/out Setting) for the email address is O1 or O2, and
-
the Oracle Retail Customer Engagement Card Inquiry Response returned from Oracle Retail Customer Engagement contains a loyalty card number, and
-
there is a valid email generation program specified for the ORCE Loyalty Registration Notification Email Program (M10) system control value.
For more information: See:
-
Customer Engagement Loyalty Integration for an overview on Loyalty processing, including setup.
-
the ORCE Loyalty Registration Notification Email Program (M10) for information on when the system generates the notification.
-
Oracle Retail Customer Engagement Loyalty Registration Notification Sample and Contents for a sample email.
Other Email Notifications
Backorder, soldout, cancellations, loyalty membership activation or deactivation, credit card credit notifications, “contact us” emails, credit card decline emails, maintenance failure, and order or order line cancellation confirmation emails: The system generates an email, rather than including the notice in a document (if applicable), only when:
-
the Email notification field for the order type is selected, and
-
if the notification type is listed at the Order Type Email Selection Screen, the Send email flag is selected, and
-
the Opt-in/out setting (see Determining the Opt-in/out Setting) for the email address on the order is O1 or O2, and
-
there is a valid email generation program specified for the related system control value.
Generation of other notification emails: The rules on generating other emails besides the types called out separately above are illustrated below.

Affected by settings at the order type? The settings at the order type include the Email notification flag and the Send email flag available for selected notifications for that order type. Order type settings control the generation of backorder notices, credit card credit acknowledgements, order or order line cancellation confirmations, and loyalty activation and deactivation notices. Also, the settings control the generation of quote confirmations for orders received through the order API as well as order confirmations and shipment and return confirmations, as described above.
Not affected by settings at the order type: The settings at the order type do not control the generation of membership cancellations, stored value card notifications, “contact us” emails, maintenance failure notifications, or credit card decline notifications.
Note:
-
If you delete the email address and the Suppress Email Address Search (J09) system control value is selected, the system does not generate order-related emails for the order. See that system control value for more information.
-
The system does not confirm that the customer’s email address is valid.
-
The customer API does not generate notification emails when it activates or deactivates a loyalty membership; these emails are generated only as a result of order activity. See Generic Customer API and v for more information.
-
The XML only? flag for the template used controls whether you generate an actual email notification or the For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).. See Email Setup within Order Management System for more information on how the system determines the setting of the XML only? flag.
-
This Email notification flag for the order type does not control email generation for “contact us” emails, loyalty activation or deactivation notices, maintenance failure notices, or credit card decline notices.
-
Quotes are not subject to most of the notification types described above; however, the system does generate the soldout notification for a quote if you use Process Auto Soldouts to sell out the item and the quote is otherwise eligible for emails based on the criteria that apply to other order types.
Backorder, soldout, “contact us,” credit card credit, and credit card decline notifications:
-
To generate an actual notification email (rather than the Outbound Email XML Message (CWEmailOut)), you need to have set the related system control values correctly:
For more information see the Web Services Guide on https://support.oracle.com My Oracle Support (ID 2149144.1).
-
the Backorder Notification E-Mail Program (G95) system control value set to BONOTF or to the name of your unique HTML-based email program.
-
the Soldout Notification E-Mail Program (G96) must be set to SONOTF or to the name of your unique HTML-based email program.
-
the Credit Card Credit Acknowledgement E-Mail Program (H08) must be set to CCCNOTF or to the name of your unique HTML-based email program.
-
the Credit Card Decline Email Program (K53) must be set to CDECLNOTF or to the name of your unique HTML-based email program.
-
the Contact Us Email Program (K54) must be set to CTUSNOTF or to the name of your unique HTML-based email program. This email is generated on demand, and not produced automatically by the system. See Summary of Customer Correspondence for more information on when the option to generate the “Contact Us” email is available.
-
the Order Cancellation Email Program (K78) must be set to ORDCANNOTF or to the name of your unique HTML-based email program.
-
the Order Line Cancellation Email Program (K79) must be set to ORDLCANOTF or to the name of your unique HTML-based email program.
-
for both the order and order line cancellation emails, the cancel reason code used must not match the Cancel Reason Code to Suppress Email (L08).
-
To generate the Outbound Email XML Message (CWEmailOut), you have to set the related system control value to any value, but it cannot be blank.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
For more information see the Web Services Guide on https://support.oracle.com My Oracle Support (ID 2149144.1).
Determining the Opt-in/out Setting
The system uses the following hierarchy to determine the opt-in/out setting to use when generating emails:
-
Check the Customer Sold To Email Address table for an email address that matches the email address on the order. If there is a match, use that Opt in/Opt out setting; otherwise,
-
Use the customer’s Opt in/Opt out setting
Additional Information about Email Notifications
Related system control values: See System Control Values Related to Email Generation for a listing.
Template text hierarchy: See Email Text Templates for information on how the system determines which text template to use. The XML only? setting applied is usually the one from the text template used; see HTML Email or Outbound Email XML Message? for information.
Order history message: The system writes an Order Transaction History message when it generates an email or the Outbound Email XML Message (CWEmailOut). You can review these messages at the Display Order History Screen.
Save in email repository? The Write Outbound Email to Email Repository (H99) system control value controls whether header information on email notifications or the Outbound Email XML Message (CWEmailOut) are stored in correspondence history. If the system control value is selected, the system records the correspondence history regardless of whether you generate an actual email or the Outbound Email XML Message (CWEmailOut). See this system control value for more information on identifying and reviewing outbound emails for a customer.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
The system does not retain the body of outbound emails in correspondence history, only the header information, such as the date, subject, and “to” email address.
Selection hierarchy for the “From” email address: See “From” Email Address for information.
HTML Format Notification Samples and Contents
The system generates HTML format emails for the notification types described below if the XML only? flag for the template is unselected. If the flag is selected, the system generates the Outbound Email XML Message (CWEmailOut) instead.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
The contents of each of the HTML emails are derived from the Outbound Email XML Message (CWEmailOut). The EMAIL_OUT process must be set to generate the most recent version of the outbound message in order to generate all of these email notifications correctly.
All other email notification types besides these notification types use the simple format described below under Simple Format Notification Sample.
Sample HTML messages:
Order Confirmation Email Sample and Contents
See Order Confirmation Emails for a discussion on how to generate this email.

Contents: The contents of the order confirmation email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Preliminary Information:
-
greeting: The word Dear followed by the:
-
sold_to_fname, if any; otherwise,
-
sold_to_fname, if any; otherwise,
-
Valued customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
Order Summary:
-
Order #: order_nbr and order_ship_to, separated by a hyphen
-
Order Date: order_date
-
for each item/SKU ordered:
-
Item/SKU: odt_item and odt_SKU, if any, separated by a slash; however, this is the odt_alias_item if the customer ordered by alias, regardless of the setting of the Display Item Alias (D56) system control value
-
Quantity: odt_qty
-
Price: odt_price
-
Extended Price: odt_extended_price
-
Status: odt_availability_msg; indicates whether the item is: In stock Backordered (including order lines that are not reserved because they have future arrival dates); a brokered backorder being fulfilled through the Order Broker Integration (Store Ship); a drop ship (includes an Exp Date); flagged for pickup at a designated store location through the Order Broker Integration (Store Pickup); or sold out (No longer available). The Status Message for E-Commerce Partial Reserved Lines (G52) system control value controls whether to list partially reserved lines as Backordered or Reserved, or to include details (for example, 7 reserved, 3 B/O).
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
If the background jobs are not running and the order ships before the order confirmation email is generated, the status of the shipped order lines is indicated as In stock.
-
Expected Date: odt_expected_ship_date; included only if the item is backordered or drop ship
-
item description: odt_item_desc
-
SKU description: odt_SKU_desc, if any (included only if the item has SKU’s)
-
custom special handling: osf_label and osf_input, if any (included only if item is assigned custom special handling) All custom special handling is included, even handling whose Suppress S/H window flag is set to Suppress. The system includes the osf_label even when the osf_input is blank. Note: The order confirmation does not include line level special handling charges since these charges are included at the order level.
-
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
-
totals:
-
Merchandise: ost_merch
-
Shipping and Handling: ost_freight, ost_addl_freight, ost_hand, and ost_addl_charge
-
Tax: ost_tax
-
Total: ost_total_amt
-
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Purchasing Information:
-
Ship To: ship_to_company, ship_to_fname, ship_to_minitial, ship_to_lname, ship_to_addr1, ship_to_addr2, ship_to_addr3, ship_to_addr4, ship_to_apt, ship_to_city, ship_to_state, ship_to_postal, ship_to_country
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
If the Suppress Order Confirmations for Orders in Error (K09) system control value is unselected and there are any errors on the order, the generated email might not be formatted correctly. For example, if there is not sufficient valid information for the shipping address on the order, this name and address are omitted from the generated email.
Shipment Confirmation Email Sample and Contents
See Shipment and Return Confirmation Emails for information on how to generate this email.

Contents: The contents of the shipment confirmation email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
sold_to_fname, if any; otherwise,
-
sold_to_company, if any; otherwise,
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
-
Valued customer
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
Shipment Summary:
-
Order #: order_nbr and order_ship_to, separated by a hyphen
-
Order Date: order_date
-
Date Shipped: ist_ship_date
-
Amount Charged: ist_ship_total_amt
-
Items included in this shipment:
-
Item/SKU: idt_item and idt_SKU, if any, separated by a slash; however, this is the idt_alias_item if the customer ordered by alias, regardless of the setting of the Display Item Alias (D56) system control value
-
Quantity: idt_ship_qty
-
item description: idt_item_desc
-
SKU description: idt_SKU_desc, if any (included only if the item has SKU’s)
-
-
Here are your tracking numbers for the items that shipped:
-
Carrier: tracking_ship_via_desc.
-
Tracking Number: tracking_nbr, made into a live link to the shipper’s web site using the tracking_URL.
Brokered backorder? If the item was a brokered backorder shipped through integration with Order Broker, then the ship via description is listed only if the Order Broker passed a valid ship via code set up in Order Management System; otherwise, the message lists the shipping agent passed from the Order Broker. In this case, the tracking number is not a live link. Also, if a brokered backorder ships on the same day as a warehouse shipment, the shipment confirmation email includes both the tracking numbers. This occurs regardless of whether you consolidate invoices. See Brokered Backorders for more information.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
If the order includes two invoices on the same date, one for a brokered backorder with a tracking number, and another shipment without a tracking number, the tracking number from the brokered backorder is indicated for both shipments. A shipment might not have a tracking number if, for example, you confirm a drop shipment or use manual confirmation.
-
-
Ship To: ship_to_company, ship_to_fname, ship_to_minitial, ship_to_lname, ship_to_addr1, ship_to_addr2, ship_to_addr3, ship_to_addr4, ship_to_apt, ship_to_city, ship_to_state, ship_to_postal, ship_to_country
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Return Confirmation Email Sample and Contents
See Shipment and Return Confirmation Emails for more information on how to generate this email.

Contents: The contents of the return confirmation email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
sold_to_fname, if any; otherwise,
-
sold_to_company, if any; otherwise,
-
Valued customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
Return Summary:
-
Order #: order_nbr and order_ship_to, separated by a hyphen
-
Order Date: order_date
-
Date Shipped: ist_ship_date
-
Amount Charged: ist_ship_total_amt
-
Items included in this shipment:
-
Item/SKU: idt_item and idt_SKU, if any, separated by a slash; however, this is the idt_alias_item if the customer ordered by alias, regardless of the setting of the Display Item Alias (D56) system control value
-
Quantity: idt_ship_qty
-
item description: idt_item_desc
-
SKU description: idt_SKU_desc, if any (included only if the item has SKU’s)
-
-
Here are your tracking numbers for the items that shipped:
-
Carrier: tracking_ship_via_desc.
-
Tracking Number: tracking_nbr, made into a live link to the shipper’s web site using the tracking_URL.
Brokered backorder? If the item was a brokered backorder shipped through integration with Order Broker, then the ship via description is listed only if the Order Broker passed a valid ship via code set up in Order Management System; otherwise, the message lists the shipping agent passed from the Order Broker. In this case, the tracking number is not a live link. Also, if a brokered backorder ships on the same day as a warehouse shipment, the shipment confirmation email includes both the tracking numbers. This occurs regardless of whether you consolidate invoices. See Brokered Backorders for more information.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
If the order includes two invoices on the same date, one for a brokered backorder with a tracking number, and another shipment without a tracking number, the tracking number from the brokered backorder is indicated for both shipments. A shipment might not have a tracking number if, for example, you confirm a drop shipment or use manual confirmation.
-
Note:
If no items were returned: If the order was credited through the application of a negative additional charge rather than processing a return, no item/SKUs are listed. Instead, a message indicates: There were no items associated with this return. A miscellaneous credit was processed on your order. However, the Item/SKU and Quantity headings are still included in the email.
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
Backorder Notification Email Sample and Contents
You can generate first, second, and continue backorder notifications through the Generate Backorder Notices (GBOC) and Working with Backorders Pending Cancellation (WBPC) menu options. See Other Email Notifications for more information on how to generate these emails.

Contents: The contents of the first, second, or continue backorder notification email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
sold_to_fname, if any; otherwise,
-
sold_to_company, if any; otherwise,
-
Valued customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
Notice type:
-
Backorder Summary - First Notification
-
Backorder Summary - Second Notification
-
Backorder Summary - Subsequent Notification
Purchasing Information:
-
Order #: order_nbr and order_ship_to, separated by a hyphen
-
Order Date: order_date
-
for each backordered item:
-
Item/SKU: bo_item and bo_SKU, if any, separated by a slash
Note:
This email does not specify the item alias even if the customer ordered by alias -
Backorder quantity: bo_qty
-
Expected date: bo_expected_date
-
item description: bo_item_desc and SKU description: bo_SKU_desc, if any (included only if the item has SKU’s)
-
-
Ship To: ship_to_company, ship_to_fname, ship_to_minitial, ship_to_lname, ship_to_addr1, ship_to_addr2, ship_to_addr3, ship_to_addr4, ship_to_apt, ship_to_city, ship_to_state, ship_to_postal, ship_to_country
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Credit Card Credit Acknowledgement Email Sample and Contents
You generate this email through the Processing Refunds (MREF) or Processing Refunds by Order Number (MRFO) menu options. See Other Email Notifications for more information on how to generate this email.

Contents: The contents of the credit card credit acknowledgement email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
sold_to_fname, if any; otherwise,
-
sold_to_company, if any; otherwise,
-
Valued Customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
-
Refund Summary:
-
Refund Order #: order_nbr and order_ship_to, separated by a hyphen
-
Refund Date: ccc_refund_date
-
Refund Total: ccc_refund_amt
-
Items included in the order:
-
Item/SKU: ccc_item and ccc_SKU if any, separated by a slash
-
item description: ccc_item_desc
-
SKU description: ccc_SKU_desc if any (included only if the item has SKU’s)
-
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
If the credit was generated through a negative additional charge, there are no items listed; however, the headings are still included in the email.
Purchasing Information:
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
-
Ship To: ship_to_company, ship_to_fname, ship_to_minitial, ship_to_lname, ship_to_addr1, ship_to_addr2, ship_to_addr3, ship_to_addr4, ship_to_apt, ship_to_city, ship_to_state, ship_to_postal, ship_to_country
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Soldout Notification Email Sample and Contents
You use the Generating Soldout Notifications (MSON) option to generate these soldout notifications. See Other Email Notifications for more information on how to generate these emails.

Contents: The contents of the soldout notification email are derived from the v as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
sold_to_fname, if any; otherwise,
-
sold_to_company, if any; otherwise,
-
Valued customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
-
Notice type: Soldout Summary
-
Order #: order_nbr and order_ship_to, separated by a hyphen
-
Order Date: order_date
-
for each soldout item:
- Item/SKU: so_item and so_SKU, if
any, separated by a slash
Note:
This email does not specify the item alias even if the customer ordered by alias. -
Soldout quantity: so_qty
-
item description: so_item_desc and SKU description: so_SKU_desc, if any (included only if the item has SKU’s)
- Item/SKU: so_item and so_SKU, if
any, separated by a slash
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Purchasing Information:
-
Ship To: ship_to_company, ship_to_fname, ship_to_minitial, ship_to_lname, ship_to_addr1, ship_to_addr2, ship_to_addr3, ship_to_addr4, ship_to_apt, ship_to_city, ship_to_state, ship_to_postal, ship_to_country
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Store Pickup Notification Sample and Contents
See the Store Pickup Confirmation Email Program (L48) for information on how to generate this email.
Note:
Order Broker’s Store Connect module does not use this notification email; instead, you can use Order Broker to generate a notification to the customer.
Contents: The contents of the store pickup notification email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:-
greeting: The word Dear followed by the:
-
sold_to_fname, if there is a sold-to name; otherwise,
-
Valued customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
-
Order Summary:
-
Order #: order_nbr and order_ship_to, separated by a hyphen
-
Order Date: order_date
-
for each item/SKU ordered:
-
Item/SKU: odt_item and odt_SKU, if any, separated by a slash; however, this is the odt_alias_item if the customer ordered by alias, regardless of the setting of the Display Item Alias (D56) system control value
-
Quantity: odt_qty
-
Price: odt_price
-
Extended Price: odt_extended_price
-
item description: odt_item_desc
-
SKU description: odt_SKU_desc, if any (included only if the item has SKU’s)
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
-
-
totals:
-
Merchandise: ost_merch
-
Shipping and Handling: ost_freight, ost_addl_freight, ost_hand, and ost_addl_charge
-
Tax: ost_tax
-
Total: ost_total_amt
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
-
Pickup Information:
-
Ship To: ship_to_company, ship_to_fname, ship_to_minitial, ship_to_lname, ship_to_addr1, ship_to_addr2, ship_to_addr3, ship_to_addr4, ship_to_apt, ship_to_city, ship_to_state, ship_to_postal, ship_to_country
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
See Stored Value Card Notification Emails for information on when the system generates these emails.
Stored Value Card Notification Sample and Contents
Note:
Each activated stored value card generates a separate email notification.
Contents: The contents of the stored value card notification email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
ship_to_fname, if any; otherwise,
-
ship_to_company, if any; otherwise,
-
Valued customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
-
Notice type: Stored Value Card Summary
-
Order #: order_nbr and order_ship_to, separated by a hyphen
-
Order Date: order_date
-
Date Activated: svc_activation_date
-
for the stored value card item:
-
Item/SKU: svc_item and svc_SKU, if any, separated by a slash
Note:
This email does not specify the item alias even if the customer ordered by alias.
-
-
Quantity: svc_qty
Note:
The quantity is always 1. A separate notification is generated for each value card number activated.
-
item description: svc_item_desc and SKU description: svc_SKU_desc, if any (included only if the item has SKU’s)
Shipment message:
-
For a virtual card: You will not be receiving a physical card on the item above.
-
For a physical card, early notification: You will be receiving a physical card on the item above.
Here is your Stored Value Card number for the item that shipped:
-
Stored Value Card Number: svc_card_nbr
-
Value: svc_issue_amount
-
ID Number: svc_id_nbr (if your Stored Value Card Email Notification Program (I30) supports it)
-
Up to four lines of order message lines flagged to print as gift messages: svc_message1, 2, 3, and 4
Purchasing Information
-
Ship To: ship_to_company, ship_to_fname, ship_to_minitial, ship_to_lname, ship_to_addr1, ship_to_addr2, ship_to_addr3, ship_to_addr4, ship_to_apt, ship_to_city, ship_to_state, ship_to_postal, ship_to_country
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
“Contact Us” Notification Sample and Contents
You can generate this email by selecting Send Contact Us Email at the Display More Options Screen in order entry, maintenance, and inquiry. See Summary of Customer Correspondence for information on how to generate these emails.

Contents: The contents of the “contact us” email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
sold_to_fname,, if any; otherwise,
-
sold_to_company, if any; otherwise,
-
Valued customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
-
Purchasing Information:
-
Order #: order_nbr and order_ship_to, separated by a hyphen
-
Order Date: order_date
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
-
Ship To: ship_to_company, ship_to_fname, ship_to_minitial, ship_to_lname, ship_to_addr1, ship_to_addr2, ship_to_addr3, ship_to_addr4, ship_to_apt, ship_to_city, ship_to_state, ship_to_postal, ship_to_country
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Credit Card Decline Notification Sample and Contents
The pick slip generation program generates these emails to customers when their orders have been placed on hold due to a declined authorization. Also, the REAUTH periodic function generates them; see REAUTH Processing for background. See Summary of Customer Correspondence for more information.

Contents: The contents of the credit card decline email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
sold_to_fname,, if any; otherwise,
-
sold_to_company, if any; otherwise,
-
Valued customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
-
Purchasing Information:
-
Order #: order_nbr and order_ship_to, separated by a hyphen
-
Order Date: order_date
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Quote Confirmation Email Sample and Contents
See Quote Confirmation Emails for a discussion on how to generate this email.

Contents: The contents of the quote confirmation email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
sold_to_fname,, if any; otherwise,
-
sold_to_company, if any; otherwise,
-
Valued customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
Quote Summary:
-
Quote #: order_nbr and order_ship_to, separated by a hyphen
-
Quote Date: order_date
-
Quote Expire Date: cancel_date
-
Sale Rep: sales_rep_name
-
for each item/SKU ordered:
-
Item/SKU: odt_item and odt_SKU, if any, separated by a slash; however, this is the odt_alias_item if the customer ordered by alias, regardless of the setting of the Display Item Alias (D56) system control value
-
Quantity: odt_qty
-
Price: odt_price
-
Extended Price: odt_extended_price
-
Country of Orig.: sku_country_of_origin
-
Harmonize Code: harmonize_code
-
item description: odt_item_desc
-
SKU description: odt_SKU_desc, if any (included only if the item has SKU’s)
-
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Soldout items: oldout items are included on the Quote Confirmation regardless of the Exclude S/O on order confirmation setting for the order type on the quote.
-
totals:
-
Merchandise: ost_merch
-
Shipping and Handling: ost_freight, ost_addl_freight, ost_hand, and ost_addl_charge
-
Tax: ost_tax
-
Total: ost_total_amt
-
Gift quotes: If you enter a gift quote (the Gift flag on the Work with Order screen is selected), the system still prints pricing information on the Quote Form and Quote Confirmation.
Purchasing Information:
-
Ship To: ship_to_company, ship_to_fname, ship_to_minitial, ship_to_lname, ship_to_addr1, ship_to_addr2, ship_to_addr3, ship_to_addr4, ship_to_apt, ship_to_city, ship_to_state, ship_to_postal, ship_to_country
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Membership Cancellation Notification Sample and Contents
See Membership Cancellations for information on how to generate this email.

Contents: The contents of the membership cancellation confirmation email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
sold_to_fname,, if the email is sent to the sold-to customer and there is a sold-to name; otherwise,
-
ship_to_fname, if the email is sent to the ship-to customer and there is a ship-to name; otherwise,
-
Valued customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
Membership Summary:
-
Membership ID: membership_id
-
Membership description: membership_desc
-
Cancel reason: mbr_cancel_rsn and mbr_cancel_rsn_desc, separated by a space and hyphen
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Purchasing Information:
-
Ship To: ship_to_company, ship_to_fname, ship_to_minitial, ship_to_lname, ship_to_addr1, ship_to_addr2, ship_to_addr3, ship_to_addr4, ship_to_apt, ship_to_city, ship_to_state, ship_to_postal, ship_to_country
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Cancellation Request Failure Email Sample and Contents
See the Order Maintenance Confirmation E-Mail Program (H12) system control value on how to generate this email.

Contents: The contents of the cancellation request failure email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
v, if there is a sold-to name; otherwise,
-
Valued customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
Order Information Summary:
-
Order #: order_nbr and order_ship_to, separated by a hyphen
-
Order Date: order_date
Sold To Information:
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
-
Ship To: ship_to_company, ship_to_fname, ship_to_minitial, ship_to_lname, ship_to_addr1, ship_to_addr2, ship_to_addr3, ship_to_addr4, ship_to_apt, ship_to_city, ship_to_state, ship_to_postal, ship_to_country
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Order Cancellation Confirmation Email Sample and Contents
See the Order Cancellation Email Program (K78)) system control value for information on how to generate this email.

Contents: The contents of the order cancellation confirmation email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
v, if there is a sold-to name; otherwise,
-
Valued customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
Order Cancellation Summary:
-
Order #: order_nbr and order_ship_to, separated by a hyphen
-
Order Date: order_date
For each open or held order line from the order when you canceled it:
-
Item/SKU: odt_item and odt_SKU, if any, separated by a slash; however, this is the odt_alias_item if the customer ordered by alias, regardless of the setting of the Display Item Alias (D56) system control value
-
Quantity: odt_qty_cancelled. If there have been previous cancellations against the order line, this is the quantity canceled during the session that canceled the order.
-
item description: odt_item_desc
-
SKU description: odt_SKU_desc, if any (included only if the item has SKU’s)
-
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Order lines that were previously canceled or sold out are not listed; also, any order lines canceled using the Cancel Reason Code to Suppress Email (L08) are omitted.
Purchasing Information:
-
Ship To: ship_to_company, ship_to_fname, ship_to_minitial, ship_to_lname, ship_to_addr1, ship_to_addr2, ship_to_addr3, ship_to_addr4, ship_to_apt, ship_to_city, ship_to_state, ship_to_postal, ship_to_country
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Order Line Cancellation Confirmation Email Sample and Contents
See the Order Line Cancellation Email Program (K79) system control value for information on how to generate this email.

Contents: The contents of the order line cancellation confirmation email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
sold_to_fname,, if there is a sold-to name; otherwise,
-
Valued customer
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
Order Line Cancellation Summary:
-
Order #: order_nbr and order_ship_to, separated by a hyphen
-
Order Date: order_date
-
For each order line canceled during the order maintenance session or other activity, such as Working with Backorders Pending Cancellation (WBPC):
-
Item/SKU: odt_item and odt_SKU, if any, separated by a slash; however, this is the odt_alias_item if the customer ordered by alias, regardless of the setting of the Display Item Alias (D56) system control value
-
Quantity: odt_qty_cancelled, the total quantity canceled at this time, even if multiple cancel reason codes were used in order maintenance. Does not include any previous quantity canceled.
-
item description: odt_item_desc
-
SKU description: odt_SKU_desc, if any (included only if the item has SKU’s)
-
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Order lines that were previously canceled or sold out are not listed; also, any order lines canceled using the Cancel Reason Code to Suppress Email (L08) are omitted.
-
Remaining Unshipped or Open Items:
-
For each remaining open or held order line:
-
Item/SKU: odt_item and odt_SKU, if any, separated by a slash; however, this is the odt_alias_item if the customer ordered by alias, regardless of the setting of the Display Item Alias (D56) system control value
-
Quantity: odt_qty, the open or held quantity remaining on the order line
-
Status: odt_availability_msg; indicates whether the item is In stock Backordered (including order lines that are not reserved because they have future arrival dates); being fulfilled through the Order Broker Integration (Store Ship); drop ship (includes an Exp Date); or sold out (No longer available). The Status Message for E-Commerce Partial Reserved Lines (G52) system control value controls whether to list partially reserved lines as Backordered or Reserved, or to include details (for example, 7 reserved, 3 B/O).
-
Expected Date: odt_expected_ship_date; included only if the item is backordered or drop ship
-
item description: odt_item_desc
-
SKU description: odt_SKU_desc, if any (included only if the item has SKU’s)
-
Purchasing Information:
-
Ship To: ship_to_company, ship_to_fname, ship_to_minitial, ship_to_lname, ship_to_addr1, ship_to_addr2, ship_to_addr3, ship_to_addr4, ship_to_apt, ship_to_city, ship_to_state, ship_to_postal, ship_to_country
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Oracle Retail Customer Engagement Loyalty Registration Notification Sample and Contents

See the ORCE Loyalty Registration Notification Email Program (M10) for information on how to generate this email.
Contents: The contents of the Oracle Retail Customer Engagement loyalty registration notification email are derived from the Outbound Email XML Message (CWEmailOut) as follows:
Preliminary Information:
-
greeting: The word Dear followed by the:
-
sold_to_fname, if there is a sold-to name; otherwise,
-
sold_to_company For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
Each of the above is in lower case, with just the first letter of the first word capitalized.
-
-
text: before_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
-
Here is your Loyalty Card number: the loyalty card number generated and signed to the customer from Oracle Retail Customer Engagement.
-
Sold To: sold_to_company, sold_to_fname, sold_to_minitial, sold_to_lname, sold_to_addr1, sold_to_addr2, sold_to_addr3, sold_to_addr4, sold_to_apt, sold_to_city, sold_to_state, sold_to_postal, sold_to_country Customer #: sold_to_nbr
Closing: after_line_msg. The email includes a line break (<br>) between each line entered at the Change E-Mail Template Screen.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Simple Format Notification Sample
The loyalty activation/deactivation and purchase order use a simple email format such as the following.
From: customer_servoce@example.com
Sent: Friday, February 2, 2009 4:22 p.m.
To: ebrown@example.com
Subject: PREFERRED Activation
We are pleased to tell you that your recent order qualifies
you for membership in our Preferred Members Club. Club
members receive a 5% discount on all orders and free
ground shipping.
GUESTVIP12 000000038
Sold To: JONES, MICHAEL Customer #: 13082
PREFERRED MEMBERS CLUB PREFERRED
Welcome to the club! We appreciate your business.
Work with E-Mail Template Screen
Purpose: Use this screen to enter boilerplate company-wide text to include in email notifications.
Overrides? You can also enter override text templates at the entity level, or overrides for certain notification types at the order type level and the entity/order type level. See Email Text Templates for more information.
How to display this screen: Enter WEMT in the Fast path field at the top of any menu, or select Work with E-Mail Templates from a menu.
Field | Description |
---|---|
Notice type |
Indicates the type of email notification. Available templates are:
Alphanumeric, 25 positions; display-only. |
Screen Option | Procedure |
---|---|
Enter or change the contents of an email notification template |
Select Change for a template to advance to the Change E-Mail Template Screen. |
Display the contents of an email notification template |
Select Display for a template to advance to the Display E-Mail Template Screen. You cannot change any information at this screen. See the Change E-Mail Template Screen for field descriptions. |
Change E-Mail Template Screen
Purpose: Use this screen to specify the standard text to include in one of the types of email notifications available in Order Management System at the company level.
Overrides? You can also enter override text templates at the entity level, and override certain notification types at the order type level and the entity/order type level. See Email Text Templates for more information.
How to display this screen: Select Change for a notice type at the Work with E-Mail Template Screen.
Field | Description |
---|---|
XML only |
Indicates whether to generate the Outbound Email XML Message (CWEmailOut)) rather than an actual email notification. This XML message includes additional information that is not included in the standard email notice. You might choose to generate the XML message so that you can use the information to produce a reformatted HTML email that includes promotional material. See Outbound Email XML Message (CWEmailOut)) for an overview. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). Valid values are: Selected = Generate the Outbound Email XML Message (CWEmailOut)) rather than an actual email Unselected = Generate the email notification. See HTML Format Notification Samples and Contents for more information. Note:
|
Text to print above items |
The standard text to include in each email above the information specific to the order, if the email is order-related. See the HTML Format Notification Samples and Contents and the Simple Format Notification Sample. Alphanumeric, ten 60-position lines; at least one line required. |
Text to print below items |
The standard text to include in each email below the information specific to the order, if the email is order-related. See the HTML Format Notification Samples and Contents and the Simple Format Notification Sample. Note: Not typically included for the purchase order email, since the email does not include any details. Alphanumeric, three 60-position lines; optional. |
Completing this screen: Enter the text to appear in the email notification or to include in the Outbound Email XML Message (CWEmailOut)). You can type over existing text to change it, or delete it to clear a line. The text you enter will be included the next time you generate this type of email notification. Any lines that you leave blank will be omitted from the email.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Testing Email Generation (UEML)
Purpose: Use this option to generate a test email in order to confirm that Order Management System is correctly configured to generate emails.
This option does not support testing individual message notification types.
Send Email Message Screen
How to display this screen: Enter UEML in the Fast path field at the top of any menu or select Test Email from a menu.
Field | Description |
---|---|
To |
The email address to receive the test email. Note: The system does not confirm that you enter a valid email address. Alphanumeric, 50 positions; required. |
Subject |
The text to use as the subject line for the test email. Alphanumeric, 44 positions; required. |
Message |
Up to four lines of text to include in the body of the email. Alphanumeric, 64 positions each; at least one line required. |
Completing this screen: Complete the three fields and click OK to generate a test email.
Troubleshooting: See Emails Troubleshooting for some steps you can take to identify whether the Order Management System application is configured correctly to generate emails.
Sending Internet Order Ship Confirmation (ESCF)
Purpose: Use the Send Internet Order Ship Confirmation menu option to generate email notifications or the Outbound Email XML Message (CWEmailOut)) to customers when an order shipment or return takes place. The confirmation is sent to the order-level email address on the order; see Working with an Order-Level Email Address.
Confirmations for all orders? See Shipment and Return Confirmation Emails for a discussion of which orders are eligible to generate these email confirmations based on the settings in your company and the customer’s email information.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Generate shipment confirmation during billing? If the Send Shipment Confirmation from Billing (L98) system control value is selected, the system generates shipment and return confirmations during billing. You can still use this menu option to generate an additional shipment or return confirmation. See this system control value for more information.
Note:
If you use the Narvar Integration, Narvar generates shipment confirmation emails to the customer based on an order request message sent through billing, and the shipment confirmation is not generated through the process described here.
Periodic function: You can also use the periodic function ECSHCNF (program name = ECR0154) to generate shipment and return confirmation emails or messages. See E-Commerce Setup.
About the outbound email XML message: See Outbound Email API for an overview.
For sample emails and more information: See Shipment Confirmation Email Sample and Contents and Return Confirmation Email Sample and Contents.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Interrupting or completing email generation: If you generate emails for a single day, the system keeps track of the last email generated so that you do not send the same email more than once; however, this option is not supported if you consolidate invoices. See Stopping and Restarting Shipment and Return Confirmation Emails for more information.
Save in email repository? The Write Outbound Email to Email Repository (H99) system control value controls whether the email notification or the Outbound Email XML Message (CWEmailOut) is stored in correspondence history. See this system control value for more information on identifying and reviewing outbound emails for a customer.
Order history message: When a shipment or return confirmation email or Outbound Email XML Message (CWEmailOut)) is sent, Order Management System creates an order history message such as Retrn Conf to acustomer@example.com. You can review order history messages at the Display Order History Screen.
No emails generated? If the Shipment Confirmation Program (G51) system control value is blank, or if you are generating an actual email (rather than the Outbound Email XML Message (CWEmailOut)) and the system control value is not set to ShpConf, no shipment confirmation emails are generated. Similarly, if the Return Confirmation E-Mail Program (H53) system control value is blank, or if you are generating an actual email (rather than the Outbound Email XML Message (CWEmailOut)) and the system control value is not set to RetConf, no return confirmation emails are generated.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Send Internet Shipment Confirmations Screen
How to display this screen: Enter ESCF in the Fast path field at the top of any menu, or select Send Internet Order Ship Confirmation from a menu.
Field | Description |
---|---|
From... |
The first shipment date to include when generating shipment confirmations. All eligible orders with shipments on or after this date, and not later than the To date, are included for shipment confirmation. The current date defaults. Numeric, 6 positions (in user date format); required. |
To... |
The last shipment date to include when generating shipment confirmations. All eligible orders with shipments on or before this date, and not before the From date, are included for shipment confirmation. The current date defaults. Numeric, 6 positions (in user date format); required. |
Instructions: To generate shipment confirmation emails and return confirmation emails or the Outbound Email XML Message (CWEmailOut)), override the From and To dates if necessary. Select Accept to generate the confirmation emails for the selected date(s).
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Stopping and Restarting Shipment and Return Confirmation Emails
Overview: When you generate shipment and return confirmation emails through the Send Internet Shipment Confirmations Screen or through the ECSHCNF periodic function, the system can keep track of the last email generated based on invoice number, enabling you to:
-
generate confirmation emails throughout the day for new shipments
-
continue email generation if you need to interrupt the process for any reason
Supported when? Stopping and restarting shipment and return confirmations is supported only if:
-
the Consolidated Invoice (B49) system control value is not selected
-
you do not enter a range of dates at the Send Internet Shipment Confirmations Screen. To be able to restart generation where you left off, you must make sure that the To...and From...dates are the same.
Otherwise, you do not have the option to restart the email generation process without generating duplicate emails.
How to stop email generation: To interrupt the generation of shipment and return confirmation emails, use the Purge Active Procedures Across Users (MACX) option to delete the active procedure with a Type of SC and a Program of ECR0154. After you delete the active procedure, the generation process might generate approximately 25 more confirmations before it stops.
Restarting email generation: To restart email generation where it left off for the date, simply run the periodic function or use the Send Internet Shipment Confirmations Screen to generate confirmations for the same date. Using the periodic function generates email confirmations for the current date, while the Send Internet Shipment Confirmations Screen enables you to specify a single date for email generation.
How does the system keep track? When you generate shipment and return email confirmations, the system writes a record in the Report Generic table noting the date and the last invoice number with a confirmation email generated. If you generate email confirmations again for that same date, the process starts with the next invoice number. Similar to the Active Procedure record, the Report Generic record has a Report type of SC. If for any reason you ever need to regenerate a group of confirmation emails again, you can use SQL to reset the last invoice number in that table before you restart the email generation process.
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.
Working with Tickler User Groups (WTUG)
Purpose: Use this menu option to create, change, or display a tickler user group.
Tickler groups are groups of users that work with and resolve ticklers. You can assign users to a tickler user group on the Work with User Tickler Group Screen.
The Type field for the tickler group defines whether the users in the group are:
-
tickler users (tickler group type U), indicating they work with ticklers assigned to their tickler user group using the Working with Tickler Users/User Groups (WTIC) menu option. Tickler users can work with ticklers assigned to them or their user group, but do not have access to any other ticklers.
-
tickler supervisors (tickler group type S), indicating they monitor the ticklers assigned to their tickler user group using the Workflow Management (WWFM) menu option. Tickler supervisors can monitor all ticklers, regardless of the user or tickler user group assigned to the tickler.
When the system creates a tickler, the system assigns the tickler:
-
to a tickler user group, if the event rule or event that created the tickler has an Assign to user group defined. Tickler users can work with ticklers for their group at the Work with Tickler Screen (group view).
-
to a tickler supervisor group, if the event rule or event that created the tickler has a Supervisor group defined. Supervisors can monitor ticklers for their group at the Workflow Management screen (supervisor group view).
A user can belong to multiple tickler groups.
Example: User KBROWN belongs to the HO-U-AT user group (ticklers created for the HO event and the rule is paytype hold reason AT) and the HO-S-AV supervisor group (ticklers created for the HO event and the rule is paytype hold reason is AV).

In this topic:
For more information:
Work with Tickler User Group Screen
Purpose: Use this screen to create, change, or delete a tickler group. You can also define the users that belong to a tickler group.
Note:
This menu option is not company specific; tickler user groups are created across companies.
How to display this screen: Enter WTUG in the Fast path field or select Work with Tickler User Group from a menu.
Field | Description |
---|---|
Group ID |
A code for a group of users that work with ticklers. Alphanumeric, 10 positions; optional. |
Description |
A description of the tickler group. Alphanumeric, 40 positions; optional. |
Type |
The type of tickler group. S = Tickler supervisor group. U = Tickler user group. Alphanumeric, 1 position; optional. |
Screen Option | Procedure |
---|---|
Create a tickler group |
Select Create to advance to the Create Tickler User Group Screen. |
Change a tickler group |
Select Change for a tickler group to advance to the Change Tickler User Group Screen. You can change any field except the group ID code. See the Create Tickler User Group Screen for field descriptions. |
Delete a tickler group |
Select Delete for a tickler group to delete it. Note: The system allows you to delete a tickler group that is currently assigned to a tickler event, event rule, or open or in use tickler. |
Display a tickler group |
Select Display for a tickler group to advance to the Display Tickler User Group Screen. You cannot change any information at this screen. See the Create Tickler User Group Screen for field descriptions. |
Review the users in a tickler group |
Select Users in group for a tickler group to advance to the Display Users In Group Screen. |
Create Tickler User Group Screen
Purpose: Use this screen to create a tickler group.
How to display this screen: Select Create at the Work with Tickler User Group Screen.
Field | Description |
---|---|
Group ID |
A code for a tickler group. You cannot create a duplicate tickler user group: Tickler User Group already exists. The system considers a tickler group a duplicate if the group ID code is used for another tickler group, regardless of the setting of the Type field. For example, you cannot have a UP supervisor tickler group and a UP user tickler group. Alphanumeric, 10 positions. Create screen: required. Change screen: display-only. |
Description |
A description of the tickler group. Alphanumeric, 40 positions; required. |
Type |
Indicates the type of tickler group. Supervisor = Supervisor tickler group; users in this group monitor ticklers assigned to their group. User = User tickler group; users in this group work with and resolve ticklers assigned to their group. Alphanumeric, 1 position; required. |
E-mail address |
The email address associated with the tickler supervisor group; this is the email address where ticklers assigned to this tickler group are sent. You can enter an email address only for supervisor (type S) tickler groups. You can enter only one email address in this field. When you enter an email address, the system verifies that:
The system confirms that your entry meets certain minimum formatting requirements, but not that it represents a valid, active email address. Alphanumeric, 50 positions; optional. |
Display Users In Group Screen
Purpose: Use this screen to review the users assigned to a tickler group.
You can assign users to a tickler group at the Work with User Tickler Group Screen.
How to display this screen: Select Users in group for a tickler group at the Work with Tickler User Group Screen.
Field | Description |
---|---|
Group ID |
The code and description of the tickler group assigned to the displayed users. Code: Alphanumeric, 10 positions; display-only. Description: Alphanumeric, 40 positions; display-only. |
User |
The user ID of the user assigned to the tickler group. Alphanumeric, 10 positions; display-only. |
Name |
The name of the user assigned to the tickler group. Alphanumeric, 30 positions; display-only. |
Working with Tickler Category (WTCT)
Purpose: Use this menu option to create, change, or delete a tickler category.
Tickler categories allow you to group ticklers by the event or event rule associated with the tickler. When you define settings for a tickler event or event rule, you can define the tickler category to assign to the ticklers created for the event/rule. You can scan for ticklers by tickler 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 (pay type 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.
In this topic:
For more information:
Work with Tickler Category Screen
Purpose: Use this screen to create, change, or delete a tickler category.
How to display this screen: Enter WTCT in the Fast path field or select Work with Tickler Category from a menu.
Field | Description |
---|---|
Cat (Category) |
A code for a tickler category, used to group ticklers. Alphanumeric, 3 positions; optional. |
Description |
The description of the tickler category. Alphanumeric, 40 positions; optional. |
Screen Option | Procedure |
---|---|
Create a tickler category |
Select Create to advance to the Create Tickler Category Screen. |
Change a tickler category |
Select Change for a tickler category to advance to the Change Tickler Category Screen. You can change the description. See the Create Tickler Category Screen for field descriptions. |
Delete a tickler category |
Select Delete for a tickler category to delete it. Note: The system allows you to delete a tickler category that is currently assigned to a tickler event, event rule, or open or in process tickler. |
Create Tickler Category Screen
Purpose: Use this screen to create a tickler category.
How to display this screen: Select Create at the Work with Tickler Category Screen.
Field | Description |
---|---|
Category |
A code for a tickler category, used to group ticklers. You cannot create a duplicate tickler category: Tickler Category already exists. The system considers a tickler category a duplicate if the category code is used for another tickler category. Alphanumeric, 3 positions. Create screen: required. Change screen: display-only. |
Description |
A description of a tickler category. Alphanumeric, 40 positions; required. |
Working with Tickler Resolution Reason (WTRR)
Purpose: Use this menu option to create, change, and delete tickler resolution reasons.
Tickler resolution reasons are assigned to ticklers once they are resolved, indicating 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.
In this topic:
For more information:
Work with Tickler Resolution Reason Screen
Purpose: Use this screen to create, change, and delete tickler resolution reasons.
How to display this screen: Enter WTRR in the Fast path field or select Work with Tickler Resolution Reason from a menu.
Field | Description |
---|---|
Rsn (Tickler resolution reason code) |
A code for a tickler resolution reason, indicating the reason why the tickler is resolved. Alphanumeric, 3 positions; optional. |
Description |
A description of the tickler resolution reason. Alphanumeric, 40 positions; optional. |
Screen Option | Procedure |
---|---|
Create a tickler resolution reason |
Select Create to advance to the Create Tickler Resolution Reason Screen. |
Change a tickler resolution reason |
Select Change for a tickler resolution reason to advance to the Change Tickler Resolution Reason Screen. You can change the description. See the Create Tickler Resolution Reason Screen for field descriptions. |
Delete a tickler resolution reason |
Select Delete for a tickler resolution reason to delete it. Note: The system allows you to delete a tickler resolution reason that is currently assigned to a tickler event, event rule, or open or in process tickler. |
Create Tickler Resolution Reason Screen
Purpose: Use this screen to create a tickler resolution reason.
How to display this screen: Select Create at the Work with Tickler Resolution Reason Screen.
Field | Description |
---|---|
Reason (Tickler resolution reason code) |
A code for a tickler resolution reason, indicating the reason why the tickler is resolved. You cannot create a duplicate tickler resolution reason: Tickler Resolution Reason already exists. The system considers a tickler resolution reason a duplicate if the tickler resolution reason code is used for another tickler resolution reason. Alphanumeric, 3 positions. Create screen: required. Change screen: display-only. |
Description |
A description of the tickler resolution reason. Alphanumeric, 40 positions; required. |
Working with Tickler Events (WTEV)
Purpose: Use this menu option to set up each system delivered tickler event, including:
-
tickler event settings at the event level
-
tickler event settings at the event rule level
-
event rule criteria for each rule you create
-
event rule procedures for each rule you create
In this topic:
For more information: See Workflow Management Overview and Setup for an overview on workflow management.
Defining Tickler Events and Event Rules
To create a tickler, you must define:
-
the tickler events that can create a tickler. There are system actions that can create ticklers. You cannot create other tickler events for the system to evaluate for tickler creation. Also, each tickler event is delivered as not active.
-
BO: backorders
-
CO: cancelled orders
-
HO: held orders
-
MN: manually created ticklers
-
NO: new orders
-
OO: aged open orders
-
SD: stored value card activation decline
-
SO: soldout orders
-
SV: stored value card number assignment
-
UP: unconfirmed pick tickets
-
VP: voided pick tickets
-
WF: ticklers received from a remote system
- 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; see Event Rule Procedures.
Tickler event hierarchy: For each tickler event, you can define multiple event rules. For each event rule, you can define procedures to resolve the tickler.

Working with Tickler Users/User Groups (WTIC)
Purpose: Use this menu option to review, work with, and resolve ticklers in a tickler work queue. Users can work with ticklers assigned to themselves or their tickler user groups.
Tickler supervisors: Tickler supervisors can review and work with ticklers assigned to their tickler supervisor group, or review all ticklers regardless of assignment, using the Workflow Management (WWFM) menu option.
In this topic:
Work with Tickler Screen (user/group view)
Purpose: Use this screen to review, work with, and resolve ticklers assigned to a particular user’s work queue or the tickler user groups defined for the user.
View current or future ticklers? The word CURRENT or FUTURE displays in the upper right corner of the screen indicating if you are viewing:
-
ticklers whose Assigned date is equal to or past the current date (current), or
-
ticklers whose Assigned date is later than the current date (future)
Select Current/future to toggle between viewing current ticklers or future ticklers; when you first advance to this screen, current ticklers display.
View open or resolved ticklers? The word OPEN or RESOLVED displays in the upper right corner of the screen indicating if you are viewing:
-
ticklers whose Status is O (open) or I (in process), or
-
ticklers whose Status is R (resolved)
Select Open/resolved to toggle between viewing open and in process ticklers or resolved ticklers; when you first advance to this screen, open ticklers display.
View FIFO or LIFO sequence? The word FIFO or LIFO displays in the left column to indicate how ticklers sort on the screen:
-
select FIFO to display ticklers in FIFO (first in, first out; meaning oldest to newest) sequence, or
-
select LIFO to display ticklers in LIFO (last in, first out; meaning newest to oldest) sequence
When you first advance to this screen, ticklers display in FIFO sequence (meaning the word LIFO displays in the left column, indicating you can switch the view to LIFO sequence).
View ticklers for user or tickler group? The User field or Group field displays at the top of the screen indicating if you are viewing:
-
ticklers assigned to a particular user, or
-
ticklers assigned to a particular tickler group for the user
Select User or Group to toggle between viewing ticklers for a particular user or tickler group for the user; when you first advance to this screen, ticklers display for the user who advanced to the screen. If the user is assigned to more than one tickler group, the Select User Tickler Group Screen displays when you toggle to view ticklers for a tickler group.
Searching for ticklers: You can search for specific ticklers by tickler status, tickler priority, assigned date, event code, tickler category, tickler number, order number, sold to customer number, bill to customer number, and item number.
How to display this screen: Enter WTIC in the Fast path field or select Work with Tickler by User/User Group from a menu.
Field | Description |
---|---|
User |
The user ID and description of the user assigned to work with the displayed ticklers. This field displays only if you are viewing ticklers for the signed-in user; you can view ticklers for a tickler user group defined for the user by selecting Group; if the user is assigned to more than one tickler user group, the system advances you to the Select User Tickler Group Screen where you can select the tickler user group whose ticklers you wish to review. User ID: Alphanumeric, 10 positions; display-only. User description: Alphanumeric, 30 positions; display-only. |
Group |
The tickler user group ID and description of the tickler user group assigned to resolve the displayed ticklers. This is a tickler user group assigned to the user reviewing ticklers. This field displays only if you viewing ticklers for a tickler user group; you can view ticklers for the signed-in user by selecting User. Group ID: Alphanumeric, 10 positions; display-only. |
S (Tickler status) |
The status of the tickler.
Alphanumeric, 1 position; optional. |
P (Tickler priority) |
The priority of the tickler, indicating how important the issue associated with the tickler is to resolve (1 is the lowest priority and 9 is the highest priority). Numeric, 1 position; optional. |
Assign date |
The date the tickler was assigned to the user or tickler user group. Numeric, 6 positions (user date format); optional. |
Event code |
The code for the tickler event that created the tickler.
See System Delivered Tickler Events. Alphanumeric, 2 positions; optional. |
Event Cat (Event category) |
The tickler category assigned to the tickler. Tickler categories are defined in and validated against the Tickler Category table; see Working with Tickler Category (WTCT). Alphanumeric, 3 positions; optional. |
Tickler number |
The tickler number assigned to the tickler, from the Tickler Number number assignment record. Numeric, 9 positions; optional. |
Order status |
The status of the order associated with the tickler.
Alphanumeric, display-only. |
Order number |
The order associated with the tickler. Numeric, 8 positions; optional. |
Sold to |
The sold to customer associated with the tickler. Numeric, 9 positions; optional. |
Bill to |
The bill to customer associated with the tickler. Numeric, 7 positions; optional. |
Item |
The item associated with the tickler. Alphanumeric, 12 positions; optional. |
Screen Option | Procedure |
---|---|
Change a tickler |
Select Change for a tickler to advance to the Change Tickler Screen. |
Delete a MN tickler |
Select Delete for a tickler to delete it. You can only delete MN (manually created) ticklers. |
Display a tickler |
Select Display for a tickler to advance to the Display Tickler Screen. You cannot change any fields on this screen. See the Change Tickler Screen for field descriptions. |
Release the order associated with the tickler from hold |
Select Release for a tickler to advance to the Release Reason Prompt Pop-Up Window (order header hold), Release Reason Prompt Pop-Up Window (recipient hold), and/or Release Order Payment Method Window (pay type hold). If you release an order from hold for an HO tickler, the system automatically resolves the tickler. Also, the system evaluates any other ticklers associated with the order to determine if they can be resolved. Pick slip preparation: When you release an order from hold, the system determines whether the order is eligible for pick slip preparation; see Preparing Orders for Pick Slip Generation. Errors:
Note: You must have authority to the Release Held Orders (ERHO) menu option to release the order from hold. |
Select a tickler to work on |
Select In Process for a tickler to change the status of the tickler from open (O) to in process (I). You can only select to work with a tickler that is in an open status; if you select In process for a tickler that is in an in process (I) or resolved (R) status, an error message indicates: Tickler status cannot be changed - resolved or already in process. Selecting this option automatically assigns the tickler to the user and creates a tickler history record. If you are on the Work with Tickler screen (group view), the tickler is cleared from the screen; you can view the tickler on the Work with Tickler screen (user view). |
Enter or review tickler work notes |
Select Notes for a tickler to advance to the work notes screen, based on the note type defined for the tickler. Note type A advances you to the Edit Customer Actions Window. Note type B advances you to the Work with Bill To Notes Screen. Note type O advances you to the Work with Order Messages Screen. Note type S advances you to the Edit Customer Notes Screen. Note type T advances you to the Work with Tickler Notes Screen. |
Review the tickler source |
Select Detail for a tickler to advance to the source screen, based on the tickler event associated with the tickler. BO, CO, HO, NO, OO, SO, UP, VP, and WF ticklers advance you to the Order Inquiry Header Screen. You cannot view the source for MN ticklers: Requested tickler has no source reference. |
Review tickler history |
Select History for a tickler to advance to the Work with Tickler History Screen. |
Resolve a tickler |
Select Resolve for a tickler to advance to the Resolve Tickler Window. |
Review procedures for a tickler |
Select Procedure for a tickler to advance to the Work with Tickler Event Rule Procedure Screen. You cannot add or change tickler procedures when you advance from the Work with Tickler screen. You cannot review procedures for MN ticklers. |
Toggle between viewing ticklers for a user or ticklers for a tickler group |
Select Group or User. The system toggles between displaying:
If the user is associated with more than one tickler group, you advance to the Select User Tickler Group Screen. If the user is not associated with a tickler group an error message indicates: Current user is not associated with any group. |
Create a tickler for the MN (manually created) tickler event |
Select Create to advance to the Create Tickler Screen. Note: To create a MN tickler, you must have authority to the Create Manual Tickler (B13) secured feature and the MN tickler event must be active. |
Toggle between displaying ticklers in LIFO sequence (last in, first out; meaning newest to oldest) or FIFO sequence (first in, first out; meaning oldest to newest) |
Select LIFO or FIFO.
|
Toggle between displaying ticklers in a current status or future status |
Select Current/Future. The word CURRENT or FUTURE displays in the top right corner of the screen, depending on which ticklers you are viewing. |
Review the number of ticklers in the work queue, based on the selection criteria you have defined |
Select Count to advance to the Current Tickler Count Window. |
Review ticklers for a selected tickler user group |
Select Group to advance to the Select User Tickler Group Screen. This option is available only when you are viewing ticklers in a tickler user group work queue. |
Toggle between displaying open and in process ticklers or resolved ticklers |
Select Open/Resolved. The system toggles between displaying:
|
Create Tickler Screen
Purpose: Use this screen to create a tickler for the MN (manually created) tickler event.
You cannot create a tickler for any tickler event except MN (manually created).
When you manually create a tickler you can associate the 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.
Secured feature: To create a MN tickler, you must have authority to the Create Manual Tickler (B13) secured feature.
How to display this screen: Select Create at the Work with Tickler Screen (user/group view) or Workflow Management Screen (tickler supervisor).
You can also advance to this screen from the:
Field | Description |
---|---|
Tickler number |
The next number available from the Tickler Number number assignment record. Numeric, 9 positions; display-only. |
Category |
The tickler category assigned to the tickler. The tickler category defined for the MN tickler event defaults, but you can override it. Alphanumeric, 3 positions; required. |
Priority |
The priority of the tickler, indicating how important the issue associated with the tickler is to resolve (1 is lowest priority, 9 is highest priority). The priority defined for the MN tickler event defaults, but you can override it. Numeric, 1 position; optional. |
Notify user |
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.
See Tickler Notification for a sample email. |
Assign to user |
The user ID of the user assigned to resolve the tickler. The assign to user defined for the MN tickler event defaults, but you can override it. You can define either an assign to user or assign to user group for the tickler, 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 group ID of the tickler group assigned to resolve the tickler; when you manually create a tickler, the tickler group can be either a user group or supervisor group. The assign to group defined for the MN tickler event defaults, but you can override it. You can define either an assign to user or assign to user group for the tickler, 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. |
Assigned date |
The date the tickler is assigned to the assigned to user or assigned to tickler user group. The current date defaults, but you can enter a future date. If you enter a future date, the tickler does not display in the assigned to tickler work queue until the assigned date is equal to the current date. 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. You cannot enter a past date or an error message indicates: Must enter current date or future date. Numeric, 6 positions (user date format); required. |
Note type |
The type of notes you enter for this tickler. The note type defined for the MN tickler event defaults, but you can override it.
Alphanumeric, required. |
Short note |
A brief note you can enter for the tickler. The short note you enter displays on the Tickler Notification email and, if you reassign this tickler to another user or tickler user group, the short note displays on the Tickler Reassignment email. See Tickler Notification for a sample email. Alphanumeric, 60 positions; optional. |
Order number |
The order number and ship to number associated with the tickler. If you define an order number, you must also define the customer ship to number; if the order is associated with only 1 ship to, ship to number 1 defaults. Order numbers are defined in and validated against the Order Header table. Numeric, 8 positions; optional. |
Cust sold to number |
The customer sold to number associated with the tickler. Sold to customers are defined in and validated against the Customer Sold To table. Numeric, 9 positions; optional. |
Cust ship to number |
The customer ship to number associated with the tickler. If the order number you define is associated with only 1 ship to customer, ship to 1 defaults. Ship to customers are defined in and validated against the Customer Ship To table. Numeric, 3 positions; optional. |
Cust bill to number |
The customer bill to number associated with the tickler. Bill to customers are defined in and validated against the Customer Bill To table. Numeric, 7 positions; optional. |
Related tickler number |
The tickler number associated with the tickler. Tickler numbers are defined in and validated against the Tickler table. Numeric, 9 positions; optional. |
Screen Option | Procedure |
---|---|
Enter work notes for the newly created tickler |
Select OK to advance to the work notes screen, based on the note type defined for the tickler.
|
Change Tickler Screen
Purpose: Use this screen to change a tickler.
You can change the following information for a tickler:
-
tickler status
-
tickler priority
-
tickler category
-
assigned to user/user group
-
assigned date; you can enter a future assigned date to have a tickler assigned to a user or tickler user group in the future; ticklers with a future assign date do not display in a tickler work queue until the assign date is equal to the current date.
-
short note
Note:
Each time you advance to this screen to change a tickler, the system creates a tickler history record; see Work with Tickler History Screen.
How to display this screen: Select Change for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen (tickler supervisor).
Field | Description |
---|---|
Tickler # |
The tickler number whose information you are reviewing. Numeric, 9 positions; display-only. |
Sts (Status) |
The status of the tickler.
Note: You cannot change the status of an open or in process tickler to resolved; to resolve a tickler select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management (WWFM) (tickler supervisor). You cannot change the status of a resolved tickler. The system creates a tickler history record when you change the tickler status, indicating the “from status” and the “to status”; see Work with Tickler History Screen. Alphanumeric, required. |
Pty (Priority) |
The priority of the tickler, indicating how important the issue associated with the tickler is to resolve (1 is the lowest priority, 9 is the highest priority). The system creates a tickler history record when you change the tickler priority, indicating the “from priority” and “to priority”; see Work with Tickler History Screen. Numeric, 1 position; required. |
Note type |
The type of notes you enter for this tickler.
Alphanumeric, display-only. |
Event |
The code and description for the tickler event that created the tickler.
Alphanumeric, 2 positions; display-only. |
Rule number |
The rule sequence number and description defined for the event rule that created the tickler. Numeric, 3 positions; display-only. |
Category |
The tickler category assigned to the tickler. The system creates a tickler history record when you change the tickler category, indicating the “from category” and “to category”; see Work with Tickler History Screen. You must define a tickler category for manually created ticklers: Tickler category is required for manually created ticklers. Alphanumeric, 3 positions; optional. |
Assign to user |
The user ID and description of the user assigned to resolve the tickler. The system creates a tickler history record when you change the assign to, indicating the “from assign to” and “to assign to”; see Work with Tickler History Screen. You can define either an assign to user or assign to user group for the tickler, 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 group code and description of the tickler group assigned to resolve the tickler; when you change a tickler, the tickler group can be either a user group or supervisor group. The system creates a tickler history record when you change the assign to, indicating the “from assign to” and “to assign to”; see Work with Tickler History Screen. You can define either an assign to user or assign to user group for the tickler, 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 code and description for the supervisor group assigned to manage the tickler. This is the supervisor group the system sends a Supervisor Notification Count email when the date in the Date to notify supervisor field is reached. The system sends an email to the email address defined for the supervisor group in the Tickler User Group table. Alphanumeric, 10 positions; display-only. |
Assigned date |
The date the tickler was assigned to the user or tickler user group. You can enter a future assigned date to have a tickler assigned to a user or user group in the future. The system creates a tickler history record when you change the assigned date, indicating the “from assigned date” and “to assigned date”; see Work with Tickler History Screen. If you enter a future date, the tickler does not display in the assigned to tickler work queue until the assigned date is equal to the current date. You cannot enter a past date or an error message indicates: Must enter current date or future date. Numeric, 6 positions (user date format); required. |
Date to notify supervisor |
Indicates the date the system sends a Supervisor Notification Count email to the assigned supervisor group, notifying the supervisor that the tickler has not yet been resolved. The system sends a Supervisor Notification Count email if the date to notify supervisor is equal to or past the current 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 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 the tickler assigned to the supervisor group is in an open or in process status. See Tickler Notification for a sample email. Numeric, 6 positions (user date format); display-only. |
Created by user |
The user ID of the user that created the tickler. Alphanumeric, 10 positions; display-only. |
Created on...at |
The date and time when the tickler was created. Created date: Numeric, 6 positions (user date format); display-only. Created time: Numeric, 6 positions (HHMMSS format); display-only. |
Source |
The program that created the tickler. Alphanumeric, 10 positions; display-only. |
Original user |
The user ID of the user originally assigned to resolve the tickler. Alphanumeric, 10 positions; display-only. |
Original group |
The code for the tickler user group originally assigned to resolve the tickler. Alphanumeric, 10 positions; display-only. |
Short note |
A brief note you can enter to further describe the tickler. This note displays on the Tickler Notification email and Tickler Reassignment email. Alphanumeric, 60 positions; optional. |
Order # |
The order number and ship to number associated with the tickler. Order number: Numeric, 8 positions; display-only. Ship to number: Numeric, 3 positions; display-only. |
Cust sold to # |
The customer sold to number associated with the tickler. Numeric, 9 positions; display-only. |
Cust ship to # |
The customer ship to number associated with the tickler. Numeric, 3 positions; display-only. |
Cust bill to # |
The bill to customer number associated with the tickler. Numeric, 7 positions; display-only. |
Item/SKU |
The item and optionally, SKU, associated with the tickler. Item: Alphanumeric, 12 positions; display-only. SKU: Alphanumeric, 14 positions; display-only. |
Pick control # |
The pick control number associated with the tickler. Numeric, 7 positions; display-only. |
Related tickler # |
The tickler number associated with the tickler. Numeric, 9 positions; display-only. |
Email sequence # |
The email sequence number associated with the tickler. Numeric, 11 positions; display-only. |
Screen Option | Procedure |
---|---|
Enter or change work notes for the tickler |
Select Notes to advance to the work notes screen, based on the note type defined for the tickler.
|
Work with Tickler Notes Screen
Purpose: Use this screen to enter work notes regarding the activity a user performed to resolve the tickler.
Work with Tickler History ScreenTickler work notes screen: The screen where you enter activity notes for a tickler varies, depending on the note type defined for the tickler in the Tickler table.
Tickler work notes screen: The screen where you enter activity notes for a tickler varies, depending on the note type defined for the tickler in the Tickler table.
-
Note type Sold To Action Notes advances you to the Edit Customer Actions Window.
-
Note type Bill To Notes advances you to the Work with Bill To Notes Screen.
- Work with Order Messages Screen
-
Note type Sold To Notes advances you to the Edit Customer Notes Screen.
-
Note type Tickler Notes advances you to the Work with Tickler Notes Screen.
When you enter work notes on the Work with Tickler Notes screen and select OK, the system updates the work notes with the user ID of the user who entered the notes and the date when the work notes were entered.
Types of work notes: Select Resolution notes or Activity notes at this screen to toggle between entering and updating activity notes or resolution notes.
-
activity notes describe the actions taken against a tickler that do not resolve the tickler. For example, if a tickler is created for a declined credit card, a user might enter activity notes indicating he reviewed the reason why the credit card was declined and assigned the tickler to another user to re-send for authorization. When a tickler is first created, the system creates an activity note: XX Tickler# 000003140 HAS BEEN CREATED. RULE:INITIAL B/O IS Y, where XX is the tickler event associated with the tickler and the RULE is the event rule associated with the tickler.
-
resolution notes describe the actions taken against a tickler that resolve the tickler. For example, if a ticker is created for a declined credit card, a user might enter resolution notes indicating he resent the credit card for authorization and received an approval (resolving the tickler). When a tickler is resolved, the system creates a resolution note: XX Tickler# 000003140 HAS BEEN RESOLVED. REASON: BO BY: KBROWN RULE:INITIAL B/O IS Y, where XX is the tickler event associated with the tickler, REASON is the resolution reason code, BY is the user ID of the person that resolved the tickler, and RULE is the event rule associated with the tickler.
How to display this screen: You can advance to this screen by:
-
selecting Notes for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen (tickler supervisor).
-
selecting OK at the Create Tickler Screen.
-
selecting Notes at the Change Tickler Screen or Display Tickler Screen.
Field | Description |
---|---|
Tickler # |
The tickler number for which you are entering or updating work notes. Numeric, 9 positions; display-only. |
Activity notes /Resolution notes |
Free-form lines where you can describe the activity performed against the tickler.
Alphanumeric, 60 positions; optional. |
User |
The user ID of the user who entered the tickler work notes or who performed the activity that created the work notes. Alphanumeric, 10 positions; display-only. |
Date |
The date the tickler work notes were entered. Numeric, 6 positions (user date format); display-only. |
Screen Option | Procedure |
---|---|
Enter new work notes or update existing work notes |
Select Add/Change to toggle between adding new lines and updating existing lines. |
Enter or update tickler resolution notes or tickler activity notes |
Select Resolution notes or Activity notes to toggle between adding and updating tickler activity notes and adding and updating tickler resolution notes. |
Work with Tickler History Screen
Purpose: Use this screen to review the history of a tickler, indicating the activity performed against the tickler.
The system creates a tickler history record when:
-
the tickler is created
-
the tickler is changed
-
work notes for the tickler are added/updated, regardless of the type of work notes you enter
-
the tickler is resolved
How to display this screen: Select History at the Work with Tickler Screen (user/group view) or Workflow Management Screen (tickler supervisor).
Field | Description |
---|---|
Tickler # |
The tickler number whose history you are reviewing. Numeric, 9 position; display-only. |
Activity date |
The date when the system created the tickler history record; this is the date when the tickler was created or updated. Numeric, 6 positions (user date format); optional. |
Activity time |
The time when the system created the tickler history record; this is the time when the tickler was created or updated. Numeric, 6 positions (HH:MM:SS format); display-only. |
Activity user |
The user ID of the user that updated the tickler, creating the tickler history record. Alphanumeric, 10 positions; optional. |
To user |
The user ID of the user assigned to work with the tickler, based on the update performed against the tickler. Alphanumeric, 10 positions; display-only. |
To group |
The code for the user group assigned to work with the tickler, based on the update performed against the tickler. Alphanumeric, 10 positions; display-only. |
To sts (To status) |
The status of the tickler, based on the update performed against the tickler.
Alphanumeric, 1 position; display-only. |
To pty (To priority) |
The priority assigned to the tickler, based on the update performed against the tickler (1 is the lowest priority and 9 is the highest priority). Numeric, 1 position; display-only. |
To cat (To category) |
The category assigned to the tickler, based on the update performed against the tickler. Alphanumeric, 3 positions; display-only. |
Assign date |
The date the tickler was assigned to the current user or tickler user group. Numeric, 6 positions (user date format); display-only. |
Screen Option | Procedure |
---|---|
Review tickler history details |
Select Display for a tickler to advance to the Display Tickler History Screen. |
Display Tickler History Screen
Purpose: Use this screen to review the tickler history details.
This screen indicates the tickler detail changed from this (previous tickler detail), to that (current tickler detail), where the specific detail being updated is:
-
assigned to user
-
assigned to user group
-
assigned to supervisor group
-
tickler status
-
tickler priority
-
next notification date
-
rule sequence number
-
assigned date
-
graduated date
-
short note
-
tickler category
-
note change (indicating tickler work notes were added or updated)
-
source program (indicating the program that created or updated the tickler)
Note:
The From detail is identical to the To detail if the detail was not updated for the tickler history record. For example, the From tickler status is identical to the To tickler status if the history record was created as a result of the tickler category changing from S1 to S2.
How to display this screen: Select Display for a tickler history record at the Work with Tickler History Screen.
Field | Description |
---|---|
Tickler # |
The tickler number whose history you are reviewing. Numeric, 9 position; display-only. |
Date |
The date and time when the tickler was updated, creating this tickler history record. Date: Numeric, 6 positions (user date format); display-only. Time: Numeric, 6 positions (HH:MM:SS format); display-only. |
User |
The user ID of the user that updated the tickler, creating this tickler history record. Alphanumeric, 10 positions; display-only. |
From user |
The user ID and description of the user previously assigned to the tickler. Alphanumeric, 10 positions; display-only. |
To user |
The user ID and description of the user currently assigned to the tickler. Alphanumeric, 10 positions; display-only. |
From user group |
The code and description of the tickler user group previously assigned to the tickler. Alphanumeric, 10 positions; display-only. |
To user group |
The code and description of the tickler user group currently assigned to the tickler. Alphanumeric, 10 positions; display-only. |
From supervisor group |
The code and description of the tickler supervisor group previously assigned to the tickler. Alphanumeric, 10 positions; display-only. |
To supervisor group |
The code and description of the tickler supervisor group currently assigned to the tickler. Alphanumeric, 10 positions; display-only. |
From status |
The code for the status previously assigned to the tickler. Alphanumeric, 1 position; display-only. |
To status |
The code for the status currently assigned to the tickler. Alphanumeric, 1 position; display-only. |
From priority |
The priority previously assigned to the tickler. Numeric, 1 position; display-only. |
To priority |
The priority currently assigned to the tickler. Numeric, 1 position; display-only. |
From next notify date |
The next notification date previously assigned to the tickler. The next notification date is updated only for graduating ticklers (AR, OO, and UP tickler events). Numeric, 6 positions; display-only. |
To next notify date |
The next notification date currently assigned to the tickler. Numeric, 6 positions; display-only. |
From rule seq # |
The rule sequence number and description previously assigned to the tickler. Numeric, 3 positions; display-only. |
To rule seq # |
The rule sequence number and description currently assigned to the tickler. Numeric, 3 positions; display-only. |
From assigned date |
The assigned date and time previously assigned to the tickler. Date: Numeric, 6 positions (user date format); display-only. Time: Numeric, 6 positions (HH:MM:SS format); display-only. |
To assigned date |
The assigned date and time currently assigned to the tickler. Date: Numeric, 6 positions (user date format); display-only. Time: Numeric, 6 positions (HH:MM:SS format); display-only. |
From graduated date |
The graduated date previously assigned to the tickler. Numeric, 6 positions (user date format); display-only. |
To graduated date |
The graduated date currently assigned to the tickler. Numeric, 6 positions (user date format); display-only. |
From note |
The short note previously assigned to the tickler. Alphanumeric, 60 positions; display-only. |
To note |
The short note currently assigned to the tickler. Alphanumeric, 60 positions; display-only. |
From category |
The tickler category previously assigned to the tickler. Alphanumeric, 3 positions; display-only. |
To category |
The tickler category currently assigned to the tickler. Alphanumeric, 3 positions; display-only. |
Note change |
Indicates if the tickler work notes have been updated.
|
Source program |
The program that created or updated the tickler. Alphanumeric, 10 positions; display-only. |
Resolve Tickler Window
Purpose: Use this window to select a resolution reason and resolve a tickler.
You can resolve ticklers that are in an O (open) or I (in process) status.
How to display this screen: Select Resolve for a tickler at the Work with Tickler Screen (user/group view) or Workflow Management Screen (tickler supervisor).
Field | Description |
---|---|
Tickler # |
The tickler number you are resolving. Numeric, 9 positions; display-only. |
Resolution reason |
The tickler resolution reason, to identify the reason why the tickler is resolved. 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. |
Screen Option | Procedure |
---|---|
Enter tickler resolution notes |
Select OK to advance to the work notes screen, based on the note type defined for the tickler.
|
Current Tickler Count Window
Purpose: Use this window to review the number of ticklers currently in view, based on the selection criteria you defined at the Work with Tickler Screen (user/group view).
The selection criteria you can define is:
-
tickler status
-
tickler number
-
priority
-
assigned date
-
event
-
category
-
current user
-
supervisor group
-
order number
-
customer sold to number
-
customer bill to number
-
item
A value displays next to the fields you have selected as criteria.
Work with Tickler Screen (user/group view)How to display this screen: Select Count at the Work with Tickler Screen (user/group view) or Workflow Management Screen (tickler supervisor).
Field | Description |
---|---|
Tickler count is |
The number of ticklers currently in view, based on the selection criteria you defined at the Work with Tickler Screen (user/group view). Numeric, 9 positions; display-only. |
Status |
The status of the ticklers currently in view. Alphanumeric, 1 position; display-only. |
Tickler # |
The tickler number currently in view. Numeric, 9 positions; display-only. |
Priority |
The priority assigned to the ticklers currently in view. Numeric, 2 positions; display-only. |
Assigned date |
The assigned date of ticklers currently in view. Numeric, 6 positions (user date format); display-only. |
Event |
The event code assigned to ticklers currently in view. Alphanumeric, 2 positions; display-only. |
Category |
The tickler category assigned to ticklers currently in view. Alphanumeric, 3 positions; display-only. |
Current user |
The user ID of the user assigned to ticklers currently in view. Alphanumeric, 10 positions; display-only. |
Supervisor group |
The supervisor group assigned to ticklers currently in view. Alphanumeric, 10 positions; display-only. |
Order # |
The order number assigned to ticklers currently in view. Numeric, 8 positions; display-only. |
Customer sold to # |
The sold to customer assigned to ticklers currently in view. Numeric, 9 positions; display-only. |
Customer bill to # |
The bill to customer assigned to ticklers currently in view. Numeric, 7 positions; display-only. |
Item |
The item associated with the ticklers currently in view. Alphanumeric, 12 positions; display-only. |
Select User Tickler Group Screen
Purpose: Use this screen to select the tickler group whose ticklers you wish to review.
How to display this screen:
-
Select Group at the Work with Tickler Screen (user/group view). All tickler groups (both user and supervisor) assigned to the signed-in user display.
-
Select Supervisor at the Workflow Management Screen. All tickler supervisor groups assigned to the signed-in user display.
Field | Description |
---|---|
User |
The user ID of the signed-in user; this is the user whose tickler groups you are reviewing. Alphanumeric; 10 positions; display-only. |
Group ID |
The tickler group ID code of the tickler groups assigned to the signed-in user. Alphanumeric, 10 positions; optional. |
Screen Option | Procedure |
---|---|
Select the tickler group whose ticklers you wish to review |
Select a tickler group to advance to the: Work with Tickler Screen (user/group view) for the group view. Workflow Management Screen for the supervisor view. |
Select Tickler User Group Screen
Purpose: Use this screen to select the tickler group whose ticklers you wish to review. You can also view the users assigned to each group.
The tickler group type indicates if the tickler group is a user group (type U) or supervisor group (type S).
How to display this screen:
-
Select Select Group at the Work with Tickler Screen (user/group view). All tickler groups (both user and supervisor) assigned to the signed-in user display.
-
Select Select Group at the Workflow Management Screen (supervisor view). All tickler supervisor groups (both user and supervisor) assigned to the signed-in user display.
Field | Description |
---|---|
Group ID |
Work with Tickler Screen (user/group view): The group ID code of the tickler groups assigned to the signed-in user. Workflow Management Screen: The group ID code of a tickler supervisor group. This screen displays ALL tickler supervisor groups, regardless of tickler assignment. Tickler user groups do not display on the screen. Alphanumeric, 10 positions; optional. |
Description |
A description of the tickler group. Alphanumeric, 40 positions; optional. |
Type |
The type of tickler group.
Alphanumeric, 1 position; optional. |
Screen Option | Procedure |
---|---|
Select the tickler group whose ticklers you wish to review |
Select a tickler group to advance to the: Work with Tickler Screen (user/group view) for the group view. Workflow Management Screen for the supervisor group view. |
Review the users in a tickler group |
Select Users in group for a tickler group to advance to the Display Users In Group Screen. |
Workflow Management (WWFM)
Purpose: Use this menu option to review, work with, and resolve ticklers in a tickler work queue. Tickler supervisors can work with ticklers assigned to their tickler supervisor groups or work with all ticklers, regardless of the tickler supervisor group assigned to the tickler.
Tickler users/groups: Tickler users can review and work with ticklers assigned to themselves or their tickler user groups using the Working with Tickler Users/User Groups (WTIC) menu option.
In this topic:
Workflow Management Screen
Purpose: Use this screen to review, work with, and resolve ticklers in a tickler work queue.
View current or future ticklers? The word CURRENT or FUTUREdisplays in the upper right corner of the screen indicating if you are viewing:
-
ticklers whose Assigned date is equal to or past the current date (current), or
-
ticklers whose Assigned date is later than the current date (future)
Select Current/future to toggle between viewing current ticklers or future ticklers; when you first advance to this screen, current ticklers display.
View open or resolved ticklers? The word OPEN or RESOLVED displays in the upper right corner of the screen indicating if you are viewing:
-
ticklers whose Status is O (open) or I (in process), or
-
ticklers whose Status is R (resolved)
Select Open/resolved to toggle between viewing open and in process ticklers or resolved ticklers; when you first advance to this screen, open ticklers display.
View FIFO or LIFO sequence? The word FIFO or LIFO displays in the upper left corner of the screen indicating if you are viewing:
-
ticklers in FIFO (first in, first out; meaning oldest to newest) sequence, or
-
ticklers in LIFO (last in, first out; meaning newest to oldest) sequence
Select FIFO or LIFO to toggle between viewing ticklers in FIFO sequence or LIFO sequence; when you first advance to this screen, ticklers display in FIFO sequence.
View all ticklers or for supervisor group? The word ALL or the Supervisor group field displays at the top of the screen indicating if you are viewing:
-
all ticklers, regardless of the supervisor group assigned to the ticklers
-
ticklers assigned to a particular tickler supervisor group for the signed-in user
Select Supervisor to toggle between viewing all ticklers or ticklers for a specific tickler supervisor group. When you first advance to this screen, ticklers for the supervisor group display if you are assigned to only one supervisor group. If you are assigned to none or more than one supervisor group, all ticklers display.
Searching for ticklers: You can search for specific ticklers by tickler status, tickler priority, created date, assigned date, event code, tickler category, tickler number, user group, user, and order number.
How to display this screen: Enter WWFM in the Fast path field or select Workflow Manager from a menu.
Field | Description |
---|---|
Supervisor group |
The group ID and description of the tickler supervisor group assigned to monitor the displayed ticklers. This is a tickler supervisor group assigned to the user reviewing ticklers. This field displays only if you are viewing ticklers for a tickler supervisor group; you can view all ticklers by selecting All. Group ID: Alphanumeric, 10 positions; display-only. |
Status |
The status of the tickler. Open = The tickler is open and is available to work on in the assigned tickler work queue. In process = The tickler is currently being worked on by the assigned user. Resolved = The tickler has been resolved. Alphanumeric, 1 position; optional. |
P (Tickler priority) |
The priority of the tickler, indicating how important the issue associated with the tickler is to resolve (1 is the lowest priority and 9 is the highest priority). Numeric, 1 position; optional. |
Create date |
The date the tickler was created. Numeric, 7 positions (in user date format); optional. |
Assign date |
The date the tickler was assigned to the user or tickler user group. Numeric, 7 positions (in user date format); optional. |
Cd (Event code) |
The code for the tickler event that created the tickler. BO = Backorders CO = Cancelled orders HO = Held orders MN = Manually created NO = New orders OO = Aged open orders SO = Sold out orders UP = Unconfirmed pick tickets VP = Voided pick tickets WF = Remote workflow See System Delivered Tickler Events. Alphanumeric, 2 positions; optional. |
Cat (Event category) |
The tickler category assigned to the tickler. Tickler categories are defined in and validated against the Tickler Category table; see Working with Tickler Category (WTCT). Alphanumeric, 3 positions; optional. |
Tickler number |
The tickler number assigned to the tickler, from the Tickler Number number assignment record. Numeric, 9 positions; optional. |
User group |
The tickler user group assigned to the tickler. Tickler user groups are defined in and validated against the Tickler User Group table; see Working with Tickler User Groups (WTUG). Alphanumeric, 10 positions; optional. |
User |
The user assigned to the tickler. Users are defined in and validated against the User table; see Working with User Records (WUSR). Alphanumeric, 10 positions; optional. |
Sts (Order status) |
The status of the order associated with the tickler. blank = Open. A = Archived to optical disk. This option is not currently implemented. C = Cancelled. H = Held. Note: The system highlights the held status in a different color (for example fuchsia) if the sold to customer is a new customer, based on purchase history. A new customer has placed an order, but no orders have shipped (# orders LTD is equal to or greater than 1 and # sales LTD is equal to 0 in the Customer Sold To Order History table). P = Purged. S = Suspended. X = Closed. Alphanumeric, 1 position; display-only. |
Order number |
The order associated with the tickler. Numeric, 8 positions; optional. |
Screen Option | Procedure |
---|---|
Change a tickler |
Select Change for a tickler to advance to the Change Tickler Screen. |
Delete a MN tickler |
Select Delete for a tickler to delete it. You can only delete MN (manually created) ticklers. |
Display a tickler |
Select Display for a tickler to advance to the Display Tickler screen. See the Change Tickler Screen for more information. |
Release the order associated with the tickler from hold |
Select Release for a tickler to advance to the Release Reason Prompt Pop-Up Window (order header hold), Release Recipient Hold Reason Pop-Up Window (recipient hold), and/or Release Order Payment Method Window (pay type hold). If you release an order from hold for an HO tickler, the system automatically resolves the tickler. Also, the system evaluates any other ticklers associated with the order to determine if they can be resolved. |
|
If you select Release for a tickler not associated with a held order, an error message indicates: Order not on hold. If you select Release for a tickler not associated with an order, an error message indicates: Tickler not eligible for this option. Note: You must have authority to the Release Held Orders (ERHO) menu option to release the order from hold. |
Select a tickler to work on |
Select In Process for a tickler to change the status of the tickler from open (O) to in process (I). You can only select to work with a tickler that is in an open status; if you select In process for a tickler that is in an in process (I) or resolved (R) status, an error message indicates: Tickler status cannot be changed - resolved or already in process. Selecting this option automatically assigns the tickler to the user and creates a tickler history record. If you are on the Workflow Management screen (supervisor view), the tickler is cleared from the screen; you can view the tickler on the Workflow Management screen (all ticklers view) or in the Working with Tickler Users/User Groups (WTIC) menu option. |
Enter or review tickler work notes |
Select Notes for a tickler to advance to the work notes screen, based on the note type defined for the tickler. Note type A advances you to the Edit Customer Actions Window. Note type B advances you to the Work with Bill To Notes Screen. Note type O advances you to the Work with Order Messages Screen. Note type S advances you to the Edit Customer Notes Screen. Note type T advances you to the Work with Tickler Notes Screen. |
Review the tickler source |
Select Detail for a tickler to advance to the source screen, based on the tickler event associated with the tickler. BO, CO, HO, NO, OO, SO, UP, VP, and WF ticklers advance you to the Order Inquiry Header Screen. You cannot view the source for MN ticklers: Requested tickler has no source reference. |
Review tickler history |
Select History for a tickler to advance to the Work with Tickler History Screen. |
Resolve a tickler |
Select Resolve for a tickler to advance to the Resolve Tickler Window. |
Review procedures for a tickler |
Select Procedure for a tickler to advance to the Work with Tickler Event Rule Procedure Screen. You cannot add or change tickler procedures when you advance from the Work with Tickler screen. You cannot review procedures for MN ticklers. |
Toggle between viewing all ticklers or ticklers for a tickler supervisor group |
Select All or Supervisor. The system toggles between displaying:
If the user is associated with more than one supervisor group, you advance to the Select User Tickler Group Screen. If the user is not associated with a tickler supervisor group an error message indicates: Current user is not associated with any group. |
Create a tickler for the MN (manually created) tickler event |
Select Create to advance to the Create Tickler Screen. Note: To create a MN tickler, you must have authority to the Create Manual Tickler (B13) secured feature and the MN tickler event must be active. |
Toggle between displaying ticklers in LIFO sequence (last in, first out; meaning newest to oldest) or FIFO sequence (first in, first out; meaning oldest to newest) |
Select LIFO or FIFO. The word LIFO or FIFO displays in the top left corner of the screen, depending on which tickler order you are viewing. |
Toggle between displaying ticklers in a current status or future status |
Select Current/future. The word CURRENT or FUTURE displays in the top right corner of the screen, depending on which ticklers you are viewing. |
Review the number of ticklers in the work queue, based on the selection criteria you have defined |
Select Count to advance to the Current Tickler Count Window. |
Review ticklers for a selected tickler supervisor group |
Select Select Group to advance to the Select User Tickler Group Screen. This option is available only when you are viewing tickles in a tickler supervisor group work queue. |
Toggle between displaying open and in process ticklers or resolved ticklers |
Select Open/resolved. The system toggles between displaying:
|
Reassign ticklers to another user/user group |
Select Reassign to advance to the Reassign Tickler window. |
Print the Tickler Listing By Current User/Group report |
Enter a Supervisor group, User group, or User and select List. The system displays the message Job TKL_LIST submitted to job queue QBATCH and generates the Tickler Listing by Current User/Group report. This report lists the ticklers assigned to the specified user or group. Note: The error message A user, user group, or supervisor group must be entered first displays if you do not indicate the user or group for which you wish to generate the report. |
Reassign Ticklers Window
Purpose: Use this window to reassign ticklers to another user or tickler user group.
The system reassigns all ticklers currently assigned to the From tickler user/group to the To tickler user/group; you cannot select a range of ticklers to reassign.
You can reassign a specific tickler to another tickler user or tickler user group at the Change Tickler Screen.
How to display this screen: Select Reassign at the Workflow Management Screen.
Field | Description |
---|---|
From tickler user |
The user ID of the user currently assigned to the ticklers you wish to reassign. You can reassign ticklers from a user or tickler group, but not both. Users are defined in and validated against the User table; see Working with User Records (WUSR). Alphanumeric, 10 positions; required if From tickler group is blank. |
From user group |
The group ID of the tickler group currently assigned to the ticklers you wish to reassign; this can be a tickler user group or tickler supervisor group. You can reassign ticklers from a user or tickler group, but not both. Tickler groups are defined in and validated against the Tickler User Group table; see Working with Tickler User Groups (WTUG). Alphanumeric, 10 positions; required if From tickler user is blank. |
To tickler user |
The user ID of the user reassigned to the ticklers. You can reassign ticklers to a user or tickler user group, but not both. Users are defined in and validated against the User table; see Working with User Records (WUSR). Alphanumeric, 10 positions; required if To tickler group is blank. |
To tickler user group |
The group code of the tickler user group reassigned to the ticklers; this can be a tickler user group or tickler supervisor group. You can reassign ticklers to a user or tickler user group, but not both. Tickler user groups are defined in and validated against the Tickler User Group table; see Working with Tickler User Groups (WTUG). Alphanumeric, 10 positions; required if To tickler user is blank. |
Purging Ticklers (MPTK)
Purpose: Use this menu option to purge resolved ticklers that are older than a specified purge date.
The system purges ticklers that are in an R (resolved) status; the system does not purge ticklers that are in an O (open) or I (in process) status.
Which date? The system looks at the Resolution date in the Tickler table for the resolved tickler to determine if the tickler is older than the purge date you specify.
Purge Tickler Screen
Use this screen to define the date you wish to use for purging ticklers. The system purges resolved ticklers whose Resolution date is older than the purge date you specify.
How to display this screen: Enter MPTK in the Fast path field or select Purge Ticklers from a menu.
Field | Description |
---|---|
Purge date |
The date you wish to use for purging ticklers. The system purges ticklers that are in a resolved status whose Resolution date is older than the purge date you specify. Numeric, 6 positions (in user date format); required. |
Screen Option | Procedure |
---|---|
Submit the Tickler Purge job to purge ticklers |
Select Submit. The system displays the Confirm Accept window; select OK to submit the TKL_PURGE job. |
Point of Sale Integration
Topics in this part: This part describes integration between Order Management System 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 Management System and an external system such as Order Broker 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.
-
Customer Engagement Batch Customer and Sales Integration describes the process of sending customer, item, sales and return information from Order Management System to Oracle Retail Customer Engagement.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Working with Outbound Interface Transactions (WOIT)
Purpose: Use this option to review triggers in the IL Outbound Trigger table.
Certain actions in Order Management System triggers the system to create IL outbound triggers.
In this topic:
You can create triggers for the following information.
Information | Generated When | See: | File/ Key |
---|---|---|---|
stored value card authorization reversals |
a cancellation is processed against a stored value card payment or the stored value card payment is deactivated and an open, unused authorization amount exists |
AHR |
|
credit card authorization reversals |
the Send reversal field for the service bureau is selected and a cancellation is processed against a credit card payment or the credit card payment is deactivated and an open, unused authorization amount exists |
AHR |
|
ChannelAdvisor shipments |
the BILL_ASYNC job processes a shipment for an order whose type matches the ChannelAdvisor Order Type (L90) |
CAS |
|
customers |
the Create Generic Customer Download Triggers (L12) system control value is selected |
Generic Customer Download API For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
CST |
invoices |
the Create Generic Invoice Download Trigger Records (I17) system control value is selected |
Generic Invoice Download API and Integration with the Sales Audit Module of the Oracle Retail Merchandising Foundation Cloud Service For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
IHD |
inventory |
the Create Generic Inventory Download Triggers (I32) system control value is selected |
Generic Inventory Download API For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
ITW |
pick slips |
the Create Generic Pick Download Triggers (I31) system control value is selected |
Generic Pick Out API For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
PCH |
purchase orders |
the Use WMS Integration (K25) and/or Create Generic PO Download Triggers (K26) and/or Create Generic PO Download Trigger for PO Receipt (K27) system control values are selected |
Generic Outbound Purchase Order API For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
POH |
return authorizations |
the Create Return Download Triggers (K28) system control value is selected |
RAD |
|
items/SKUs |
the Create Generic Item Download Trigger Records (I15) system control value is selected |
Generic Item Download API For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
SKU |
stored value cards |
a stored value card item is processed through billing |
SVC |
|
vendors |
the Create Generic Vendor Download Trigger Records (I16) system control value is selected |
Generic Vendor Download API For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
VND |
Mass trigger creation: Additionally, you can create triggers for all item/SKUs, vendors, item warehouses (inventory), and/or invoices using the Generating Outbound Interface Triggers (GOIT) menu option.
Jobs in the Working with Integration Layer Processes (IJCT) menu option monitor the triggers in the IL Outbound Trigger table. At certain intervals the jobs process the triggers and generate a download XML message to send to another system.
Each trigger in the IL Outbound Trigger table contains a File code, indicating the Order Management System table(s) associated with the trigger, the key fields necessary to retrieve the information, and which IL Process job processes the trigger record.
Trigger rules: You can define trigger rules for the following IL Process jobs to determine when the system generates a trigger, based on criteria defined. The record for which you wish to create a trigger must meet the trigger rule criteria in order to create a trigger in the IL Outbound Trigger table; see Defining Outbound Interface Trigger Rules.
Example: If a trigger rule for the Item Outbound job is that the item’s Allow SKU field must equal ’Y’, the system creates a trigger only for SKU’ed items.
If you generate triggers for: | look at trigger rules for IL Process job: | trigger rules are based on criteria for this table: |
---|---|---|
customers |
Customer Download Outbound |
Customer Sold To (Company, Customer class, Inactive?, Country) |
item |
Item Outbound |
Item (INITEM) SKU (INSKU) See Item Outbound Trigger Rules. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
vendor |
Vendor Outbound |
Vendor (POVEND) See Vendor Outbound Trigger Rules. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
invoice |
Invoice Outbound |
Invoice Header (OEINHD) Order Header (OEORDR) See Invoice Outbound Trigger Rules. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
inventory |
Inventory Download |
Item (INITEM) Item Warehouse (INIWRE) SKU (INSKU) Warehouse (INWRHS Item UPC (ITMUPC) See Inventory Download Trigger Rules. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
pick slips |
Pick Outbound |
Pick Control Header (FLPCTH) See Pick Out Processing. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
purchase order |
Purchase Order Outbound |
Purchase Order Header (POH) See Purchase Order Download Trigger Rules For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
return authorization |
Return Authorization Outbound |
Order Header (OEORDR) |
Note:
Direct table updates are not captured in the IL Outbound Trigger table.
IL Outbound Triggers
This table indicates:
-
when the system creates a trigger
-
the File code assigned to each trigger created
-
the referenced tables, based on the File code
-
the key data captured in the Key field
-
the IL Process job that processes the trigger.
File code | Created when | Refers to table(s) | Key | IL Process job |
---|---|---|---|---|
AHR |
A cancellation is processed against a stored value card or credit card payment or the stored value card or credit card payment is deactivated and an open, unused authorization amount exists. |
Auth History SVC Reversal |
11122222222333444555 where: 111 is the company code 22222222 is the order number 333 is the order payment method sequence number 444 is the authorization sequence number 555 is the authorization reversal sequence number |
SVC_REVRSL (for stored value cards) |
CAS |
The BILL_ASYNC job processes a shipment for an order whose type matches the ChannelAdvisor Order Type (L90) |
Order Header Invoice Header |
111222222223333333 where: 111 is the company code 22222222 is the order number 3333333 is the invoice number |
N/A (processed by the CASHIP periodic function) |
CST |
You create, change, or delete a customer |
Customer Sold To |
11122222222333444555 where: 111 is the company code 222222222 is the customer number |
CUST_OUT |
IHD |
An invoice is created or updated, if the Create Generic Invoice Download Trigger Records (I17) system control value is selected |
Invoice Header Order Header |
111222222223333333 where: 111 is the company code 22222222 is the order number 3333333 is the invoice number |
INVOIC_ OUT |
ITW |
The item/SKU’s availability threshold is breached, if the Create Generic Inventory Download Triggers (I32) system control value is selected, and when you create or maintain a purchase order for the item, if the Include PO Updates (J93) system control value is selected |
Item Warehouse |
11122222222222233333333333333 where: 111 is the company code 222222222222 is the item number 33333333333333 is the SKU code |
INV_ DOWNLD |
PCH |
A pick slip is generated, if the Create Generic Pick Download Triggers (I31) system control value is selected |
Pick Control Header |
1112222222 where: 111 is the company code 2222222 is the pick control number |
PICK_OUT |
POH |
A purchase order outbound trigger is generated, if the Create Generic PO Download Triggers (K26) system control value is selected. |
PO Header |
1112222222 where: 111 is the company code 2222222 is the purchase order number |
PO_OUT |
RAD |
A return authorization is created, changed, or deleted if the Create Return Download Triggers (K28) system control value is selected |
RA Detail |
11122222222333444555 where: 111 is the company code 22222222 is the order number 333 is the ship to number 444 is the return authorization number 555 is the return authorization line number |
RETURN_OUT |
SKU |
An item or SKU is added, updated or deleted, if the Create Generic Item Download Trigger Records (I15) system control value is selected |
Item SKU |
11122222222222233333333333333 where: 111 is the company code 222222222222 is the item number 33333333333333 is the SKU code |
ITEM_OUT |
SVC |
An order containing a stored value card item that is assigned a number is processed through the Billing Async; see Stored Value Card Purchase and Activation |
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 |
VND |
A vendor is added, updated or deleted, if the Create Generic Vendor Download Trigger Records (I16) system control value is selected |
Vendor Vendor Extended |
1112222222 where: 111 is the company code 2222222 is the vendor code |
VENDOR_ OUT |
Work with Outbound Interface Transactions Screen
Purpose: Use this screen to review the triggers in the IL Outbound Trigger table.
How to display this screen: Enter WOIT in the Fast path field or select Work with Outbound Interface Transactions from a menu.
Field | Description |
---|---|
File |
A code identifying the Order Management System table(s) containing records you wish to download. This code also indicates which IL Process job processes the trigger record.
|
|
Example: If you create an item, the system creates an item download trigger in the IL Outbound Trigger table with a File code of SKU, indicating a change has been made to the Item and SKU table and an item download message should be generated. The Key field identifies the particular Order Management System company and data, in this example, item and SKU record, that has been updated. Alphanumeric, 3 positions; optional. |
S (status) |
The status of the IL outbound trigger.
The system purges processed (X) trigger records, based on the setting of the Outbound Interface Trigger File Purge Days (I14) system control value, when you run the PURGIJT periodic function (program name ILR0026) or select the Purge option at this screen. Alphanumeric, 1 position; optional. |
Capture date |
The date the activity occurred which created the trigger. Numeric, 6 positions (in user date format); optional. |
Capture time |
The time the activity occurred which created the trigger. Numeric, 6 positions (HH:MM:SS format); display-only. |
Orig process date |
The date the trigger was originally processed by the system. Blank if the trigger has not yet been processed. Numeric, 6 positions (in user date format); display-only. |
Orig process time |
The time the trigger was originally processed by the system. Blank if the trigger has not yet been processed. Numeric, 6 positions (HH:MM:SS format); display-only. |
Last process date |
The date the trigger was last re-processed by the system. You can reprocess a specific trigger by selecting Reset for a trigger. You can reprocess a group of triggers by selecting Reset All. You can only reprocess triggers that are in a pending (P) or processed (X) status. Numeric, 6 positions (in user date format); display-only. |
Last process time |
The time the trigger was last re-processed by the system. Numeric, 6 positions (HH:MM:SS format); display-only. |
From |
The name of the program associated with the Order Management System action that created the trigger. Alphanumeric, 8 positions; display-only. |
A/C |
A code that indicates whether the Order Management System activity represents creation of a new record, a change to an existing record, or a delete of an existing record.
Alphanumeric, 1 position; display-only. |
Key |
A code used to identify the Order Management System company and data that has been updated. The File field identifies the table where the updated data is located. The Key is then used to identify the record in the table that has been updated. ChannelAdvisor shipment If the file code is CAS, the key is company code + order number + invoice number. For example, 0060000123400000123 indicates the trigger is for company 6, order number 1234, and invoice number 123. Customer If the file code is CST, the key is company code + customer number. For example, 006000013049 indicates the trigger is for company 6, customer 13049. Item/SKU If the file code is SKU, the key is company code + item number + SKU code. For example, 555ABC101020 RED GRLS LRGE indicates the trigger is for company 555, item number ABC101020, and SKU code RED GRLS LRGE. If the item is non-SKU’ed, the SKU code is not part of the key. Invoice If the file code is IHD, the key is company code + order number + invoice number. For example, 5550000596900000495 indicates the trigger is for company 555, order number 5969, and invoice number 495. |
|
Inventory If the file code is ITW, the key is company code + item number + SKU code, as described above for Item/SKU. Purchase Order Download If the file code is POH, the key is company code + purchase order number. For example, 0120000636 indicates the purchase order is from company 12 and the purchase order number is 636. Vendor If the file code is VND, the key is company code + vendor code. For example, 55520002 indicates the trigger is for company 555 and vendor number 20002. Stored Value Card If the file code is SVC, the key is company code + order number + ship to number + order detail sequence number + stored value card sequence number. For example, 555000066760010000100004 indicates the trigger is for company 555, order number 6676, ship to number 1, order detail sequence number 1, and stored value card sequence number 4. Return Authorization Download If the file code is RAD, the key is company code + order number + ship to number + return authorization number + return authorization line number. For example, the Key 00700001446001001001 indicates the return authorization download information is located in company 7 for order number 1446, ship to number 1, return authorization number 1, and return authorization line number 1. Alphanumeric, 30 positions; optional. |
Screen Option | Procedure |
---|---|
Delete an IL outbound trigger |
Select Delete for a trigger to advance to the Confirm Delete window; select OK to delete it. Note: The system allows you to delete any trigger, regardless of whether the status is ready (R) or processed (X). |
Reprocess a processed trigger |
Select Reset for a trigger to update the status of the trigger from pending (P) or processed (X) to ready (R). The system also updates the Last processed date and Last processed time fields once the trigger is reprocessed. The next time the IL Process job monitors the IL Outbound Trigger table for unprocessed triggers, the job will reprocess the trigger. Pick triggers associated with a drop ship invoice/pick: If a PCH trigger is associated with a drop ship invoice/pick, you will not be able to re-send a CWPickOut message for the trigger because the system deletes the pick records immediately after the drop ship forms are generated. |
Reprocess a group of triggers |
Select Reset All to advance to the Reset All Window. |
Purge processed triggers |
Select Purge to submit the PURGE_IL job. This job deletes processed (X) trigger records, based on the setting of the Outbound Interface Trigger File Purge Days (I14) system control value. You can also purge records through the PURGIJT periodic function (program name ILR0026). |
Reset All Window
Use this window to update the status of a group of triggers from Pending or Processed to Ready.
To reset: Enter the File code, Capture date, and the current Status of the group of triggers you wish to reprocess and select OK.The system changes the status of the group of triggers to Ready.
The next time the IL Process job monitors the IL Outbound Trigger table for unprocessed triggers, the job will reprocess the triggers.
Pick triggers associated with a drop ship invoice/pick: If a PCH trigger is associated with a drop ship invoice/pick, you will not be able to re-send a CWPickOut message for the trigger because the system deletes the pick records immediately after the drop ship forms are generated.
How to display this screen: Select Reset All at the Work with Outbound Interface Transactions Screen.
Field | Description |
---|---|
File code |
A code identifying the type of triggers you wish to reprocess.
Alphanumeric, 3 positions; required. |
Capture date |
The date the activity occurred which created the group of triggers you wish to reprocess. Numeric, 6 positions (in user date format); required. |
Status |
The status of the group of triggers you wish to reprocess.
Select Pending or Processed in this field to change the status of the group of triggers to Ready. The next time the IL Process job monitors the IL Outbound Trigger table for unprocessed triggers, the job will reprocess the triggers. Alphanumeric, 1 position; required. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
Generating Outbound Interface Triggers (GOIT)
Purpose: Use this menu option to create triggers in the IL Outbound Trigger table. You have the option to create triggers for:
-
item/SKUs (if the Create Generic Item Download Trigger Records (I15) system control value is selected)
-
vendors (if the Create Generic Vendor Download Trigger Records (I16) system control value is selected)
-
invoices (if the Create Generic Invoice Download Trigger Records (I17) system control value is selected)
-
inventory (if the Create Generic Inventory Download Triggers (I32) system control value is selected)
You can use the Working with Outbound Interface Transactions (WOIT) menu option to review the triggers the system generated.
In this topic:
Trigger Rules
You can define trigger rules for each IL Process job to determine when the system generates a trigger, based on criteria defined. The record for which you wish to create a trigger must meet the trigger rule criteria in order to create a trigger in the IL Outbound Trigger table; see Defining Outbound Interface Trigger Rules.
If you generate triggers for: | look at trigger rules for IL Process job: | trigger rules are based on criteria for these tables: |
---|---|---|
item |
Item Outbound |
Item (INITEM) SKU (INSKU) See Item Outbound Trigger Rules. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
vendor |
Vendor Outbound |
Vendor (POVEND) See Item Outbound Trigger Rules. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
invoice |
Invoice Outbound |
Invoice Header (OEINHD) Order Header (OEORDR) See Invoice Outbound Trigger Rules. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
inventory |
Inventory Download |
Item (INITEM) Item Warehouse (INIWRE) SKU (INSKU) Warehouse (INWRHS Item UPC (ITMUPC) See Inventory Download Trigger Rules. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
Processing Sequence of Item Triggers
The system generates item download triggers alphabetically by item number and SKU code in Kit type sequence. This way all items that are components of any type of kit are processed before the main kit item is processed.
-
The system generates triggers alphabetically by item number and SKU code for all items/SKUs whose Kit type is blank.
-
The system generates triggers alphabetically by item number and SKU code for all items/SKUs whose Kit type is F (finished good kit).
-
The system generates triggers alphabetically by item number and SKU code for all items/SKUs whose Kit type is S (set kit).
-
The system generates triggers alphabetically by item number and SKU code for all items/SKUs whose Kit type is V (variable set kit).
Example: The system generates item download triggers in the following sequence, based on the item’s Kit type.
Item number | Kit type | Sequence |
---|---|---|
204I |
blank |
1 |
204J |
blank |
2 |
204K |
blank |
3 |
204C |
F |
4 |
204F |
F |
5 |
204B |
S |
6 |
204G |
S |
7 |
204D |
V |
8 |
204E |
V |
9 |
Generate Outbound Interface Trigger Screen
Use this screen to define the type of triggers you wish to create in the IL Outbound Trigger table.
How to display this screen: Enter GOIT in the Fast path field or select Generate Outbound Interface Triggers from a menu.
Field | Description |
---|---|
Item |
Indicates whether you wish to create triggers in the IL Outbound Trigger table for items/SKUs.
See Generic Item Download API for more information on processing item download triggers. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). Note: The Create Generic Item Download Trigger Records (I15) system control value must be selected to generate item triggers. Process sequence: The system generates item download triggers alphabetically by item number and SKU code in Kit type sequence. This way all items that are components of any type of kit are processed before the main kit item is processed. See Processing Sequence of Item Triggers for an example. |
Invoice |
Indicates whether you wish to create triggers in the IL Outbound Trigger table for invoices.
See Generic Invoice Download API for more information on processing invoice download triggers. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). Note: The Create Generic Invoice Download Trigger Records (I17) system control value must be selected to generate invoice triggers. |
Vendor |
Indicates whether you wish to create triggers in the IL Outbound Trigger table for vendor information.
See Generic Vendor Download API for more information on processing vendor download triggers. Note: The Create Generic Vendor Download Trigger Records (I16) system control value must be selected to generate vendor triggers. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
Inventory |
Indicates whether you wish to create triggers in the IL Outbound Trigger table for inventory information.
See Generic Inventory Download API for more information on processing inventory download triggers. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). Note: The Create Generic Inventory Download Triggers (I32) system control value must be selected to generate inventory triggers. |
Completing this screen:
-
Select the triggers you would like to generate.
-
Select OK to validate your selection.
-
Select Submit to submit the triggers.
The system submits the:
-
ITMDWNLD job to generate item triggers; see Generic Item Download API.
-
INVDWNLD job to generate invoice triggers; see Generic Invoice Download API.
-
VNDDWNLD job to generate vendor triggers; see Generic Vendor Download API.
-
INVENDL job to generate inventory triggers; see Generic Inventory Download API.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Screen Option | Procedure |
---|---|
Submit the generation of IL outbound triggers |
Select Submit. The system submits the:
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
Work with Store Cross Reference (WSCR)
Purpose: Use this screen to set up cross-reference information between a store location and Order Management System. This information can be used to:
-
display a description of the store location assigned to fulfill a brokered backorder. See the Work with Order Broker Screen for an example, and see Brokered Backorders for background.
-
enable the customer to select a store location for pickup of a ship-for-pickup order at the Store Location Screen, or for a store pickup order at the Store Pickup Search Results Screen. When the customer selects the store, the store’s shipping address defaults to the order. See Ship-for-Pickup Orders and Store Pickup Orders for background.
-
indicate the source code to default to a retail pickup or delivery order. See Retail Pickup (including Ship-for-Pickup) or Delivery Orders for background.
-
display a description of an Order Management System warehouse at the Work with Order Broker Screen when it is assigned to fulfill a retail pickup or delivery order. See Retail Pickup (including Ship-for-Pickup) or Delivery Orders for background.
-
display a description of an Order Management System warehouse at the Work with Order Broker Screen for a ship-for-pickup order. See Ship-for-Pickup Orders for background.
-
provide default information for your unique POSLog extract. See the Default Location for ORCE Integration (K69) system control value for more information.
-
provide the pickup location displayed in the store pickup notification email. See Store Pickup Confirmation Email Program (L48) for more information.
-
provide the store name, address, and phone number to include in the OriginatingStore element of the Outbound Email XML Message (CWEmailOut) for:
-
a retail pickup, delivery, ship-for-pickup, or store pickup order; or,
-
for a sales rep’s Home store, if it is flagged as active, or for the Originating store from the Order Header table
-
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
Note:
The Store Cross Reference record is not used:
-
as part of the Merchandise Locator API.
-
to display store descriptions or addresses at the Store Pickup Search Results Screen, although the Store Cross Reference record defaults to the Order Ship To Address when you accept the order.
Other ways to create store cross references: You can also create records in the Store Cross Reference table by:
-
uploading them from an external system: see Store Upload for instructions. Using this option, you can also update existing records.
-
importing them from Order Broker through a web service: see Importing Store Cross Reference Locations through Order Broker’s Discovery Web Service for more information. Using this option, you can create records, but cannot update them.
In this topic:
Work with Store Cross Reference Screen
How to display this screen: Enter WSCR in the Fast path field at the top of any menu or select Work with Store Cross Reference from a menu.
When you first advance to this screen, stores display in ascending store code sequence.
Column sort: You can sort on any column on this screen by clicking on the column name. An arrow pointing up displays next to the field when the values for the field display in ascending sequence; an arrow pointing down displays next to the field when the values for the field display in descending sequence.
Field | Description |
---|---|
Store |
A code identifying an external store location. Can also act as a cross-reference to a Order Management System warehouse. Enter a full or partial store code to display stores that begin with your entry. Alphanumeric, 10 positions. |
Description |
The description of the store location or warehouse. This description is displayed in Working with Order Broker (WOBR) as the name of the store assigned to fulfill a brokered backorder, or the description of the warehouse assigned to fulfill a retail pickup or delivery order or that is shipping a ship-for-pickup order; also, it defaults to the Company field at the Create One Time Ship To Address Screen when you select this store location at the Store Location Screen for a ship-for-pickup order. See the Order Broker Integration for a discussion. Enter a full or partial description to display stores that contain your entry. Alphanumeric, 40 positions. |
Option | Procedure |
---|---|
Create a store cross reference |
Select Create for a store cross reference to advance to the Create Store Cross Reference Screen. Note: You can also use the Importing Store Cross Reference Locations through Order Broker’s Discovery Web Service process or the Store Upload to create store cross reference records. |
Change a store cross reference |
Select Change for a store cross reference to advance to the Change Store Cross Reference screen. See the Create Store Cross Reference Screen for field descriptions. |
Display a store cross reference |
Select Display for a store cross reference to advance to the Display Store Cross Reference screen. You cannot change any information on this screen. See the Create Store Cross Reference Screen for field descriptions. |
Delete a store cross reference |
Select Delete for a store cross reference. At the Confirm Delete window, select Yes to delete the record; otherwis |
Create Store Cross Reference Screen
Purpose: Use this screen to enter store cross-reference information for:
-
transferring invoice data or sales transactions to your unique POSLog integration.
-
integration with the Order Broker; see the Order Broker Integration for background.
Note:
You can also use the Importing Store Cross Reference Locations through Order Broker’s Discovery Web Service process or the Store Upload to create store cross reference records.
How to display this screen: Select Create at the Work with Store Cross Reference Screen.
Field | Description |
---|---|
Store # |
A code identifying an external store location. Can also act as a cross-reference to a Order Management System warehouse. Used in certain integrations:
Alphanumeric, 10 positions. Create screen: required. Change screen: display-only. |
Phone Number |
The phone number for the store. Included in the OriginatingStore element of the Outbound Email XML Message (CWEmailOut); see the OriginatingStore in the Web Services Guide on My Oracle Support (ID 2149144.1) element for more information. Alphanumeric, 14 positions; optional. |
Description |
The description to:
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). Note: If the description exceeds 30 positions, it is truncated at the Store Location Screen and at the Create One Time Ship To Address Screen. Also, any additional characters do not print on the pick slip and are not sent to the Order Broker. Alphanumeric, 40 positions. Create screen: required. Change screen: optional. |
Active? |
Defines whether the store location is active.
The system validates that the store location is active when you define the store on the Work with Order Ship to Properties Screen in Order Entry or receive an order through the Generic Order Interface (Order API) that specifies a sales_rep_store location. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
System Code |
The system associated with the store location in Order Broker. Used to identify the fulfilling location when sending a SubmitOrder request to Order Broker for a store pickup or ship-for-pickup order, and acts as an override to the Name in OROB for Point of Sale (L09). If this field is:
Your entry must be a valid system code associated with the fulfilling location in Order Broker and the case must match exactly. Used only for store pickup and ship-for-pickup orders. Note: You still need to complete the Name in OROB for Point of Sale (L09) system control value, or you cannot create a ship-for-pickup order even if a valid system code is specified here. |
Register # |
The register number for transactions to pass to the point-of- sale (POS) system as part of a POSLog integration. Numeric, 3 positions; optional. |
Employee ID |
The employee identification to pass to the POS system as part of a POSLog integration. Alphanumeric, 12 positions; optional. |
Discount Code |
The discount code used to pass discount information for items to the POS system as part of a POSLog integration. Alphanumeric, 12 positions; optional. |
Price Override Code |
The price override reason code used as a cross reference as part of a POSLog integration. Not validated against the Price Override Reason Code table. Alphanumeric, 3 positions, optional. |
Item Hierarchy Level 1-4 |
Optionally, select the level of the item hierarchy in Order Management System that matches to the hierarchy level in an external system. Possible settings:
Optional. |
Ship for Pickup |
Indicates whether the store location is available for selection as a destination for a ship-for-pickup order. Only store locations that have this field selected are listed at the Store Location Screen in order entry. See Ship-for-Pickup Orders for an overview. If you select this field, the system validates that you enter:
Note: Select this field only for stores whose Ship For Pickup Receiving/Pickup Available setting is selected in Order Broker. |
Source Code |
The source code to assign to retail pickup or delivery orders received from the Order Broker. Used as follows for orders created through the fulfillments response message based on whether the order originated in Order Management System:
See e Retail Pickup (including Ship-for-Pickup) or Delivery Orders for an overview. Your entry must be an existing source code. See Working with Source Codes (WSRC) for more information. Alphanumeric, 9 positions; optional. |
OriginatingStore element in the CWEmailOut message |
The following address fields, plus the Phone Number, are included in the OriginatingStore element of the Outbound Email XML Message (CWEmailOut). See the OriginatingStore for more information. For more information see the Web Services Guide on My Oracle Support (ID 2149144.1). |
Address |
The address to default to the Address fields at the Create One Time Ship To Address Screen when you select this store location at the Store Location Screen for a ship-for-pickup order. See Ship-for-Pickup Orders for a discussion. Alphanumeric, four 32-position fields; optional. |
City |
The address to default to the Address fields at the Create One Time Ship To Address Screen when you select this store location at the Store Location Screen for a ship-for-pickup order. See Ship-for-Pickup Orders for a discussion. Alphanumeric, four 32-position fields; optional. |
State |
The state to default to the Create One Time Ship To Address Screen when you select this store location at the Store Location Screen for a ship-for-pickup order. See Ship-for-Pickup Orders for a discussion. Required only if the Ship for Pickup flag is selected, and if the Require state? flag is selected for the country (see Setting Up the Country Table (WCTY)). Alphanumeric, 2 positions; required if you select the Ship for Pickup flag; otherwise, optional. |
Postal code |
The postal or zip code to default to the Postal code field at the Create One Time Ship To Address Screen when you select this store location at the Store Location Screen for a ship-for-pickup order. See Ship-for-Pickup Orders for a discussion. Required only if the Require postal code? flag is selected for the country (see Setting Up the Country Table (WCTY)) and if the Ship for Pickup flag is selected for the store cross reference. If a postal code is required, it is validated against the Zip/City/State (Postal Code) table; see Setting Up the Zip/City/State (Postal Code) Table (WZIP). Alphanumeric, 10 positions; required if you select the Ship for Pickup flag; otherwise, optional. |
Country |
The country code to default to the Country field at the Create One Time Ship To Address Screen when you select this store location at the Store Location Screen for a ship-for-pickup order. See Ship-for-Pickup Orders for a discussion. If the Ship for Pickup flag is selected, you need to enter a valid country code. The Default Country for Customer Address (B17) defaults. Alphanumeric, 3 positions; required if you select the Ship for Pickup flag; otherwise, optional. |
Order Broker Integration
Topics in this part: This part describes integration between Order Management System and Order Broker.
-
Order Broker Integration Overview describes the components of the integration between Order Broker and Order Management System, including the extract processes that occur automatically as well as the Order Broker and Merchandise Locator API’s, and describes required setup.
-
Order Broker Integration provides details on how the integration with Order Broker handles each order type.
-
Merchandise Locator API describes how to search for a store location where the customer can pick up an item.
Working with Order Broker (WOBR)
Purpose: Use this menu option to review the records and history of all order lines sent to or received from the Order Broker for shipment or customer pickup. You can also use this menu option to cancel fulfillment of a brokered backorder request to the Order Broker and leave the order line open, so you can fulfill it from your warehouse using your standard process.
Determining the Order Broker type: A Delivery type of retail pickup, delivery, store pickup, or ship-for-pickup is indicated on the Display Order Broker Screen. The Delivery type at this screen is blank for a brokered backorder. This screen is available by selecting Display for an Order Broker record at the Work with Order Broker screen.
Both originating and fulfilling orders listed: If the Use OROB for Fulfillment Assignment (M31) system control value is selected, both the originating order submitted to Order Broker and the fulfilling order assigned in Order Management System to fulfill it are included in these totals.
Example: Order 12345 was submitted to Order Broker for assignment, and Order Broker submitted the order to Order Management System to fulfill from the warehouse. Order Management System created order 12346 to fulfill order 12345. Lines from both order 12345 and 12346 are listed with their respective statuses.
For more information: See the Order Broker Integration for an overview.
In this topic:
Work with Order Broker Screen
How to display this screen: Enter WOBR in the Fast path field at the top of any menu, or select Work with Order Broker from a menu.
Column sort: You can sort on any column except Line # on this screen by clicking on the column name. An arrow pointing up displays next to the field when the values for the field display in ascending sequence; an arrow pointing down displays next to the field when the values for the field display in descending sequence.
When you first advance to this screen, order broker records display in ascending create date, order number sequence.
Field | Description |
---|---|
Status |
The current status of the Order Broker request. Possible statuses are described at the Order Broker Status Summary Table. Search: Select a status and select OK to display order broker records that match your entry. |
Create date |
The date when the Order Broker request was created. Search: Enter a date and select OK to display order broker records that match your entry. Numeric, 6 positions (user date format); optional. |
Order # |
The order number and ship-to number that originated a brokered backorder, store pickup, or ship-for-pickup order, or was created as a result of a retail pickup or delivery request. The ship-to number is set to 1 if there is a single shipping address. Note: Ship-for-pickup orders are not listed here until you generate a pick slip and Order Management System submits the order to the Order Broker.Search: Enter an order number and select OK to display order broker records that match your entry. Order number: numeric, 8 positions; optional. Ship-to number: numeric, 3 positions; optional. |
Line # |
The sequence number in the Order Detail table that identifies the order line to be fulfilled through the Order Broker integration. The sequence number might differ from the order line number displayed in order maintenance or order inquiry if, for example, you deleted one of the previous lines on the order. Numeric, 5 positions; optional. |
Item/SKU |
The item to be fulfilled through the Order Broker. If the item has SKU’s, the SKU code also displays. Search: Enter a valid item number and select OK to display order broker records that contain your entry. If the item has SKU’s, you can search on item number only. Alphanumeric, 12 positions; optional. |
Qty |
The current quantity to be fulfilled at the Fulfilling location. Displayed regardless of status. Numeric, 5 positions; display-only. |
Fulfilling location |
See the Order Broker Originating Location, Fulfilling Location, and Pickup Location for a discussion. Search: Enter a full or partial fulfilling location code and select OK to display order broker records that contain your entry. Alphanumeric, 50 positions; optional. |
Request ID |
A unique ID number assigned by the Order Broker to identify the order. If the Use Split Order (L56) system control value is:
The Use Split Order (L56) system control value does not affect how Order Management System creates or processes ship-for-pickup, retail pickup, delivery, or store pickup orders. The request ID is blank for requests whose status is:
The field might also be blank for requests in E (Error) status, depending on the nature of the error. For example, requests that the Order Broker did not receive and create successfully are not assigned request ID’s. Although the field in Order Management System is up to 25 positions, Order Broker does not support a request ID longer than 10 positions. Search: Enter a valid request ID and select OK to display order broker records that match your entry. Numeric, 25 positions; optional. |
Option | Procedure |
---|---|
Display details of an Order Broker request |
In the Action field, select Display to advance to the Display Order Broker Screen. |
Review history for an Order Broker request |
In the Action field, select History to advance to the Display Order Broker History Screen. |
Cancel an Order Broker request |
In the Action field, select Cancel to cancel a brokered backorder and return the order line to standard backorder processing. See Canceling a Brokered Backorder Request for more information. Note:
|
Print the Order Broker Aging Report |
Select Print to advance to the Print Aging Report Window. See Printing the Order Broker Aging Report for more information. |
Display Order Broker Screen
Purpose: Use this screen to review details about an Order Broker request.
How to display this screen: Select Display in the Action field for a record at the Work with Order Broker Screen.
Field | Description |
---|---|
Order # |
The order number that originated the brokered backorder, store pickup, or ship-for-pickup, or that was created as a result of the retail pickup or delivery request. The order number is separated from the ship-to number by a hyphen. Numeric, 8 positions; display-only. |
Ship To # |
The order ship to number that originated the brokered backorder, store pickup, or ship-for-pickup, or that was created as a result of the retail pickup or delivery request. The order number is separated from the ship-to number by a hyphen. Numeric, 3 positions; display-only. |
Line # |
The sequence number in the Order Detail table that identifies the order line to be fulfilled through the Order Broker integration. The sequence number might differ from the order line number displayed in order maintenance or order inquiry if, for example, you deleted or canceled one of the previous lines on the order. Numeric, 5 positions; display-only. |
Item/SKU |
The item and SKU fulfilled through the Order Broker integration. Item: alphanumeric, 12 positions; display-only. SKU: alphanumeric, three 4-position fields; display-only. |
Description |
A description of the item. If the item has SKUs, the SKU description displays. Alphanumeric, 120 positions (item) or 40 positions (SKU); display-only. |
Order qty |
The ordered quantity for the order detail line. This field is used for all order types. Numeric, 5 positions; display-only. |
Qty |
The quantity of a brokered backorder line that is currently assigned to Order Broker for fulfillment, or has been fulfilled or canceled. Might be less than the ordered quantity if this is a brokered backorder, the Use Split Order (L56) system control value is selected, and the Allow Split Order and Allow Split Line preferences in Order Broker are also selected. See the Use Split Order (L56) system control value for a discussion. Numeric, 5 positions; display-only. |
Status |
The current status of the Order Broker request.The description is to the right. Possible statuses are described at the Order Broker Status Summary Table. Alphanumeric, 1 position; display-only. |
Create date |
The date when the Order Broker request was created. Numeric, 6 positions (user date format); display-only. |
Create time |
The time when the Order Broker request was created. Numeric, 6 positions (HH:MM:SS format); display-only. |
Last request date |
The last date when Order Management System sent an order or status request to the Order Broker. Numeric, 6 positions (user date format); display-only. |
Last request time |
The last time when Order Management System sent an order or status request to the Order Broker. Numeric, 6 positions (HH:MM:SS format); display-only. |
Request ID |
A unique ID number assigned by the Order Broker to identify the order. If the Use Split Order (L56) system control value is:
The request ID is blank for requests whose status is:
The field might also be blank for requests in E: Error status, depending on the nature of the error. For example, requests that the Order Broker did not receive and create successfully are not assigned request ID’s. Numeric, 30 positions; display-only. |
Originating location |
See the Order Broker Originating Location, Fulfilling Location, and Pickup Location for a discussion. Alphanumeric, 50 positions; optional. |
Fulfilling location |
See the Order Broker Originating Location, Fulfilling Location, and Pickup Location for a discussion. Alphanumeric, 50 positions; optional. |
Pickup location |
See the Order Broker Originating Location, Fulfilling Location, and Pickup Location for a discussion. Alphanumeric, 50 positions; optional. |
Broker delivery type |
The type of order:
|
Option | Procedure |
---|---|
Review history for the Order Broker request |
Select History to advance to the Display Order Broker History Screen. |
Display Order Broker History Screen
Purpose: Use this screen to review the order, status, and cancel requests sent from Order Management System to the Order Broker, and the responses received. History is listed in chronological order (oldest to newest).
Not included in this history:
-
Fulfillments request and response messages
-
SubmitOrder request and response messages for store pickup or ship-for-pickup orders
-
Changes to a brokered backorder’s Under Review flag that can occur if the Send Held Orders to OROB (M18) system control value is selected
How to display this screen: Select History in the Action field for a record at the Work with Order Broker Screen, or select History at the Display Order Broker Screen.
Field | Description |
---|---|
Order # |
The order number and ship-to number related to the Order Broker request. The order number is separated from the ship-to number by a hyphen. Order number: numeric, 8 positions; display-only. Ship-to number: numeric, 3 positions; display-only. |
Line # |
The sequence number in the Order Detail table that identifies the order line to be fulfilled through the Order Broker integration. The sequence number might differ from the order line number displayed in order maintenance or order inquiry if, for example, you deleted or canceled one of the previous lines on the order. Numeric, 5 positions; display-only. |
Item/SKU |
The item and SKU to be fulfilled through the Order Broker integration. Item: alphanumeric, 12 positions; display-only. SKU: alphanumeric, three 4-position fields; display-only. |
Item/SKU description (unlabeled field to the right of the Item/SKU) |
The description of the item and SKU. This field displays up to 52 positions; however, if the SKU description is truncated, you can display the rest by putting your cursor in the field and advancing it to the right. Item description: alphanumeric, 120 positions; display-only. SKU description: alphanumeric, 40 positions; display-only. |
Order qty |
The ordered quantity for the order detail line. This field is used for all order types. Numeric, 5 positions; display-only. |
Originating Location |
See Order Broker Originating Location, Fulfilling Location, and Pickup Location for a discussion. Alphanumeric, 50 positions; optional. |
Pickup Location |
See Order Broker Originating Location, Fulfilling Location, and Pickup Location for a discussion. Alphanumeric, 50 positions; optional. |
For each Order Broker History record: |
|
Date/Time |
The date and time when the request was sent to the Order Broker, or when the response was received in Order Management System. There might be a difference between the time of the Send Status Request and Receive Status Response activities, because the status list request can include up to 1000 records, resulting in a delay between generating the request and processing the response for an individual order line. Date: numeric, 6 positions (user date format); display-only. Time: numeric, 6 positions (HH:MM:SS format); display-only. |
Transaction type |
The type of activity that occurred. Possible transaction types are: A - Send Order Request = Order Management System sent the initial submit order message to the Order Broker (brokered backorders). B - Receive Order Response = Order Management System received the order response message from the Order Broker (brokered backorders). C - Send Status Request = Order Management System sent an request to the Order Broker to inquire about the order’s current status. D - Receive Status Response = Order Management System received the status inquiry response message from the Order Broker. M - Maintenance Transaction = You canceled the brokered backorder or store pickup request. You can cancel a brokered backorder either through order maintenance, or by canceling the Order Broker request itself (but not the order line) at the Work with Order Broker Screen; however, you can only cancel a store pickup request through order maintenance. E - Send Update Request = Order Management System sent a status update request message to the Order Broker. F - Receive Update Response = Order Management System received the status update response message from the Order Broker. See Sample Order Broker Messages for examples of the different messages generated or received by Order Management System as part of the Order Broker integration. Alphanumeric, 25 positions; display-only. |
Status |
The current status of the Order Broker request.The description is to the right. Possible statuses are described at the Order Broker Status Summary Table. Alphanumeric, 1 position; display-only. |
Fulfilling location |
See the Order Broker Originating Location, Fulfilling Location, and Pickup Location for a discussion. Alphanumeric, 50 positions; optional. |
Qty |
The quantity of the Order Broker line at the time of the activity. Might be less than the ordered quantity if this is a brokered backorder, the Use Split Order (L56) system control value is selected, and the Allow Split Order and Allow Split Line preferences in Order Broker are also selected. See the Use Split Order (L56) system control value for a discussion. Numeric, 5 positions; display-only. |
OROB Ln # |
The sequence number in the Order Detail table that identifies the order line to be fulfilled through the Order Broker integration. The sequence number might differ from the order line number displayed in order maintenance or order inquiry if, for example, you deleted or canceled one of the previous lines on the order. Numeric, 5 positions; display-only. |
Error |
The error,
if any, received from the Order Broker. The error message is truncated
if it exceeds 30 positions. An error of See Troubleshooting the Order Broker Integration and the Order Broker Operations Guide for more information on possible errors. Alphanumeric, 30 positions; display-only. |
Canceling a Brokered Backorder Request
Overview: Your options in canceling a brokered backorder request in Order Management System are:
Cancel the brokered backorder request and reassign fulfillment: to return the order line to standard backorder and fulfillment processing in Order Management System, use the cancel option from the Work with Order Broker Screen.
Cancel both the brokered backorder request and the order line itself: to prevent the order line from shipping to the customer, use the:
-
Cancel option at the Work with Order Lines Screen for an order line: cancels just the selected order line. If you enter a different cancel quantity at the Enter Cancel Reason Window, any remaining uncanceled quantity returns to standard backorder and warehouse processing in Order Management System.
-
Cancel Order option at the Work with Order Screen in Order Maintenance or Work with Order Lines Screen: cancels the entire order.
Important:
-
Before canceling a brokered backorder request, it is important to confirm that the assigned fulfilling location is not in the process of shipping it. Even if the current status in Order Management System indicates that the order is not in the process of fulfillment, depending on the setting of the Order Broker Status Update Interval (K10) this information could be out of date.
-
If the Use OROB for Fulfillment Assignment (M31) system control value is selected you can cancel the delivery order that was created to fulfill the originating broker backorder. In this situation, the system changes the Order Broker record’s status to Canceled and sends a status inquiry request to the Order Broker. See Canceling an Item in Order Maintenance for more information.
-
If you broker ship-for-pickup orders for fulfillment assignment (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), when you cancel a ship-for-pickup order, the system sends an update to Order Broker so that the order can be updated to canceled. In addition, if a retail pickup order was created in Order Management System to fulfill the ship-for-pickup order, when you run pick slip generation for the retail pickup order, the system does not generate a pick slip and assigns the hold reason defined in the Order Broker Hold Reason (Cancel) (L02) system control value to the order. The system also writes an order transaction history message for the retail pickup order:
Order held - line(s) canceled in Order Broker.
Secured feature: The Cancel Order Broker Lines (B19) secured feature controls the authority to cancel a brokered backorder. If you do not have authority under this secured feature:
-
the Cancel option is not available at the Work with Order Broker Screen
-
you cannot cancel a brokered backorder line in order maintenance
-
if you select the Cancel Order option in order maintenance, Order Management System does not cancel any brokered backordered lines and displays an error message:
Not authorized to cancel Order Broker line.
Note:
You cannot use the e-commerce cancel request message to cancel a backordered line assigned to the Order Broker. See E-Commerce Cancel Process for background.Confirm Order Broker Cancel Window
How to display this window: Select Cancel for:
-
an Order Broker request at the Work with Order Broker Screen
-
in order maintenance:
-
a backordered order line assigned to the Order Broker
-
an order that includes a backordered order line assigned to the Order Broker
-
Cancel option available? The Cancel option is available only if you have authority under the Cancel Order Broker Lines (B19) secured feature and if the Order Broker request has not already been shipped or submitted for cancellation, it is not in error, and the Order Broker has not indicated that it is unfulfillable.
Field | Description |
---|---|
Status |
The current status of the Order Broker request. A brokered backorder request is eligible for cancellation only if its status is:
|
Item/SKU |
The backordered item and SKU to be fulfilled through the Order Broker. Item: alphanumeric, 12 positions; display-only. SKU: alphanumeric, three 4-position fields; display-only. |
Fulfilling location |
The code identifying the store location assigned to fulfill the backorder. In the case of a retail pickup or delivery order, this is the Order Management System warehouse. See the Order Broker Originating Location, Fulfilling Location, and Pickup Location for a discussion. Alphanumeric, 50 positions; optional. |
Completing this screen: Click OK to submit.
Updates at accept: When you confirm the cancellation:
-
An Order Broker History message tracks the activity. The Transaction type is M - Maintenance Transaction.
-
The order detail line is updated immediately. If you cancel the Order Broker request but not the order line itself, the Drop ship flag and Printed quantity are cleared, and the order line returns to standard backorder processing.
-
Order Broker status change:
-
If the order has not yet been sent to the Order Broker (the status of the Order Broker request is R (ready), the status of the Order Broker request changes to C (closed). No further updates take place.
-
If the order has been sent to the Order Broker (the status of the Order Broker request is W (waiting), K (acknowledged), P (polled), or A (accepted): the status of the Order Broker request changes to Y (pending cancel). Once the BROKER job receives confirmation of the cancellation from the Order Broker, it changes the status of the Order Broker request to Z (canceled), and writes an Order Transaction History message (for example,
Ln#: 2 Cancel Acknowledged by Broker
).
-
Status update message: The status update message includes the cancel reason code and description. See the Order Status Update Cancel Request Message Sample (Brokered Backorder or Store Pickup) for information about the fields submitted to Order Broker for the cancellation of a brokered backorder.
Printing the Order Broker Aging Report
Purpose: Use the Order Broker Aging Report to review order lines that have been assigned to the Order Broker for fulfillment.
Print Aging Report Window
How to display this window: Select Print at the Work with Order Broker Screen.
Field | Description |
---|---|
Status |
Optionally, select a status to include Order Broker records that are currently in this status, or leave this field unselected to include records regardless of status. Statuses that are eligible for selection are:
Note: You cannot include Order Broker records on the report if their status is Unfulfillable (U), Closed (C), Completed (X), or Error (E).Optional. |
Fulfilling location |
Optionally, select a single store location, or leave this field blank to select records regardless of fulfilling location. This information is from Work with Store Cross Reference (WSCR). See the Order Broker Originating Location, Fulfilling Location, and Pickup Location for a discussion. Alphanumeric, 50 positions; optional. |
Older than |
Optionally, enter a number of days to have the report include Order Broker records only if their age exceeds this number, or leave this field set to 00000 to select records that are at least two days old. Note: It is not possible to include Order Broker records from the current or previous day on the report. Only records that are at least two days old are eligible for selection.Numeric, 5 positions; optional. |
Note:
The Order Broker Aging Report is accessible at the Document Management Screen. It is not available by selecting a submitted job at the Job Management Screen.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 Management System and the Oracle Retail Customer Engagement stored value card system.
Working with Physical Stored Value Card Assignment (WPSA)
Purpose: Before you can activate a stored value card, you must first assign a number to the card. Assigning a number to a physical stored value card occurs after pick slip generation. Use this menu option to assign a number to a physical stored value card by selecting the associated pick control number.
Assigning numbers using an external system: You can use the Pick Message from Order Management System (CWPickOut) to send physical stored value card information to an external system. The external system assigns a number to the card and returns the number in the svc_card_nbr tag in the CWPickIn XML Message. When Order Management System receives a CWPickIn message that contains a stored value card number, the system creates a record in the Billing SVC Data Queue table and sends the information to billing. See Billing a Stored Value Card.
For more information see the Web Services Guide on My Oracle Support (ID 2149144.1).
For more information: See:
-
Assigning Numbers to Virtual Stored Value Cards for more information on assigning a number to a virtual stored value card.
-
Assigning a Stored Value Card Number for an overview on assigning a number to a physical or virtual stored value card.
In this topic:
Pick SVC Assignment/Billing Screen
Use this screen to select the physical stored value card for which you wish to assign a number, by selecting the associated pick control number.
An error message indicates if you enter a pick control number that
does not contain a physical stored value card item (SVC type is Physical Card or Physical Card/Early Notify): Pick
control# not valid for SVC number assignment.
Once you select a physical stored value card by pick control number, select OK to advance to the Stored Value Card Assignment Screen.
How to display this screen: Enter WPSA in the Fast path field or select Work with Stored Value Card Assignment from a menu.
Field | Description |
---|---|
Pick control # |
The pick control number containing the physical stored value card item for which you wish to assign a number. An error message indicates
if you enter a pick control number that does not contain a physical
stored value card: Numeric, 7 positions; required. |
Stored Value Card Assignment Screen
Purpose: Use this screen to define a number for each physical stored value card associated with the selected pick control number.
Typically, the stored value card number is printed on the physical card. You can enter this number in the Stored value card number field on this screen. A separate line displays for you to enter a number for each physical card associated with the pick control number.
Note:
Depending on the user’s authority to credit card information, the system writes a record to the Credit Card Audit table when this screen is displayed. See Logging Credit Card Data Access in the Data Security and Encryption Guide on My Oracle Support (1988467.1) for more information.Stored value card number validation
-
The system performs a modulus check against the stored value card number if a method is specified in the Stored Value Card Modulus Checking Method (I24) system control value. If the stored value card number fails the modulus check, an error message indicates:
Card number failed modulus check.
-
If MU is selected as the type of modulus check to perform and the User Defined Modulus Check Program (E94) system control value is blank, an error message indicates
Modulus check program has not been specified for SCV E94.
-
You must define a number for each stored value card associated with the pick control number. An error message indicates if you do not define a number for each physical stored value card:
All stored value card numbers must be entered before accepting.
-
You cannot assign the same number to more than one stored value card on the pick control record or an error message indicates:
Duplicate card# on pick# 9999 line# 2.
-
You cannot enter a number that is already assigned to an existing stored value card or an error message indicates:
Card number entered already used.
How to display this screen: Select OK at the Pick SVC Assignment/Billing Screen after entering a pick control number associated with a physical stored value card.
Field | Description |
---|---|
Control# |
The pick control number containing the physical stored value cards to which you wish to assign numbers. Numeric, 7 positions; display-only. |
Billing batch# |
The billing batch number associated with the pick control number containing the physical stored value card. Numeric, 7 positions; display-only. |
Order# |
The order number and ship to number where the physical stored value cards were purchased. Order #: Numeric, 8 positions; display-only. Ship to #: Numeric, 3 positions; display-only. |
Line# |
The pick control line number associated with the physical stored value card. Numeric, 3 positions; display-only. |
Item |
The item number of the physical stored value card item. Alphanumeric, 12 positions; display-only. |
SKU |
The SKU code of the physical stored value card item. Alphanumeric, 14 positions; display-only. |
Description |
A description of the physical stored value card item. The first 25 positions display. Alphanumeric, 25 positions; display-only. |
Qty |
The quantity of the physical stored value card associated with the pick control number. This is the number of cards to which you must assign a number. Numeric, 5 positions; display-only. |
Amount |
The issue amount assigned to each physical stored value card purchased. Numeric, 13 positions with a 2-place decimal; display-only. |
Stored value card# |
The number you wish to assign to the physical stored value card. Typically, this number is printed on the physical card. A separate line displays for you to enter a number for each physical card associated with the pick control number. The full stored value card number displays, regardless if a default credit card number format is defined at the Credit Card Number Layout Screen. This allows you to verify the stored value card number you are entering. See Stored value card number validation for additional edits the system performs against the stored value card number. Numeric, 20 positions; required. |
Screen Option | Procedure |
---|---|
Accept the stored value card number assignment |
Select Accept to assign the stored value card number to the physical card, linking the stored value card to the recipient card holder. |
Reject the stored value card number assignment |
Select Reject. The system does not assign the number to the stored value card. |
If you accept: If you accept the stored value card number assignment, the system:
-
assigns the number to the physical stored value card and updates the Pick Stored Value Card Table.
-
sends the pick control number associated with the physical stored value card item to billing if the Use Streamlined Stored Value Card Billing (I23) system control value is selected; otherwise the system sends the card to billing once it is wanded and billed at your manifesting station.
Note:
If you do not Use Streamlined Stored Value Card Billing (I23), you can update the stored value card number at the Pick SVC Assignment/Billing Screen by entering a new number over the existing number. Once you bill the stored value card item, you cannot update the stored value card number.Stored Value Card Balance Inquiry (MSVB)
Overview: You can inquire on the remaining amount available on a stored value card:
-
Using the Stored Value Card Balance Inquiry (MSVB) menu option; see Stored Value Card Balance Inquiry (MSVB).
-
In order entry and maintenance; see Order Entry/Maintenance Balance Inquiry.
-
Before performing batch authorization against the card during pick slip generation or drop ship processing; see Batch Authorization Balance Inquiry.
Note:
This option is also available in Modern View.In this topic:
Stored Value Card Balance Inquiry (MSVB)
Purpose: Use the Stored Value Card Balance Inquiry menu option to submit a stored value card balance inquiry request.
For more information: See Stored Value Card Balance Inquiry (MSVB).
Stored Value Card Balance Inquiry Screen (MSVB)
Use this screen to specify the stored value card whose balance you wish to know.
Note:
Depending on the user’s authority to credit card information, the system writes a record to the Credit Card Audit table when this window is displayed. See Logging Credit Card Data Access in the Data Security and Encryption Guide on My Oracle Support (1988467.1) for more information.How to display this screen:
-
Enter MSVB in the Fast path field or select Stored Value Card Balance Inquiry from a menu.
-
Select Balance Inquiry on the Customer Selection Screen.
Note:
The system returns you to the Customer Selection screen after you complete the balance inquiry.
Field | Description |
---|---|
Pay type |
The code for the stored value card pay type assigned to the stored value card number whose remaining balance you are inquiring. The pay type
you enter must be a stored value card pay type or an error message
indicates: Numeric, 2 positions; required. |
Card number |
The stored value card number whose balance you are inquiring. Alphanumeric, 20 positions; required. |
SVC ID # |
The ID number assigned to the stored value card. Include only if your stored value card processor supports it. Numeric, 9 positions; optional. |
Balance |
The remaining balance on the stored value card. This field is blank until you receive a balance inquiry response from the service bureau. However, the service bureau may return a blank balance if the stored value card number exists, but has not yet been activated or the remaining balance is zero. Numeric, 13 positions with a 2-place decimal; display-only. |
Screen Option | Procedure |
---|---|
Submit a stored value card balance inquiry request |
Select Submit Request. |
Instructions: Use the following steps to submit a stored value card balance inquiry request from the Stored Value Card Balance Inquiry Screen (MSVB).
# | Step |
---|---|
1. |
Enter a stored value card pay type, card number, and optionally ID number, and select OK. |
2. |
The system looks at the Authorization service field defined for the stored value card pay type to determine the service bureau that performs balance inquiries for the stored value card pay type. |
3. |
The system looks at the Communication type field defined for the service bureau to determine the method of communication used to transmit balance inquiry transactions between Order Management System and the service bureau. Integration Layer indicates Order Management System communicates with the external system using advanced queuing.
Payment Link indicates Order Management System communicates
with the external system using a point-to-point integration instead
of using advanced queuing. The system looks at the settings in the
Interface Properties to communicate with the service bureau using
a point-to-point integration.
Note: This option is available for the Customer Engagement Stored Value Card Integration. The system uses the Customer Engagement Inquiry Request to send the balance inquiry request to Oracle Retail Customer Engagement and receives the response in the Customer Engagement Inquiry Response. |
4. |
If a response is received from the service bureau, the system displays the remaining balance amount for the stored value card in the Balance field. However, this field may remain blank if the stored value card number exists, but has not yet been activated.00 displays if the remaining balance is zero. If a response is not received from the service
bureau, the system displays the message: |
Order Entry/Maintenance Balance Inquiry
Purpose: Use the following steps to submit a stored value card balance inquiry request from order entry/maintenance.
-
At the Enter Payment Method screen, select Balance Inquiry for a stored value card payment method.
You can also select this option at the Enter Credit Card For window. However, an error message indicates if you have not yet created the stored value card payment method on the order:
Must create pay method before Balance Inquiry.
-
The system looks at the Authorization service field defined for the stored value card pay type to determine the service bureau that performs balance inquiries for the stored value card pay type.
-
The system looks at the Communication type field defined for the service bureau to determine the method of communication used to transmit balance inquiry transactions between Order Management System and the service bureau.
-
Integration Layer indicates Order Management System communicates with the external system using advanced queuing.
-
The system looks at the SVC balance inquiry integration layer process field defined for the service bureau to determine the integration layer process used to process stored value card balance inquiries.
-
The integration layer process sends the stored value card balance inquiry request to the service bureau and waits for a balance inquiry response, based on the number of seconds defined in the Wait time field for the integration layer process.
-
-
Payment Link indicates Order Management System communicates with the external system using a point-to-point integration instead of using advanced queuing.
The system looks at the settings in the Interface Properties to communicate with the service bureau using a point-to-point integration.Note:
This option is available for the Customer Engagement Stored Value Card Integration. The system uses the Customer Engagement Inquiry Request to send the balance inquiry request to Oracle Retail Customer Engagement and receives the response in the Customer Engagement Inquiry Response.
-
-
If a response is received from the service bureau, the system displays the Balance Inquiry For Window, indicating the remaining balance on the stored value card.
If a response is not received from the service bureau, the system
displays the message: No response from service.
Balance Inquiry For Window
Use this window to review the remaining balance on a stored value card during order entry/maintenance.
When a balance is received, you can:
-
Select OK to add the stored value card balance as the amount to charge for the stored value card payment on the order. You can also enter a lesser amount in the Balance field if you wish to use a partial amount of the remaining balance on the card as payment on the order.
-
Select Exit to return to the previous screen without adding the stored value card balance as the amount to charge on the order.
Note:
-
Depending on the user’s authority to credit card information, the system writes a record to the Credit Card Audit table when this window is displayed. See Logging Credit Card Data Access in the Data Security and Encryption Guide on My Oracle Support (1988467.1) for more information.
-
This screen may return a blank balance if the stored value card number exists, but has not yet been activated by the service bureau or the remaining balance is zero.
How to display this screen: This screen displays when a balance inquiry response is received from the service bureau, after you send a stored value card balance inquiry request to the service bureau by:
-
Selecting Balance Inquiry for a stored value card payment method at the Enter Payment Method screen.
-
Selecting Balance Inquiry at the Enter Credit Card For window.
Field | Description |
---|---|
Pay type |
The code and description of the stored value card pay type assigned to the stored value card number whose remaining balance you are inquiring. Code: Numeric, 2 positions; display-only. Description: Alphanumeric, 30 positions; display-only. |
Card # |
The stored value card number whose balance you are inquiring. Masking: If you do not have authority to the Display Full Credit Card Number (B14) secured feature, the stored value card number displays in the format specified at the Credit Card Number Layout Screen for the associated pay type. For example, 4788********1443 may display instead of the entire stored value card number. See Credit Card Number Format for an overview. Alphanumeric, 20 positions; display-only. |
Balance |
The remaining balance on the stored value card. Numeric, 13 positions with a 2-place decimal; required. |
Batch Authorization Balance Inquiry
Purpose: Use the following steps to submit a stored value card balance inquiry request before performing batch authorization against the stored value card.
Note:
In order to perform a balance inquiry before batch authorization, the Perform Balance Inquiry during Batch Authorizations (J19) system control value must be selected.# | Step |
---|---|
1. |
Submit pick slip generation or drop ship processing that includes an order with an active stored value card pay type that requires batch authorization. Note: The system compares the authorized amount across all stored value card pay types on the order against the pick total to determine if the stored value card requires batch authorization. If the authorized amount across all stored value card pay types on the order is equal to or greater than the pick total, the system does not send perform batch balance inquiry against the card. |
2. |
The system looks at the Authorization service field defined for the stored value card pay type to determine the service bureau that performs balance inquiries for the stored value card pay type. |
3. |
The system looks at the Communication type field defined for the service bureau to determine the method of communication used to transmit balance inquiry transactions between Order Management System and the service bureau. Integration Layer indicates Order Management System communicates with the external system using advanced queuing.
Payment Link indicates Order Management System communicates
with the external system using a point-to-point integration instead
of using advanced queuing. The system looks at the PAY_LINK properties
in Working with Customer Properties (PROP) to
communicate with the service bureau using a point-to-point integration.
Note: This option is available for the Customer Engagement Stored Value Card Integration. The system uses the Customer Engagement Inquiry Request to send the balance inquiry request to Oracle Retail Customer Engagement and receives the response in the Customer Engagement Inquiry Response. |
4. |
If a response is received from the service bureau, and:
|
Note:
If a balance inquiry response is not received from the service bureau, for example, due to communication errors, the system will continue with batch authorization.Examples: The following examples explain what happens to a stored value card pay type on an order, based on the remaining balance on the card.
Example: | Balance: | Results: |
---|---|---|
Order total = $100.00 Stored value card = catch-all |
$120.45 |
The system authorizes the stored value card pay type for $100.00. Once the stored value card on the order is authorized, the system generates a pick slip. The remaining balance on the stored value cad is $20.45. |
Order total = $100.00 Stored value card = catch-all Credit card = $25.00 |
$45.50 |
Because the stored value card does not have $75.00 remaining to apply to the order, the system does not authorize the pay types on the order and does not generate a pick slip for the order. If a Hold Reason for Stored Value Cards with Insufficient Funds (J18) is defined, the system places the order on hold. The remaining balance on the stored value card is $45.50. |
Order total = $100.00 Stored value card = $75.00 Credit card = catch-all |
$45.50 |
The system authorizes the stored value card for $45.50 and authorizes the credit card for $54.50. Once the pay types on the order are authorized, the system generates a pick slip. The remaining balance on the stored value card is zero. An order payment history message is created:
|
Transmitting Activation and Reversal Transactions (SSVC)
Purpose: Use this menu option to process activation and authorization reversal download triggers and generate the corresponding messages to send to the service bureau for processing.
System control value: The Use Activation / Reversal Batch Processing (I50) system control value controls whether activation and authorization reversal transactions are processed immediately or in batch.
-
If selected, the system does not process activation or authorization reversal trigger records until you submit the batch process using this menu option or a periodic function.
-
Periodic function SVCACT (program name PFR0076) processes activation trigger records.
-
Periodic function SVCREV (program name PFR0077) processes authorization reversal trigger records.
In this situation, the SVC Activation and SVC Reversal integration layer jobs can remain inactive.
-
-
If unselected, when active, the Activation and Reversal integration layer jobs monitor for activation and authorization reversal trigger records to process at defined intervals, based on the Outbound delay time.
For more information: See:
-
Stored Value Card Purchase and Activation for more information on activating a stored value card.
-
Stored Value Card Authorization Reversal for more information on performing a stored value card authorization reversal.
-
Credit Card Authorization Reversal for more information on performing a credit card authorization reversal.
-
Working with Outbound Interface Transactions (WOIT) for more information on reviewing triggers.
Transmit SVC/CC Transactions Screen
Use this screen to submit a batch job to process activation and authorization reversal download triggers and generate the corresponding messages to send to the service bureau for processing.
You can select to process activations or authorization reversals from this screen.
How to display this screen: Enter SSVC in the Fast path field or select Transmit Stored Value Card Transactions from a menu.
Field | Description |
---|---|
Activations |
Indicates if the submitted batch job processes activation download triggers. Valid values: Selected = The submitted batch job processes activation download triggers. Unselected = The submitted batch job does not process activation download triggers. Activation download triggers are identified by:
See Activating a Stored Value Card for additional processing information. |
Reversals |
Indicates if the submitted batch job processes authorization reversal download triggers. Valid values: Selected = The submitted batch job processes authorization reversal download triggers. Unselected = The submitted batch job does not process authorization reversal download triggers. Authorization reversal download triggers are identified by:
See:
|
Screen Option | Procedure |
---|---|
Submit the batch job to process download triggers |
Select Submit. See: |
Importing Item/SKU and Set Data
Topics in this part: The following topics describe how to import item/SKU and set data into Order Management System 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 Management System.
-
Importing Set Components (WCUP) provides details on building sets, including finished goods and variable sets.
Importing Item-Related Supporting Data (SDUP)
Purpose: Use the Submit Supporting Data Upload option to import supporting data related to items and order maintenance.
In this topic:
Periodic function: You can also submit the upload through the UPLSDTA periodic function.
Submit Supporting Data Upload Screen (SDUP)
Purpose: Use this screen to create new records in supporting tables based on the records that are currently in the Supporting Data Upload table for your company. You can use this screen to create records in the following tables:
-
Long SKU Division
-
Long SKU Department
-
Long SKU Class
-
Item Class
-
SKU Elements 1, 2, and 3
-
Item Status
-
Retail Class
-
Return Reason
-
Exchange Reason
How to display this screen: Enter SDUP in the Fast path field at the top of any menu, or select Submit Supporting Data Upload from a menu.
When you select Submit at this screen, the system submits the SUPPUPLOAD job.
Job processing:
-
The job evaluates each record in the Supporting Data Upload table that is associated with your current company.
-
If the job can create the record in the specified table without error, it creates the record and deletes the Supporting Data Upload record.
-
If the Supporting Data Upload record is in error for any reason, the job leaves the record in the table and updates it with a description of the error.
-
Since the job selects records in your company, records that do not have a valid company number remain in the table.
Supporting Data Upload Table
The contents of this table are described below.
Company field: The company field is required for all record types. The company number is numeric, three positions, and is validated against the Company table.
Additional fields ignored: If the record includes information in additional fields not listed below, the system ignores the information. For example, if the Misc1 field is populated for a record type that does not require this information, the contents of the field are discarded.
When you select Submit at the Submit Supporting Data Upload Screen (SDUP), the system process all error-free records whose Company field matches the submitting company, and ignores any records in the table whose Company does not match or that have already been flagged with an error reason.
Type | Updates | Additional Fields Used to Create Records |
---|---|---|
EXR |
Exchange Reason: Establishing Exchange Reason Codes (WEXR) |
Code = Numeric, 3 positions. The exchange reason code. Description = Alphanumeric, 30 positions. Each of the above fields is required. You can use Establishing Exchange Reason Codes (WEXR) to enter additional information. See that menu option for more information. |
ICL |
Item Class: Working with Item Classes (WICL) |
Code = Alphanumeric, 3 positions. The item class code. Description = Alphanumeric, 30 positions. Each of the above fields is required. Note: You can use Working with Item Classes (WICL) to enter additional information for an item class. See that menu option for more information. |
IST |
Item Status: Working with Item Status (WIST) |
Code = Alphanumeric, 1 position. The item status code. Description = Alphanumeric, 30 positions. Each of the above fields is required. Note: You can use Working with Item Status (WIST) to enter order entry messages and a return disposition code. See that menu option for more information. |
LDV |
Long SKU Division: Creating and Maintaining Long SKU Divisions (WLDV) |
Code = Alphanumeric, 3 positions. The long SKU division code. Note: Although the long SKU division field is 4 positions elsewhere, the supporting data upload supports just 3 positions.Description = Alphanumeric, 30 positions. Each of the above fields is required. |
LSC |
Long SKU Class: Working with Long SKU Classes (WLSC) |
Code = Numeric, 4 positions. The long SKU class code. Description = Alphanumeric, 30 positions. Each of the above fields is required. You cannot upload or work with long SKU classes if the Use Retail Integration (H26) system control value is selected. |
LSD |
Long SKU Department: Working with Long SKU Departments (WLSD) |
Code = Numeric, 4 positions. The long SKU department code. Description = Alphanumeric, 30 positions. Each of the above fields is required. Misc1 = Long SKU division. Alphanumeric, 3 positions. Required if the Require Long SKU Division with Long SKU Department (E85) system control value is selected; otherwise, optional. Must be a valid long SKU division. |
RTC |
Retail Class: Working with Long SKU Departments (WLSD) |
Code = Numeric, 4 positions. The retail class code. Description = Alphanumeric, 30 positions. Misc1 = The long SKU department to which the retail class is being assigned. Numeric, 4 positions. Must be a valid long SKU department. Each of the above fields is required. Note:
|
RTR |
Return Reason: Establishing Return Reason Codes (WRTR) |
Code = Numeric, 3 positions. The return reason code. Description = Alphanumeric, 30 positions. Each of the above fields is required. You can use Establishing Return Reason Codes (WRTR) to enter additional information. See that menu option for more information. |
SEO |
SKU Element 1: Working with SKU Elements (WSK1, WSK2, WSK3) |
Code = Alphanumeric, 4 positions. The SKU element. Description = Alphanumeric, 10 positions. Misc1 = Sort sequence number. Numeric, 5 positions. All fields except Misc1 are required. |
SET |
SKU Element 3: Working with SKU Elements (WSK1, WSK2, WSK3) |
Code = Alphanumeric, 4 positions. The SKU element. Description = Alphanumeric, 10 positions. Misc1 = Sort sequence number. Numeric, 5 positions. All fields except Misc1 are required. |
SEW |
SKU Element 2: Working with SKU Elements (WSK1, WSK2, WSK3) |
Code = Alphanumeric, 4 positions. The SKU element. Description = Alphanumeric, 10 positions. Misc1 = Sort sequence number. Numeric, 5 positions. All fields except Misc1 are required. |
Understanding Supporting Data Upload Errors
When you run the upload, the job clears any Supporting Data Upload records if it was able to create a new record in the related target table. It updates each remaining record with a description of the error that prevented the update of the target table.
The information in the Supporting Data Upload table (MSSDUP) is not displayed on any screen.
Error | Notes |
---|---|
All record types |
See the Supporting Data Upload Table for a summary of the requirements of each record type. |
|
No code was specified for the Supporting Data Upload record. |
|
The record already exists in the related table. Note: See the RTC record type above for additional considerations related to retail class uploads. |
|
No description was specified for the Supporting Data Upload record. |
Exchange Reason |
|
|
The exchange reason is a three-position numeric code. See Establishing Exchange Reason Codes (WEXR) for background. |
ICL (item class) |
|
|
The item class code is a three-position alphanumeric field. See Working with Item Classes (WICL) for background. |
IST (item status) |
|
|
The item status code is a one-position alphanumeric field. See Working with Item Status (WIST) for background. |
LSC (long SKU class) |
|
|
You cannot upload a long SKU class if the Use Retail Integration (H26) system control value is not selected. |
|
The long SKU class is a four-position numeric code. |
LSD (long SKU department) |
|
|
The long SKU division code specified in the Misc1 field exceeds three positions. |
|
No long SKU division code was specified in the Misc1 field, and the Require Long SKU Division with Long SKU Department (E85) system control value is selected. |
|
The long SKU department code cannot exceed four positions. |
|
The long SKU division code specified in the Misc1 field is not valid. Note: This error occurs even if the Require Long SKU Division with Long SKU Department (E85) system control value is unselected. |
|
The long SKU department specified cannot include non-numeric characters. |
RTC (retail class) |
You can assign a retail class to a long SKU department if the Use Retail Integration (H26) system control value is selected. Also, you can assign the same retail class code to multiple long SKU departments, but not through the same supporting table upload process. See Working with Long SKU Departments (WLSD) for background. |
|
The Use Retail Integration (H26) system control value is not selected. |
|
The long SKU department code specified in the Misc1 field is not valid. |
|
The long SKU department code specified in the Misc1 field is not numeric, or no long SKU department was specified. |
|
The retail class is a four-position numeric code. |
|
The retail class is a four-position numeric code. |
RTR (return reason) |
|
|
The return reason is a three-position numeric code. See Establishing Return Reason Codes (WRTR) for background. |
SEO, SEW, SET (SKU element 1, 2, or 3) |
See Working with SKU Elements (WSK1, WSK2, WSK3) for background on the SKU element fields. |
|
The first, second, and third SKU elements are each four-position alphanumeric fields. |
|
The first, second, and third SKU sort sequence numbers are each five-position numeric fields. |
|
The first, second, and third SKU descriptions are each ten-position alphanumeric fields. |
Importing Set Components (WCUP)
Purpose: Use the set component upload to build sets, including standard sets, finished goods, and variable sets.
Process overview: To create sets:
-
Create the main set item. Use Performing Initial Item Entry (MITM) or the RI Item Upload Process to create the main set item, specifying the appropriate Kit type. For example, to create a variable main set item, select a Kit type of Variable Set.
-
Specify additional information about the main set. Set up any additional information specific to the main set item, such as the item offer and item price.
-
Variable set? For a variable set, you need to first use either Entering Variable Set Information (WVST) or the set component upload to create variable set groups before you add variable set components to each group.
-
-
Build the set components. You can use either the menu options described under Working with Sets or the set component upload to specify the component items included in the set.
Example:
To sell an assortment of pens as a set:
-
Use Performing Initial Item Entry (MITM) or the RI Item Upload Process to create the item PE123 with a Kit type of Set. At this time, you can assign the item to an offer and specify pricing for the set.
-
If necessary, use Performing Initial Item Entry (MITM) or the RI Item Upload Process to create each component item that will be included in the set.
-
Create the main set item if you are using Entering Set Information (WSET). (If you are using the set component upload, this step takes place automatically when you build components.)
-
Using Entering Set Information (WSET) or the set component upload, assign each component item to the set, specifying the quantity to add. Optionally, you can specify additional information, such as cost percentage or a coordinate group number to make sure the components ship together.
In this topic:
Work with Component Upload Screen (WCUP)
Purpose: Use this screen to create new sets and set components based on the records in the Set Component Upload table for your company. You can use this screen to create records in the following tables:
-
Kit and Kit Detail
-
Set and Set Detail
-
Variable Set, Variable Set Detail, and Variable Set Group
Background on sets: See Working with Sets for general background on sets in Order Management System.
How to display this screen: Enter WCUP in the Fast path field at the top of any menu, or select Work with Set Component Upload from a menu.
Field | Description |
---|---|
Type |
The type of set record being uploaded. Valid values are:
If the Type in the Set Component Upload table is set to any other value, that value is displayed. The Type is an alphanumeric, 2-position field. Optionally, select a Type to restrict display to upload records of that type. |
Master item |
The main set item specified in the Set Component Upload record. You identify an item as a main set item through the Kit type field. The SKU fields, if any, are to the right. Note: To determine the set component item, select Change or Display. See the Component Upload Screen (Change Mode) for more information.Item code: alphanumeric, 12 positions; optional. SKU codes: alphanumeric, three 4-position fields; optional. |
Error |
The description of the error, if any, flagged by the upload program. This field is blank if you have not yet attempted to upload the record, or if you have corrected the error and the record can be resubmitted. See Understanding Set Component Upload Errors for more information. |
Option | Procedure |
---|---|
Submit the set component upload process |
Select Process to generate set headers and components based on the information in the Set Component Upload table. See Submitting the Set Component Upload for more information. |
Change a set component upload record |
Select Change for a record to advance to the Component Upload Screen (Change Mode) in Change mode. |
Review a set component upload record |
Select Display for a record to advance to the Component Upload screen in Display mode to review the set component and other detail information. You cannot change any information at this screen. See the Component Upload Screen (Change Mode) for field descriptions. |
Delete a set component upload record |
Select Delete to delete a set component record. |
Submitting the Set Component Upload
Upload process: You can create set component records from the contents of the Set Component Upload table:
-
Create a Set Component file (INSCUP) file that you will use to populate the Set Component Upload Table (INSCUP) by:
-
Creating your own, using a text editor, or
-
Copying the sample file upload data, pasting the data into a text editor, and saving it with the file extension
.TXT
.
Note:
To leave any field in the upload file blank, pass a space in an alphanumeric field or 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. -
-
Use the contents of the upload file to create records in the Set Component Upload table:
-
Use the File Storage API to upload the contents of the file to the FILE_STORAGE table, and then use the UPSETCM periodic function (Program name PFR0134, Parameter INSCUP) to use the file contents to populate the Set Component Upload Table (INSCUP), or
-
Place the file in the CWDIRECTCP_UPLOAD_ DIRECTORY if you do not have the file storage API enabled, and then use the UPSETCM periodic function (Program name PFR0134, Parameter INSCUP) to use the file contents to populate the Set Component Upload Table (INSCUP), or
-
Use the Work with File Upload Screen to upload the Set Component file and automatically populate the Set Component Upload table.
-
-
Use the contents of the Set Component Upload table to create or update set components:
-
Run the UPLSETS periodic function (Program name PFR0095), or
-
Select Process at the Work with Component Upload Screen (WCUP).
Job processing:
-
Regardless of whether you use the UPLSETS periodic function or select Process at the Work with Component Upload Screen (WCUP), the job evaluates each record in the Set Component Upload table that is associated with your current company.
-
If the job can create the record in the specified table without error, it creates the record and deletes the Set Component Upload record.
-
If the Set Component Upload record is in error for any reason, the job leaves the record in the table and updates it with a description of the error.
-
Since the job selects records in your company, records that do not have a valid company number remain in the table.
-
Set Component Upload Table (INSCUP)
The contents of this table are described below.
Sample Set Component Upload data: You can use the sample data below to create a record in the Set Component Upload table.
Sample Type F: Kit and Kit Detail upload record:
7|F|FINISHEDGOOD||||FINISHCOMP1||||1|0|0|0|0||0|
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|
Additional information: Any additional information beyond the fields listed below is discarded in most cases; however, if a non-SKUed main set item or component item includes SKU fields, the process puts the record in error. See Understanding Set Component Upload Errors for more information.
Field | Description |
---|---|
Company |
The company field is required for all record types and is validated against the Company table. Numeric, 3 positions; required. |
Set type |
Indicates the type of record to create. Valid values: Note: This field is not case-sensitive; the process treats f the same as F.Alphanumeric, 2 positions; required. |
Type F: Kit and Kit Detail |
See Entering Finished Goods Information (WFGD) for background. |
Master item |
The finished good item for which you are building the components. The item must have its Kit type set to Finished Good. If the Kit Header does not already exist, the process creates it when you upload the first component. Alphanumeric, 12 positions; required. |
Master SKU elements 1, 2, and 3 |
Alphanumeric, three 4-position fields. A valid SKU is required if the kit master item has SKU’s. |
For each component used to make the finished good: |
|
Component item |
Alphanumeric, 12 positions; required. |
Component SKU elements 1, 2, and 3 |
Alphanumeric, three 4-position fields. A valid SKU is required if the item has SKU’s. |
Quantity |
The quantity of the item used to create the finished good. Numeric, 5 positions; required. |
Type S: Set and Set Detail |
See Entering Set Information (WSET) for background. |
Master item |
The main set item for which you are building the components. The item must have its Kit type set to Set. If the Set record does not already exist, the process creates it when you upload the first component. Alphanumeric, 12 positions; required. |
Master SKU elements 1, 2, and 3 |
Alphanumeric, three 4-position fields. A valid SKU is required if the set item has SKU’s. |
For each component to add to the order when the customer orders the set: |
|
Component item |
Alphanumeric, 12 positions; required. |
Component SKU elements 1, 2, and 3 |
Alphanumeric, three 4-position fields. A valid SKU is required if the item has SKU’s. |
Quantity |
The quantity of the component to add to the order. Numeric, 5 positions; required. |
Cost % |
The percentage of the set’s total cost contributed by this component. Numeric, 5 positions with a 2-place decimal; optional. |
Coordinate group |
A common coordinate group number assigned to components to make sure they ship together. Numeric, 3 positions; optional. |
Type VG: Variable Set and Variable Set Group |
Note:
See Entering Variable Set Information (WVST) for background. |
Master item |
The main set item for which you are building the variable set group(s). The item must have its Kit type set to Variable Set. If the Variable Set record does not already exist, the process creates it when you upload the first variable set group. Alphanumeric, 12 positions; required. |
Master SKU elements 1, 2, and 3 |
Alphanumeric, three 4-position fields. A valid SKU is required if the variable set item has SKU’s. |
For each group to add to the variable set: |
|
Group |
The code identifying the group of like items from which the customer selects in order entry. Numeric, 3 positions; required. |
Group description |
The description of the group. Displayed in order entry. Alphanumeric, 30 positions; required. |
# of items |
The number of items or units that the customer can order from this group. Numeric, 3 positions; required. |
Type VI: Variable Set Detail |
|
Master item |
The main set item for which you are building the variable set components. The item must have its Kit type set to Variable Set, and the Variable Set record and Variable Set Group must already exist. Alphanumeric, 12 positions; required. |
Master SKU elements 1, 2, and 3 |
Alphanumeric, three 4-position fields. A valid SKU is required if the variable set item has SKU’s. |
For each component item to add to the variable set group: |
|
Component item |
Alphanumeric, 12 positions; required. |
Component SKU elements 1, 2, and 3 |
Alphanumeric, three 4-position fields. A valid SKU is required if the item has SKU’s. |
Group |
The variable set group in which to include the item. Numeric, 3 positions; required. |
Understanding Set Component Upload Errors
When you run the upload, the job clears any Set Component Upload records if it was able to create a new record in the related target table. It updates each remaining record with a description of the error that prevented the update of the target table.
Which errors can you correct?
-
You can use the Component Upload Screen (Change Mode) to correct errors related to any additional fields beyond the company, set type, component item and SKU, and component item and SKU.
-
Otherwise, you can correct the record directly in the Set Component Upload table, or delete the record and recreate it, or create the record in the target table using the standard menu option.
Error | Notes |
---|---|
All component upload types |
See the Set Component Upload Table (INSCUP) for a summary of the requirements of each record type. |
|
The record already exists in the destination table. |
|
The Type was not K, S, VG, or VI. The error displayed at the Component Upload Screen
(Change Mode) is |
|
The main set item specified does not exist. |
|
The main set item specified is a SKU’d item, and no SKU’s were specified in the upload table; or the main set item specified is a non-SKU’d item, and SKU’s were specified. |
|
No type was specified. |
For all types except Variable Set Group (VG): |
|
|
The component item specified does not exist. |
|
The component item specified is a SKU’d item, and no SKU’s were specified in the upload table; or the component item specified is a non-SKU’d item and SKU’s were specified. |
Kit (Type F) |
When you upload the first component for a finished good master item, the system automatically creates the Kit header. See Entering Finished Goods Information (WFGD) for background. |
|
The master item specified does not have its Kit type set to Finished Good. |
|
No Quantity was specified for the component. The Quantity is a required field. |
|
There is an open work order for the finished good. See Finished Good Work Order Processing (WWOR) for information. Note: The following do not cause errors when you upload finished good components:
|
Set (Type S) |
When you upload the first component for a main set item, the system automatically creates the Set header. See Entering Set Information (WSET) for background. |
|
The master item specified does not have its Kit type set to Set. |
|
No Quantity was specified for the component. The Quantity is a required field. Note: The following do not cause errors when you upload set components:
|
Variable Set Group (Type VG) |
When you upload the first group for a variable main set item, the system automatically creates the Variable Set header. Note:
See Entering Variable Set Information (WVST) for background. |
|
The master item specified does not have its Kit type set to Variable Set. |
|
No # of items was specified for the group. The # of items is a required field. |
|
No Group number was specified. The Group is a required field. |
|
No Group description was specified. The Group description is a required field. Note: Populating additional fields (except for SKU fields for a non-SKU’d item) does not create an error when you upload a variable set group. |
Variable Set Item (Type VI) |
The variable set header and group must already exist before can upload a variable set item. See Entering Variable Set Information (WVST) for background. |
|
The master item specified does not have its Kit type set to Variable Set. |
|
No Group number was specified. The Group is a required field. |
|
The Group number specified does not exist for the variable set. |
Component Upload Screen (Change Mode)
Purpose: Use this screen to review or change the information in a Set Component Upload record.
For more information: See the Set Component Upload Table (INSCUP) for information on how to create Set Component Upload records.
What can you change? At this screen, you can change any of the information except the upload type, the main item/SKU, and the component item/SKU. If this information is incorrect, you can delete the upload record and create the component another way, such as sending a correct upload record or using the related menu option to create the component manually.
Errors flagged at this screen: This screen flags:
-
All of the errors identified under Understanding Set Component Upload Errors, with the exception of the
Record already exists
error. The upload program identifies this error by comparing the information for the upload record with the information in the target table. You can delete records flagged with this error, as the upload will not process them. Also, -
Errors related to additional information that is not used for the component upload type. This is information that the upload program ignores. These errors are described below under the fields that trigger the errors.
How to display this screen: Select Change for a Set Component Upload record at the Work with Component Upload Screen (WCUP).
Field | Description |
---|---|
Type |
The type of component to upload:
If the Type in the Set Component Upload table is set to any other value, that value is displayed. The Type is an alphanumeric, 2-position field. Alphanumeric; display-only. |
Master item |
The main set item specified in the Set Component Upload record. You identify an item as a main set item through the Kit type field. Alphanumeric, 12 positions; display-only. |
Master SKU |
Additional information identifying the master item, such as its color or size. Alphanumeric, three 4-position fields; display-only. |
Component item |
The component item to upload. Alphanumeric, 12 positions; display-only. |
Component SKU |
Additional information about the component item, such as its color or size. Alphanumeric, three 4-position fields; display-only. |
Quantity |
The quantity of the component item/SKU to add to the order. Required for finished good and set components (types F and S). Not valid for variable set group or variable set items (types VG or VI). Numeric, 5 positions; required or invalid depending on type. |
Cost |
The percentage of the set’s cost represented by the component. Used only for set components (type S). Invalid for other record types. Numeric, 5 positions with a 2-place decimal; optional or invalid depending on type. |
Coordinate group# |
A number you can assign to components to make sure they ship together. Valid for set components (type S). Invalid for other record types. You cannot assign a coordinate group number of 999 to a component of a regular set (type S). Numeric, 3 positions; optional or invalid depending on type. |
Interval |
Not currently implemented. Numeric, 5 positions. |
Group |
The code identifying the group of like items from which the customer selects in order entry for a variable set. Required for variable set groups and components (types VG and VI). Invalid for other record types. Numeric, 3 positions; required or invalid depending on type. |
Description |
The description of the variable set group. Required for variable set groups (type VG). Invalid for other record types. Numeric, 3 positions; required or invalid depending on type. |
# of items |
The number of items or units that the customer can order from the variable set group. Required for variable set groups (type VG). Invalid for other record types. Numeric, 3 positions; required or invalid depending on type. |
Error |
The error assigned by the upload program. See Understanding Set Component Upload Errors for a list of errors. |
ChannelAdvisor Integration
Topics in this part: The following topics describe the integration between Order Management System and ChannelAdvisor.
-
ChannelAdvisor Integration Overview provides an overview of the various components of the integration.
-
ChannelAdvisor Setup provides information on the setup required within Order Management System to support the integration.
-
Working with ChannelAdvisor Accounts (WCAA) describes the screens you use to up accounts, marketplaces, and offers for integration with ChannelAdvisor.
Working with ChannelAdvisor Accounts (WCAA)
Purpose: Use this option to set up your ChannelAdvisor account and marketplaces.
Background: See ChannelAdvisor Integration Overview for background on the ChannelAdvisor integration.
Additional setup: See ChannelAdvisor Setup for information on additional required setup for the ChannelAdvisor integration.
In this topic:
Note:
The ChannelAdvisor integration has been designed and tested to work for the Amazon Marketplace. To use the ChannelAdvisor integration with a marketplace other than Amazon, contact your Order Management System project manager.Work with ChannelAdvisor Accounts Screen
Use this screen to work with ChannelAdvisor accounts and marketplaces.
How to display this screen: Enter WCAA in the Fast path field at the top of any menu, or select ChannelAdvisor Work with Accounts from a menu.
Field | Description |
---|---|
Account |
The account ID assigned by ChannelAdvisor for your account. Upper and lower case. Note: You may be able to verify the account ID by logging into ChannelAdvisor, selecting the account, and then My Account > Account Authorizations.Alphanumeric, 50 positions; optional. |
Description |
The description of your ChannelAdvisor account. Alphanumeric, 30 positions; optional. |
Option | Procedure |
---|---|
Create a new ChannelAdvisor account |
Select Create to advance to the Create ChannelAdvisor Account Screen. |
Change an existing ChannelAdvisor account |
In the Action field, select Change to advance to the Change ChannelAdvisor Account screen. At this screen, you can change any information except the ChannelAdvisor account ID. See the Create ChannelAdvisor Account Screen for field descriptions. |
Display an existing ChannelAdvisor account |
In the Action field, select Display to advance to the Display ChannelAdvisor Account screen. You cannot change any information at this screen. See the Create ChannelAdvisor Account Screen for field descriptions. |
Delete an existing ChannelAdvisor account |
In the Action field, select Delete. At the Confirm Delete window, select Yes to delete the account; otherwise, select No. |
Work with ChannelAdvisor marketplaces |
In the Action field, select Marketplaces to advance to the Work with ChannelAdvisor Marketplaces Screen. |
Work with ChannelAdvisor offers |
In the Action field, select Integration Offers to advance to the Work with ChannelAdvisor Offers Screen. |
Create ChannelAdvisor Account Screen
Purpose: Use this screen to set up the ChannelAdvisor account you use to integrate with ChannelAdvisor, including information required for the inventory and pricing uploads to ChannelAdvisor and authentication information required for ChannelAdvisor web services (orders, shipments, and refunds).
How to display this screen: Select Create at the Work with ChannelAdvisor Accounts Screen.
Field | Description |
---|---|
Account (ChannelAdvisor account ID) |
The account ID assigned by ChannelAdvisor for your account. Upper and lower case. This ID is a GUID (globally unique identifier) composed of a string of hexadecimal digits, such as 21ec2020-3aea-1069-A2dd-08002b30309d. Not the same as the user ID you use to log into the ChannelAdvisor web site. Note: You may be able to verify the account ID by logging into ChannelAdvisor, selecting the account, and then My Accounts > Developer Network > Account Authorizations.Alphanumeric, 50 positions. Create screen: Required. Change screen: Display-only. |
Description |
The description of your ChannelAdvisor account. Alphanumeric, 30 positions; required. |
Web Developer Key |
A unique ID assigned by ChannelAdvisor. Upper and lower case. The developer key, Account (ChannelAdvisor account ID), and Web Developer Password are required for any call to a ChannelAdvisor API that accesses your account information. The developer key and password are included in the messages sent to ChannelAdvisor to request a list of orders, confirm shipments, and submit refunds. See ChannelAdvisor Integration Overview for descriptions of these processes. Alphanumeric, 50 positions; optional, but required for the ChannelAdvisor integration. |
Web Developer Password |
The password associated with the Web Developer Key. Upper and lower case. Not the same as the password you use to log into the ChannelAdvisor web site. The developer key and password are included in the messages sent to ChannelAdvisor to request a list of orders, confirm shipments, and submit refunds. See ChannelAdvisor Integration Overview for descriptions of these processes. Alphanumeric, 50 positions; optional, but required for the ChannelAdvisor integration. |
Price Filename |
The file name for the CAPRICE periodic function to use when creating the pricing upload file. Upper and lower case. Note: Both the inventory import and the pricing import may be listed with a File Type of Inventory in ChannelAdvisor.Alphanumeric, 50 positions; optional, but required for the ChannelAdvisor integration. |
Local Price Folder |
The folder
on the Order Management System server for the CAPRICE periodic
function to use when creating the price upload file. Upper and lower
case. Typically set to Alphanumeric, 50 positions; optional, but required for the ChannelAdvisor integration. |
When creating your application in ChannelAdvisor, record the following fields so that you can enter them correctly when creating or updating your ChannelAdvisor account in Order Management System. |
|
Application Id |
A code generated automatically by ChannelAdvisor, identifying your system during authentication. Displayed at the Your Applications screen in ChannelAdvisor. Required for price and inventory integration with ChannelAdvisor. Case-sensitive. Alphanumeric, 60 positions; optional, but required for the ChannelAdvisor integration. |
Shared Secret |
A code generated automatically by ChannelAdvisor to authentication your system. Displayed at the Your Applications screen in ChannelAdvisor. Required for price and inventory integration with ChannelAdvisor. Case-sensitive. Alphanumeric, 60 positions; optional, but required for the ChannelAdvisor integration. |
Refresh Token |
A value generated by ChannelAdvisor during the initial authorization request. Required for price and inventory integration with ChannelAdvisor. Case-sensitive. Generating the Refresh Token: To generate the request token:
You need to retrieve the token before closing the window. For more information: See https://developer.channeladvisor.com/authorization/developer-console-token. If the refresh token is not correct, the log indicates: Alphanumeric, 60 positions; optional, but required for the ChannelAdvisor integration. |
Work with ChannelAdvisor Marketplaces Screen
Purpose: Use this screen to work with marketplaces
where you sell through ChannelAdvisor. The CAORDUP periodic function matches the
marketplace with the ItemSaleSource
passed for
an order to identify the:
-
source code to apply to the order, based on your entry at this screen
-
payment method to apply to the order, based on the pay type’s CA cross reference #
See Importing Orders from ChannelAdvisor for background.
Note:
The ChannelAdvisor integration has been designed and tested to work for the Amazon Marketplace. To use the ChannelAdvisor integration with a marketplace other than Amazon, contact your Order Management System project manager.How to display this screen: Select Marketplaces from the Action field for your ChannelAdvisor account at the Work with ChannelAdvisor Accounts Screen.
Field | Description |
---|---|
Account (ChannelAdvisor account) |
The account ID assigned by ChannelAdvisor for your account. This ID is a GUID (globally unique identifier), as set up through the Create ChannelAdvisor Account Screen. Alphanumeric, 50 positions; display-only. |
Description (unlabeled field) |
The description of your ChannelAdvisor account, as set up through the Create ChannelAdvisor Account Screen. Alphanumeric, 30 positions; display-only. |
Source |
The source
code to use on orders from this marketplace. Typically associated
with the offer specified through the Work with ChannelAdvisor Offers Screen option. If the Enter a full or partial source code to display marketplaces that start with your entry. Note: The source code specified must use a line-level freight method.Alphanumeric, 9 positions; optional. |
Marketplace |
The name
of the marketplace, such as Amazon, where you sell merchandise through
ChannelAdvisor. If the
Note: If there is more than one pay type whose CA cross reference # matches, the function selects the highest pay type code.Enter a full or partial marketplace name to display marketplaces that start with your entry. Alphanumeric, 30 positions; optional. |
Option | Procedure |
---|---|
Create a new marketplace |
Select Create to advance to the Create ChannelAdvisor Marketplace Screen. |
Change an existing marketplace |
Select Change from the Action field to advance to the Change ChannelAdvisor Marketplace screen. At this screen, you can change the Source or the Marketplace. See the Create ChannelAdvisor Marketplace Screen for field descriptions. |
Delete a marketplace |
Select Delete for a marketplace. At the Confirm Delete window, select Yes to delete the marketplace; otherwise, select No. |
Create ChannelAdvisor Marketplace Screen
Purpose: Use this screen to create a new
marketplace where you sell through ChannelAdvisor. The CAORDUP periodic
function matches the marketplace with the ItemSaleSource
passed for an order to identify the:
-
source code to apply to the order, based on your entry at this screen
-
payment method to apply to the order, based on the pay type’s CA cross reference #
Purpose: See Importing Orders from ChannelAdvisor for background.
How to display this screen: Select Create at the Work with ChannelAdvisor Marketplaces Screen.
Field | Description |
---|---|
Account (ChannelAdvisor account) |
The account ID assigned by ChannelAdvisor for your account. This ID is a GUID (globally unique identifier), as set up through the Create ChannelAdvisor Account Screen. Alphanumeric, 50 positions; display-only. |
Description |
The description of your ChannelAdvisor account, as set up through the Create ChannelAdvisor Account Screen. Alphanumeric, 30 positions; display-only. |
Source |
The source
code to use on orders from this marketplace. Typically associated
with the offer specified through the Work with ChannelAdvisor Offers Screen option. If the Note: The source code specified must use a line-level freight method.Alphanumeric, 9 positions; required. |
Marketplace |
The name
of the marketplace, such as Amazon, where you sell merchandise through
ChannelAdvisor. If the
The marketplace name needs to match a ChannelAdvisor Site Token value. Note: If there is more than one pay type whose CA cross reference # matches, the function selects the highest pay type code.Alphanumeric, 30 positions; required. |
Work with ChannelAdvisor Offers Screen
Purpose: Use this screen to set up the offer you use to control pricing for the ChannelAdvisor integration, including the label for the ChannelAdvisor offer price. You send pricing information to ChannelAdvisor through the CAPRICE periodic function. This offer should match the ChannelAdvisor SKU X-Ref Offer (L92).
Note:
Although you can set up multiple offers with this menu option, typically you use a single offer for integration with ChannelAdvisor.Background: See ChannelAdvisor Integration Overview for background on the ChannelAdvisor integration, especially Sending Current Prices to ChannelAdvisor.
Additional setup:
-
See Working with ChannelAdvisor Accounts (WCAA) for information on setting up accounts and marketplaces for integration with ChannelAdvisor.
-
See Working with ChannelAdvisor Accounts (WCAA) for information on additional required setup for the ChannelAdvisor integration.
Note:
The ChannelAdvisor integration has been designed and tested to work for the Amazon Marketplace. To use the ChannelAdvisor integration with a marketplace other than Amazon, contact your Order Management System project manager.How to display this screen: Select Integration Offers for a ChannelAdvisor account on the Work with ChannelAdvisor Accounts Screen.
Field | Description |
---|---|
Account |
The account ID assigned by ChannelAdvisor for your account. Upper and lower case. This ID is a GUID (globally unique identifier), as set up through the Create ChannelAdvisor Account Screen. Alphanumeric, 50 positions; optional. |
Description |
The description of your ChannelAdvisor account, as set up through the Create ChannelAdvisor Account Screen. Alphanumeric, 30 positions; optional. |
Offer |
The offer that controls pricing for ChannelAdvisor. You send pricing information to ChannelAdvisor through the CAPRICE periodic function. This offer should match the ChannelAdvisor SKU X-Ref Offer (L92). Alphanumeric, 3 positions; optional. |
Price Output |
The label of the third price included in the price extract file by the CAPRICE periodic function. Upper and lower case. From the SKU Price, if any, for the specified offer; otherwise, from the Item Price for the specified offer. If there is no SKU Price or Offer Price for an item/SKU, this field is blank in the price file. Alphanumeric, 30 positions; optional. |
Option | Procedure |
---|---|
Create a Channeladvisor offer |
Select Create to advance to the Create ChannelAdvisor Offer Screen. |
Change a Channeladvisor offer |
Select Change for a Channeladvisor offer to advance to the Change ChannelAdvisor Offer screen. See the Create ChannelAdvisor Offer Screen for a description of the fields on this screen. |
Create ChannelAdvisor Offer Screen
Purpose: Use this screen to set up the offer you use to control pricing for the ChannelAdvisor integration, including the label for the ChannelAdvisor offer price. You send pricing information to ChannelAdvisor through the CAPRICE periodic function. This offer should match the ChannelAdvisor SKU X-Ref Offer (L92).
Background: See ChannelAdvisor Integration Overview for background on the ChannelAdvisor integration, especially Sending Current Prices to ChannelAdvisor.
How to display this screen: Select Create at the Work with ChannelAdvisor Offers Screen.
Field | Description |
---|---|
Account |
The account ID assigned by ChannelAdvisor for your account. Upper and lower case. This ID is a GUID (globally unique identifier), as set up through the Create ChannelAdvisor Account Screen. Alphanumeric, 50 positions; display-only. |
Description |
The description of your ChannelAdvisor account, as set up through the Create ChannelAdvisor Account Screen. Alphanumeric, 30 positions; display-only. |
Offer |
The offer that controls pricing for ChannelAdvisor. You send pricing information to ChannelAdvisor through the CAPRICE periodic function. This offer should match the ChannelAdvisor SKU X-Ref Offer (L92). Alphanumeric, 3 positions. Create screen: required. Change screen: display-only. |
Price output |
The field label of the third price included in the price extract file by the CAPRICE periodic function. Upper and lower case. From the SKU Price, if any, for the specified offer; otherwise, from the Item Price for the specified offer. If there is no SKU Price or Offer Price for an item/SKU, this field is blank in the price file. Alphanumeric, 30 positions; required. |
Merchandising Integration
Topics in this part: The following topics describe the integration between Order Management System and Oracle Retail merchandising applications.
-
Oracle Retail Merchandising Foundation Cloud Service (RMFCS) and Oracle Retail Pricing Cloud Service (RPCS) Integration: Provides information on importing items and pricing from Oracle Retail Merchandising Foundation Cloud Service (RMFCS) and from Oracle Retail Pricing Cloud Service (RPCS).
Note:
This integration will be deprecated in a future release. Importing Enterprise Foundation Data through Omnichannel Cloud Data Service (OCDS) can be used instead to import items and pricing. -
Integration with the Sales Audit Module of the Oracle Retail Merchandising Foundation Cloud Service; Provides information on transmitting sales and returns information to the Sales Audit module of the Oracle Retail Merchandising Foundation Cloud Service, details on the information mapped, and the setup required to support the integration.
-
Importing Enterprise Foundation Data through Omnichannel Cloud Data Service (OCDS): Provides information on importing enterprise foundation data, including items, prices, merchandise hierarchy, and item images from other retail applications through Oracle Omnichannel Cloud Data Service (OCDS).
-
Enterprise Order Integration (Future Receipts and Active PO/Pre-Order Processing): Provides information on importing future availability information for pre-orders, processing updates as pre-order items become available, and controlling the submission of these orders to Order Broker.
Print User Security Audit Reports (PUSA)
Purpose: Use this option to generate a report of:
-
changes to users, user classes, and secured features, or
-
users with changed passwords, or
-
both
You need to specify a date range for the reports, and have the option of restricting the user authority change report to a specific user or to updates for a particular table. Only administrative users should have authority to generate these reports.
Note:
Not all activity tracked in the User Audit table is included on the generated reports. See Tracking User, Authority, and Password Updates for background.Print Security Audit Reports Screen
How to display this screen: Enter PUSA in the Fast path field at the top of any menu, or select Print User Security Audit Reports from a menu.
Field | Description |
---|---|
Start date |
The first date to include on the User Authority Change Report and Password Change Report. Numeric, 6 positions (user date format); required. |
End date |
The last date to include on the User Authority Change Report and Password Change Report. The end date must be on or after the start date. Numeric, 6 positions (user date format); required. |
User authority changes |
Select this option to generate the ’User Authority Change Report. |
Password changes |
Select this option to generate the Password Change Report. No data is created for this report when you use Oracle Identity Cloud Service for password authentication. |
User |
Enter a valid user ID to restrict the User Authority Change Report to activity related to that user. Only updates to tables whose Authority changed matches the specified user ID can be included. This field does not affect the results included on the Password Change Report. Alphanumeric, 10 positions; optional. |
Table |
Select a table from the drop-down list to restrict the User Authority Change Report to activity for that table. Options and corresponding tables are:
Note:
|
Completing this screen:
-
Complete the Start date and End date.
-
Select either User authority changes to generate the User Authority Change Report, Password changes to generate the Password Change Report, or both options.
-
Optionally, specify a User or a Table to restrict the results on the User Authority Change Report to activity for your selections.
-
Select OK to validate your entries.
Completing this screen: Select Submit.
Order Volume Report (OVOL)
Purpose: Use this menu option to generate the Order Count report, which provides the total number of orders entered in Order Management System broken out by company, and optionally, order type for a specified date range.
Order Count Report Screen
Use this screen to specify the criteria used to generate the Order Count report.
Field | Description |
---|---|
From...To |
The date range you wish to use to generate the Order Count report. The system totals the number of orders entered within this date range for each Order Management System company. Numeric, 6 positions (user date format); required. |
Sort by order type |
Select this field to generate the Order Count Report by Order Type, which provide a break out of the total number of orders entered for a company by order type. Deselect this field to generate the Order Count Report, which provides an order count for each company across all order types. Optional. |
Screen Option | Procedure |
---|---|
Generate the Order Count Report or Order Count Report by Order Type |
Select Submit to generate the report. |
To generate the report:
-
Enter the date range you wish to use to generate the Order Count report in the From and To fields.
-
Select the Sort by order type field to generate the Order Count Report by Order Type, which provides a break out of the total number of orders entered for each company by order type; otherwise, deselect this field to generate the Order Count Report, which provides an order count for each company across all order types.
-
Select OK to validate your entries.
-
Select Submit to generate the Order Count report.
-
If you did not select the Sort by order type field, the system generates the Order Count Report, which provides the total number of orders entered in Order Management System broken out by company for a specified date range.
-
If you selected the Sort by order type field, the system generates the Order Count Report by Order Type, which provides the total number of orders entered in Order Management System broken out by order type within company for a specified date range.
-
Encryption: Re-Run Non-Order Report (CENR)
Purpose: This menu option is described in the Security Guides on My Oracle Support (1988467.1). Please contact your Order Management System representative for more information.
Encrypt Credit Card Order Batch (ECOB)
Purpose: This menu option is described in the Security Guides on My Oracle Support (1988467.1). Please contact your Order Management System representative for more information.
Encryption: Generate Switch Key (CESK)
Purpose: This menu option is described in the Security Guides on My Oracle Support (1988467.1). Please contact your Order Management System representative for more information.
Encryption: Switch Key Non-Order Conversion (CESN)
Purpose: This menu option is described in the Security Guides on My Oracle Support (1988467.1). Please contact your Order Management System representative for more information.
Encryption: Initial Non-Order Conversion (CENO)
Purpose: This menu option is described in the Security Guides on My Oracle Support (1988467.1). Please contact your Order Management System representative for more information.
Encryption: Delete Switch Key (CDSK)
Purpose: This menu option is described in the Data Encryption and Security Guide on My Oracle Support (1988467.1). Please contact your Order Management System representative for more information.
Work with Batch Tokenization (WBTK)
Purpose: This menu option is described in the Security Guides on My Oracle Support (1988467.1). Please contact your Order Management System representative for more information.
Process New Secured Features (NSEC)
Purpose: Use the Process New Secure Features option to create new secure features in each company in your environment, and define the default settings for each.
Prompting to process new secure features: When a new update that includes one or more new secure features is applied to your environment, a window prompts you to use this option. The prompt occurs for the first user to log in after the update was applied, and is no longer displayed once a user has worked through the new secure features for all companies.
You can also use this option on demand to process new secure features by selecting Process New Secure Features or entering NSEC in the Fast path field.
Note:
Oracle recommends that you process new secure features when they are added through an update, to prevent inconsistent results if a new secure feature has not been created for a company.How to process new secure features: When you select this option, the Change Secure Feature screen opens for each new secure feature in each existing company in your environment. Each time the screen opens, the user can select the setting for the new secure feature, or exit to set the secured feature to its default value.
When you select this option, an error message indicates if there are no new secure features.
Process New System Control Values (NSCV)
Purpose:Use the Process New System Control Values option to create new system control values in each company in your environment, and define the default settings for each.
Prompting to process new system control values: When a new update that includes one or more new system control values is applied to your environment, a window prompts you to use this option. The prompt occurs for the first user to log in after the update was applied, and is no longer displayed once a user has worked through the new system control values for all companies.
You can also use this option on demand to process new system control values by selecting Process New System Control Values or entering NSCV in the Fast path field.
Note:
Oracle recommends that you process new system control values when they are added through an update, to prevent inconsistent results if a new system control value has not been created for a company.How to process new system control values: When you select this option, the Change System Control Value screen opens for each new system control value in each existing company in your environment. Each time the screen opens, the user can select the setting for the new system control value, or exit to set the system control value to its default value.
When you select this option, an error message indicates if there are no new system control values.
Work with Finished Good (WKIT)
Purpose: This menu option is the same as WFGD; see Entering Finished Goods Information (WFGD) for more information.
Work with Warehouse Drop Point (WWDP)
Purpose: This menu option is the same as EWDP; see Editing Warehouse Drop Points (EWDP) for more information.