2 Configuration and Administration
About Application Screen
Purpose: Use the About Application screen to review information about Order Administration.
How to display this screen: Select About from an Admin screen (such as the Document Management Screen, Forms Management Screen, Job Management Screen, Commands, or User Control screens).
Note:
The About the Application window in Modern View also displays information about the Modern View build, including the build number, JET version, and JRAF version.
System Information | System Value |
---|---|
Version |
The build number installed in Order Administration. The version displays in major.minor.patch format, where major is the major release number, minor is the minor release number, and patch is the hot fix release number, if any. |
Operating System |
The version of the operating system you are using. |
Operating System Architecture |
The processing architecture used to run the Order Administration application. |
Java Version |
The version of Java used to run the Order Administration application. |
Java Vendor |
The vendor that provided the version of Java that runs the Order Administration application. |
Database Level |
The database level used to run the Order Administration application. The database level displays in major.minor.patch.databaselevel format, where major is the major release number, minor is the minor release number, patch is the patch release number, and databaselevel indicates the number of times a database update script has been run for the release, and is set to 0 if there is no patch, for example: 19.4.0. |
Internal Build |
The internal build number assigned to the EAR file used to run the Order Administration application. The build number displays in YYYYMMDDHHMMSSPM format, indicating the date and time of the build, with the last two positions indicating either AM or PM. |
Current Order Volume |
The order count for the current year. You can also run the Order Volume Report (OVOL) to generate the Order Count report, which provides the total number of orders entered in Order Administration broken out by company, and optionally, order type for a specified date range. Note:
|
Copyright |
Copyright information provided by Oracle. |
About Application Screen Options
Option | Procedure |
---|---|
Advance to the Document Management Screen |
Select My Docs. |
Advance to the Job Management Screen |
Select My Jobs. |
No additional options are available at this screen |
Select Advanced commands. |
Return to the previous Order Administration screen |
Select Exit. |
Advanced Queuing
Advanced queuing allows you to send messages between Order Administration and other applications using database-integrated message queuing.
Advanced queuing is made up of the following components:
Component | Description |
---|---|
Queuing Database |
The Oracle database used for queue processing. |
Queues |
An area where messages are stored so that they can be processed in sequential order (first in, first out). |
Queue Table |
Queues are stored in queue tables in the database. |
Message |
The actual data, such as an XML message, that is inserted into and retrieved from a queue. The message contains:
|
Message log |
The Message log tracks XML and transactional messages generated or received by Order Administration. |
In this topic:
For more information: See:
-
See Generic Web Services in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information on the web services available for Order Administration.
-
Working with Web Service Authentication (WWSA) for more information on how to define which Order Administration web service endpoints require authentication and the valid web service authentication users or client IDs for each web service
-
Logs for more information on the Order Administration application logs.
-
Working with Integration Layer Processes (IJCT) for more information on the processes that transmit data between Order Administration and an external system.
Advanced Queuing Process
Outbound Process Flow
-
A user or a process in Order Administration calls an outbound integration layer process to send information to an external system.
-
If the Communication type setting for the outbound integration layer process (IJCT) is set to Message Queue and the status of the integration layer process is active, the process looks at the queue defined for the process. For an outbound process, the queue indicates:
-
the name of the outbound queue to which the integration layer process sends the message for transmission to the external system; this must be a valid queue in the database used for queue processing.
-
the name of the XML message generated and sent to the external system.
-
-
The system sends the message to the outbound queue defined for the integration layer process.
-
An external system uses the JMS RESTful web service to retrieve the message from the queue in order to process the message; see the JMS RESTful Web Service for the correct format of the URL for this web service.
Note:
The web service authenticator, JMSQueue, in Work with Web Service Authentication (WWSA), defines the user for basic web service authentication for the JMS RESTful web service when it reads from a queue in the queuing database. In addition to defining the web service authentication user in Work with Web Service Authentication (WWSA), 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.
Inbound Process Flow
-
An external system uses an Order Administration web service to send a message to a queue in the database used for queue processing. Note: The target in the message must match the Inbound job name defined on the Integration Layer Process Queue screen in Work with Integration Layer Processes (IJCT). See Generic Web Services in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information on the web services available for Order Administration.
-
If the Communication type setting for an inbound integration layer process is set to Message Queue and the status of the integration layer process is active, the process monitors the queue defined for the process for new messages. For an inbound process, the queue indicates:
-
the name of the inbound queue that the integration layer process monitors for new messages to process from an external system; this must be a valid queue in the database used for queue processing.
-
the name of the job that processes the message from the inbound queue.
-
-
If the integration layer process finds a new message to process in the queue, the process picks up the message and processes it using existing functionality.
Note:
The web service authenticator, JMSQueue, in Work with Web Service Authentication (WWSA), defines the user for basic web service authentication for the JMS RESTful web service when it reads from a queue in the queuing database. In addition to creating the web service authentication user in Work with Web Service Authentication (WWSA), you must also create a corresponding user profile in Oracle Identify Cloud Service and assign the user to the corresponding web service role defined for the Order Management application.
For more information: See Integration Layer Processes and Web Services for more information on the integration layer processes that use a message queue.
Advanced Queuing Setup
Before you can begin using advanced queuing, you must complete the necessary setup.
JMS Server in WebLogic
# | Step |
---|---|
1. |
During installation of the application, the JMS server for Order Administration was created and configured in WebLogic. In addition, the OrderManagementNonXADS JDBC data source in WebLogic was created and configured in order to connect to the Order Administration database and advanced queuing database. |
2. |
In Work with Admin Properties (CPRP), the JMS_QUEUE_FACTORY property was set during installation based on the JMS server defined in WebLogic. This property contains the name of the Java Naming and Directory Interface (JNDI) used for queuing; this is the Local JNDI Name as defined in WebLogic. The delivered setting is AqJmsConnectionFactory. Use the following steps to verify the Local JNDI Name in WebLogic:
|
Queuing Database and Queues Configuration
# | Step |
---|---|
1. |
Typical advanced queuing configuration uses the Order Administration database as the queuing database. Make sure the database has open access to use for queue processing. |
2. |
Queues are delivered for the processes in Working with Integration Layer Processes (IJCT); see Delivered Queues. Use the following steps if you wish to create another queue for a job. For each queue you wish to create in the database:
EXEC DBMS_AQADM.CREATE_QUEUE_TABLE (queue_table => 'process_table', queue_payload_type => 'SYS.AQ$_JMS_TEXT_MESSAGE'); where process_table is the name of the queue table you wish to create.
EXEC DBMS_AQADM.CREATE_QUEUE (queue_name => 'process', queue_table => 'process_table'); where process is the name of the queue you wish to create and process_table is the name of the corresponding queue table. Note: the queue name is case-sensitive.
EXEC DBMS_AQADM.START_QUEUE (queue_name => 'process'); where process is the name of the queue you wish to start. The queue must be started in order to enable the queue for processing. Recommended queue naming convention:To easily identify the purpose of a queue, use the following naming convention when creating a queue: PROCESS_DIRECTION where:
Example:
|
3. |
Queue information is delivered for the processes in Working with Integration Layer Processes (IJCT). Verify the following:
|
Delivered Queues
The following queues are delivered with the application.
IJCT Process | Inbound queue | Outbound queue |
---|---|---|
CUST_OUT |
|
CUST_OUT_OUT |
EMAIL_OUT |
|
EMAIL_OUT_OUT |
INVOIC_OUT |
|
INVOIC_OUT_OUT |
INVTRAN_IN |
INVTRAN_IN_IN |
|
INV_DOWNLD_OUT |
|
INV_DOWNLD_OUT_OUT |
INV_INQURY |
INV_INQURY_IN |
INV_INQURY_OUT |
ITEM_OUT |
|
ITEMOUT |
PICK_OUT |
|
PICK_OUT_OUT |
PO_OUT |
|
PO_OUT_OUT |
RETURN_OUT |
|
'RETURN_OUT_OUT |
SVC_REVRSL |
SVC_REVRSL_IN |
SVC_REVRSL_OUT |
VENDOR_OUT |
|
VENDOR_OUT_OUT |
Viewing Messages on a Queue in the Database
Because messages are placed in normal rows in a database table, if you have access to the queuing database, you can query the table using standard SQL.
Use the following SQL command to view existing messages on a queue:
select msgid, enq_time, enq_uid, qt.user_data.text_vc || qt.user_data.text_lob from process_table qt where q_name = 'process'
where process_table is the name of the queue table and process is the name of the queue. Note: the queue name is case-sensitive.
JMS RESTful Web Service
Advanced queuing uses the Java Messaging Service (JMS) as its method to transmit information from the queuing database to an external system. The JMS RESTful web service is used to read from a queue in the queuing database.
The individual URLs for the web service use the following format: http(s)://server:port/oms/sxrs/jms/getFromQueue, where server:port identifies the server where the JMS RESTful web service is located.
In the payload, or message data, include the name of the queue to be read as a JSON string; for example: {"queueName":"process"}, where process is the name of the queue.
Basic Authentication
For security, the RESTful web service endpoint requires basic authentication. In the basic authentication header, you must pass the user ID and password that has access to the queue.
You can define web service authentication using the Work with Web Service Authentication (WWSA) menu option. The web service authenticator, JMSQueue, in Work with Web Service Authentication (WWSA), defines the user for basic web service authentication for the JMS RESTful web service when it reads from a queue in the queuing database.
-
If the message passes basic authentication, the message will be returned as a JSON string: {"status": "OK", "message": "data"}, where data is the message data.
-
If there are no more messages to read from the queue, a status of EOF (End Of File) will be returned: {"status": "EOF"}.
-
If there is a failure, the status will return the error condition; for example: {"status": "JMS-232: An invalid user/password was specified for the JMS connection"}
Authorization/Deposit Interface Setup
Purpose: This topic describes the setup required to communicate with a service bureau for authorization and deposit settlement.
In this topic:
For more information: See:
-
Stored Value Card Overview and Setup for more information on the setup required to process a stored value card.
System Control Value | Description |
---|---|
Defines whether you are using the interface to electronically transmit authorization and deposit information for your credit card orders to an authorization service. |
|
Determines whether a separate authorization and invoice will be created for each pick associated with an order, or if only one authorization and invoice will be created per shipment. Note: In Order Management System 21.0 or higher, or Order Administration, you cannot select the Consolidated Invoice system control value if it is not already selected. If the system control value is currently selected (set to Y) and you deselect it (change it to N or blank), you cannot then change it back to selected. The option to consolidate invoices will be removed at a later date. |
|
Defines whether the system performs online credit card authorization during order entry. See Performing Online Credit Card Authorizations for an overview and required setup. |
|
Determines the maximum number of times to attempt to authorize an order before flagging the order for cancellation. |
|
Specifies how to handle orders put on the same type of AVS hold a second time after you have released them. If you select this field, the system will not hold an order more than once for the same AVS response code if, for example, you need to reauthorize the order again because a backordered item is now available for shipment. |
|
Default Credit Card Authorization Number for Soft Declines (F93) |
Defines the authorization number the system defaults when a credit card authorization is declined but is under a specified dollar amount. |
Use Credit Card Vendor Response Entity Ship Via Dollar Limits (F94) |
Defines whether the system performs an edit against a credit card vendor response to determine if the dollar amount for the credit card authorization exceeds the dollar limit defined for the ship via on the order. |
Defines whether the credit card on the order is authorized for the entire dollar amount defined for the card or the shippable amount defined for the card when you perform online authorization during order entry. |
|
Defines the authorization number the system automatically applies to credit cards that require authorizations that are under one dollar. |
|
Defines whether the system processes online authorizations for $1.00 for the purpose of validating the card. During batch authorizations, the system authorizes the card for the shippable dollar amount and voids the online authorization for $1.00. |
Number Assignment | Description |
---|---|
Assigns the next available number to the credit card authorization. |
Use the Defining Authorization Services (WASV) menu option to:
-
define the service bureaus that you use, such as:
-
Authorization services, to authorize charges against a credit card or stored value card.
-
Authorization/Deposit services, to authorize card charges and receive deposit amounts.
-
Deposit services, to provide settlement for card payments.
-
-
identify the type of service the service bureau performs
-
define the parameters that identify your company to the service bureau
-
define the information necessary to connect, transmit, and receive data to and from the service, such as:
-
the method of communication: Integration Layer (via an integration layer process (IJCT)) or Payment Link (point-to-point)
-
if the communication type is Integration Layer, the integration process control job used to transmit data between Order Administration and the service bureau
-
response codes (vendor responses, AVS responses, and CID responses)
-
currency codes
-
merchant IDs for individual entities within your company
-
whether the order originated as an internet order
-
Some of the information required to establish a service bureau on your system is provided by the service bureau. For example, each service bureau will assign you a unique password.
The Communication type field for the service bureau indicates how you send transactions between Order Administration and the service bureau.
-
Integration Layer = Transactions are sent between Order Administration and the service bureau using an integration layer process (IJCT). Integration layer jobs provide the settings required to send transactions between Order Administration and the service bureau.
-
Payment Link = Transactions are processed between Order Administration and the service bureau using a point-to-point integration. Settings in Working with Customer Properties (PROP) provide the point-to-point service that is executed and the URL used to connect to the service bureau.
You define whether an order type is eligible for on-line authorizations and if the order type will display a window during order entry when a response is received from the service bureau, based on the On-line authorization field:
-
1 = the order type is eligible for on-line authorizations and the Select Authorization Response Option Window displays.
-
2 = the order type is eligible for on-line authorization and the Select Authorization Response Option Window does not display.
-
3 = the order type is not eligible for on-line authorization.
See Performing Online Credit Card Authorizations for more information on online authorizations.
Each credit card pay type eligible for authorization should have the service bureau set up as its authorization and deposit service. See Working with Pay Types (WPAY) for more information on setting up pay types.
If you wish to generate pick slips only for orders that contain pre-paid payment methods and/or credit cards that have received an authorization, you can create a pick slip generation template with the Preauthorized orders only field selected.
In order to respond to Order Administration jobs that may require user intervention to proceed, you must define notify property settings 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
-
Deposit
For more information:See Working with Required Responses (WREQ) for more information on the steps performed when a job requires user intervention.
Property Name | Description |
---|---|
RESPONSE_RETRIES |
The number of times Order Administration looks for a response to a job that requires user intervention before using the default response in order to proceed with the job. For example, if this setting is 5, Order Administration will look for a user response five times, waiting 60 seconds between each time. |
RESPONSE_EMAILS |
The list of email addresses that receive the Response Required email when a job requires user intervention. Each email address entered must be separated by a semi-colon (;). For example: email1@add.com;email2@add.com. |
Avalara AvaTax Setup
Overview: This document provides the steps needed to configure Order Administration to integrate with Avalara AvaTax so that AvaTax calculates tax for orders during order entry, pick slip preparation, and billing.
Compatibility: Order Management System version 17.0 and later, or Order Administration, is compatible with Avalara AvaTax REST API v2.
In this topic:
For more information: See Avalara AvaTax Interface for an overview on the integration.
Before You Start: Taxability Considerations
Mapping Data from Order Administration to AvaTax
Before you start the configuration steps described below, it is helpful to note the information in Order Administration that maps to corresponding values in AvaTax.
OROMS | AvaTax | Notes |
---|---|---|
company (WCMP) |
taxpayer |
Typically, the Order Administration company code matches the AvaTax taxpayer code; however, if you specify a default_company in the AvaTaxValues_999.properties file, it overrides the actual company code. You might define a company override if the AvaTax taxpayer is already set up in AvaTax and you need to configure Order Administration to map to the existing taxpayer. |
entity (WENT) |
taxpayer |
Used if the Pass Entity Code to Tax Interface (F69) system control value is selected, indicating you want to report taxes by entity. In AvaTax, set up the company taxpayer as the parent, and configure all required data at the entity-level taxpayer (child). Typically, the Order Administration entity code matches the entity-level (child company) AvaTax taxpayer code; however, if you specify an entity_999_child_company in the AvaTaxValues_999.properties file, it overrides the actual entity code. You might define an entity override if the AvaTax taxpayer is already set up in AvaTax and you need to configure Order Administration to map to the existing taxpayer. The entity on an order is determined by the division assigned to the source code on the order header. |
item class (WICL)/ long SKU department (WLSD)/ long SKU division (WLSV)/ long SKU class (WLSC) |
product class |
Assigned in Order Administration to the item/SKU (MITM). Used to map to the tax code in AvaTax in order to apply tax rules and exemptions. You can create a cross-reference between a tax product code and an item class, long SKU division, long SKU department, and long SKU class combination using the Working with Tax Product Code Cross References (WTPC) menu option. |
customer class (WCCL) |
customer class |
Assigned in Order Administration to the customer. Defined in the AvaTaxValues_999.properties file. Maps to the tax code in AvaTax to apply tax rules and exemptions. Note:
|
Configuration Steps
Setup within Order Administration
AvaTax Account ID and License
Use the AvaTax Account (M37) and AvaTax License (M38) system control values to specify a company-specific account ID and license ID used for communication with AvaTax.
If a company-specific account ID and license ID is not defined, the system uses the AVATAX_ACCOUNT and AVATAX_LICENSE properties in Working with Customer Properties (PROP) for communication with AvaTax.
The system encrypts the license ID entry.
System Control Values
-
Tax on Freight (B14): Must be selected.
-
AvaTax Account (M37): Enter the company-specific account ID used for communication with AvaTax. If you leave this blank, the system uses the account ID defined in the AVATAX_ACCOUNT property.
-
AvaTax License (M38): Enter the company-specific license ID used for communication with AvaTax. If you leave this blank, the system uses the license ID defined in the AVATAX_LICENSE property. The system encrypts this value.
-
Use Generic XML Tax Interface (J10): Must be set to AVATAX to have Order Administration communicate with AvaTax.
-
Use Standard Tax Calculation if Tax Interface Fails (J13): Select this value to have Order Administration use the standard tax calculation if it does not receive a response from AvaTax. If you select this value, you will need to set up tax rates at the SCF level (WSCF) and/or the postal code level (WZIP).
-
Pass Entity Code to Tax Interface (F69): Select this value to pass the entity associated with the source code on the order header to AvaTax,. If you select this value, then you can set up product class or customer class tax exemptions at the entity level in AvaTax. In AvaTax, set up the company taxpayer as the parent, and configure all required data at the entity-level taxpayer (child). Typically, the Order Administration entity code matches the entity-level (child company) AvaTax taxpayer code; however, if you specify an entity_999_child_company in the AvaTaxValues_999.properties file, it overrides the actual entity code. You might define an entity override if the AvaTax taxpayer is already set up in AvaTax and you need to configure Order Administration to map to the existing taxpayer.
-
Tax Included in Price (E70): Must be unselected if your company integrates with AvaTax.
-
Send Tax to Tax Interface as Quote not Invoice (L11): Indicates whether billing should send a quotation or an invoice request message to AvaTax when processing a shipment or a return.
Note:
When you change a system control value, stop and restart the background jobs (MBJC) and exit and re-enter Order Administration to have your changes take effect.
TAX_INT Integration Layer Job (IJCT)
For the TAX_INT job: Set the Communication type to Web Service and set the WSDL Document Name to CalculateTax90.wsdl. Note: The system requires a value in the WSDL Document Name field, but the wsdl is not used by the interface.
Because the TAX_INT job is always in INTERACT status, you do not stop or restart the job for your change to take effect.
Note:
The TAX_INT job does not require a process queue.
Customer Class for Exempt Customers
Use the Work with Customer Class (WCCL) to set up one or more classes of customers who are tax exempt, and then assign customers in Order Administration to the appropriate customer class. You can then set up the customer class(es) as tax exempt in AvaTax. Similarly, set up tax product code exemptions in AvaTax and define a tax product code cross reference in the Working with Tax Product Code Cross References (WTPC).
Note:
If the customer on an order is assigned to a customer class in Order Administration that does not correspond to a matching class in AvaTax, AvaTax calculates tax as if there is no customer class assignment.
Specific Customer Tax Exemptions
Use Work with Customers (WCST) to set up specific customers as tax exempt, including specifying their Tax identification number and the Expiration date, or setting this information up for the customer in specific states or provinces. Order Administration passes this information to AvaTax when a tax exempt customer places an order. It is not necessary to assign these customers to a particular customer class in order to flag them as tax exempt to AvaTax.
Tax Product Codes
Use Work with Items/SKUs (MITM) to assign items and SKUs to an item class, long SKU department, and long SKU class and define a cross reference to a tax product code in AvaTax.
Note:
It is not necessary to set up tax rates or other settings at the SCF level or the postal code level if you are using the generic tax integration with AvaTax.
Warehouse Address
Use Work with Warehouses (WWHS) to define an address for each warehouse used for items that require tax.
Set up Data within AvaTax
Companies and Entities
Use the Organization tab within Avalara AvaTax to set up company and entities as companies in AvaTax:
-
Set up an AvaTax company for each company to integrate with AvaTax. The AvaTax company code should match the Order Administration company code and should be zero-filled (for example, company 3 in Order Administration = company code 003 in AvaTax). Assign the company code to the appropriate jurisdictions, such as all U.S. states.
-
If you are sending entity information to AvaTax, add an AvaTax company for each entity for the related Order Administration company, where the Order Administration company is the parent company to the entity company. For example, if you are adding entity 100 for company 3, select company 003 in AvaTax as the parent for company 100. Again, assign the company to the appropriate jurisdictions, such as all U.S. states.
Note:
If the Order Administration company code does not match the company code in AvaTax, set up default values in the AvaTaxValues_999.properties file.
Tax Jurisdictions
For each AvaTax company, use the Nexus Jurisdictions option to define where AvaTax calculates tax.
Custom Tax Codes
For each AvaTax company, use the Custom Tax Codes option to define custom tax codes for a product, service, or charge.
Custom Tax Rules
For each AvaTax company, use the Custom Tax Rules option to define tax rules for a specified country, tax level (state, county, city, special tax jurisdiction), and region.
Items
For each AvaTax company, use the Items option to map your items to tax codes.
Note:
Use the Working with Tax Product Code Cross References (WTPC) menu option as your main list for mapping; any mapping you define in AvaTax will override the mapping in the Working with Tax Product Code Cross References (WTPC) menu option.
For more information: See the AvaTax documentation for more information on the set up required in AvaTax.
Configuration Files
Use a text editor to edit the following files.
Important:
Make a backup copy of each of the files discussed below before making any changes. Also, it is important that you do not make any changes in these files beyond those outlined in these instructions.
WebService Mapping File
Purpose: This file contains information required for the AvaTax web service. The AvaTax web service runs outside of Order Administration and is used to transmit information between AvaTax and Order Administration.
Property Name | Description |
---|---|
TAX_INT |
This setting indicates Order Administration communicates with AvaTax. The setting for AvaTax production is: com.mr.interfaces.avatax.AvaTaxWS The setting for AvaTax test is: com.mr.interfaces.avatax.AvaTaxWSTest |
AvaTax Values by Company Properties File
Purpose: Use this file to specify default values to send to AvaTax for each company that will use the tax integration.
File name and location: An AvaTaxValues.properties file is delivered with the application.
-
If you wish to define specific settings for a company, create a copy of the file and name it AvaTaxValues_999.xml, where 999 is the company code. The company number in the file name should be zero-filled; for example, the file name for company 1 is AvaTaxValues_001.xml.
-
If you do not define an AvaTaxValues.properties file for a specific company, the system uses the settings in the generic AvaTaxValues.properties file.
The files are typically located on the application server at /domain/conf/cwdirectcpproperties/AvaTax/, where domain is the WebLogic domain directory for Order Administration.
Configuring the file: Each entry in the file is labeled by an ID, for which you enter the corresponding Value.
Note:
After making any change to the file, you need to restart Order Administration to have your changes take effect. See Restarting Order Administration for more information.
Default Value ID | Value |
---|---|
default_company |
If the Order Administration company code differs from the actual company value in AvaTax, use this field to enter an override company code to pass to AvaTax. Leave this field blank to pass the actual Order Administration company code to AvaTax. This value is mapped to the companyCode in the AvaTax Request message if the entity_999_child_company setting is blank. |
entity_999_child_company (where 999 is the Order Administration entity code) |
If you are configured to use entity and the entity defined in Order Administration does not match the value defined in AvaTax, use this field to enter an override entity code to pass to AvaTax. Leave this field blank to pass the value in the default_company field to AvaTax. If the default_company field is blank, the system passes the actual Order Administration company code to AvaTax. Note: There can be multiple records for this property value. This value is mapped to the companyCode in the AvaTax Request message. |
default_warehouse_line1 |
Used to populate the ShipFrom address fields in AvaTax message. If the ship_from_warehouse is 000 in the CWTaxRequest message, the system uses this value to populate the line1 field in the ShipFrom section of the AvaTax message. |
default_warehouse_line2 |
Used to populate the ShipFrom address fields in AvaTax message. If the ship_from_warehouse is 000 in the CWTaxRequest message, the system uses this value to populate the line2 field in the ShipFrom section of the AvaTax message. |
default_warehouse_line3 |
Used to populate the ShipFrom address fields in AvaTax message. If the ship_from_warehouse is 000 in the CWTaxRequest message, the system uses this value to populate the line3 field in the ShipFrom section of the AvaTax message. |
default_warehouse_city |
Used to populate the ShipFrom address fields in AvaTax message. If the ship_from_warehouse is 000 in the CWTaxRequest message, the system uses this value to populate the city field in the ShipFrom section of the AvaTax message. |
default_warehouse_state |
Used to populate the ShipFrom address fields in AvaTax message. If the ship_from_warehouse is 000 in the CWTaxRequest message, the system uses this value to populate the region field in the ShipFrom section of the AvaTax message. |
default_warehouse_country |
Used to populate the ShipFrom address fields in AvaTax message. If the ship_from_warehouse is 000 in the CWTaxRequest message, the system uses this value to populate the country field in the ShipFrom section of the AvaTax message. |
default_warehouse_postalcode |
Used to populate the ShipFrom address fields in AvaTax message. If the ship_from_warehouse is 000 in the CWTaxRequest message, the system uses this value to populate the postalcode field in the ShipFrom section of the AvaTax message. |
call_center_line1 |
Used to populate the PointOfOrderAcceptance address fields in AvaTax message. The system uses this value to populate the address line 1 field in the PointOfOrderAcceptance section of the AvaTax message. |
call_center_line2 |
Used to populate the PointOfOrderAcceptance address fields in AvaTax message. The system uses this value to populate the address line 2 field in the PointOfOrderAcceptance section of the AvaTax message. |
call_center_line3 |
Used to populate the PointOfOrderAcceptance address fields in AvaTax message. The system uses this value to populate the address line 3 field in the PointOfOrderAcceptance section of the AvaTax message. |
call_center_city |
Used to populate the PointOfOrderAcceptance address fields in AvaTax message. The system uses this value to populate the city field in the PointOfOrderAcceptance section of the AvaTax message. |
call_center_state |
Used to populate the PointOfOrderAcceptance address fields in AvaTax message. The system uses this value to populate the state field in the PointOfOrderAcceptance section of the AvaTax message. |
call_center_country |
Used to populate the PointOfOrderAcceptance address fields in AvaTax message. The system uses this value to populate the country field in the PointOfOrderAcceptance section of the AvaTax message. |
call_center_postalcode |
Used to populate the PointOfOrderAcceptance address fields in AvaTax message. The system uses this value to populate the postalcode field in the PointOfOrderAcceptance section of the AvaTax message. |
order_freight_tax_code |
Used to populate the AvaTax tax code for Order Freight. The system uses this value when the line item type is OF (order freight). |
line_duty_tax_code |
Used to populate the AvaTax tax code for Line Duty. The system uses this value when the line item type is LD (line duty). |
line_handling_tax_code |
Used to populate the AvaTax tax code for Line Handling. The system uses this value when the line item type is LH (line handling). Note: If the S/H exclude tax? flag is selected for an additional charge code, then a line that uses this additional charge code for special handling is not subject to order line handling (LH) tax. See Establishing Additional Charge Codes (WADC) for background. |
additional_freight_tax_code |
Used to populate the AvaTax tax code for Additional Freight. The system uses this value when the line item type is AF (additional freight and shipper item charges). |
line_freight_tax_code |
Used to populate the AvaTax tax code for Line Freight. The system uses this value when the line item type is LF (line freight). |
customer_usage_type_CC (where CC is the Order Administration customer class code) |
Defines the customer usage type value for each customer class. Note: There can be multiple records for this property value. |
tax_date |
Used to determine the tax date during billing. Valid values are:
|
Browser Setup for Order Administration
Purpose: This topic discusses how to configure a browser for access to Order Administration.
Supported Browsers
Order Administration Classic View and Modern View support the current versions of the following browsers:
-
Mozilla Firefox
-
Microsoft Edge
-
Chrome (desktop)
-
Safari
Note:
Microsoft has deprecated Internet Explorer 11 in Windows 10 and recommends using Edge as the default browser.
Important:
Starting with 19.4, the URL to log into Order Management System, or Order Administration, no longer ends with OMS.html. If the URL was formerly https://SERVERNAME:PORT/jenasys/OMS.html,it is now https://SERVERNAME:PORT/jenasys.
Note:
The browser you use must support TLSv1.2.
Running Multiple Sessions of Order Administration
Overview: You can have more than one active Order Administration session open at a time, but you need to open each Order Administration session in a separate instance of the web browser.
-
Select File > New Session to start a new Order Administration session; or
-
Create a shortcut on your desktop. You can click this shortcut to open multiple Order Administration sessions.
Do not use any other methods to open another Order Administration session. For example, do not select File > New Window or File > New Tab from your current session, or the sessions will share a cache and the results will be unpredictable.
Miscellaneous screen format problems:
-
Occasionally a series of keystrokes can cause the screen format to be incorrect, or can cause your Order Administration session to end unexpectedly. If this occurs, exit the web browser and log back into Order Administration. If the problem continues to occur, check the Job Management screen and confirm that your previous session does not appear to be running. If the previous session is still running, this can cause your current session to retain the incorrect settings. End your previous session at the Job Management screen to correct the formatting issues.
-
Mozilla Firefox does not currently support highlighting fields that are currently focused. For example, when you first advance to the Default Value for Orders screen in Classic View order entry, the Error order batches field is automatically highlighted in other browsers, but is not highlighted in Firefox.
-
It may be necessary to set the zoom in Firefox to 100% to align all fields on the screen precisely.
Auto-fill options: Typically, you would turn off auto-fill options provided by the browser, such as defaulting personal information.
Caching
Cache: A store of information that will be required in the future, and can be retrieved quickly. Order Administration uses caching to store recently used information from the Order Administration database in a place where it can be accessed quickly, rather than accessing the database, in order to improve performance. Caching occurs across all Order Administration companies; if you use multiple application servers, you can specify which servers share the same cache. For example, you should have all of your test servers share the same cache and all of your production servers share a cache that is different from the cache assigned to your test servers.
Note:
Order Administration stores certain information in a cache so that it can be retrieved quickly. If a screen created using the Google Web Toolkit (GWT), such as Work with Accounting Periods (WACP) or Streamlined Order Inquiry (DORI), does not display correctly, or if you have changed an image and the updated image does not display, you must clear your cache to remove the information from your cache so that the screen or image can display correctly.
My Cache Screen
Purpose: Use the My Cache screen to determine which servers share the same cache and to determine which caches currently contain data.
How to display this screen: If you have Advanced Commands authority, select Advanced Commands from the Document Management screen (My Docs), Job Management screen (My Jobs) or Forms Management screen (My Forms) to advance to the Commands screen; then, select My Cache.
Field | Description |
---|---|
You are connected to Server |
The name of the Order Administration application server that you are currently logged into. |
Servers in Cluster A list of the servers that share the same cache as the server you are currently logged into. The system does not display a server that shares the same cache until a user logs into Order Administration using that server. The server information remains on the My Cache screen until the server is restarted or the connection times out due to lack of activity. |
Example: SERVER1 and SERVER2 share the same cache. User A logs into SERVER1. At this point, the Servers in Cluster section of the My Cache screen does not display any server information because no one has logged into SERVER2. User B logs into SERVER2. At this point, SERVER1 displays server information for SERVER2 in the Servers in Cluster section of the My Cache screen and SERVER2 displays server information for SERVER1 in the Servers in Cluster section of the My Cache screen. User B restarts SERVER2 and logs into SERVER1. At this point, the Servers in Cluster section of the My Cache screen no longer displays server information because no one has logged back into SERVER2. Note: If a user changes a record in a table that is associated with a cache, the system does not clear the records in the cache and does not remove the cache from this screen. |
Host Name |
The name of a server that shares the same cache as the server you are currently logged into. The server you are currently logged into is also displayed. |
Current Cache A list of the caches that currently contain records. |
When does a cache display on this screen? A cache displays on the My Cache screen if it contains a record. When a Order Administration process or a user changes a table that is associated with a cache, the system clears the records in the cache and removes the cache from this screen until a new record is added to the cache. How many records are in the cache? The Live objects represents the number of records that are in the cache. The system continues to update the Live objects until the cache is cleared or the maximum number of records for the cache is reached. How many times has a record been retrieved from the cache? The Hit count represents the number of times the system retrieved data from the cache instead of the database. The system continues to update the Hit count until you stop and restart Order Administration. |
Cache Name |
The name of a cache that currently contains records. |
Live Objects |
The number of records in the cache. For example, if two additional charge code records exist in the ADDL.CHARGE.CACHE, the Live Objects is 2. Note: This number continues to increment until the cache is cleared. |
Hit Count |
The number of times the system retrieved data from the cache instead of the database. For example, if records for additional charge code A and additional charge code B exist in the ADDL.CHARGE.CACHE, and the system retrieved additional charge code A from the cache 7 times and retrieved additional charge code B from the cache 2 times, the Hit count is 9. Note: This number continues to increment until you stop and restart Order Administration. If the system clears a cache, when the cache reappears on the screen, the Hit count will still be from the last time Order Administration was restarted. |
Which Order Administration Tables are Cached?
Purpose: The dbtablecachemapping.properties file indicates which Order Administration tables are cached.
DBTableCacheMapping Properties File
The dbtablecachemapping.properties file controls which tables are cached and the name of the cache associated with the table so that the system knows which cache to clear when a Order Administration process updates the information in a table.
This file provides the table name of each Order Administration table that is cached and the corresponding cache name.
Important:
Staff should not change the information in the dbtablecachemapping.properties file.
Location of file: This file is normally saved on the application server at the following location, where domain is the WebLogic domain directory for Order Administration:
/domain/conf/cwdirectcpproperties/ dbtablecachemapping.properties
Table Name | View Name | Cache Name |
---|---|---|
accitm |
Accompanying Item |
ACCOMPANYING_ITEM_CACHE |
acenty |
Entity |
ENTITY_CACHE |
ccpt00 |
CC Paytype Cross Ref |
PAY_TYPE_CACHE |
ccvnrs |
CC Vendor Response |
CC_VENDOR_RESPONSE_CACHE |
cscanr |
Cancel Reason |
CANCEL_REASON_CACHE |
cscscl |
Customer Class |
CUSTOMER_CLASS_CACHE |
csprfx |
Prefix Code |
PREFIX_CODE_CACHE |
csprod |
Profile Data |
PROFILE_CACHE |
csprof |
Profile |
PROFILE_CACHE |
dolofr |
Dollar Chart by Offer |
DOLLAR_CHART_BY_OFFER_CACHE |
flshrt |
Shipping Rate |
SHIPPING_RATE_CACHE |
frgofr |
Free Gift by Offer/Source |
FREE_GIFT_CACHE |
ftfefep |
Freight Exemption |
FRT_EXEMPT_CACHE |
ftftdp |
Freight Table Detail |
FREIGHT_TABLE_DETAIL_CACHE |
inabcv |
ABC/Velocity |
ITEM_MISC_CACHE |
infreq |
Frequency |
ITEM_MISC_CACHE |
inhzrd |
Hazard |
ITEM_MISC_CACHE |
inicls |
Item Class |
ITEM_CLASS_CACHE |
inictg |
Item Category |
ITEM_CLASS_CACHE |
inicty |
Item Coordinate Type |
ITEM_MISC_CACHE |
iniofr |
Item Offer |
ITEM_OFFER_CACHE |
iniskg |
Item SKU Group |
ITEM_DETAIL_CACHE |
inists |
Item Status |
ITEM_DETAIL_CACHE |
inisvo |
Item Ship Via Override |
ITEM_SHIP_VIA_OVERRIDE_CACHE |
inlcls |
Location Class |
ITEM_DETAIL_CACHE |
inldvp |
Long SKU Division |
ITEM_CLASS_CACHE |
inlobp |
Line of Business |
ITEM_MISC_CACHE |
inloc |
Location |
LOCATION_CACHE |
inlskc |
Long SKU Class |
ITEM_CLASS_CACHE |
inlskd |
Long SKU Department |
LONG_SKU_DEPARTMENT_CACHE |
insecf |
Secure Feature |
SECURED_FEATURE_CACHE |
insetd |
Set Detail |
SET_DETAIL_CACHE |
inskeo |
SKU Element 1 |
ITEM_DETAIL_CACHE |
insket |
SKU Element 3 |
ITEM_DETAIL_CACHE |
inskew |
SKU Element 2 |
ITEM_DETAIL_CACHE |
insldo |
Soldout Control |
SOLDOUT_CONTROL_CACHE |
insubs |
Item Subscription |
ITEM_SUBSCRIPTION_CACHE |
inprpp |
Prep Code |
ITEM_MISC_CACHE |
inuom |
Unit Of Measure |
ITEM_MISC_CACHE |
inwrhs |
Warehouse |
WAREHOUSE_CACHE |
inloba |
Line of Business Assignment |
LOB_ASSIGNMENT_CACHE |
msaocp |
Add On Code |
ITEM_MISC_CACHE |
msaucf |
Auth User Class Feature |
USER_CACHE |
msausf |
Auth User Feature |
USER_CACHE |
mscfrd |
Miscellaneous Fraud |
FRAUD_CACHE |
mscnte |
Country Extended |
STATE_COUNTRY_CACHE |
mscnty |
Country |
STATE_COUNTRY_CACHE |
mscoad |
Company Address |
COMPANY_ADDRESS_CACHE |
msctle |
Entity System Control Val |
ENTITY_SCV_CACHE |
msctlv |
System Control Value |
SCV_CACHE |
mscurr |
Currency |
CURRENCY_CACHE |
msdiv |
Division |
DIVISION_CACHE |
msilpr |
Integration Layer Process |
INTEGRATION_PROCESS_CACHE |
msoffr |
Offer |
OFFER_CACHE |
msscf |
SCF |
SCF_CACHE |
msscfe |
SCF Extended |
SCFEXTENDED_CACHE |
msscft |
SCF Tax Rate |
TAX_RATE_CACHE |
msseas |
Season |
ITEM_MISC_CACHE |
msshfd |
Special Format |
SPECIAL_FORMAT_CACHE |
msshpv |
Ship Via |
SHIP_VIA_CACHE |
mssta |
State |
STATE_COUNTRY_CACHE |
mssvwp |
Ship Via Weight Charge |
SHIP_VIA_WEIGHT_CHARGE_CACHE |
msudep |
User Defined Exit Point |
USER_CACHE |
oeadch |
Additional Charge |
ADDL_CHARGE_CACHE |
oeauct |
Auth Service Country |
STATE_COUNTRY_CACHE |
oeausv |
Authorization Service |
AUTH_SERVICE_CACHE |
oeauex |
Authorization Service Ext |
AUTH_SERVICE_CACHE |
oebogo |
Promotion BOGO |
PROMOTION_CACHE |
oeexrs |
Exchange Reason |
EXCHANGE_REASON_CACHE |
oeicrc |
Item Class Restr by Cust |
ITEM_CLASS_RESTRICTION_CACHE |
oeicrs |
Item Class Restr by SpclH |
ITEM_CLASS_RESTRICTION_CACHE |
oeicsp |
Item Restr by Country/State |
ITEM_RESTRICTION_CACHE |
oeirct |
Item Class Restr by City |
ITEM_CLASS_RESTRICTION_CACHE |
oeitxx |
Item Tax Exempt |
ITEM_TAX_EXEMPT_CACHE |
oepaye |
Pay Type Extended |
PAY_TYPE_EXTENDED_CACHE |
oepayt |
Pay Type |
PAY_TYPE_CACHE |
oepnck |
Order Pending Check |
FRAUD_CACHE |
oepore |
Price Override Reason Ext |
PRICE_OVERRIDE_REASON_ EXTENSION_CACHE |
oeprcu |
Promotion Customer |
PROMOTION_LIST_CACHE |
oeprex |
Promotion Item Exclusion |
PROMOTION_LIST_CACHE |
oepric |
Promotion Item Category |
PROMOTION_CACHE |
oeprom |
Promotion |
PROMOTION_CACHE |
oepror |
Price Override Reason |
PRICE_OVERRIDE_REASON_CACHE |
oeprsr |
Promotion Source |
PROMOTION_CACHE |
oertrs |
Return Reason |
RETURN_REASON_CACHE |
oesfrc |
Dollar Chart by Source |
DOLLAR_CHART_BY_SOURCE_CACHE |
oeshim |
Shipper/Item |
SHIPPER_ITEM_CACHE |
oetype |
Order Type |
ORDER_TYPE_CACHE |
oezpct |
Zip/City/State Tax Rate |
TAX_RATE_CACHE |
oezpsv |
Zip Ship Via |
ZIP_SHIP_VIA_CACHE |
oezrcp |
Zone Reservation |
ITEM_MISC_CACHE |
povend |
Vendor |
VENDOR_CACHE |
povia |
PO Ship Via |
ITEM_MISC_CACHE |
rtndis |
Return Disposition |
RETURN_DISPOSITON_CACHE |
scfvia |
SCF Ship Via |
SCF_VIA_CACHE |
scuser |
User |
USER_CACHE |
users |
N/A |
JENASYS_USER_CACHE |
Ehcache
Purpose: Order Administration uses Ehcache to manage caching. Ehcache is a widely used open source Java cache. For more information about Ehcache, visit the ehcache web site (http://ehcache.sourceforge.net/).
Note: Ehcache copyright Luck Consulting Pty Ltd.
Ehcache.xml File
The Ehcache.xml file is used to configure how caching works in Order Administration.
A separate Ehcache.xml file should exist on each Order Administration application server.
Location of file: This file is normally saved on the Order Administration application server at the following location, where domain is the WebLogic domain directory for Order Administration.
/domain/conf/ehcache.xml
The settings that staff may wish to review for troubleshooting purposes are described below.
Setting | Description |
---|---|
cacheManagerPeerProviderFactory |
Description below. |
peerDiscovery |
automatic = Indicates the system detects which Order Administration application servers share the same cache by checking the multicastGroupAddress and multicastGroupPort defined for each application server. |
multicastGroupAddress |
The multicast group address assigned to each server that shares a cache. Valid multicast group addresses must be within the range of 224.0.0.1 to 238.000.000.000. The default setting is 235.0.0.1. Note: This is not the IP address of the server; you can enter any number as the group address as long as it is between the range of 224.0.0.1 and 238.000.000.000. |
multicastGroupPort |
The port number assigned to each server that shares a cache. The port number can be any number, as long as each server is assigned the same multicast group port number. |
timeToLive |
Indicates the level at which multiple application servers can share the same cache. 0 = Share the same host. 1 = Share the same subnet. 32 = Share the same site. 64 = Share the same region. 128 = Share the same continent. 255 = Unrestricted. Note: Order Administration is configured to share the same cache at the subnet level (timeToLive is 1). If you need to configure a higher level at which multiple Order Administration application servers share the same cache, contact your Order Administration representative. |
Custom Link Setup
Purpose: This topic describes how to set up custom links to display on Order Administration screens. You can use custom links to access an internal or external web site.
Types of links: You can add a link on a specified screen or add a global link on all screens (with the exception of the menu screens, the Inventory Transaction History (DITH) and Update Customer Memberships (MMCM) menu options, and the administrative screens such as Job Management and Document Management).
If you set up a link to an individual screen and a global link for all screens, both links will display on the screen.
Important:
Screen-specific links and global links are NOT company specific.
Location of link: The link is the last entry on the left-hand side of the screen. If you define a screen-specific link and a global link, the screen-specific link is above the global link.

In this topic:
Adding a Link to a Specified Screen
Purpose: You can add a link to a specified screen by editing the screen’s XML file.
Note:
Changes you make to individual screens take effect immediately.
Instructions:
# | Step |
---|---|
1. |
Identify the program name for the screen by hovering the mouse over the screen title. For example, the program name for the standard Order Inquiry scan screen is OER0545. ![]() |
2. |
On the Order Administration application server, advance to the folder that contains the XML files used to render screens. Typically, the XML files are located on the application server at /domain/conf/OMSFiles/screens/, where domain is the WebLogic domain directory for Order Administration. |
3. |
Open the subfolder whose two-character prefix matches the first two positions of the screen’s program name. For example, if the screen’s program name is OER0545, open the subfolder oe. |
4. |
Locate the screen’s XML file and make a copy of the original XML file. For example, if the original XML file name is Oer0545N.xml, name the copy Oer0545N_YYMMDD.xml. |
5. |
Open the original XML file in a text editor, and insert the tags for the button you would like to add in the same area as the other button tags. To add a link, insert a new “button” tag in the following format: <button id="CF99" flag="99" value="Text to display on link"> attribute id="url" value="URL for link"/></button> |
|
Example: To add a link to the CNN home page, insert the following: <button id="CF99" flag="99" value="Launch CNN"> attribute id="url" value="http://www.cnn.com"/></button> |
6. |
Make a backup copy of your edited XML file. |
Adding a Global Link to All Screens
Purpose: The CWDIRECTCP_LINK_TEXT and CWDIRECTCP_LINK_URL settings in Working with Customer Properties (PROP) allow you to add a link to all screens in Order Administration (with the exception of the menu screens, the Inventory Transaction History (DITH) and Update Customer Memberships (MMCM) menu options, and the administrative screens such as Job Management and Document Management).
Example: If you enter Go To Google in the CWDIRECTCP_LINK_TEXT setting and http://www.google.com in the CWDIRECTCP_LINK_URL setting, then each screen will have a link that reads Go To Google. This link will open a new browser window and launch the URL of the Google website.
Property | Description |
---|---|
CWDIRECTCP_LINK_TEXT |
The text to display on the Order Administration screens for the link. Example: If you enter Go To CNN, then each screen will have a link that reads Go To CNN. If you are Using Multiple Application Servers If you are using multiple application servers, you need to update this setting on each server. |
CWDIRECTCP_LINK_URL |
The URL to open when a user clicks the link on a Order Administration screen. Example: If you enter http://www.cnn.com, the system opens a new browser window and advances to the URL of the CNN website. If you are Using Multiple Application Servers If you are using multiple application servers, you need to update this setting on each server. |
Email Generation Setup
Purpose: This topic describes the required and optional setup for generating email notifications through Order Administration.
Narvar integration: 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 using the settings described here.
In this topic:
For more information: See Clearing the Cache for HTML Email Templates (CEML).
Email Properties
Purpose: Use Working with Admin Properties (CPRP) to set defaults for email generation within Order Administration.
Setting | Description |
---|---|
CWEmailOutQueue Name |
The output queue to use for emails. Output queues are displayed when you select the My Jobs option in Order Administration, where you can use them for filtering purposes. The default output queue is EMAIL. |
CWEMAIL_ TEMPLATE_ PATH |
The location of the folder containing the template files used to generate HTML-based emails. An example location is /domain/conf/OMSFiles/EmailTemplates/, where domain is the installed location of Order Administration. See HTML Format Notification Samples and Contents for more information. |
oms.email.support.to |
The list of email addresses to receive the Support Notification email when a job is placed in MSG status because an error has occurred, or System Alert email for other errors such as inconsistent system control value setup across companies. Separate each email address with a semi-colon (;), such as: email1@add.com;email2@add.com. Note: You cannot enter an email distribution list in this field. However, you can use an email program, such as Microsoft Outlook®, to create rules to send emails to a distribution list. See Order Administration Support Notifications for more information on error email processing. |
Email Setup within Order Administration
Overview: The email setup within Order Administration includes:
Also, see System Control Values Related to Email Generation for information on related system control values.
Generate Notifications?
Order type: You can generate or suppress the automatic generation of emails based on order type. The Email notification setting for the order type controls whether to automatically generate any emails. If this flag is not selected, the system does not automatically generate any emails related to orders of this type.
If the Email notification flag for the order type is selected, you also have the option to control the automatic generation of specific notifications for that order type. The notification types you can control by order type are:
-
Backorder 1st Notice
-
Backorder 2nd Notice
-
Backorder Continue Notice
-
C/C Credit Acknowledgment
-
Order Cancel Confirmation
-
Order Confirmation
-
Order Line Cancel Confirmation
-
Return Confirmation
-
Soldout Confirmation
-
Shipment Confirmation
If the Email notification flag for the order type is selected, the system automatically generates the following notification types if the customer and order are otherwise eligible. These additional notification types are:
-
Credit Card Decline
-
Loyalty Activate Notice
-
Loyalty Deactivate Notice
-
Maintenance Failure
-
Membership Cancel Confirmation
-
Store Pickup Notification
-
Stored Value Card Notification
Note:
The Email notification flag does not apply to emails generated for quotes except for soldout notifications, because the system does not automatically generate any other emails for a quote until you accept the quote by changing it to a different order type.
For more information: See the Order Type Email Selection Screen for a discussion.
Email Text Templates
About text templates: Email notification text templates supply the boilerplate text to appear in the email. Each template provides a means to include text both above and below detail information included in the email notice, such as items on the order; however, some email types, such as the purchase order, do not include detail information, so you would not normally include the text below.
Setup options: You can set up email notification text at the company or entity level for most notifications. You can also set up email notification text at the order type and entity/order type level for the order, shipment, order cancellation, and order line cancellation notifications.
Hierarchy: The system uses the following hierarchy in selecting the boilerplate text to include in email notifications:
-
Entity/Order Type: To set up boilerplate text at the entity/order type level, advance to the Entity Email Override by Order Type Screen and select the Create or Change for the email notification whose text you would like to edit. This option is available only for the order, shipment, order cancellation, or order line cancellation notifications.
-
Entity: To set up boilerplate text at the entity level, advance to the Work with Entity Email Overrides Screen and select Change for the email notification whose text you would like to edit.
-
Order Type: To set up boilerplate text at the order type level, advance to the Order Type Email Template Screen and select Change for the email notification whose text you would like to edit. This option is available only for the order, shipment, order cancellation, or order line cancellation notifications.
-
Company: To set up boilerplate text at the company level, use Working with E-Mail Notification Templates (WEMT) and select Change for the email notification whose text you would like to edit.
Note:
The purchase order email and Oracle Retail Customer Engagement loyalty registration notification email do not have an order type, order type/entity or entity-level template, since these emails are not related to a specific order type or entity.
The system treats the text template entries at each level as a separate unit, and does not combine entries if you leave any text fields blank. For example, if you enter just the lines above the item fields in the entity template, but the company template also includes the lines below, the email includes just the entity-level text and does not include any text below the items.
“From” Email Alias
You can define the alias to display with the “from” address for emails, for example, My Email Alias <no-reply@omni.retail.oraclecloud.com>. The actual “from” address is set by Oracle and cannot be changed. The system uses the following hierarchy in selecting the “from” email alias:
-
Order Type/Entity: If a From email alias is specified at the Create Entity Order Type Template Screen (WENT) or Change Entity Order Type Template Screen (WENT), use this alias; otherwise,
-
Entity: If a From email alias is specified here for the email notification type, use this address; otherwise,
-
Company: If a From email alias is specified at the Change Company Screen (WCMP), use this address; otherwise,
-
Do not use an email alias
You can enter an email alias in upper and lower case.
Not included in the CWEmailOut message: The “from” email address is not included in the Outbound Email XML Message (CWEmailOut).
For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1)
HTML Email or Outbound Email XML Message?
XML only? Some of the screens you use to set up Email Text Templates also include the XML only? flag. This flag indicates whether to generate HTML-formatted emails or generic XML messages that you can route to a secondary email formatting utility.
Note:
HTML formatting and generic XML messages are not available for the loyalty activation/deactivation, cancellation failure, or purchase order emails. These emails are sent as plain text.
Hierarchy: The system determines whether to generate an HTML email or the Outbound Email XML Message (CWEmailOut) by checking the XML only? flag using the hierarchy described above under Email Text Templates.
For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1)
If the XML only? flag is selected for the template text selected through the hierarchy, the system generates the Outbound Email XML Message (CWEmailOut); otherwise, if this flag is not selected, the system generates the email in HTML format.
If no template text: If you have not set up template text at any of the levels listed above under Email Text Templates, the system checks the setting of the XML only? flag associated with the “from” email address for a notification type:
-
Entity/Order Type: If a From email address is specified at the Create Entity Order Type Template Screen for the email notification type in the related order type and entity, use the related setting of the XML only? flag; otherwise,
-
Entity: If a From email address is specified at the Change Email Override Screen for the email notification type in the related entity, use the related setting of the XML only? flag; otherwise,
-
The system uses the XML only? setting for the blank email template at the company level. Since you cannot set the XML only? flag for this template without entering text, the flag is normally unselected, so the system does not generate the Outbound Email XML Message (CWEmailOut). For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1)
HTML Email Template Setup
For notifications available in HTML format, you need to define an HTML template to control the appearance of the email as well as the template text described under Email Text Templates. Setup includes:
-
HTML program name: See System Control Values Related to Email Generation for a listing that includes each system control value you use to define an HTML template.
-
Location of email templates: The CWEMAIL_TEMPLATE_PATH property indicates where the HTML email templates are located. For example, if the Order Acknowledgement Program (G50) is set to OrdConf, and the CWEMAIL_TEMPLATE_PATH property is set to /domain/conf/OMSFiles/EmailTemplates/, then the system uses the OrdConf.html file in this folder to generate the order confirmation email. See Email Properties for more information.
-
Samples of HTML emails: See HTML Format Notification Samples and Contents.
-
Changing template content: If you change the content of an HTML email template and would like to begin using the new template without restarting Order Administration, you can use the Clearing the Cache for HTML Email Templates (CEML) option.
For more information: For more information on creating custom HTML email templates, contact your Order Administration representative.
System Control Values Related to Email Generation
Purpose: The system control values available to configure email notice generation are summarized below. See the description of each system control value for details.
Print programs for each email notification type:
-
Backorder Notification E-Mail Program (G95): The base program is BONOTF.
-
Contact Us Email Program (K54): The standard base program is CTUSNOTF.
-
Credit Card Credit Acknowledgement E-Mail Program (H08): The standard base program is CCCNOTF.
-
Credit Card Decline Email Program (K53): The standard base program is CDECLNOTF.
-
Loyalty Membership Activation Notification Email Program (I82): The base program is OER1359.
-
Loyalty Membership Deactivation Notification Program (I83): The base program is OER1361.
-
Order Acknowledgement Program (G50): The standard base program is OrdConf.
-
Order Maintenance Confirmation E-Mail Program (H12): The base program is OCFAILNOTF.
-
Return Confirmation E-Mail Program (H53): The standard base program is RtnConf.
-
Shipment Confirmation Program (G51): The standard base program is ShpConf.
-
Soldout Notification E-Mail Program (G96): The base program is SONOTF.
-
Stored Value Card Email Notification Program (I30): The standard base program is SVCNOTF.
-
Quote Confirmation Email Program (K74): The standard base program is QUOCONF.
-
Membership Cancellation Email Program (K77): The standard base program is MEMCANNOTF.
-
Order Cancellation Email Program (K78): The standard base program is ORDCANNOTF.
-
Order Line Cancellation Email Program (K79): The standard base program is ORDLCANOTF.
-
Store Pickup Confirmation Email Program (L48): The standard base program is SPCONF.
-
ORCE Loyalty Registration Notification Email Program (M10): The standard base program is LoyRegNotf.
Additional system control values related to email generation:
-
E-Mail Order Confirmations for All Orders (H51): Controls whether the system sends an email confirmation when any order is accepted, or only when a customer on the web storefront accepts or maintains an order.
-
E-Mail Shipment Confirmations for All Orders (H52): indicates whether all order shipments and return confirmations should generate email confirmations
-
Write Outbound Email to Email Repository (H99): Controls whether to keep a record of email notifications you send to customers in the email repository.
-
Email Purchase Order (K80): must be selected in order to send the purchase order by email.
-
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).
-
Suppress Order Confirmations for Orders in Error (K09): indicates whether the order API should generate order confirmations if an order it creates is in error, or to wait until you correct the order and accept and process the corrected order batch.
-
Return Disposition Code to Exclude in ORCE Sales Feed (M22) defines the return disposition code assigned to return (credit) invoices that Order Administration excludes from the Customer Engagement Sales Feed and suppresses a return confirmation when the Suppress refund field in the Order Payment Method table is Y.
-
Send Shipment Confirmation from Billing (L98): defines whether the system generates shipment and return confirmations during billing.
Note:
The Print Credit Card Credit Acknowledgments (C35) system control value does not control whether to email credit card credit acknowledgments. The system checks this value only if the customer would not receive an email notification.
Emails Troubleshooting
Problem | Possible Explanation or Solution |
---|---|
The system is not generating any emails. |
|
You have replaced an HTML email template with new content or appearance, but Order Administration is still generating emails using the old HTML template |
Use Clearing the Cache for HTML Email Templates (CEML) to update the HTML template in the cache. |
Frequently Asked Questions
-
Does the system track when a user logs in and out of Order Administration?
-
Can I have more than one active Order Administration session open at a time?
-
How do I display the Order Administration screens correctly on a laptop?
-
Why is the screen sometimes blank when I return to it after an interval, and how do I correct it?
Question | Answer |
---|---|
Which browsers can I use for Order Administration? |
You can use the most current version of the following browsers:
Results in other browsers may vary. |
Why is the currently selected field not highlighted? |
Mozilla Firefox does not support highlighted the currently selected field. |
How can I fix misalignment issues on screens? |
Field positions and outlines may be misaligned if the zoom in your browser is not set to 100%. |
Why do I receive an error message indicating “xxx is not a valid number” or “12/31/20 is not a valid date”? |
You might see these error messages after applying an update, such as 19.2, that enhances numeric fields in the database. To address:
|
What is the recommended application window size? |
In order to align screens correctly, the default size of the application window has been adjusted to 800 x 1200. Displaying the application in this window size is recommended for most screens except the Streamlined Order Inquiry (DORI) menu option. |
How do I re-enable a disabled user ID? |
The Status of a user ID is stored in the Users table and indicates whether a user ID is *ENABLED or *DISABLED. Log in to Order Administration using another user ID and advance to Working with User Records (WUSR) to re-enable a user. Note: After you re-enable a user ID, the user ID remains disabled until the Lockout Duration specified in the User Lockout options in WebLogic has passed. See Protecting User Accounts in the Configuring Security for a WebLogic Domain section of the Oracle WebLogic Server documentation for more information: |
Certain screens are not displaying correctly; when I advance to them, only the screen title displays and the rest of the screen is blank. How do I fix this? |
Possible explanations:
|
I updated an image, such as the Order Statistics on the Home page, and the updated image is not displaying. How do I get the updated image to display? |
OROMS stores certain information in a cache so that it can be retrieved quickly. If you have changed an image and the updated image does not display, you must clear your cache to remove the information from your cache so that the updated image can displays instead of the old image. |
Does the system track when a user logs in and out of Order Administration? |
The system does not track when a user logs in and out of Order Administration. |
Can I have more than one active Order Administration session open at a time? |
You can run more than one session at a time by using separate browser windows. |
Where does the date in the calendar window come from? |
The date shown in the calendar window is based on the local PC rather than the application server (system time). |
How do you select a date from the calendar pop-up window? |
When you open the window by clicking the calendar icon, as displayed below, ![]() The current date is in bold; however, you need to select the date by clicking it. The current date is not selected automatically. ![]() |
What are the sorting rules for alpha and numeric fields? |
Unlike some other environments, such as the iSeries, Order Administration displays alphabetical characters after numeric characters. For example, if you are working with SCF codes and enter a country of USA and an alphabetical SCF, the screen lists alphabetical SCFs starting with your entry, and then numeric SCFs after that. |
How do I display the Order Administration screens correctly on a laptop? |
|
How do I restart Order Administration? |
|
Why is the screen sometimes blank when I return to it after an interval, and how do I correct it? |
Certain screens “time out” after a period of inactivity. If you return to Order Administration and, after you click an option, the body of the screen goes blank, but the icons are still displayed in the upper right area, you can:
Note: Since only certain screens are subject to the time out, it sometimes occurs that you return to your Order Administration session after a period of inactivity and are able to work for awhile until you advance to one of the affected screens, and then you see a timeout message. In this situation, you need to close your browser window and start a new session. |
Are there keyboard shortcuts available? |
When you use Internet Explorer, many Order Administration screens provide keyboard shortcuts that you can use to select screen functions, such as pressing the F5 function key to refresh the content displayed on a screen. Common shortcuts: Some common shortcuts that are available in Order Administration, provided you use Internet Explorer:
Note: Not all shortcuts are supported on all screens. Additional shortcuts: Some screens support additional shortcuts. For example, the order header screen in order entry provides various shortcuts, such as pressing F14 to enter a one-time shipping address. Displaying the shortcut: Some screens support displaying a tooltip with the function key by positioning the cursor over the function name. ![]() Note: Shortcuts are not available on the system management screens (Document Management Screen, Job Management Screen, Forms Management Screen, or the Advanced Commands screen). |
Image Setup
Purpose: This topic describes how to set up images to display in Order Administration.
You can set up the following types of images:
-
A company logo to display at menu screens: see Setting Up Company Logos for Menu Screens and the Modern View Home Page.
-
An image to display in the right-hand area of the menu driver screen for users who do not have authority to view Open, Held Order Recap Amounts and Order Statistics; see Setting Up Menu Driver Images for Companies.
-
A company logo to print on forms: see Setting Up Company Logos for Forms.
-
An entity logo to print on selected forms: see Setting Up Entity Logos for Picks and Other Forms.
-
An item depiction to display in order entry and the Work with Item screen, as well as in Modern View: see Setting Up Item Images.
Setting Up Company Logos for Menu Screens and the Modern View Home Page
Purpose: You can set up a company logo for each company within Order Administration to display at menu screens and at the Modern View Home page. To set up company logos for menu screens and the Home page:
-
Image size: The company image for menus should be 270 pixels wide by 240 pixels high.
-
Image location: Specified in the IMAGE_URL_PREFIX property.
-
Image naming convention: The company logo image file name for menus should consist of:
-
the label MenuLogo and the zero-padded company number in order to display individual company-specific logos.
-
the jpg extension.
-
Example: The logo image file for company 6 should be named MenuLogo006.jpg.
If there is no image file for the user’s current company, Order Administration displays:
-
Classic View menu screens: The default logo delivered with the application, named MenuLogo.jpg.
-
Modern View Home page: The default logo delivered with the application, named MenuLogo.jpg.
If the company logo does not display correctly:
-
If you add, change, or delete the company image for menus, menu screens in Order Administration might not display the change immediately because the image might be cached on your local computer. To display the current company image for menus, exit Order Administration and clear the cache in your browser.
-
Image files should not exceed 10K in size.
Setting Up Menu Driver Images for Companies
Purpose: You can set up a menu driver image for each company within Order Administration to display in the right-hand area of menu screens for users who do not have authority to view the Open, Held Order Recap Amounts and Order Statistics. The Display Order Statistics and Recap (J03) secured feature controls the authority to view these components. To set up menu driver images:
-
Image size: The menu driver image should be 400 pixels wide by 420 pixels high.
-
Image location: Specified in the IMAGE_URL_PREFIX property.
-
Image naming convention: The menu driver image file name should consist of:
-
the label MenuDriverLogo and the zero-padded company number
-
the jpg extension
-
Example: The menu driver image file for company 6 should be named MenuDriverLogo006.jpg.
If there is no menu driver image file for the user’s current company, this area on the menu driver screen is blank. You cannot set up a default image that is not specific to a company.
For more information: See the Menu Driver Screen.
Setting Up Company Logos for Forms
Purpose: If you use a standard graphical print program for a form, you can point to an image of your company logo to include on the form. The image must be in jpg format, and:
-
Image size:
-
The company logo image for the purchase order should be 210 pixels wide by 70 pixels high.
-
All other company logo images for forms, including the pick slip image should be 239 pixels wide by 80 pixels high. The pick slip image is also used on several other forms, listed below.
-
-
Image location: Specified in the IMAGE_URL_PREFIX property.
-
Image naming convention: The company logo image file name should consist of the name of the print program for the form, the label CompanyLogo, and the company number, plus the jpg extension. Unlike some of the other images, the company logo for forms does not use zero-padding before the company number. For example, the logo image file for pick slips in company 6 should be named PICKCompanyLogo6.jpg.
-
Pick image used on other forms: You do not have to create a separate company logo image to print on the following forms, which use the logo image for the pick slip:
-
For each of these forms, the system uses the image file created for the pick slip (for example, PICKCompanyLogo1.jpg (company logo, where 1 is the company code) or the PICKEntityLogo177.jpg (entity logo, where 1 is the company code and 77 is the entity if the Print Entity Image (K35) system control value is selected. See Setting Up Entity Logos for Picks and Other Forms for details.
-
Image naming for unique forms: Even if you use a custom printing program, it is not necessary to include the complete print program in the image name. For example, if your unique pick printing program is PICKABC rather than PICK, you can still use a name of PICKCompanyLogo6.jpg.
Note:
Image files should not exceed 10K in size.
For more information: See Forms Management (My Forms) for additional background and setup requirements for forms, such as related system control values.
Restart the application: To be sure that changes to form images take effect, you can restart the application. See Restarting Order Administration for more information.
Setting Up Entity Logos for Picks and Other Forms
Purpose: Optionally, you can print the entity logo rather than the company logo on picks and other forms.
Select the Print Entity Image (K35) system control value if you want to always use the entity logo on pick slips and certain other forms. This setting requires that you set:
-
the outbound version of the PICK_OUT job in Working with Integration Layer Processes (IJCT) to 2.0 or higher, and
-
the Pick Printing Program (C37) system control value to PICKG, or to a unique graphical print program that supports printing the entity logo.
Note:
If you select the Print Entity Image (K35) system control value, then the pick slip will never print a company logo, so it is important to set up an entity logo for each entity in your company that might generate pick slips. If there is no logo for an entity, the logo area on the pick slip will be blank.
Generating pick slips: When you generate pick slips, the job includes pick slips of different entities within the same PDF file. See Performing Pick Slip Generation for background.
Setup requirements: The entity logo image file name should consist of the label PICKEntityLogo, the company number, the entity number, plus the jpg extension.
Note:
The company number and the entity number are not zero-filled. For example, the logo for company 6, entity 10 is PICKEntityLogo610.jpg.
Image size and location: The image should be the same dimensions as the company logo, and stored using the same URL prefix. See Setting Up Company Logos for Forms, above, for details.
Other printing programs:
-
Drop ship pick slip: Includes the entity logo if the Print Entity Image (K35) system control value is selected and the Drop Ship Pick Print Program (E92) system control value is set to PICKG.
-
Quote form: Includes the entity logo if the Print Entity Image (K35) system control value is selected and the Quote Printing Program (K73) system control value is set to QUOTEG.
-
Order receipt: Includes the entity logo if the Print Entity Image (K35) system control value is selected and the Order Receipt Print Program (L46) is set to ORDERRECG.
Note:
The gift acknowledgment does not use the entity logo regardless of the setting of the Print Entity Image (K35) system control value.
Setting Up Item Images
Purpose: Certain screens in order entry, order maintenance, and item maintenance display an item image if one is configured for the item.
To define: Use the Item Image/Info Link Screen to define the URLs where the image and product information for an item or SKU are stored on an external image hosting application.
Note:
The Item Image/Info Link screen is available only if the Use External Item Image (L55) system control value is selected; otherwise, an error message indicates: Image/Info Link not available - enabled by SCV L55.
Note:
You need to specify the complete URL for an item image; the IMAGE_URL_PREFIX property is not used for item images.
Import from OCDS: You can import primary item images from Omnichannel Cloud Data Service (OCDS) as well as other item-related data. This import is available regardless of the setting of the Use External Item Image (L55) system control value. See Importing Enterprise Foundation Data through Omnichannel Cloud Data Service (OCDS) for more information.
Displaying the Item Image
-
Work with Order Lines Screen (Adding Items to the Order): This screen displays the image for each item after you enter the item, and the image of the last item entered remains on this screen until you exit. The image that displays is:
-
The image defined at the SKU level.
-
If an image is not defined at the SKU level, the image defined at the item level displays.
-
If an image is not defined at the SKU or item level, no image displays.
If you click on the image, the system opens a web browser to the URL specified in the Information Link field for the item/SKU on the Item Image/Info Link screen.
-
-
Work with Items Screen (MITM): When you mouse over the item code, this screen displays:
-
The image defined at the item level.
-
If an image is not defined at the item level, the image defined for the first SKU in alphabetical order displays.
-
If an image is not defined for the item or SKU, no image displays.
-
-
Modern View: Various pages and windows in Modern View display the item or SKU image, if defined, including Contact Center Order Entry, the Order Summary page, Add Item window, and Frequently Purchased Items panel. See the Modern View online help for details.
Image size: The image is displayed at 150 x 150 pixels at the Work with Order Lines Screen (Adding Items to the Order), and at 120 x 120 pixels at the Work with Items Screen in item maintenance.
Logging into the Order Administration
In this topic:
Login Screen
Use the login screen to sign in to the Order Administration application.
Modern View? The user’s Modern View at Initial Login flag controls whether you log automatically into the Classic View of Order Administration or into Modern View.
IDCS (Oracle Identity Cloud Service) or OCI IAM (Oracle Cloud Infrastructure Identity and Access Management) requires you to provide a valid user ID and password set up in IDCS or OCI IAM and select Sign In. The user must also be configured within Order Administration.
Note:
You can also
return to Order Administration by selecting the Classic View icon
() from Modern View.
Successful Login
If the user ID and password are valid, IDCS or OCI IAM authenticates the user, and if the user is configured in Order Administration, the system logs the user in.
Determining the user’s language and date format: The system looks at the Locale and Date Format defined for the user in the Users table to determine the language and date format to display in certain areas of the application.
See:
-
Regional Settings for an overview.
-
Where are Date Formats Applied? for more information on which date format the system uses in different areas of the application.
-
Where are Number Format Applied? for more information on the decimal and thousand separators the system uses in different areas of the application.
Unsuccessful Login
If the login screen indicates that your user ID and password are invalid: This situation can occur if:
-
The Order Administration user ID does not exist. Log in to Order Administration using another user ID and advance to Working with User Records (WUSR) to verify the user ID exists.
-
An invalid password was entered.
-
The connection to the database is temporarily lost. Oracle staff can confirm the problem by checking the CWDirect log. To correct the situation, restart Order Administration.
-
The user ID exists in IDCS or OCI IAM, but:
-
The password for the user account in IDCS or OCI IAM is expired, or
-
The user profile in IDCS or OCI IAM is deactivated, or
-
The connection to IDCS or OCI IAM is temporarily lost.
-
-
The user ID is disabled in Order Administration. The Status of a user ID is stored in the Users table and indicates whether a user ID is *ENABLED or *DISABLED. Log in to Order Administration using another user ID and advance to Working with User Records (WUSR) to re-enable the user.
Note:
After you re-enable a user ID, the user ID remains disabled until the Lockout Duration specified in the User Lockout options in WebLogic has passed. See Protecting User Accounts in the Configuring Security for a WebLogic Domain section of the Oracle WebLogic Server documentation for more information:
https://docs.oracle.com/cd/E24329_01/web.1211/e24422/domain.htm#SECMG402
See the Administration guide for step-by-step instructions on how to set up users, password requirements, and for additional setup requirements. If you can’t sign in, select the Can’t sign in? link to request a password reset from IDCS or OCI IAM. You must provide your IDCS or OCI IAM user ID to submit a password reset request to IDCS or OCI IAM. IDCS or OCI IAM will send an email with a link to reset your password.
Logs
Purpose: A variety of logs are available to help troubleshoot Order Administration processing:
-
CWDirect Log: to review messages generated by the Order Administration application server at startup and during Order Administration processing, such as when the application receives an invalid character in an XML message, or when a submitted job encounters an error.
-
Order Administration Application Logs: to review activity such as:
-
processing by the Order Administration job scheduler
-
email notification processing
-
creation, change, or deletion of a record in Order Administration
also, you can use these logs to troubleshoot situations such as:
-
occasions when a stored value card or authorization job requires user intervention in order to proceed due to error or communication failure
-
communication problems between Order Administration and PayPal when using the PayPal Direct Connection Integration
Information related to application logs
-
Logs
CWDirect Log
Use this log to review messages generated during processing of the Order Administration application.
Location of file: This file is normally saved on the application server at /domain/log/CWDirect.log, where domain is the WebLogic domain directory for Order Administration.
To review the file: You can review the contents of this file using a text editor.
Special characters in the CWOrderIn message: If you pass a special character that is not properly encoded in the Header element of the Inbound Order XML message (CWOrderIn), the system does not process the message and logs the error in the CWDirect log.
Example:
If you pass Mary&Joe in the sold_to_fname tag, an error message similar to the following is in the CWDirect log:
2008-06-18 11:25:59,934 99184497 ERROR [STDERR] (43049:) (LoggerStream.java:152) [Fatal Error] :1:214: The reference to entity "Joe" must end with the ';' delimiter.
If you pass Mary& in the sold_to_fname tag, an error message similar to the following is in the CWDirect log:
2008-06-18 11:10:29,315 98253878 ERROR [STDERR] (43049:) (LoggerStream.java:152) [Fatal Error] :1:110: The entity name must immediately follow the '&' in the entity reference.
Errors for submitted jobs: To see if the system has written a log message for an error that occurred during a submitted job, search for the Job number displayed at the Job Management screen. For example, the following message indicates a problem with submitted job 3133:
2014-11-20 14:14:12,852 ERROR [JENASYS] (197213%Thu Nov 20 14:14:11 EST 2014) -MonitorOutputQueues- processServiceRequest: could find/load properties filr for the queue = [QPRINT]
Changes to queues for jobs: When a user has moved a job to a different queue at the Job Management (My Jobs) screen, the system writes a message such as the following:
Queue Change: User USERNAME has moved job number 123456 / name IJCTSTART from queue QBATCH to queue QSYSNOMAX
Order Administration Application Logs
Purpose: Use the following logs to review the processing that occurred on the Order Administration application server.
Logging Level
The LOG_LEVEL in Working with Admin Properties (CPRP) defines the level of detail to include in the log.
-
ALL = Include all levels of information in the log, including debug statements, informational statements, warnings, errors, and fatal statements. This is the most detailed level of logging.
-
DEBUG = Include debug, or detailed informational event statements in the log, as well as informational, warning, error, and fatal statements.
-
INFO = Include informational statements in the log, as well as warning, error, and fatal statements. Do not include debug statements in the log.
-
WARN = Include warning statements in the log, as well as error and fatal statements. Do not include debug or informational statements in the log.
-
ERROR = Include error, or serious issue, statements and fatal statements in the log. Do not include debug, informational, or warning statements in the log.
-
FATAL = Include fatal statements on actions that cause the application to abort in the log. Do not include debug, informational, warning, or error statements in the log. This is the highest level of logging.
-
OFF = Do not create a log.
Logging Level Illustration:

Archived Logs
The MAXBACKUP_DAYS setting in Working with Admin Properties (CPRP) defines the number of days the system stores a backup copy of the log before deleting. For example, if the MAXBACKUP_DAYS setting is set to 30d, the system stores a backup copy of the log for 30 days before deleting it.
Note:
The entry in this field must include the letter d, as in 30d.
When is a log archived? Each day at midnight, the system archives the current log, adding a zip file extension and date to the log name. For example, if the current date is 02/05/2008, the system archives the APP.log, renaming the file from APP.log to APP.2008-02-05.log.zip.
Note:
The system does not create a new log until activity occurs to write to the log. For example, the system does not create a new APP.log until application activity occurs. The LOG_LEVEL determines when the system writes a message to the APP.log.
Sensitive Data in Application Logs
Order Administration masks sensitive data, such as credit card number, CID number, account number, and all personal data (person or company name, mailing address, email address, phone number, and so on) in the application logs. The system uses the XML Removed by Logger table to determine which message tags are masked in the log files. This table lists all message tags that contain sensitive data. If a tag in a message matches a message tag in this table, Order Administration masks the value in the tag; otherwise, the actual value displays.Note:
Masking only applies to message tags, or attributes, in the message. You cannot apply masking to a message element.
Logging Properties
Use Working with Admin Properties (CPRP) to define the type of information the system includes in the Order Administration application logs.
Setting | Description |
---|---|
MQ Log |
Use the MQ.log to track XML and transactional messages generated or received by Order Administration that are not tracked in the Application Log, Order Log, or Trace Log. You can use this file to confirm that you are receiving or generating messages correctly, to isolate communication problems, or to recover information. |
Job Log |
This log is not currently implemented. |
Application Log |
Use the APP.log to track the activity performed in the Order Administration application, such as:
|
APP_ MAXBACKUP_DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
Response Log |
Use the RESP.log to review when a job required user intervention in order to proceed. A job may require user intervention if:
The types of job that require user intervention:
|
RESP_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
RESP_ MAXBACKUP_ DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
Trace Log |
Use the TRACE.log to review internal messages about Order Administration application processing. Typically, you review this log only if the contents of the Application Log did not help you. |
TRACE_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
TRACE_ MAXBACKUP_ DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
Order Log |
Use the ORDER.log to review the messages between an external system and Order Administration through the Generic Order Interface (Order API). You can use this log to confirm that communication between the external system and Order Administration is working correctly, to isolate communication problems, or to recover information. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
ORDER_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
ORDER_MAX BACKUP_ DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
Order Orchestration Log |
Use the OOCS.log to review the messages between Order Administration and Order Orchestration when you use the Order Orchestration Integration. You can use this log, in addition to Order Orchestration’s logs, to review data passed between the two systems. |
OROB_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
OROB_MAX BACKUP_DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
PayPal Log |
Use the PAYPAL.log to review the messages between Order Administration and PayPal when you use the PayPal Direct Connection Integration. You can use this log to confirm that communication between Order Administration and PayPal is working correctly, to isolate communication problems, or to recover information. Any errors that occur during processing are also in this log. |
PAYPAL_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
PAYPAL_MAX BACKUP_DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
Alert Log |
Use the ALERT.log to review the alerts generated by the Job Monitor Status (WJMO) menu option; see Monitoring Jobs. Note: The system updates this log only if the ALLOW_JOB_MONITOR and TRACK_ALERTS_IN_LOG settings in the Monitor Properties file are set to Y. These settings should only be set to Y for the application server that allows job scheduling; see How to Schedule a Job. See the Alert Log for more information. |
ALERT_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
ALERT_MAX BACKUP_ DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
IntegrationOrder (ChannelAdvisor) Log |
Use the IntegrationOrder.log to review activity related to integration with ChannelAdvisor. Note: The system updates this log only if the you use the ChannelAdvisor integration. See ChannelAdvisor Integration Overview for background. See the IntegrationOrder (ChannelAdvisor) Log for more information. |
INTEGRATION ORDER_LOG_ LEVEL |
Defines the level of detail to include in the log. See Logging Level. |
INTEGRATION ORDER_MAX BACKUP_DAYS |
The number of days to store a backup copy of a log before deleting it. See Archived Logs. Example: To retain a month’s worth of logs, set this field to 30d. The system deletes any log file older than 30 days. Note: The entry in this field must include the letter d, as in 30d. |
ORCE (Oracle Retail Customer Engagement) Log |
Use the ORCE.log to review activity related to the loyalty integration with Oracle Retail Customer Engagement. Note: The system updates this log only if the you use the Customer Engagement Loyalty integration. See Customer Engagement Loyalty Integration for background. See the ORCE (Oracle Retail Customer Engagement) Log for more information. |
Narvar Log |
Use this log to review activity related to the generation of shipment notification emails to customers through the Narvar Integration. |
MQ Log
Use this log to track XML and transactional messages generated or received by Order Administration, with the exception of those captured in theOrder Log, and the tax messages captured in the Trace Log. You can use this file to confirm that you are receiving or generating messages correctly, to isolate communication problems, or to recover information.
The MQ Log settings in the Logging Properties define the level of detail to include in the log and the number of days to store a backup copy of the log before deleting it.
To review the file: You can use a text editor to review the log.
Data security: For data security, Order Administration masks credit card information in this log.
Successful message: A message similar to the following indicates if the transmission was successful:
08:33:54,228 INFO MQ - Out Message:<Message source="OMS" target="external" type="CWPickOut" date_created="2011-08-08" time_created="08:33:53"> <PickHeader transaction_type="A" company="7" pick_nbr="1234" pick_status="M" nbr_labels="2" billing_batch_nbr="1011" date_printed="2011-08-05" time_printed="13:50:46" cart_batch_nbr="18" pick_zone1="A" nbr_lines="1" gen_type="R" merch_amt="10.35" tax_amt="0.52" amt_paid="10.87" total_order_amt="10.87" first_pick="Y" master_carton_nbr="2464" master_carton_pick="N" master_label_order="N" order_nbr="3715" order_shipto_nbr="1" ...
Errors to look for:
A message similar to the following indicates if the transmission failed:
14:42:48,724 ERROR MQ - Cwmqget -Queue Manager: QM_process Queue:ORDERDATAQ Error Message: MQ Object not found
A message similar to the following indicates the queue manager is down and needs to be restarted:
09:08:19,939 ERROR MQ - Cwmqput -Queue Manager: QM_PD3 Queue:PD3.CWDIRECTCPDEV.RETURN_OUT Error Message:null
or
12:51:07,721 INFO MQ - Cwmqput -Queue Manager:QM_PD3 Queue:PD3.CWDIRECTCPDEV.RETURN_OUT Message:
Application Log
Use this log to track the activity performed in the Order Administration application, such as:
-
the processing that occurs in the Order Administration job scheduler
-
any errors that occur during email notification processing
-
when a user creates, changes, or deletes a record in Order Administration
-
any errors that occur during the Customer Engagement Batch Customer and Sales Integration the CWEmailOut message
The Application Log settings in the Logging Properties defines the level of detail to include in the log and the number of days the system stores a backup copy of the log before deleting it.
To review the file: You can use a text editor to review the log.
Email error: The following error indicates an attempt to send an email failed. In this example, the mail server rejected the email request from port 25. This error usually occurs due to virus-checker rejecting the remote mail requests.
13:06:28,586 ERROR APP - Error in CWSendMail.sendMessage(). Could not send email. Here is the exception: javax.mail.SendFailedException: Sending failed; nested exception is: class javax.mail.MessagingException: Could not connect to SMTP host: CWIEX1, port: 12; nested exception is: java.net.SocketException: Software caused connection abort: connect
Response Log
Use this log to review when a job required user intervention in order to proceed. A job may require user intervention if:
-
an error occurred during processing
-
the job is used to send transactions to another system and communication failures occur before the transmission completes
The types of job that require user intervention:
-
stored value card (activation, balance inquiry, or authorization reversal)
-
authorization (batch only, for all card types)
-
deposit
The Response Log settings in the Logging Properties defines the level of detail included in the log and the number of days the system stores a backup copy of the log before deleting it.
To review the file: You can use a text editor to review the log.
Sample messages:
Message | Written When |
---|---|
Deposits - Response required for job. E-Mail sent to:email1@example.com; email2@example.com |
Order Administration generates a Response Required email, indicating a job requires user intervention. In this example, Deposits is the job name and email@example.com is the email address to receive the Response Required email. |
Deposits - Received R response from JSMITH |
A user responded to a response required message at the Reply To Message screen. In this example, Deposits is the job name and JSMITH is the user that responded to the job. |
Deposits - No response after 5 attempts, will retry |
Order Administration 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 Administration 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 Administration 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 Response screen. Order Administration uses the default response for the job. In this example, Deposits is the job name. |
Trace Log
Use this log to review internal messages about Order Administration application processing. Typically, you review this log only if the contents of the Application Log did not help you.
The Trace Log settings in the Logging Properties define the level of detail to include in the log and the number of days to store a backup copy of the log before deleting it.
To review the file: You can use a text editor to review the log.
To review the file: You can use a text editor to review the log.
Order Log
Use this log to review the CWOrderIn and CWORDEROUT messages between an external system and Order Administration as part of the Generic Order Interface (Order API). You can use this log to confirm that communication between the external system and Order Administration is working correctly, to isolate communication problems, or to recover information.
The Order Log settings in the Logging Properties define the level of detail to include in the log and the number of days to store a backup copy of the log before deleting it.
To review the file: You can use a text editor to review the log.
Successful message: A message similar to the following indicates if an order message was successful:
12:32:42,483 INFO ORDER - In Message: <Message source="IDC" target="RDC" type="CWORDERIN" resp_qmgr="CWIAS400" resp_q="CWDIRECT.PROMOTION.OUT.10.Q"> <Header company_code="009" order_number="012345-1" payment_only="N" source_code="JMNSRC" response_type="E" order_channel="I" customer_number="123456" pay_incl="Y" order_type="W"> <Payments> <Payment pay_seq_number="1" payment_type="04" cc_type="04" cc_number="************1443" cc_exp_month="12" cc_exp_year="2012" auth_number="manual" auth_date="02112011" /></Payments> <ShipTos><ShipTo shipping_method="98" ship_to_type="2"> <Items><Item quantity="1" item_id="API100"></Item></Items></ShipTo></ShipTos><Coupons> <Coupon /></Coupons></Header></Message>
Errors to look for:
A message similar to the following indicates that the CWOrderIn message passed was not formatted correctly or contained invalid data:
17:21:46,031 INFO ORDER - Out Message:<Message>Invalid XML Message: <Message source="String" target="String" type="CWORDERIN" > <Header company_code="6" rdc_order_number="9967" payment_only="Y" nbr_ship_tos="1" pay_incl="Y" source_code="SOURCE" response_type="E" order_channel="I" sold_to_fname="John" sold_to_lname="Smith" sold_to_address1="10 Example Street" sold_to_city="NATICK" sold_to_state="MA" sold_to_zip="01760" sold_to_country="USA" order_type="I" sold_to_email="eleanor.johnson@example.com" > <Payments> <Payment payment_type="5" cc_number="***5556" cc_exp_month="12" cc_exp_year="12" /> </Payments> </Header> </Message> com.mr.serenade.exception.BOException: OrderInMessageBO.checkDuplicateWebOrder - null </Message>
PayPal Log
Use this log to review the messages generated between Order Administration and PayPal when you are using the PayPal Direct Connection Integration. You can use this log to confirm that communication between Order Administration and PayPal is working correctly, to isolate communication problems, or to recover information. Also, any errors that occur during processing are written in this log.
The PayPal Log settings in the Logging Properties define the level of detail to include in the log, and the number of days to store a backup copy of the log before deleting it.
To review the file: You can use a text editor to review the log.
Data security: For data security, Order Administration masks credit card information in this log.
Successful message: A message similar to the following indicates if the PayPal deposit transmission was successful:
11:56:55,831 INFO PAYPAL - [Settlement] Transmitted deposit(*PURCH) Processed : AMT=20.94&INVNUM=111-1234&NOTE=PAYPAL+1234&AUTHORIZATIONID=12345678901234567890&COMPLETETYPE=NotComplete&METHOD=DoCapture
Failed message: A failure in the deposit process or errors during processing generate ERROR level messages, such as the following:
11:56:55,831 ERROR PAYPAL - [Settlement] Transmitted deposit(*PURCH) Failure : AMT=20.94&INVNUM=111-1234&NOTE=PAYPAL+1234&AUTHORIZATIONID=12345678901234567890&COMPLETETYPE=NotComplete&METHOD=DoCapture
11:57:06,581 ERROR PAYPAL - [Settlement] Timestamp : 2009-05-08T15:52:55Z
11:57:08,737 ERROR PAYPAL - [Settlement] CorrelationId : 12345abcde
11:57:10,284 ERROR PAYPAL - [Settlement] Error code : 10002
11:57:11,972 ERROR PAYPAL - [Settlement] Short message : Security error
11:57:15,018 ERROR PAYPAL - [Settlement] Long message : Security header is not valid
11:57:17,300 ERROR PAYPAL - [Settlement] Severity code : Error
Setup errors: Errors reading the authorization service or authorization service extended generate ERROR level messages, such as the following:
11:31:04,471 ERROR PAYPAL - [Settlement] Defaults set. Do not process in PayPal 'live' environment
11:31:31,841 ERROR PAYPAL - [Settlement] Exception(s) encountered during Initialization. No Deposit processing performed.
For more information: See , LogsPayPal Direct Connection Integration for an overview and the required setup for processing deposit transactions between Order Administration and PayPal using a direct connection.
Alert Log
Use this log to review the alerts generated by the Job Monitor Status (WJMO) menu option. This log indicates:
-
the name of the job monitor associated with the alert
-
the name of the job monitor rule associated with the alert
-
the action taken for the job monitor rule, such as generating an email or running a periodic process
Note:
The system updates this log only if the ALLOW_JOB_MONITOR and TRACK_ALERTS_IN_LOG settings in Working with Admin Properties (CPRP) are set to Y. These settings should only be set to Y for the application server that allows job scheduling; see How to Schedule a Job.
IntegrationOrder (ChannelAdvisor) Log
Use this log to review activity related to integration with ChannelAdvisor. See ChannelAdvisor Integration Overview for background.
ORCE (Oracle Retail Customer Engagement) Log
Use this log to review activity related to the loyalty integration and stored value card integration with Oracle Retail Customer Engagement. The system logs the transactions passed between Order Administration and Oracle Retail Customer Engagement if the Logging Level is DEBUG.
For more information: See:
OOCS (Oracle Retail Order Orchestration) Log
Use this log, in addition to Order Orchestration’s logs, to review messages passed between Order Administration and Order Orchestration as part of the Order Orchestration Integration.
Monitoring Jobs
The system collects the monitoring information in the Job Monitor Status table. You can review the monitoring information on the Work with Job Monitor Screen (WJMO)
Overview: Job Monitoring provides the ability to monitor jobs to ensure that they are running correctly.
The Job Monitor:
Collects monitoring information, such as:
-
Last heartbeat date/time: the last date and time when the system verified the job was running.
-
ast transaction date/time: the last date and time when a transaction was processed by the job.
Note:
If you use multiple application servers, the system collects monitoring information in the Job Monitor Status table across all application servers.Performs an action when job monitor rules you set up for a job are met, such as:
-
receiving an email so that you can react to the condition.
-
running a periodic function. For example, you can define a job monitor rule that if the Controlling Async goes down, to run the periodic function that starts the Controlling Async. If you define a periodic function, you can also have the system notify you by email if the condition for the job monitor rule still exists after running the periodic function.
The monitor rules defined for a job can be based on the last update date and time, the last transaction date and time, or query results.
You can define monitor rules for a job on the Work with Job Monitor Rules Screen. When you schedule a job monitor rule, the rule becomes a scheduled job that you can review on the Scheduled Jobs screen. Whenever you restart Order Administration, the system determines if any job monitor rules should be running, and if so, starts them.
Additional Job Monitoring
-
Running a Periodic Process on Server Startup provides the ability when you restart Order Administration (see Restarting Order Administration) for the system to look at the settings in the Monitor Property Settings to determine the periodic process and its assigned periodic functions to run on server startup. See Running a Periodic Process on Server Startup for more information about this process and the setup requirements.
In this topic:
Job Monitor Setup
Before you can use the Job Monitor, you must complete the required setup.
Monitor Properties
The Monitor Properties in Working with Admin Properties (CPRP) contain the settings required to enable the Job Monitor.
Property Name | Description |
---|---|
ALLOW_JOB_ MONITOR |
Indicates whether you wish to run the job monitor. Valid values: Y = Run the job monitor. N (default) or blank = Do not run the job monitor. In this situation, the only option on the Work with Job Monitor Rules Screen is to display a rule’s settings. Note: Set this value to Y for all application servers. |
JOB_MONITOR_QUERY_ DIRECTORY |
The directory on the application server where you store queries used by the job monitor. An example directory is /domain/conf/OMSFiles/JobMonitorQueries/, where domain is the WebLogic domain directory for Order Administration. |
TRACK_ALERTS_IN_LOG |
Indicates whether you log all alerts generated by the job monitor. Valid values: Y = Log all alerts generated by the job monitor in the Alert Log. N or blank = Do not log alerts generated by the job monitor. |
Job Monitor Rules
Use the Work with Job Monitor Rules Screen to define monitor rules for a job. For each rule, you can define:
-
how often the system evaluates the rule to determine if its condition is met.
-
whether the system uses the last update date and time, the last transaction date and time, or query results to determine whether to act on the rule.
-
the type of action to perform if the rule’s conditions are met, such as:
-
receiving an email so that you can react to the condition.
-
running a periodic function. For example, you can define a job monitor rule that if the Controlling Async goes down, to run the periodic function that starts the Controlling Async. If you define a periodic function, you can also have the system notify you by email if the condition for the job monitor rule still exists after running the periodic function.
-
Job Monitor Queries
Create any queries for which you wish to receive an alert if the query results come back true. Once you create the query:
-
Store these queries in the directory defined for the JOB_MONITOR_QUERY_ DIRECTORY property.
-
Create a job monitor rule for the Query job monitor on the Work with Job Monitor Rules Screen. For this job monitor rule:
-
Select to Alert On Query and enter the name of the query that you created.
-
Define a schedule when the system determines if the query results come back true.
-
Define the action to take if the query results come back true.
Job Monitor Query Examples
Job Monitor Rule | Query Example |
---|---|
receive an alert when the number of records in the billing data queue is equal to or greater than 100 |
select 'Y' from dual where (Select COUNT(*) from Billing_Header_Data_Queue)>=100 |
receive an alert if the number of running jobs for the INVTRAN_IN integration layer job is not equal to 3 |
select 'Y' from dual where (Select COUNT(*) from JenasysJob where jobName in (select ilq_job_name from Integration_Process_Queue where ILP_Process='INVTRAN_IN' and ILQ_Enabled='Y') and status='RUN')=3 |
receive an alert if no orders were created for the current date |
select 'Y' from dual where (select COUNT(*) from Order_Header where CMP_Company=555 and OHD_Order_date=FNSYNONDATE)>0 |
Which Jobs are Monitored?
The table below lists the jobs you can monitor on the Work with Job Monitor Screen (WJMO). For each job, this table lists:
-
The name of the job.
-
The type of information collected for each job.
-
Heartbeat Only = the job is associated with a heartbeat that the system uses to verify that the job is still active. Currently, there are no jobs associated with a heartbeat only.
-
Transactions Only = the job processes transactions.
-
Heartbeat and Transactions = the job is associated with a heartbeat and processes transactions.
-
Query = the job runs queries not related to the other jobs listed on the Work with Job Monitor screen.
-
When the system collects the type of information.
-
The purpose of the job.
-
The menu option where you can work with the job.
Note:
-
If you have the same job running more than once; for example, you have multiple Billing Async jobs running at the same time, the job displays on the Work with Job Monitor Screen (WJMO) only once.
-
If you have the same integration layer job running more than once; for example, you have multiple stored value card activation jobs, each job displays on the Work with Job Monitor Screen (WJMO).
Job | Information Collected | Updated When |
---|---|---|
MBJC |
Use Background Job Control (MBJC) to review and work with these jobs. |
|
BILL_ASYNC background job Processes updates related to shipments and returns.See Working with the BILL_ASYNC Job. |
Heartbeat and Transaction date/time |
Heartbeat date/time The job reads the billing async data queue every 30 seconds. Transaction date/time The system reads a record from the billing async data queue. Note: The system also updates the heartbeat date/time and transaction date/time when you end the asyncs. |
CNTL_ASYNC background job Starts and ends each of the background ASYNC jobs. When you start the CNTL_ASYNC job, all of the background ASYNC jobs start; when you end the CNTL_ASYNC job, all of the background ASYNC jobs end. You cannot start or end an individual background ASYNC job.See Working with the CNTL_ASYNC Job. |
Heartbeat and Transaction date/time |
Heartbeat date/time The job reads the controlling async data queue every 30 seconds. Transaction date/time The system reads a record from the controlling async data queue. Note: The system also updates the heartbeat date/time and transaction date/time when you end the asyncs. |
EBO_ASYNC background job Updates the system tables with reservation and backorder information whenever the inventory level for a backordered item increases. Inventory levels for an item increase when you process inventory transactions, receive purchase orders, or transfer merchandise from suspense.See Working with the EBO_ASYNC Job. |
Heartbeat and Transaction date/time |
Heartbeat date/time The job reads the EBO async data queue every 30 seconds. Transaction date/time The system reads a record from the EBO async data queue. Note: The system also updates the heartbeat date/time and transaction date/time when you end the asyncs. |
ORDR_ASYNC background job Updates the system tables with order and demand information as orders are entered and maintained. See Working with the ORDR_ASYNC Job. |
Heartbeat and Transaction date/time |
Heartbeat date/time The job reads the order async data queue every 30 seconds. Transaction date/time The system reads a record from the order async data queue. Note: The system also updates the heartbeat date/time and transaction date/time when you end the asyncs. |
OTHR_ASYNC background job Updates the system tables with purchase order information when purchase orders are entered, maintained, or received. See Working with the OTHR_ASYNC Job. |
Heartbeat and Transaction date/time |
Heartbeat date/time The job reads the other async data queue every 30 seconds. Transaction date/time The system reads a record from the other async data queue. Note: The system also updates the heartbeat date/time and transaction date/time when you end the asyncs. |
CUSTIN CWCustomer web service Processes an Inbound Customer Message (CWCustomerIn) received from an external system, such as a point-of-sale system. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Transactions Only date/time |
Transaction date/time The CWCustomer web service processes a CWCustomerIn message. |
APIs |
|
|
ORDERINAPI CWOrderIn web service Processes an Inbound Order XML Message (CWORDERIN) received from an external system, such as a web storefront. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Transactions Only date/time |
Transaction date/time The CWOrderIn web service processes a CWOrderIn message. |
PICKINAPI CWPickIn web service Processes a CWPickIn XML Message received from a warehouse management system. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Transactions Only date/time |
Transaction date/time The CWPickIn web service processes a CWPickIn message. |
RECEIPTIN CWReceiptIn web service Processes a PO Receipt In XML Message (CWReceiptIn) received from a warehouse management system. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Transactions Only date/time |
Transaction date/time The CWReceiptIn web service processes a CWReceiptIn message. |
WPBJ |
Use Working with Drop Ship Background Jobs (WPBJ) to review and work with this job. |
|
COLLAB Processes transactions between Order Orchestration’s Drop Ship Manager and Order Administration in the Order Orchestration Drop Ship Integration. |
Heartbeat and Transaction date/time |
Heartbeat date/time The job looks for transactions to process, based on the Delay Time defined for the job. Transaction date/time The job processes a transaction. |
IJCT |
This list includes:
|
Use Working with Integration Layer Processes (IJCT) to review and work with these jobs. |
BROKER Sends and receives order information and updates using Order Orchestration’s message formats; see Sample Order Orchestration Messages for examples. |
Heartbeat and Transaction date/time |
Heartbeat date/time The BROKER job reads the IL Outbound Trigger table, based on the Outbound delay time defined for the job. Transaction date/time The BROKER job processes a broker transaction. |
BROKER_ORD Sends and receives new order, pending cancellation requests, and other status updates using Order Orchestration’s message formats; see Sample Order Orchestration Messages for examples. |
Heartbeat and Transaction date/time |
Heartbeat date/time The BROKER_ORD job reads the IL Outbound Trigger table, based on the Outbound delay time defined for the job. Transaction date/time The BROKER_ORD job processes a broker transaction. |
CUST_OUT Generates an outbound CWCustomerDownload XML message when you create, change, or delete a customer. See Generic Customer Download API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Heartbeat and Transaction date/time |
Heartbeat date/time The CUST_OUT job reads the IL Outbound Trigger table for CST customer download triggers, based on the Outbound delay time defined for the job. Transaction date/time The CUST_OUT job reads and processes a customer download trigger record in the IL Outbound Trigger table. |
CUSTHIST Receives a CustHistRequest for customer order history or information on a specific order, and generates a response (CWCUSTHISTOUT or CWORDEROUT). See Generic Customer History API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Transactions Only date/time |
Transaction date/time updated when the job receives and processes a transaction. |
CUSTSRCH Receives a CWCustomerInqRequest for information on one or more customers matching specific search criteria, and generates a CWCustomerInqResponse. See Generic Customer Inquiry (Search) API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Transactions Only date/time |
Transaction date/time updated when the job receives and processes a transaction. |
INV_DOWNLOAD Sends inventory availability information to another system in the CWInventoryDownload message. See Generic Inventory Download API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Heartbeat and Transaction date/time |
Heartbeat date/time updated by reading the IL Outbound Trigger table. If the table is empty, the system sleeps for the Outbound delay time and then reads the table again. Transaction date/time updated every time the system reads and processes a record in the IL Outbound Trigger table. |
INV_INQUIRY Receives a CWInventoryInquiryRequest for inventory availability on a specific item/SKU and generates a CWInventoryInquiryResponse. See Generic Customer Inquiry (Search) API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Transactions Only date/time |
Transaction date/time updated when the job receives and processes a transaction. |
INVOIC_OUT Sends invoice information in the CWInvoiceOut message to another system, such as a retail store, financial system, or warehouse management system. See Generic Invoice Download API for an overview. My Oracle Support |
Heartbeat and Transaction date/time |
Heartbeat date/time updated by reading the IL Outbound Trigger table. If the table is empty, the system sleeps for the Outbound delay time and then reads the table again. Transaction date/time updated every time the system reads and processes a record in the IL Outbound Trigger table. |
INVTRANIN Receives inventory transactions in the inCreateInvXaction message and updates inventory information, such as in the Item Location and Item Warehouse tables. Any errors create Item Transaction Error records. See Generic Inventory Transaction Upload for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1). |
Transactions Only date/time |
Transaction date/time updated when the job receives and processes a transaction. |
ITEM_OUT Sends item and SKU information in the CWItemOut message to another system, such as a retail store or warehouse management system. See Generic Item Download API. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Heartbeat and Transaction date/time |
Heartbeat date/time updated by reading the IL Outbound Trigger table. If the table is empty, the system sleeps for the Outbound delay time and then reads the table again. Transaction date/time updated every time the system reads and processes a record in the IL Outbound Trigger table. |
ORDCLNUP Order Cleanup job Rejects any orders that have been “abandoned” on the web storefront if, for example, the customer closes the browser window. This process uses the Time Limit for Suspended E-Commerce Orders (G43) system control value to determine the number of minutes to wait before rejecting an order. Only orders of the type specified in the E-Commerce Order Type (G42) system control value are eligible for cleanup. The system generates the E-Commerce Order Cleanup Log each time it deletes a suspended order. Each time the job rejects an order, it writes a record in the Deleted Order Table. |
Heartbeat and Transaction date/time |
Heartbeat date/time The job looks for orders to clean up every minute. The system also updates the heartbeat date/time when the job deletes an order. |
ORDLINHIST Receives order line history activity for a specified order line on an order, based on XML messages from an external system, such as a warehouse management system. See Order Line History In API. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1). |
Transactions Only date/time |
Transaction date/time updated when the job receives and processes a transaction. |
ORDTRNHIST Receives order transaction records for a specified order, based on XML messages from an external system, such as a warehouse management system. You can review the order transaction history records created on the Display Order History Screen. See Generic Order Transaction History API. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Transactions Only date/time |
Transaction date/time updated when the job receives and processes a transaction. |
PICK_OUT Sends a Pick Message from Order Administration (CWPickOut) for each pick slip generated. See Generic Pick Out API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Heartbeat and Transaction date/time |
Heartbeat date/time updated by reading the IL Outbound Trigger table. If the table is empty, the system sleeps for the Outbound delay time and then reads the table again. Transaction date/time updated every time the system reads and processes a record in the IL Outbound Trigger table. |
PO_OUT Sends a CWPurchaseOrderOut message to a warehouse management system or an EDI vendor. See Generic Outbound Purchase Order API. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Heartbeat and Transaction date/time |
Heartbeat date/time updated by reading the IL Outbound Trigger table. If the table is empty, the system sleeps for the Outbound delay time and then reads the table again. Transaction date/time updated every time the system reads and processes a record in the IL Outbound Trigger table. |
PROCESSIN Uses the CWServiceIn Web Service to receive the CWProcessIn message and submit the specified periodic process received from an external system. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Transactions Only date/time |
Transaction date/time updated when the CWServiceIn web service receives and processes a CWProcessIn message. |
RETURN_OUT Sends a Return Authorization Outbound XML Message (CWReturnRAOut) when a return authorization is created, changed, or deleted. |
Heartbeat and Transaction date/time |
Heartbeat date/time updated by reading the IL Outbound Trigger table. If the table is empty, the system sleeps for the Outbound delay time and then reads the table again. Transaction date/time updated every time the system reads and processes a record in the IL Outbound Trigger table. |
RETURNIN Receives an Return Request Message (CWReturnIn) to create and process a return against a specified order line. Optionally, the process sends an Return Response Message (CWReturnOut) to the external system, indicating if the return processed successfully or if an error occurred. See Inbound Return API for an overview. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1). |
Transactions Only date/time |
Transaction date/time updated when the job receives and processes a transaction. |
SVC_OUT Sends a Stored Value Card Activation Request to a service bureau. The service bureau returns a Stored Value Card Activation Response to Order Administration. See Stored Value Card Purchase and Activation. |
Heartbeat and Transaction date/time |
Heartbeat date/time updated by completing a stored value card activation transaction then then sleeping for 2 seconds. Transaction date/time updated every time the SVC_OUT job processes an activation transaction. |
SVC_REVRSL Sends a Stored Value Card Authorization Reversal to the service bureau. The service bureau sends a Stored Value Card Authorization Reversal Response to Order Administration. See Stored Value Card Authorization Reversal. |
Heartbeat and Transaction date/time |
Heartbeat date/time updated by completing a stored value card authorization reversal transaction then sleeping for 2 seconds. Transaction date/time updated every time the SVC_REVRSL job processes an authorization reversal transaction. |
VENDOR_OUT Sends a CWVendorOut message to another system, such as a retail store or warehouse management system. See Generic Vendor Download API. For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
Heartbeat and Transaction date/time |
Heartbeat date/time updated by reading the IL Outbound Trigger table. If the table is empty, the system sleeps for the Outbound delay time and then reads the table again. Transaction date/time updated every time the system reads and processes a record in the IL Outbound Trigger table. |
Query |
|
|
QUERY Runs queries not related to the jobs listed on the Work with Job Monitor screen. |
Query Only |
The system does not update the heartbeat date/time or transaction date/time for this job. See Job Monitor Queries for more information on how to set up the Query job monitor. |
Job Monitor Examples
Job Monitor Example: PICK_OUT
You want to be notified by email every day between 9AM and 5PM when the system does not update the Update Date and Update Time for the PICK_OUT integration layer job, indicating the job is no longer active. The system should send an email 2 minutes after the conditions for the job monitor rule are met (the update date and update time are NOT updated), and then check every 5 minutes to see if the rule’s conditions are still met. After 10 minutes, the system should send another email.
You create a job monitor rule with the following rule settings:
-
Frequency: Daily
-
Start Time: 090000
-
End Time: 170000
-
Alert On: Update Time
-
Alert After: 5 minutes
-
Sleep Time: 5 minutes
-
Re-alert After: every 10 minutes
-
Action Type: Email
The system uses the following calculation to determine if the job monitor rule’s conditions are met: current time - alert after minutes > last update time.
At 9:05 the system checks to see if the job monitor rule’s conditions are met (the update date and time are not updated, indicating the job is not active). In this example, the PICK_OUT job is not active. The system sends a job monitor rule email to the specified To Email address and updates the Check date and Check time for the rule.
The job monitor rule sleeps for 5 minutes.
At 9:10 (9:05 + 5 minutes sleep), the system checks to see if the job monitor rule’s conditions are met (the update date and time are not updated, indicating the job is not active). In this example, the PICK_OUT job is not active. Because the 10 minute re-alert time has been reached, the system sends a job monitor rule email to the specified To Email address and updates the Check date and Check time for the rule.
At 9:15 (9:10 + 5 minute sleep), the system checks to see if the job monitor rule’s conditions are met (the update date and time are not updated, indicating the job is not active). In this example, the PICK_OUT job is not active; however, the Re-alert After interval has not been reached.
At 9:20 (9:15 + 5 minutes sleep), the system checks again. If the job monitor rule’s conditions are met again, the system generates the job monitor rule email, based on the Re-alert After interval.
Job Monitor Example: ORDER_IN
You want to be notified by email every day between 9AM and 5PM when the system does not update the Transaction Date and Transaction Time for the ORDER_IN integration layer job, indicating web orders are no longer being received. The system should send an email 15 minutes after the conditions for the job monitor rule are met (the transaction date and time are NOT updated, indicating a web order was not received in the last 15 minutes), and then check every 30 minutes to see if the rule’s conditions are still met. After 15 minutes, the system should send another email.
You create a job monitor rule with the following rule settings:
-
Frequency: Daily
-
Start Time: 090000
-
End Time: 170000
-
Alert On: Transaction Time
-
Alert After: 15 minutes
-
Sleep Time: 15 minutes
-
Re-alert After: every 30 minutes
-
Action Type: Email
The system uses the following calculation to determine if the job monitor rule’s conditions are met: current time - alert after minutes > last transaction time.
At 9:15 the system checks to see if the job monitor rule’s conditions are met (the transaction date and time are not updated, indicating web orders are no longer being received). In this example, the conditions are met. The system sends a job monitor rule email to the specified To Email address and updates the Check date and Check time for the rule.
At 9:30 (9:15 + 15 minutes sleep) the system checks again, but the Re-alert After interval of 30 minutes has not yet been met.
At 9:45 (9:15 + 30 minutes total sleep), the system checks to see if the job monitor rule’s conditions are met (the transaction date and time are not updated, indicating web orders are no longer being received). In this example, the conditions are met and the 30 minute re-alert time has been reached. The system sends a job monitor rule email to the specified To Email address and updates the Check date and Check time for the rule.
Job Monitor Example: Query
You want to be notified by email every day between 9AM and 5PM when the number of unprocessed billing async records is equal to or greater than 500 records. The system should send an email 5 minutes after the query results are true, and then check every 10 minutes to see if the rule’s conditions are still met. After 30 minutes, the system should send another email.
You create the following query and place the query in the JOB_MONITOR_QUERY_ DIRECTORY:
select 'Y' from dual where (Select COUNT(*) from Billing_Header_Data_Queue )>=500
You create a job monitor rule with the following rule settings:
-
Frequency: Daily
-
Start Time: 090000
-
End Time: 170000
-
Alert On: Query
-
Query: BILLINGRECORDS.TXT
-
Alert After: 10 minutes
-
Sleep Time: 10 minutes
-
Re-alert After: every 20 minutes
-
Action Type: Email
At 9:10, the system checks to see if the job monitor rule’s conditions are met (the results for the BILLINGRECORDS.TXT query in the JOB_MONITOR_QUERY_ DIRECTORY are Y, indicating there are 500 or more unprocessed billing async records). In this example, the query results are met. The system sends a job monitor rule email to the specified To Email address and updates the Check date and Check time for the rule.
The job monitor rule sleeps for 10 minutes.
At 9:20 (9:10 + 10 minutes sleep), the system checks to see if the job monitor rule’s conditions are met (the results for the BILLINGRECORDS.TXT query in the JOB_MONITOR_QUERY_ DIRECTORY are Y, indicating there are 500 or more unprocessed billing async records). However, the Re-alert After of 30 minutes has not yet elapsed.
At 9:30 (9:20 + 10 minutes sleep), the system checks In this example, the conditions are met and the 20 minute re-alert time has been reached. The system sends a job monitor rule email to the specified To Email address and updates the Check date and Check time for the rule.
Work with Job Monitor Screen (WJMO)
Purpose: Use this screen to review and work with the job monitor rules defined for a batch job.
How to display this screen: Enter WJMO in the Fast Path field at the top of any menu or select Job Monitor Status from a menu.
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.
Jobs first display on this screen in alphanumeric job name sequence.
-
To review the job with the most recent update, click on the Update Date field until an arrow pointing down displays next to it to display jobs in descending update date sequence.
-
To review the job with the most recent transaction, click on the Transaction Date field until an arrow pointing down displays next to it to display jobs in descending transaction date sequence.
Field | Description |
---|---|
Job Name |
The name of the job. Place your cursor over the job name to determine if the job is associated with a heartbeat and/or transactions.
See Which Jobs are Monitored? for a list of jobs that display on this screen and whether the job is associated with a heartbeat and/or transactions. Alphanumeric, 10 positions; display-only. |
Update Date |
The date when a heartbeat was last processed for the job to verify that the job is still active. If the job also processes transactions, the system also updates this field when a transaction is processed. Note: If a job uses a heartbeat and processes transactions, the update date and time may be different from the transaction date and time. Numeric, 8 positions (in user date format); display-only. |
Update Time |
The time when a heartbeat was last processed for the job to verify that the job is still active. If the job also processes transactions, the system also updates this field when a transaction is processed. Note: If a job uses a heartbeat and processes transactions, the update date and time may be different from the transaction date and time. Numeric, 6 positions (HH:MM:SS format); display-only. |
Transaction Date |
The date when a transaction was last processed by the job. Note: If a job uses a heartbeat and processes transactions, the update date and time may be different from the transaction date and time. Numeric, 8 positions (in user date format); display-only. |
Transaction Time |
The time when a transaction was last processed by the job. Note: If a job uses a heartbeat and processes transactions, the update date and time may be different from the transaction date and time. Numeric, 6 positions (HH:MM:SS format); display-only. |
Process |
The menu option where you can work with the job. Click on this value to advance to the specified menu option. |
Rules |
Indicates whether any condition rules are defined for the job. Once rules
are defined for a job, the color of the Rules icon changes to blue
( |
Screen Option | Procedure |
---|---|
Work with the condition rules defined for a job |
In the Action drop down list, select Rules for a job to advance to the Work with Job Monitor Rules Screen. Note: Once rules are defined for a job, the
color of the Rules icon changes to blue ( |
Refresh the screen with the most recent Update Date, Update Time, Transaction Date, and Transaction Time |
Select Refresh. |
Display all jobs in the Job Monitor Status, including jobs that were previously hidden |
Select Show All. Note: You can use the Hide Job option on the Work with Job Monitor Rules Screen to hide a job so that it does not display on the Work with Job Monitor Screen (WJMO). |
Work with Job Monitor Rules Screen
Purpose: Use this screen to define monitoring rules for a job. When these rules are met, you can have the system:
-
Notify you by email.
-
Run a periodic function, and if the conditions for the rule are still met after the defined sleep time, send an email when the re-alert time is reached.
The condition rules can be based on the last update date and time, the last transaction date and time, or query results.
Note:
If job monitoring does not run on the application server (the ALLOW_JOB_ MONITOR property for the application server is set to N), the only option on this screen is to display a rule’s settings.
How to display this screen: In the Action drop down list, select Rules for a job on the Work with Job Monitor Screen (WJMO).
Column sort: You can sort on the Rule and Status columns 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 |
---|---|
Job Name |
The name of the job associated with the monitoring rules. This is the job you selected on the Work with Job Monitor Screen (WJMO). Alphanumeric, 10 positions; display-only. |
Rule |
The name of the job monitor rule. Note: When you schedule a job monitor rule, the system uses the first 10 positions of the rule name as the job name that displays on the Scheduled Jobs Screen. Alphanumeric, 25 positions; display-only. |
When |
Indicates how often the system monitors the job to see if it meets the rule’s conditions, based on the Frequency, Start Time, and End Time defined for the rule on the Create Job Monitor Rule Screen. Alphanumeric, 40 positions; display-only. |
Status |
The status of the job monitor rule. Valid statuses are:
Alphanumeric, display-only. |
Check Date |
The date when the system last compared this rule to the monitoring information for the job to determine if the rule’s conditions are met. Numeric, 8 positions (in user date format); display-only. |
Check Time |
The time when the system last compared this rule to the monitoring information for the job to determine if the rule’s conditions are met. Numeric, 6 positions (HH:MM:SS format); display-only. |
If you are reviewing the Work with Job Monitor Rules screen from an application server
Screen Option | Procedure |
---|---|
Create a job monitor rule |
Select Create to advance to the Create Job Monitor Rule Screen. |
Hide this job from the Work with Job Monitor Screen (WJMO) |
Select Hide Job. Note: To redisplay this job, including all other jobs that are hidden, select Show All on the Work with Job Monitor Screen (WJMO). |
Review a job monitor rule |
Select Display in the Action column for a job monitor rule to advance to the Display Job Monitor Rule screen. All fields on this window are display-only. See the Create Job Monitor Rule Screen for field descriptions. Note: This option is available if the status of the job is Unscheduled, Scheduled, Running, or Ending. |
Change a job monitor rule Note: This option is available only if the Status of the job monitor rule is Unscheduled. |
Select Change in the Action column for a job monitor rule to advance to the Change Job Monitor Rule screen. See the Create Job Monitor Rule Screen for field descriptions. Note: This option is available if the status of the job is Unscheduled. |
Run a job monitor rule Note: This option is available only if the Status of the job monitor rule is Unscheduled or Scheduled. |
Select Start in the Action column for a job monitor rule to change its status to Running. At the Confirm window, select OK to start running the rule; otherwise, select Cancel. Note: This option is available if the status of the job is Unscheduled or Scheduled and the start time is met. When you start a job monitor rule, the system changes the status of the job to Running. |
Stop a job monitor rule Note: This option is available only if the Status of the job monitor rule is Running. |
Select Stop in the Action column for a job monitor rule. At the Confirm window, select OK to stop running the rule; otherwise, select Cancel. Note: This option is available if the status of the job is Running. When you stop a rule, the system changes its status from Running to Ending, and then to Unscheduled or Scheduled. |
Schedule a job monitor rule Note: This option is available only if the Status of the job monitor rule is Unscheduled. |
Select Schedule in the Action column for a job monitor rule to change its status to Scheduled. At the Confirm window, select OK to schedule the rule; otherwise, select Cancel. Note: This option is available if the status of the job is Unscheduled. When you schedule a job monitor rule, the system displays the job on the Scheduled Jobs Screen. The first 10 positions of the job monitor rule name displays as the job name on the screen. If the job monitor rule runs a periodic process, the system also displays the periodic process on the Scheduled Jobs screen and schedules the periodic process to run 1 minute after the associated job monitor rule. Once the periodic process runs, the system removes it from the Scheduled Jobs screen. |
Unschedule a job monitor rule |
Select Unschedule in the Action column for a job monitor rule to change its status to Unscheduled. At the Confirm window, select OK to schedule the rule; otherwise, select Cancel. Note: This option is available if the status of the job is Scheduled. |
Delete a job monitor rule |
Select Delete in the Action column for a job monitor rule. At the Confirm window, select OK to delete the rule; otherwise, select Cancel. Note: This option is available if the status of the job is Unscheduled. |
Create Job Monitor Rule Screen
Purpose: Use this window to define settings for a job monitor rule.
How to display this screen: Select Create on the Work with Job Monitor Rules Screen.
Field | Description |
---|---|
Job Name |
The name of the job associated with the monitoring rule. This is the job you selected on the Work with Job Monitor Screen (WJMO). Alphanumeric, 10 positions; display-only. |
Rule |
The name of the job monitor rule. Note: When you schedule a job monitor rule, the system uses the first 10 positions of the rule name as the job name that displays on the Scheduled Jobs Screen. Alphanumeric, 25 positions; required. |
Frequency |
How often the system monitors the job to see if it meets the rule’s conditions. Valid values:
Alphanumeric; required. |
Start Time |
Defines the start time when the system monitors the job to see if it meets the rule’s conditions. You must enter the start time in HHMMSS military format; for example, enter 07:00:00 to indicate a start time of 7 AM. Note: Valid entries are 00:00:00 - 23:59:59. The start time must be earlier than the end time. Numeric, 6 positions; required. |
End Time |
Defines the end time when the system monitors the job to see if it meets the rule’s conditions. You must enter the end time in HHMMSS military format; for example, enter 17:00:00 to indicate an end time of 5 PM. Note: Valid entries are 00:00:00 - 23:59:59. The end time must be later than the start time. Numeric, 6 positions; required. |
User |
The user ID associated with the job monitor rule. The user ID defaults to the user that is creating or updating the rule, but you can override it. User IDs are defined in and validated against the User table. Alphanumeric, 10 positions; required. |
Alert On |
Defines the factor the system evaluates to determine if the job meets the rule’s conditions. Valid values:
Alphanumeric, required. |
Query |
The name of the query whose results the system evaluates to determine if the job meets the rule’s conditions. The query must be located in the directory defined in the JOB_MONITOR_QUERY_ DIRECTORY property. Alphanumeric, 25 positions; required if Alert On is set to Query. |
Alert After |
The number of minutes to wait before the system can initially generate an alert. Typically equal to or a multiple of the Sleep Time. Example:
Result:
Note: If the Sleep Time is greater than the Alert After time, the initial alert is not generated until the Sleep Time elapses. For example, if the Alert After is set to 5 minutes, but the Sleep Time is set to 10 minutes, the system does not check the job’s status until 10 minutes after the start time. For more information: See Job Monitor Examples for more examples. Numeric, 3 positions; required. |
Sleep Time |
The number of minutes to wait before checking or re-checking the condition to determine whether it is time to generate an alert. Used in combination with:
The Alert Time and Re-alert After Time would typically be multiples of the Sleep Time. For example, if the Sleep Time is 5 minutes, the Alert Time and Re-alert After Time might be 10 minutes or 15 minutes. See Alert After, above, and Re-alert After, below, for examples. Also, see Job Monitor Examples for more examples. Numeric, 3 positions; required. |
Re-alert After |
The number of minutes to wait before generating an alert after the initial alert is generated. Typically equal to or a multiple of the Sleep Time. Example:
Result:
For more information: See Job Monitor Examples for more examples. Numeric, 3 positions; optional. |
Action Type |
Defines the type of action to take when the job meets the rule’s conditions. Valid values:
Alphanumeric, required. |
Periodic Process |
The code for the periodic process to run. Periodic processes are defined in and validated against the Periodic Process table. Alphanumeric, 10 positions; required if Action Type is Periodic Process. |
Process Company |
The code for the company to run the periodic process. Company codes are defined in and validated against the Company table. Numeric, 3 positions; optional. |
From Email |
The “from” email address for the job monitor rule email. See Email Address Validation. Alphanumeric, 50 positions; required if Action Type is Email. |
Subject |
The subject of the job monitor rule email. Alphanumeric, 50 positions; required if Action Type is Email. |
To Email |
The list of email addresses that receive the job monitor rule email. Each email address entered must be separated by a semi-colon (;). For example: email1@add.com;email2@add.com. See Email Address Validation. Alphanumeric, 200 positions; required if Action Type is Email. |
Email Text |
The text to display in the body of the job monitor rule email. Alphanumeric, 255 positions; required if Action Type is Email. |
Order Orchestration Configuration
Purpose: This topic describes the required setup to integrate Order Administration with Order Orchestration, and how to load item and inventory information from Order Administration into the Order Orchestration database.
Default system? When you begin setting up data in Order Orchestration, you build a location group of integrated systems, such as your Order Administration company and your POS system. If your Order Administration company is the default system, or system of record, in Order Orchestration, then when you import your Order Administration item and SKU records into Order Orchestration, they serve as the primary products, and the product records imported from other systems reference the Order Administration items and SKUs. The Order Administration item and SKU code is the product code in Order Orchestration, and the product codes from other integrated systems are system products that reference the product code from the default system.

If Order Administration is not the default system in Order Orchestration, then each item and SKU sent to Order Orchestration in the product feed needs to reference the product code from the default system. If the systems use different product codes, you can use a secondary field in Order Administration, such as the Reference number or a UPC code, to store the Order Orchestration product code, so that the Order Administration system product is correctly linked to the default system’s product code during the import process. The OROB Product Code ID (K66) system control value indicates whether the Order Administration item and SKU, or some other field, contains the default system’s product code.
For more information: See:
-
Background on integration between Order Orchestration and Order Administration: the Order Orchestration Integration Overview.
-
Details on the order types, processing, and messages: Order Orchestration Integration.
-
Instructions on setting up data in Order Orchestration: the Setting Up Data for Order Orchestration topic in the Order Orchestration online help.
-
Instructions on setup required for integration with Order Orchestration’s Supplier Direct Fulfillment module: Interface with Order Orchestration’s Supplier Direct Fulfillment Module: Overview and Setup.
Version compatibility: Fulfillment assignment and ship-for-pickup functionality is available in release 16.0 or higher of Order Administration, or Order Administration, and release 16.0 or higher of Order Broke, or Order Orchestrationr. In order to use ship-for-pickup processing, you must select the Enable Ship For Pickup option on the Organization window in Order Orchestration. Once you enable ship for pickup, the Ship for Pickup Enabled Date displays on the Organization window and you cannot deselect this option.
When integrating with Order Broker 19.4 or higher, or Order Orchestration, you cannot create a new organization without ship-for-pickup enabled.
An OROB_MESSAGE_VERSION of 16.0 or higher is required to use the Ship-for-Pickup Orders integration with Order Orchestration.
In this topic:
Order Orchestration-Related System Control Values
Most of the system control values related to integration with Order Orchestration’s Routing Engine Module are available through theOrder Broker Values (K15) umbrella screen. See that screen for more information.
Special orders system control values: The following system control values are required to process special ship-for-pickup orders:
-
Order Type for Special Orders (L15): Identifies the order type code that indicates to send the e-commerce order number, rather than the Order Administration order number, as the order ID when submitting the ship-for-pickup order to Order Orchestration. Since special ship-for-pickup orders originate in the retail location, they are identified primarily by the store system’s original order number.
-
Pay Type for Special Orders (L16): Identifies the pay type that indicates that the customer needs to pay for a ship-for-pickup order when picking it up at the retail location. When a ship-for-pickup order uses this pay type, the Submit Order message indicates a balance_due that is the same as the order total.
-
Store Pickup Confirmation Email Program (L48): Use this system control value to specify the program that generates a notification to the customer when a store pickup order is ready for pickup.
Additional system control values:
-
Use OROB Status Inquiry List Web Service (M05): Use this system control value to specify whether pick slip generation uses the status list request message rather than individual status inquiry request messages to check on whether retail pickup or delivery orders have been canceled by the originating system; also, if using the status list request, indicates whether to request information for orders only if they are canceled, or for all orders.
-
Tax on Freight (B14): Select this system control value to avoid issues with tax calculation when you use Order Orchestration fulfillment.
-
Invoice Ship For Pickup Order Once Intransit (M73): Use this system control value to define whether to create the invoice for a ship-for-pickup order line once the system receives confirmation from Order Orchestration that the order line is in transit from the sourcing location to the pickup location, has been received at the pickup location, or has been fulfilled.
-
An ORCE customer ID is assigned to the customer, and
-
The ORCE Customer Integration (L37) system control value is set to INTERACT, and
-
This system control value is selected.
Otherwise, the Order Administration customer number is sent as the customer_no in the SubmitOrder request message.
Map Order Administration or ORCE customer number from Customer Number Received from Order Orchestration in the Fulfillments Response? The ORCE Customer ID in OROB Fulfillment (M72) system control value controls whether the customer number returned from Order Orchestration in the fulfillments response message maps to the Order Administration customer number or the ORCE customer ID. The customer number in the fulfillments response maps to the ORCE customer ID if:
-
The ORCE Customer Integration (L37) system control value is set to INTERACT, and
-
The ORCE Customer ID in OROB Fulfillment (M72)system control value is selected.
Otherwise, the customer_number in the fulfillments response message maps to the Order Administration customer number.
Order Orchestration Properties
Overview: Use Working with Customer Properties (PROP) to define property settings for:
Use Working with Admin Properties (CPRP) to define the Imports URL.
Purchasing services properties: See Interface with Order Orchestration’s Supplier Direct Fulfillment Module: Overview and Setup for information on the additional properties related to integration with Order Orchestration’s Supplier Direct Fulfillment module.
WSDL Locations
Discovery Services WSDL
Use the OROB_DISCOVERY_SERVICES_WSDL_LOCATION entry in Working with Customer Properties (PROP) to specify the endpoint for the Discovery Services web service. This entry should be set to https://SERVER:8443/Locate/DiscoveryServices, where SERVER is the name of your Oracle Retail Order Orchestration server.
Required for Supplier Direct Fulfillment integration: You need to set this property as described above even if you integrate with Order Orchestration’s Supplier Direct Fulfillment module but not with Order Orchestration’s Order Broker Module, or if you integrate with an earlier version of Order Broker than you use for the Supplier Direct Fulfillment module.
Web service authentication: If the web service requires basic web service authentication, you must use Working with Web Service Authentication (WWSA) to define a valid web service authentication user; otherwise, define the client ID and client secret if using OAuth.
Purchasing Services WSDL
Use the OROB_PURCHASING_SERVICES_WSDL_LOCATION property in Working with Customer Properties (PROP) to specify the endpoint for the Purchasing Services web service. This entry should be set to https://SERVER:8443/Locate/PurchasingServices, where SERVER is the name of your Oracle Retail Order Orchestration server.
Required for Supplier Direct Fulfillment integration: You need to set this property as described above even if you integrate with Order Orchestration’s Supplier Direct Fulfillment module but not with Order Orchestration’s Order Broker Module, or if you integrate with an earlier version of Order Broker than you use for the Supplier Direct Fulfillment module.
Web service authentication: If the web service requires basic web service authentication, you must define a valid web service authentication user and password in Working with Web Service Authentication (WWSA); otherwise, define the client ID and client secret if using OAuth.
Setting the Daily Status Inquiry Time Window (all versions)
For certain Order Orchestration statuses, it is not necessary to include an order in a status inquiry list request as frequently as the Order Broker Status Update Interval (K10), because no immediate action is required in Order Administration.
The following statuses are updated once a day:
Status | Applies to Order Type | Description |
---|---|---|
In Transit In Transit Polled |
|
You have confirmed shipment of the order from an Order Administration warehouse to the store. |
Received by Store |
|
The order has been received by the store location but not yet picked up by the customer. |
Partial Fulfill |
|
The customer has picked up one or more items on the order, but not the complete order |
In order to avoid including orders in these statuses more often than necessary in the status inquiry list request, the BROKER process checks their status once daily during a specified time window. It uses the following two additional properties in Working with Customer Properties (PROP) to determine the start and end of the window:
-
OROB_LIMITED_STATUS_BEG_TIME=123456
-
OROB_LIMITED_STATUS_END_TIME=123456
Each time is indicated in HHMMSS format, military time. For example, if you set these properties to:
OROB_LIMITED_STATUS_BEG_TIME=180000
OROB_LIMITED_STATUS_END_TIME=210000
Then the BROKER process can send status inquiry list requests including these orders between 6:00 p.m. and 9:00 p.m. daily. Orders are eligible for status inquiry if there has not been an inquiry in the previous 12 hours.
You should set the time window long enough to process status inquiries for all orders in the related statuses; also, the time window should not cross midnight.
Note: You use the Order Broker Status Update Interval (K10) system control value to define how many minutes Order Administration should wait before including orders in the status inquiry list request for all other status updates.
Message Version Number
Use the OROB_MESSAGE_VERSION property (PROP) to specify the message version to include in Order Orchestration and merchandise locator request messages that Order Administration sends to Order Orchestration.
Version requirements:
-
A message version of 5.0 or higher is required to use the status list request message and streamlined allocation at pick slip generation. See Use OROB Status Inquiry List Web Service (M05) and Use Streamlined Allocation (L63) and Use Streamlined Allocation (L63) for background.
-
A message version of 16.0 or higher is required to use the Ship-for-Pickup Orders integration with Order Orchestration.
-
A message version of 19.0 or higher is required to include the shipment_date tag in the status inquiry response message from Order Orchestration. This date indicates the actual date when the order line was shipped by the fulfilling location, provided the fulfilling system passed this date when it submitted the status update to Order Orchestration when reporting the fulfillment. The shipment date is available to include in shipment notifications to the customer; see Outbound Email API in the Web Services Guide on My Oracle Support (ID 2953017.1) for more information.
Note:
Note that this property cannot be set higher than 19.9 for integration with Order Broker 19.x, or higher than 21.1 for integration with Order Broker 22.2.301.0 or higher, or Order Orchestration.Important:
To avoid unpredictable results, do not leave the OROB_MESSAGE_VERSION blank.
Imports URL
Use the OROB_IMPORTS_URL property to define the URL used to call the Order Orchestration Import RESTful web service when sending product, product location, and incremental inventory data to Order Orchestration.
For example: https://order_broker_url:port, where order_broker_url is the URL used to connect to Order Orchestration and port if the port number used to connect to Order Orchestration.
Web service authentication: If the Import web service requires basic web service authentication, you must define a valid web service authentication user and password in Working with Web Service Authentication (WWSA); otherwise, define the client ID and client secret if using OAuth.
See Order Orchestration’s Product, Product Location, and Incremental Inventory Import Process.
Maximum Number of Request IDs to Include in a Status List Request
Use the OROB_MAXIMUM_STATUS_LIST_REQUEST in Working with Customer Properties (PROP) to specify the maximum number of request IDs that the BROKER job can include in a single order status list request message to Order Orchestration. This property defaults to 500, and should not be set higher than 1000.
Pick slip generation also uses this property to determine the maximum number of request IDs to include in a single status list request.
See Order Status List Request Message Sample for examples of how this property controls the number of request IDs included in the list request message.
Additional Order Orchestration Setup in Order Administration
Purpose: Additional setup for integration with Order Orchestration is described below:
General Order Orchestration setup:
-
Item: Deselect the OROB eligible flag for any items that should not be included in the Order Orchestration integration. This flag is selected by default.
-
Warehouse: Complete the OROB location for each warehouse that maps to a location in Order Orchestration. If the Send Inventory by Warehouse to OROB (L06) system control value is selected:
-
the product import process sends inventory information separately for each warehouse that has an OROB location specified.
-
the BROKER process sends a separate fulfillment request message for each warehouse that has an OROB location specified.
-
Note:
If the Send Inventory by Warehouse to OROB (L06) system control value is selected but you do not define an OROB location in Creating and Maintaining Warehouses (WWHS), fulfillment requests for the warehouse are not sent to Order Orchestration.
-
A first and last name or a company name are required for the sold-to customer on all orders sent to Order Orchestration.
-
BROKER_ORD process in Working with Integration Layer Processes (IJCT): Optionally, set the Outbound delay time. The Outbound delay time controls how often to send cancellation requests.
The BROKER_ORD process submits new orders and cancellation requests.
-
Outbound delay time Working with Integration Layer Processes (IJCT): Outbound delay time Outbound delay time. The Outbound delay time controls how often to send fulfillment request messages.
The BROKER process handles the messages that are not handled by the BROKER_ORD process, including status inquiries and updates, as well fulfillment requests and responses.
-
Secured features:
-
Use the Cancel Order Broker Lines (B19) secured feature to restrict access to Order Orchestration cancellations as needed.
-
Use the Maintain Brokered Fulfillment Orders (B20) secured feature to restrict access to order maintenance for retail pickup or delivery orders.
-
-
Store cross references: Create store location cross references for each potential fulfilling location through Work with Store Cross Reference (WSCR), including:
-
Specify a source code. See Order Broker Source Code (K93) for a discussion of how the source code assigned to the order varies depending on whether the order originated in Order Administration.
-
For ship-for-pickup orders, select the Ship for pickup flag; also, complete the description and address fields, as this information is used as the ship-to name and address for ship-for-pickup orders.
-
Optionally, specify a System Code to override the Name in OROB for Point of Sale (L09) used to identify the fulfilling location for ship-for-pickup and store pickup orders. For example, if you use the Store Connect module for pickup orders in some store locations, but use a point-of-sale system for other locations that support ship-for-pickup orders, you might set this system control value to the code identifying your point-of-sale system, and enter the code for your Store Connect system for the Store Cross Reference records used for Store Connect locations. When submitting a store pickup or ship-for-pickup order to Order Orchestration, Order Administration uses the System Code, if any, from the Store Cross Reference record; otherwise, it uses the system code from this system control value.
-
Note:
You can use the Importing Store Cross Reference Locations through Order Orchestration’s Discovery Web Service option to create store cross reference records.
-
BROKER periodic function: Set up and schedule the BROKER periodic function (program PFR0083) to generate requests for existing backordered lines.
Note:
Since the BROKER periodic function should not run at the same time as pick slip generation, the periodic function runs in the PICKGEN queue regardless of your selection for the periodic process.
-
Schedule BROKER process: Optionally, set up periodic functions to schedule the BROKER process in Working with Integration Layer Processes (IJCT):
-
ENDBROK (program=ILENDBROKR) to stop the BROKER process
-
STRBROK (program=ILSTRBROKR) to start the BROKER process
-
-
Schedule BROKER_ORD process: Optionally, set up periodic functions to schedule the BROKER process in Working with Integration Layer Processes (IJCT):
-
ENDBRO (program=ILENDBROK) to stop the BROKER process
-
STRBRO (program=ILSTRBROK) to start the BROKER process
-
-
CWPickOut: If you use the CWPickOut message to send pick slip information from Order Administration to an external system, set the Outbound XML version of the PICK_OUT process in Working with Integration Layer Processes (IJCT) to 3.0 or higher to include:
-
broker_delivery_type of R (retail pickup), D (delivery), or S (ship-for-pickup)
Note:
This field is not used for brokered backorders.
-
destination_store: the store cross-reference code (WSCR) for a ship-for-pickup order
-
originating_store: the store cross-reference code (WSCR) for a retail pickup or delivery order
-
-
CWInvoiceOut: If you use the CWInvoiceOut message to send invoice information to an external system, set the Outbound XML version of the INVOIC_OUT process in Working with Integration Layer Processes (IJCT) to 2.0 or higher to include:
-
ost_broker_delivery_type of R (retail pickup), D (delivery), or S (ship-for-pickup)
Note:
This field is not used for brokered backorders.
-
ost_destination_store: the store cross-reference code (WSCR) for a ship-for-pickup order
-
ost_originating_store: the store cross-reference code (WSCR) for a retail pickup or delivery order
-
-
Email setup: Use the Email notification flag to control email generation for the retail pickup, delivery, or store pickup order types. Also, set up the store pickup notification template. See Email Generation Setup for more information.
Merchandise locator setup: For merchandise locator searching: Make sure the MERCH_LOC process in Working with Integration Layer Processes (IJCT) has its Communication type field set to Web Service.
See Scheduling Jobs for more information.
You must first install and configure Order Orchestration before using the options described in the Order Orchestration Integration Overview in the online help.
Tax considerations: If you integrate with Vertex or Avalara for tax calculation and broker all orders, you can use the Order Broker Source Code (K93) to specify a source code that points to a separate entity that the tax integration can filter from tax calculation; this setup can prevent the tax from appearing to be charged twice for the same order.
Notes on Configuration in Order Orchestration
Follow the steps described under Setting Up Data in Order Orchestration in the Order Orchestration online help or operations guide, using the following notes to configure the integration between Order Orchestration and Order Administration:
System setup:
-
Default system? If Order Administration is the default system for your organization, set the OROB Product Code ID (K66) system control value in Order Administration to Item/SKU or blank. Otherwise, if Order Administration is not your default system, use the OROB Product Code (K66) system control value to indicate the field you use to store each item’s product code from the default system.
-
Setting up the Order Administration system: Also, when creating the system for Order Administration in Order Orchestration, set the System code in Order Orchestration to match the Company number in Order Administration and the OROB System (K50) system control value. The code should not be zero-padded (that is, create a system of 2 rather than 002).
Note:
Do not select the Allow Partial Updates preference in Order Orchestration when integrating Order Orchestration and Order Administration.
Warehouse (location) setup:
-
If the Send Inventory by Warehouse to OROB (L06) system control is unselected, create a location in Order Orchestration to represent your default warehouse in Order Administration as defined in the OROB Default Location (K51). The location code in Order Orchestration should match the warehouse number in Order Administration, and should not be zero-padded (that is, create a warehouse of 1 rather than 0001).
-
If the Send Inventory by Warehouse to OROB (L06) system control is selected, create a location in Order Orchestration for each warehouse that has an OROB location specified. The location code in Order Orchestration should match the warehouse number in Order Administration, and should not be zero-padded (that is, create a warehouse of 1 rather than 0001).
-
If you have defined a location in the Originating Location to Pass to OROB (M32) system control value, create this location in Order Orchestration. The location code in Order Orchestration should match the warehouse number in Order Administration, and should not be zero-padded (that is, create a warehouse of 1 rather than 0001).
-
At the Preferences screen in Order Orchestration, flag the default Order Administration location, and any additional locations representing Order Administration warehouses, as Pickup available = No. (NOTE: You can set this flag at the location type level if you have set up a location type to represent your Order Administration warehouses; in this case, you do not need to set the flag for each individual location.)
Note:
See the Order Orchestration online help for additional steps to setting up data in Order Orchestration.
Product and inventory import setup: Use the System Import Schedule screen to set up a schedule for importing items and inventory information from Order Administration into Order Orchestration. When setting up the schedule:
-
Select the Enabled flag.
-
Select each day of the week when the process should run, or select Daily to run the process every day.
-
Enter the time, in HH:MM:SS format (military time), when the process should run for all selected days.
-
If Order Administration is your default system, make sure to schedule its import process about 30 minutes earlier than any other systems to prevent product import errors. The product import will fail if you attempt to create a system product record before the product record for the default system exists.
Note:
Schedule the product and inventory import so that it occurs after the purchase order layering process completes. See Purchase Order Layering for more information.
Order Administration Application Configuration
Purpose: Use the Application Properties File to define configuration settings for Order Administration.
For more information: See:
-
Admin Properties: See Working with Admin Properties (CPRP) for more information on the properties that an administrator would update.
-
Customer Properties: See Working with Customer Properties (PROP) for more information on the properties that a user would update.
Application Properties File
The system updates this file with settings on the application server; you would typically not change the settings in this file.
Setting | Description |
---|---|
name |
The name of the application without any version information included. |
path |
The location of the application folder. |
version |
The version information of the product not including the patch level. |
patch |
The patch level of the application. |
Order Administration Support Notifications
Purpose: Support notifications notify you when an Order Administration job has been placed in a MSG status due to an error during processing, as well as other errors such as inconsistent system control value settings.
When is a support notification sent? Order Administration sends a support notification:
-
For any job that is submitted to the Job Management Screen that is placed in a MSG status.
-
After printing the Pick Authorization Error Report.
-
If there is an issue related to the SNDRTLG or RCVRTLG periodic functions that submit or resubmit the RTLOG file to the Sales Audit module of the Oracle Retail Merchandising Foundation Cloud Service. See Integration with the Sales Audit Module of the Oracle Retail Merchandising Foundation Cloud Service for more information.
A support notification is not generated when a job is placed in an ERROR status because the job will first be placed in a MSG status. Otherwise, you would receive two support notifications for the same job.
Inconsistent system control value settings for multiple billing async jobs: Order Administration sends a System Alert email notification if the Delay Billing Updates (K85) and the Number of Billing Async Jobs to Start (F08) system control values are not set consistently across all companies in your environment. See those system control values for background.
Is a support notification sent for jobs the require user intervention? Order Administration does not send a support notification for a job that requires user intervention because the job is still running and only requires a user response in order to proceed. Instead, the system generates a Response Required Email indicating the job requires user intervention. See Working with Required Responses (WREQ) for more information on require response processing.
In this topic:
For more information: See Email Generation Setup for more information on the required and optional setup for generating email notifications through Order Administration.
Support Notification Processing
When generating a support notification or a system alert email, Order Administration checks the oms.email.support.to property in Working with Admin Properties (CPRP). If the oms.email.support.to setting contains a valid email address, Order Administration generates an Order Administration Support Notification or System Alert Email and sends the email to the specified email address(es).
Order Administration Support Notification
A sample of the support notification email is presented below.
From: [Email Sender]
To: [Email Recipient]
Subject: Support Notification - OMSCS-HOST/APPSERVER
Job: PICK_GEN
User: [Name of User]
Job has gone into MSG status.
Contents:
-
From: The no-reply@omni.retail.oraclecloud.com address, rather than the from email address defined in this property, for the entity (WENT), for the company (WCMP), will be used as the “from” address; however, you have the option to display an alias with the actual “from” email address.
-
To: The user name for the oms.email.support.to setting in Working with Admin Properties (CPRP).
-
Subject: Support Notification - HOSTNAME/APPSERVER where HOSTNAME is the server host name that is hosting the Order Administration application, and APPSERVER is the name of the actual application server instance
-
Body:
-
Job: The name of the job that is in a MSG status. When this email is generated through the Transmitting the RTLOG File to Object Storage, this is the name of the periodic process rather than the SNDRTLG or RCVRTLG periodic function.
-
User: The user ID of the user that submitted the job.
-
If a job has gone into MSG status, the email indicates Job has gone into MSG status.
-
If the issue is related to transmitting an RTLOG file to object storage, the email indicates RTLOG failed to send to Sales Audit, check system logs for more information.
-
System Alert Email
A sample of system alert email is presented below.
From: [Email Sender]
To: [Email Recipient]
Subject: System Alert Email for Testing Company
Multiple Billings could not be started = K85 (Delayed Billing Updates) is not enabled in one or more companies.
Contents:
-
From: The no-reply@omni.retail.oraclecloud.com address, rather than the from email address defined in this property, for the entity (WENT), for the company (WCMP), will be used as the “from” address; however, you have the option to display an alias with the actual “from” email address.
-
To: The user name for the oms.email.support.to setting in Working with Admin Properties (CPRP).
-
Subject: System Alert Email for Testing Company, where Testing Company is the description of the company
-
Body: Multiple Billings could not be started = K85 (Delayed Billing Updates) is not enabled in one or more companies.
Support Notification Setup
In order to generate support notifications or system alert emails, you must complete the required setup. See Email Generation Setup for more information on the setup required to generate emails through Order Administration.
Payment Configurations
Note:
Access to this page requires ALLOW authority to the WPMT (Payment Configurations) menu option. If you have DISPLAY authority, you cannot advance to this page.About EFTConnect: Oracle Retail EFTConnect facilitates integration with account providers, such as CyberSource, Adyen, external payment services (EPS) and other custom Oracle Payment Interface (OPI) payment services. Use of EFTConnect removes any requirement to configure each credit card payment type in Order Administration; instead, the payment processor that hosts the payment form validates the card used on an order, including the card number length, format, leading digits, or expiration date.
Configuration for other payment methods: Use the Work with Pay Type (WPAY) option in Classic View for other payment methods, such as cash, check, PayPal, external payment service gift cards, or Customer Engagement stored value cards. Payment methods that have been configured through the Payment Configurations page in Modern View are display-only in the Work with Pay Type option in Classic View.
Required settings before you begin: Before you use this page to set up a merchant account for your brand and define payment methods, the following configuration is required in Classic View:
-
Properties: Configure the following properties in Work with Admin Properties (CPRP):
-
ELO_CONFIG_URL: Used to establish a connection with EFTConnect when you use the Payment Configurations page. Contact your Oracle representative if this property is not defined, or if the Payment Configurations page in Modern View displays an error.
-
ELO_IDCS_ENDPOINT_URL: Used to request the token for OAuth authentication for the integration with EFTConnect. If this property is blank, the IDCS_SERVICE_ENDPOINT_URL is used. OAuth must also be configured for the outbound EFTConnect web service in Work with Web Service Authentication (WWSA).
Note:
The Client ID and Client Secret are from the EFTConnect record in Work with Web Service Authentication (WWSA). Regardless of which endpoint URL is used, the client ID and secret must be valid for the EFTConnect web service. -
ELO_PAYMENT_URL: Defines the URL to use for any transactional communication with EFTConnect, such as obtaining a form token, authorization, or deposit. Required for use of the Payment Configurations page in Modern View.
-
ELO_THRESHOLD_TIME: Used for logging purposes. Compares the elapsed time of the web service with the ELO_THRESHOLD_TIME. If the elapsed time exceeds the threshold, a message is logged.
-
ELO_TIMEOUT: Defines the number of milliseconds to wait before requests from Order Administration to EFTConnect time out.
-
ELO_POLL_COUNT_THRESHOLD: Determines whether the transaction should be updated as unconfirmed if the threshold has been exceeded. It has a default threshold of 3, but this setting may need to be changed by the retailer. This value indicates the number of times that OACS calls EFTConnect to check if it has the status of the transaction (Capture, Refund, or Auth+Capture) from the payment provider. If the poll count is equal to or exceeds this setting, the status is changed to Unconfirmed. The deposit will need to be managed in Manage Rejected Deposits.
-
-
Authentication: Set up outbound authentication for EFTConnect in Work with Web Service Authentication (WWSA). OAuth is required. Note that this authentication is company-specific; for example, if you use company 1 and company 2, you need to configure authentication in both companies. The retailer needs to copy the client secret from IDCS or OCI IAM and paste it in as the Client Secret for the EFTConnect record in Work with Web Service Authentication.
-
System control values:
-
Use Auto Authorization Interface (C14) must be selected.
-
Selecting On-Line Authorizations (B89) is optional.
-
-
For CyberSource, the Merchant Account, Merchant Key, and Merchant Secret Key are entered into the merchant service screen after selecting CyberSource.
Note:
It is the responsibility of the retailer to obtain their credentials from the payment service provider.
If the page does not load successfully: Reasons why the page does not load can include:
-
If you do not have ALLOW authority to the WPMT (Payment Configurations) menu option, you cannot advance to this page.
-
If the page displays an error such as Access to Payment Configurations is not allowed. Contact your system administrator, this can indicate that one of the property settings listed above, such as the required URLs, are not set to valid URLs. The error might also include additional information, such as EFT Connect Configuration URL value is invalid or EFT Connect Payments URL value is invalid.
-
If the Auto Authorization Interface (C14) system control value is not selected, the page displays an error: Access to Payment Configurations is not allowed. Contact your system administrator.
-
If any of the required properties are not defined correctly in Work with Admin Properties:
-
EFT Connect Configuration URL value is invalid: Indicates that the ELO_CONFIG_URL is not set correctly.
-
EFT Connect Payment URL value is invalid: Indicates that the ELO_PAYMENT_URL is not set correctly.
-
Pending Transactions:
Use the EFTSTA periodic function (PfrEFTStat) to request payment status updates for pending authorization void, capture and refund transactions in EFTConnect. This function checks the status in EFTConnect of each order payment transaction record that is currently in SENT status, as this status indicates that Order Administration previously received a PENDING result code from EFTConnect for the transaction. Some payment providers process some messages asynchronously (typically can be Captures, Refunds, Voids) and will return initial result as “PENDING”, and at a later point will notify EFTConnect with the final result of the transaction. This requires Order Administration to periodically request status updates for the transactions in this status. When Order Administration receives a PENDING result code in an authorization reversal (VOID) response message from EFTConnect, the IL outbound record status will be changed to P (PENDING).
This function uses the new ELO_POLL_COUNT_THRESHOLD property in CPRP to determine whether the transaction should be updated as unconfirmed. It has a default threshold of 3, but this setting may need to be changed by the retailer. This value indicates the number of times that OMS calls EFTConnect to check if it has the status of the transaction (Capture, Refund, or Auth+Capture) from the payment provider. If the poll count is equal to or exceeds this setting, the status is changed to Unconfirmed. The deposit will need to be managed in Manage Rejected Deposits.
You should schedule this job to run at least a half hour after running deposits to allow time for processing of the requests. The exact interval to allow between running deposits and this job depends on the quantity of requests you are processing.
Fraud Processing:
When Use Fraud Checking is enabled on the Payment Configurations Merchant Account screen, the first authorization sent for each order payment method will request that the payment processor perform fraud checking. With CyberSource, fraud checking will be performed through Decision Manager. Additional configuration within Order Administration is no longer required.
When an authorization is under review, the order will be placed on a header system level hold of FS (Fraud Scoring Hold) and a pay type system level hold of PF (Payment Fraud Scoring Hold).
Note:
If the PF hold reason code is already in use, the description will be updated to Payment Fraud Scoring Hold and you should consider creating a different code for other user hold processes.Use the EFTFRA periodic function (PfrEFTFraud) to request payment status updates for authorization transactions under REVIEW in EFTConnect.
-
If result is REVIEW, no changes will be made, and the status will be checked next time the job is run.
-
If result is REJECT, the order is canceled using the reason code in the Fraud Score Cancel Reason Code (M14) system control value.
-
If result is ACCEPT, the order and pay type holds will be released and the order can now follow normal processing.
Authorization Reversals
When Send Authorization Reversal is enabled on the Payment Configurations Merchant Account screen, the REVERSE periodic function now applies only to all open (Status is A or O) Authorization History records whose authorization service is eligible for authorization reversal.
Note:
This periodic function no longer uses Send Reversal on the Work with Pay Type (WPAY) record or a restriction of not more than 72 hours old.This periodic function applies only to credit cards that are configured through the Payment Configurations option in Modern View. It does not apply to ORCE Stored Value Cards, External Payment Service Gift Cards or to PayPal.
EFTConnect Data Storage
Requests are sent to EFTConnect when an order purge occurs to confirm the purge of payment-related data. You can purge orders through Purge Orders (MPOR), Purge Orders by Order Number (MORP), or the PURGEOR periodic function.
New Web Service Message Versions
The following new message versions no longer include tags that pass the credit card number for an order and instead include tags that pass the card token. These changes were made because in 23.2.401.0 or higher, the message includes only an already tokenized card number.
Note:
The previous versions of these messages are no longer available. You need to use the new message versions listed below.-
CWEmailOut: New version 13.0 no longer includes the opm_credit_card tag and includes instead the card_token tag.
-
CWInvoiceOut: New version 7.0 no longer includes the ipm_credit_card_nbr and instead includes the card_token tag.
-
CWOrderIn: New version 12.0 no longer includes the cc_number or already_tokenized tags, but instead includes the new card_token, psp_payment_scheme, and psp_customer_token tags.
-
CWOrderOut: New version 12.0 no longer includes the credit_card_nbr tag, but instead includes the new card_token tag.
Displaying Credit Card Numbers: Storing credit card numbers are no longer supported. Instead, the Credit Card Last 4 or the Card Token will be displayed on all Classic View screens or reports where previously the credit card number would have displayed. Additionally, all Classic View screen labels have been updated to say Card instead of Credit Card.
Search by Credit Card Number: The Credit card number field is no longer available at the Classic View Order Inquiry scan screen, so that you can no longer advance to the Scan by Card Last 4 screen.
How to display: Select Payment Configurations from a menu.
For more information: See Modern View help.
Periodic Functions Available to Schedule
Purpose: The tables below provide a list of the periodic functions you can use to schedule certain functions in Order Administration.
See How to Schedule a Job for information on how to schedule a periodic process.
Periodic Functions Available to Schedule
General Usage (ALL) Periodic Functions
The table below lists the periodic functions associated with General Usage processing. The Parameter column is populated only if the periodic function allows you to define an additional parameter. The Schedule column represents how often you should generally run the periodic function. Your business requirements may require a different schedule.
Function | Program or Class | Parameter | Schedule | Description |
---|---|---|---|---|
AUTHALL |
PFR0131 |
|
As needed |
Authorize All Open Orders Calls Performing Batch Authorization (SATH), which processes online authorizations for all open orders that contain a credit card or stored value card payment that requires authorization. This periodic function allows you to use the job scheduler to schedule when you wish to process the Batch Authorization Program (SATH). |
BO_REAS |
PFR0024 |
|
Daily |
Evaluate Backorder Reasons without Backorder Warehouse Tries to reserve order detail lines that have a backorder reason, but no backorder warehouse. If inventory is not available, this function assigns a backorder warehouse so that the order detail line will process through Evaluate Backorders. See Working with the EBO_ASYNC Job. If an order line on backorder is reserved, the system determines whether the order line is eligible for pick slip preparation; see Preparing Orders for Pick Slip Generation. |
BROKER |
PFR0083 |
|
As needed |
Generate Order Orchestration Requests Generates Order Orchestration requests for currently eligible orders that have not previously been submitted to the Order Broker. You might use this function when you are first starting to use the Order Orchestration integration, or on a periodic basis to generate requests for backordered lines that were not previously eligible because, for instance, the order was held. See the Order Orchestration Integration for an overview. |
CLR_MTH |
MSR0576 |
|
Monthly |
Monthly Clear Process Clears (updates the zero) the MTD (month-to-date) fields in all tables. Tables affected include Flash Report, Item Warehouse, Location. |
COPYCMP |
PFR0200 |
FROM TO Y/N where: FROM is the From company number TO is the To company number Y/N is a Y or N setting indicating whether the system should delete the data in the To company before copying. Unless you can verify that you are not copying over any records that already exist in the target company, this setting should be set to N. Note: Separate each parameter setting with a single space. |
|
Copy Company Uses the following parameters to create a company:
Note: Separate each parameter setting with a single space. For example, enter the following in the Parameter field, where 1 is the From company number, 2 is the To company number, and N is the Delete To company parameter: 1 2 N . COPYCMP will not run if the “from” company has any EFTConnect configured merchant accounts. That is, having any merchant account record in the Payment Configuration screen. The copy company (COPYCMP) should only be done from 49 or 51 where EFTConnect is not enabled in the "From" company. If EFTConnect is enabled, the Copy Company periodic function cannot be run for copy or delete processes. Delete Company To use this periodic function to delete a company, enter the company you wish to delete in the From and To company parameters and set the Delete parameter to Y. For example, enter the following in the Parameter field, where 1 is the company you wish to delete and Y is the Delete parameter: 1 1 Y |
|
|
Note: Do not run this periodic function while users are still using the applications listed above. 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. |
||
DLYCLR |
MSR0574 |
|
Daily |
Clear Daily Journals
Tables affected include Flash Report, Division, Item Warehouse, Order Type/User, Ship Via. You should run daily reports before executing this periodic function. Add this function as the last one (or just before reorganizing data tables) in a daily periodic process. |
DSHPROC |
FLRDSHP |
|
Daily |
Process Drop Ship Orders Processes all drop ship orders by vendor, and generates vendor drop ship worksheet, purchase orders and invoices, or pick slips. Output depends on the Drop ship output selection in the Second Create Vendor Screen. You can also submit this process on demand at the Select Vendors for Drop Ship Screen. |
DSLJPAY |
ACR0315 |
|
Daily |
Daily Sales Journal by Pay Type Generates the Daily Sales Journal by Pay Type. |
DSLJRN |
ACR0216 |
|
Daily |
Daily Sales Journal Generates the Daily Sales Journal. |
ECOMERR |
ECR0295 |
|
Daily |
Batch OM Transaction Error Listing Generates the E-Commerce Order Maintenance Errors Report. See Working with Batch Order Maintenance Transactions (WBOM). |
ENDIJCT |
ILENDGENER |
The Process ID for the integration layer process you wish to end. |
As needed |
End IJCT Process Passed Ends the integration layer process whose Process ID is defined in the Parameter field. Example: If you define ITEM_OUT in the Parameter field, this periodic function ends the ITEM_OUT integration layer process. |
FUTURE |
FLR0246 |
|
Daily |
Evaluate Future Orders Evaluates and
reserves orders. If the If the order is reserved and updated to an open status, the system determines whether the order is eligible for pick slip preparation; see Preparing Orders for Pick Slip Generation. |
GBOC |
BOR0003 |
|
As needed |
Generate Backorder Cards The system submits the BO_CARDS job and displays a confirmation message at the bottom of the screen. |
JOBCLN |
PFJOBCLNUP |
|
After server restart or as needed |
The function:
Requirement: The user submitting this function must be flagged as a Security Administrator, with a User Rank of 1. Note: If you run this function by submitting it through the ProcessIn service, the wait_for_completion flag should be set to N. For more information: See Using the JOBCLN Function to Resolve Job Status Across Servers. |
MDADRCG |
CSX1069 |
|
Daily |
Marketing Download Address Change Report Generates the Marketing Download Change of Address Interface Report when you submit a periodic process that also includes the Marketing Download Extract. |
MDCSCHG |
CSX1061 |
|
Daily |
Marketing Download Customer Status Change Report Generates the Marketing Download Customer Status Change Interface Report when you submit a periodic process that also includes the Marketing Download Extract. |
MDEXTR |
CSX1041 |
|
Daily |
Marketing Download Extract Extracts information from the Marketing Download Trigger table and populates the Marketing Download order-related and customer-related tables, based on the setting of the Populate Marketing Download Trigger File (G33) system control value. Once populated, deletes the associated records in the Marketing Download Trigger table. |
MDEXPRT |
PFR0130 |
|
Daily |
Marketing Download Export Exports the data in the Marketing Download order-related and customer-related tables to pipe-delimited files and places the files in the OMS-MARKETING container of the FILE_STORAGE table. Once the extract files are created, the system deletes the records in the associated Marketing Download tables. See Working with the Marketing Download Extract. |
MDINQSM |
CSX1066 |
|
Daily |
Marketing Download Inquiry Summary Report Generates the Marketing Download Customer Inquiry Interface Report when you submit a periodic process that also includes the Marketing Download Extract. |
MDORDHD |
CSX1044 |
|
Daily |
Marketing Download Order Header Report Generates the Marketing Download Order Header Interface Summary Report when you submit a periodic process that also includes the Marketing Download Extract. |
MDORDTL |
CSX1058 |
|
Daily |
Marketing Download Order Detail Change Report Generates the Marketing Download Order Detail Interface Summary Report when you submit a periodic process that also includes the Marketing Download Extract. |
MDSRCSM |
CSX1036 |
|
Daily |
Marketing Download Source Summary Report This download is no longer supported. |
ONHAND |
PFR0005 |
|
Monthly |
On Hand by Warehouse Generates the On Hand by Warehouse Report. |
OMS-OKM |
PFR0135 |
|
As needed |
OMS to OKM Switch Encryption Key Not currently used.. |
ORDSUM |
PFR0062 |
|
Daily |
Order Summary
Note: This periodic function performs updates similar to the THRESHD periodic function. |
PFSDOUT |
CSSDOUT |
|
Daily |
Sold Out Processing Generates the soldout notifications. .You can also submit this process on demand through the Generating Soldout Notifications (MSON). |
POSLOGX |
PFPOSX |
|
As needed |
POSLOG for XLink Generates and sends a custom POSLog to Xlink using the POSLOG XLink properties, or places it in the OMS-POSLOG container in the FILE_STORAGE table if the file storage API is enabled for exports. See the File Storage API for background. Note: To use this periodic function, you need to have a valid store number specified in the Default Location for ORCE Integration (K69) system control value. Also, you need to set up the store location in Work with Store Cross Reference (WSCR). |
PRMOUPL |
PRMOUPL |
|
|
Create or Delete Promotions Creates or updates promotions and related tables based on the information in the Promotion Upload table. See Promotion Upload for more information. |
PSJD |
ACR0321 |
|
Daily |
Print Sales Journal by Division Generates the Sales Journal by Division. |
PURGECS |
PFR0137 |
The number of days old the sold to customer must be to be eligible for purge. The system uses the last change date to determine the age of the customer sold to record. |
Daily |
Purge Sold To Customers Purges sold to customers that are older than the number of days specified. If the Parameter is blank or 0, records must be 365 days old to be eligible for purge. To be eligible for purge, the system verifies that:
See Purging Sold To Customers for background and for the list of tables that are purged. |
PURGEJH |
oracle.retail.oms.services.job.functions.PurgeJobHistoryJob |
None |
As needed |
Purge Job History Records The PURGEJH periodic function purges all records in the:
When a pod/server is started up, the JOBHISTORY and JENASYSJOB tables are not purged. |
PURGEOR |
PFR0114 |
Set the parameter to Y in order to generate the Purged Order List; otherwise, the report is not generated. |
Daily |
Purge Orders Purges orders that are closed or canceled, and that:
See Purging Orders (MPOR) for background and for the list of order-related tables that are purged. |
PURGEUA |
PFR0125 |
The number of days old a User Audit or Password Audit record must be to be eligible for purge. |
Daily |
Purge User Audit Table Purges User Audit and Password Audit records that are older than the number of days specified. If the Parameter is blank or 0, records must be 365 days old to be eligible for purge. See Tracking User, Authority, and Password Updates for background. |
PURGEUH |
PFR0126 |
The number of days old a Upload History record must be to be eligible for purge. |
Daily |
Purge Upload History Table Purges Upload History records that are older than the number of days specified in the Parameter field. If the Parameter is blank or 0, records must be 21 days old to be eligible for purge. See Work with File Uploads (WUPL) for more information. |
Inventory Quantity Reset |
MSR0698 |
|
Run when a problem is detected Note: Run this function only when you have a dedicated system; do not run this periodic function when the Billing Async is active, you are running pick slip generation or performing inventory transaction processing. |
Inventory Quantity Reset
Note: You can use Reset Allocation Quantities (MRPC) 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. |
RESETOH |
PFR0093 |
|
Run when a problem is detected. |
Reset On Hand Quantity Resets the quantity on-hand for each Item Warehouse record based on the total quantities on-hand for related Item Locations within the warehouse. See Reset Item Warehouse Quantity On Hand (MRIW). Note: Run this function only when you have a dedicated system; do not run this periodic function when the Billing Async is active, you are running pick slip generation or performing inventory transaction processing. |
REVERSE |
PFR0133 |
|
Daily |
Send Reversals for Expired Authorizations Processes all open Authorization History records that are eligible for authorization reversal processing. Note: Run this periodic function daily so that expired authorizations are reversed in a timely manner without incurring penalty fees. Also, this function should be scheduled to run before the REAUTH periodic function. When you run this periodic function for a specified company, the system:
Note:
|
RFRECON |
PFR0008 |
|
Monthly |
Refund Reconciliation and Purge Purges refund checks once you have reconciled or voided the checks. Generates the Check Reconciliation List. |
RLTSLSF |
PFR0102 |
|
Daily |
Submit ORCE Sales Feed Sends sales information to Oracle Retail Customer Engagement. See Customer Engagement Sales Feed. The ORCE File Service URL (M62) and ORCE Import Folder Path (M63) system control values must be specified for the company in order for this periodic function to run. |
RSLTME |
CSR0557 |
|
Daily |
Release Order on Time Hold Releases prepaid orders from hold automatically when the number of days to hold the order (in the Hold days field in the Pay Type table) has passed, and releases orders held for credit card authorization. |
SCHDDEP |
Set the class name to: oracle.retail.oms.services.job.functions.DepositBatchSingleRunJob |
Positions 1-3: 3 position Authorization service code Positions 4-10: 7 position Purchases transactions to generate For example, where AUT is the authorization service code and 1234567 is the maximum number of deposits for purchases: AUT1234567 |
Daily |
Schedule Deposits Submits the deposit processing job. You can use the Parameter field to generate deposit transactions for a specific authorization service and/or define the maximum number of deposits to process for purchases. 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. This function requires you to specify a company when you set up the periodic process. |
|
|
|
|
The AUTO_DEP 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. |
SCVREV |
PFR0077 |
|
Daily |
Stored Value Card Reversal Processes stored value card reversal trigger records (File type AHR) that are in a ready (R) status. See Transmitting Activation and Reversal Transactions (SSVC). |
SLSSMOT |
PFSLSSUMOT |
Date, in MMDDYY format |
Daily |
Sales Journal Summary by Order Type Generates the Sales Journal Summary by Order Type for the date specified in the parameter. If no date is specified, generates the report for the previous date. |
SLSUPLD |
PFR0109 |
|
As needed |
Sales Associate Upload Upload a Sales Associate file to create records in the Salesman table. See Salesman Associate Upload. |
STOP_EC |
ECX0243 |
|
Daily |
Stop E-Commerce Order Cleanup Stops the ORDER_CLN job. |
STRASYN |
MSSTRASYNC |
|
Daily |
Start Asyncs If the asyncs are currently Inactive, this periodic function calls the Controlling Data Queue (CNTL_ASYNC) in Background Job Control (MBJC) and starts the background jobs. This periodic function performs the same updates as selecting Start for the controlling data queue to start the background jobs. |
STRIJCT |
ILSTRGENER |
The Process ID of the integration layer process you wish to start. |
As needed |
Start IJCT Process Passed Starts the integration layer process whose Process ID is defined in the Parameter field. Example: If you define ITEM_OUT in the Parameter field, this periodic function starts the ITEM_OUT integration layer process. |
STRT_EC |
ECX0242 |
|
Daily |
Start E-Commerce Order Cleanup Starts the ORDER_CLN job. See Integration Layer Processes. |
SUSPEND |
OER0756 |
|
Daily |
Suspended Orders List |
SVCACT |
PFR0076 |
|
Daily |
Stored Value Card Activation Processes stored value card activation trigger records (File type SVC) that are in a ready (R) status. See Transmitting Activation and Reversal Transactions (SSVC). |
SYNCUSR |
PFRSYNUSR |
|
Daily |
Synchronize Users from IDCS or OCI IAM Create user records in Order Administration based on user records in IDCS or OCI IAM, using the settings defined for the DEFAULTCSU user. See User Configuration in the Administration Guide for more information. Note: You should schedule the function to run daily, or include the function in multiple periodic processes to run more than once a day, in order to keep user records in Order Administration synchronized with IDCS or OCI IAM. |
THRESHD |
PFTHRESHMO |
|
Daily |
Threshold Monitor
See Working with Threshold Values (WTHR). Note: This periodic function performs updates similar to the ORDSUM periodic function. |
TICKLER |
PFR0072 |
|
Daily |
Evaluate Create/Resolve Ticklers Evaluates the:
|
UPACSTP |
PFR0134 |
CSACST |
As needed |
UPACSTP Upload ACS Tape File Uploads an ACS Tape file named CSACST from the folder defined in the CWDIRECTCP_UPLOAD_DIRECTORY property to the ACS Tape table (CSACST). You must use the Process Address Changes (PACS) menu option to process the records in the ACS Tape table. See Work with File Uploads (WUPL) and Loading Address Updates. |
UPCATRQ |
PFR0134 |
IXCRIN |
As needed |
UPCATRQ Upload Catalog Request File Uploads a Catalog Request file named IXCRIN from the folder defined in the CWDIRECTCP_UPLOAD_DIRECTORY property to the Catalog Request Interface table (IXCRIN). You must use the Work with Catalog Request Interface (WCRU) menu option to process the records in the Catalog Request Interface table. See Work with File Uploads (WUPL) and Working with the Catalog Request Interface (WCRU). |
UPCSTPG |
PFR0134 |
CUSTPGEUP |
As needed |
UPCSTPG Upload Customer Price Group Exclusion File Uploads a Customer Price Group Exclusion file named CUSTPGEUP from the folder defined in the CWDIRECTCP_UPLOAD_DIRECTORY property to the Customer Price Group SKU Exclusion Upload table (CUSTPGEUP). You must run the CPGIXUP Customer Price Group SKU Exclusion Upload periodic function (Program name PFRCPGEXUP) to process the records in the Customer Price Group SKU Exclusion Upload table. See Work with File Uploads (WUPL) and Customer Price Group SKU Exclusion Upload. |
UPLSDTA |
PFR0094 |
|
As needed |
Supporting Data Upload Creates supporting data records based on the information in the Supporting Data Upload table. See Importing Item-Related Supporting Data (SDUP) for more information. |
UMPBSTP |
PFR0134 |
CSMBST |
As needed |
UPMBSTP Upload MBS Tape file Uploads an MBS Tape file named CSMBST from the folder defined in the CWDIRECTCP_UPLOAD_DIRECTORY property to the MBS Tape table (CSMBST). You must use the Process Address Changes (PACS) menu option to process the records in the MBS Tape table. See Work with File Uploads (WUPL) and Loading Address Updates. |
UPPOLAY |
PFR0134 |
POLAYR |
As needed |
UPPOLAY Upload PO Layering File Uploads a PO Layering file named POLAYR from the folder defined in the CWDIRECTCP_UPLOAD_DIRECTORY property to the PO Layering table (POLAYR) and then uses the newly uploaded records to update the due date and backorder quantity for order lines on backorder. See Work with File Uploads (WUPL) and Purchase Order Layering. |
UPPRCCD |
PFR0134 |
PRICECDUPLOAD |
As needed |
UPPRCCD Upload Price Code File Uploads a Price Code file named PRICECDUPLOAD from the folder defined in the CWDIRECTCP_UPLOAD_DIRECTORY property to the Price Code Upload Table (PriceCdUpload). You must run the PCUPLD Price Code Upload periodic function (Program name PFPRCCODUP) to process the records in the Price Code Upload table. |
UPPROMO |
PFR0134 |
PRMUPLD |
As needed |
UPPROMO Upload Promotion Code File Uploads a Promotion file named PRMUPLD from the folder defined in the CWDIRECTCP_UPLOAD_DIRECTORY property to the Promotion Upload Table (PRMUPLD). You must run the PRMOUPL Create or Delete Promotions periodic function (Program name PRMOUPL) or use the Work with Promotion Values (WPRO) menu option to process the records in the Promotion Upload table. |
UPRITEM |
PFR0134 |
RIIUPP |
As needed |
UPRITEM Upload Retail Item File Uploads a Retail Integration Item file named RIIUPP from the folder defined in the CWDIRECTCP_UPLOAD_DIRECTORY property to the RI Item Upload Table (RIIUPP). You must run the RIUPLD Retail Integration Item Upload periodic function (Program name PFR0084) or use the Work with Retail Integration Item Upload (RIIU) menu option to process the records in the RI Item Upload table. See Work with File Uploads (WUPL) and Working with Retail Integration Item Upload (RIIU). |
UPSRCCD |
PFR0134 |
IXSRCE |
As needed |
UPSRCCD Upload Source Code File Uploads a Source Code file named IXSRCE from the folder defined in the CWDIRECTCP_UPLOAD_DIRECTORY property to the Source Upload Table (IXSRCE). You must use the Work with Source Code Upload (WSRW) menu option to process the records in the Source Code Work table. See Work with File Uploads (WUPL) and Generating Source Codes Using the Source Upload Table (WSRW). |
UTSTSRP |
UTSTSRPT |
|
As needed |
Managed Services Report Generates the Managed Services report, used by Oracle staff to manage system processing. |
UPVENDR |
PFR0134 |
VNDUPL |
As needed |
UPVENDR Upload Vendor File Uploads a Vendor file named VNDUPL from the folder defined in the CWDIRECTCP_UPLOAD_DIRECTORY property to the Vendor Upload Table (VNDUPL). You must run the VNDUPLD Vendor Upload periodic function (Program name PFR0086) or use the Submit Vendor Upload (LVUP) menu option to process the records in the Vendor Upload table. |
WEEKCLR |
MSR0575 |
|
Weekly |
Weekly Clear Clears week-to-date (WTD) fields in the SKU Offer Page table (INSKOP). |
YEARCLR or CLR_YR |
MSR0577 |
|
Yearly |
Clear Yearly Totals Clears (zeros) yearly (YTD) buckets in tables such as Flash Report table (FLFLSH). |
Customer Service (C/S) Periodic Functions
The table below lists the periodic functions associated with Customer Service processing. The Parameter column is populated only if the periodic function allows you to define an additional parameter. The Schedule column represents how often you should generally run the periodic function. Your business requirements may require a different schedule.
Function | Program or Class | Parameter | Schedule | Description |
---|---|---|---|---|
EFTSTA |
PfrEFTStat |
|
As needed (see notes) |
Request Payment Status Update for Pending Transactions in EFTConnect Checks the current status in EFTConnect of each order payment transaction record that is currently in SENT status, as this status indicates that Order Administration previously received a PENDING result code from EFTConnect for the transaction. The records can be in SENT status because the payment provider does not respond immediately to EFTConnect for a capture or refund message, but sends these updates to EFTConnect as they are available. When Order Administration receives a PENDING result code in an authorization reversal (VOID) response message from EFTConnect, the IL outbound record status will be changed to P (PENDING). Based on the status response received from EFTConnect for each transaction record, the periodic function updates the order payment transaction to:
Afterward, when you process deposits through SDEP:
Note:
|
OPENPP |
PFR0006 |
|
Monthly |
Open Prepaid Orders List Generates the Open Prepaid Order List. |
REAUTH |
PfrReauth |
|
Daily |
Reauthorize Expired Payment Authorizations This function submits reauthorization requests for expired authorizations, and processes updates based on whether the reauthorization is approved or declined. See Reauthorizing Expired Authorizations for more information. Oracle recommends that you schedule this function to run after the REVERSE periodic function. Also, it should not be scheduled to run during shipping. This job submits an active procedure. See Purge Active Procedures Across Users (MACX) for more information. Note: You need to select the Perform Reauthorization for Expired Authorizations (M61) system control value in order to use this function. |
REFCCCR |
PFR0115 |
|
Daily |
Process Credit Card Credit Refunds Process credit card credits with no limit on the amount to generate. The system generates a Credit Card Credit Register that identifies the amount, customer name, and order number of each credit processed. The system also produces either a Credit Card Credit Acknowledgement (if the Print Credit Card Credit Acknowledgements (C35) system control value is selected) or an email notification when the Credit Card Credit Acknowledgement E-Mail Program (H08) is set to CCCNOTF, (regardless of the setting of the Print Credit Card Credit Acknowledgments (C35) value) for each credit as appropriate; see When Does the System Generate an Email Notification? See Processing Refunds (MREF) for processing information. |
REFDUET |
CSR0986 |
|
Monthly |
Refund Due List by Type Generates the Refund Due List by Type. |
REFPROC |
CSR0533 |
|
Monthly |
Refunds Processed Generates the Processed Refund Register. |
REFSVCR |
PFR0118 |
|
Daily |
Process SVC Credit Refunds Process stored value card credits with no limit on the amount to generate. The system issues a new stored value card to the sold to customer for the refund amount. The system also:
You can then follow the normal process of activating, billing, and shipping the stored value card to the customer. See Generating Stored Value Card Refunds for an overview. |
REFWRO |
PFR0009 |
|
Monthly |
Refunds Written Off Writes off refunds and generates the Refund/Write Offs - Refund Checks report. See Working with Refunds, Writeoffs and Balances Due (WREF). |
RSTCONO |
CSRSTONORD |
|
Run when a problem is detected |
Reset Customer Sold To Amount On Order Resets 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. See Resetting Customer Sold To Amount On Order (RONO). Note: End all background async jobs so that the On order amount is not changed while the reset job recalculates the On order amount. |
UNACTSV |
PFR0075 |
|
Daily |
Unactivated Stored Value Cards Generates the Unactivated Stored Value Card Report. You can use this report to review any stored value cards that require attention because:
|
EMAILUD |
PFR0089 |
|
Daily |
Customer Email Status Updates Matches a record in the Customer Email Updates Table to a sold to customer and, if an exact match is found, updates the sold to customer’s Opt in/opt out field with the Email Status defined for the customer email updates record. Generates the Unmatched Email Status Report, which lists records in the Customer Email Updates table that were not matched to a sold to customer. See Receiving Customer Email Status Updates From an External System for an overview and the required setup. |
E-Commerce (EDC) Periodic Functions
The table below lists the periodic functions associated with E-Commerce processing. The Parameter column is populated only if the periodic function allows you to define an additional parameter. The Schedule column represents how often you should generally run the periodic function. Your business requirements may require a different schedule.
Function | Program or Class | Parameter | Schedule | Description |
---|---|---|---|---|
ECOMINV |
ECR0389 |
|
Daily |
E-Commerce Item XRef All Items Downloads all items that contain a long SKU style number to the EC SKU Retail XRef table and EComm SKU Extract table. |
ECOMNEW |
ECR0390 |
|
Daily |
E-Commerce Item XRef New Items Downloads new items that contain a long SKU style number to the EC SKU Retail XRef table and EComm SKU Extract table. |
ECSHCNF |
ECR0154 |
See description. |
Daily |
Shipment Confirmation Emails Sends shipment confirmation emails. See Sending Internet Order Ship Confirmation (ESCF). 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. Optionally, enter a parameter of the days prior to the current date for the function to use when selecting shipment confirmation emails, based on invoice date. Example: The current date is January 21. In order to generate shipment confirmation emails for orders billed on January 19, set the parameter to 2. Note: The new parameter also controls the generation of return confirmation emails. |
Fulfillment (FUL) Periodic Functions
The table below lists the periodic functions associated with Fulfillment processing. The Parameter column is populated only if the periodic function allows you to define an additional parameter. The Schedule column represents how often you should generally run the periodic function. Your business requirements may require a different schedule.
Function | Program or Class | Parameter | Schedule | Description |
---|---|---|---|---|
Description of the pick slip generation template you wish to run |
PFR0107 |
The Description of the pick slip generation template you wish to run. Note: The Parameter must match the Description defined for the pick slip generation template. For example, if the description of the pick slip generation template is ORDER #, the parameter must also be ORDER # and not ORDER#. |
Daily |
Scheduled Pick Slip Generation Runs pick slip generation using the pick slip generation template specified in the Parameter field. See Scheduling Pick Slip Generation for more information. |
CARRYOV |
PFR0033 |
|
|
Carryover Report Prints the Carryover Report. |
LOBSTAT |
PFR0034 |
|
Daily |
Reset Line of Business Stats Updates line of business order queue statistics. |
RESRVBO |
FLR0804 |
|
Daily |
Reserve Backorders Evaluates backorders by searching for any item warehouse that has a backorder quantity greater than 1 and whose on-hand quantity - reserved quantity is greater than 0. Will try to reserve the order detail line (as long as a cancel date does not exist). See Working with the EBO_ASYNC Job. If an order line on backorder is reserved, the system removes any pick slip preparation from the order and then reevaluates the order for pick slip preparation; see Preparing Orders for Pick Slip Generation. |
RSTPICK |
PFR0111 |
|
As needed |
Reset Pick Control Resets 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. You can also perform the same updates using the Reset Allocation Quantities (MRPC) menu option. |
STRCDC |
ILStrCDC |
|
Daily |
Start External Drop Ship Integration Starts the CDC Async job used to process transactions between Order Orchestration’s Drop Ship Manager and Order Administration in the Order Orchestration Drop Ship Integration. |
ENDCDC |
ILEndCDC |
|
Daily |
End External Drop Ship Integration Ends the CDC Async job used to process transactions between Order Orchestration’s Drop Ship Manager and Order Administration in the Order Orchestration Drop Ship Integration. |
BILLUPD |
Set the class name to: oracle.retail.oms.services.job.functions.BillingUpdateBatchJob |
Number, up to 3 positions, to indicate the number of seconds to wait between processing; if no number is specified, an interval of 60 seconds defaults |
Daily |
Delay Billing Updates Submits the BILLUPD job, which processes deferred billing updates for records in the Invoice Header table whose Process Date field is 0. You must run the Delay Billing Updates Process if you select the Delay Billing Updates (K85) system control value; see this system control value for more information. Also, see Batch Billing Updates for a table that lists the billing updates that are deferred until you run the Delay Billing Updates Process. Note: You can also submit the Delay Billing Updates Process using the BILL_UPD Billing Updates integration layer job. When this job is active, at defined intervals the job processes deferred billing updates for records in the Invoice Header table whose Process Date field is 0. The Outbound delay time defined for the BILL_UPD integration layer job defines how often the job processes the deferred billing updates. Example: If the Outbound delay time is 60, the system looks for deferred billing updates to process every 60 seconds. |
BATSTPC |
PFSTPBATCH |
As needed |
Stop Batch Billing Update Job for All Companies Stops the BILLUPD job for all companies. The Company Parameter should be unselected. |
|
BATSTPA |
PFSTPBATCH |
As needed |
Stop Batch Billing Update Job Company Specific Stops the BILLUPD job for the specified company. The Company Parameter should be selected. |
|
PICKRFH |
PFR0103 |
|
Daily |
Pick Gen Refresh Submits a process that evaluates orders for pick slip preparation, and if eligible: 1. Removes any pick slip preparation that may have already occurred for the order; see Removing Pick Slip Preparation from an Order for the updates that are performed. 2. Applies pick slip preparation to the order; see Applying Pick Slip Preparation to an Order for the updates that are performed. See Batch Pick Slip Preparation for additional details. |
Interface (INT) Periodic Functions to Start and Stop IJCT Jobs
The table below lists the periodic functions provided for starting and stopping IJCT jobs on a regular basis. Each “start” program starts the related IJCT job if it is currently inactive, while each “end” job ends the job if it is currently active. You would normally schedule these jobs to start and stop on a daily basis, but this schedule may vary based on your business requirements.
See Working with Integration Layer Processes (IJCT) for more information on each IJCT job.
Start Function | Start Program | End Function | End Program |
---|---|---|---|
BROKER: Generates Order Orchestration fulfillment requests, inquiry requests, and update requests, and receives responses. |
|||
STRBROK |
ILSTRBROKR |
ENDBROK |
ILENDBROKR |
BROKER_ORD: Generates Order Orchestration requests for new orders and cancellations, sends status updates, and receives responses. |
|||
STRBRO |
ILSTRTBROK |
ENDBRO |
ILENDBROK |
CUST_OUT: Generates an outbound message for each customer that you create, change, or delete. |
|||
STRCSTD |
LSTRCSTOT |
ENDCSTD |
ILENDCSTOT |
EMAIL: Receives email messages and creates Correspondence History and Correspondence History Detail records. |
|||
STREML |
ILSTREMLIN |
ENDEML |
ILENDEMLIN |
INV_INQURY: Receives a request for inventory availability on a specific item/SKU and generates a response. |
|||
STINVIQ |
ILSTRINVIQ |
ENINVIQ |
ILENDINVIQ |
INV_DOWNLD: Sends inventory availability information to another system. |
|||
STRINVD |
ILSTRINVDN |
ENDINVD |
ILENDINVDN |
INVOIC_OUT: Sends invoice information to another system. |
|||
STRINVO |
ILSTRINVOT |
ENDINVO |
ILENDINVOT |
INVTRAN_IN: Receives inventory transactions and updates inventory information, such as in the Item Location and Item Warehouse tables. |
|||
STRITRN |
ILSTRINVIN |
ENDITRN |
ILENDINVIN |
ITEM_OUT: Sends item and SKU information to another system. |
|||
STRITEM |
ILSTRITMOT |
ENDITEM |
ILENDITMOT |
ORDER_IN: Receives new orders through a generic order interface and optionally generates detailed or simple acknowledgments, as indicated by the inbound order message. |
|||
STRORDR |
ILSTRORDIN |
ENDORDR |
ILENDORDIN |
PICK_OUT: Sends a pick slip message for each generated or voided pick slip. |
|||
STRPICK |
ILStrPickO |
ENDPICK |
ILEndPickO |
PO_OUT: Sends purchase order information to an external system. |
|||
STRPOOU |
ILStrPOOut |
ENDPOOU |
ILEndPOOut |
RETURN_OUT: Sends customer return information to an external system. |
|||
STRRTO |
ILStrRtOut |
ENDRTO |
ILEndRtOut |
SVC_REVRSL: Sends stored value card reversal transactions to the service bureau via an integration layer process (IJCT) and receives responses. |
|||
STRSVR |
ILStrSVCRv |
ENDSVR |
ILEndSVCRv |
VENDOR_OUT: Sends vendor information to another system. |
|||
STRVEND |
ILSTRVNDOT |
ENDVEND |
ILENDVNDOT |
Additional Interface (INT) Periodic Functions
The table below lists additional periodic functions associated with integration layer processing besides those listed above under Interface (INT) Periodic Functions to Start and Stop IJCT Jobs. The Parameter column is populated only if the periodic function allows you to define an additional parameter. The Schedule column represents how often you should generally run the periodic function. Your business requirements may require a different schedule.
Function | Program or Class | Parameter | Schedule | Description |
---|---|---|---|---|
ACTPO |
PFR0205 |
|
As needed |
Submit Active PO Order Lines to Order Orchestration and Generate RICS Backorder Message Requests inventory availability, submits existing active PO order lines to Order Orchestration for fulfillment and generates the backorder quantity update notification message to RICS. For more information: See Enterprise Order Integration (Future Receipts and Active PO/Pre-Order Processing) for background. |
CAINV |
PFCAINV |
|
As needed |
ChannelAdvisor Inventory Upload Generates a file of current inventory levels for send to ChannelAdvisor. See Sending Current Inventory Information to ChannelAdvisor for an overview. |
CAORDUP |
PFCAOUP |
|
As needed |
ChannelAdvisor Order Upload Sends ChannelAdvisor a request for new orders and creates orders based on the information in the order response message. See Importing Orders from ChannelAdvisor for an overview. |
CAPRICE |
PFCAPRICE |
|
|
ChannelAdvisor Price Upload Generates a file of current pricing for items sold through the ChannelAdvisor integration. See Sending Current Prices to ChannelAdvisor for an overview. |
CAREQAC |
PFRCAREQS |
Enter connection information using the following format: REQUEST ChannelAdvisor_AccountID ChannelAdvisor_ProfileID For example: STATUS cb12d3b4-f123-1234-1234-12a3c456e7d8 12345678 |
As needed |
ChannelAdvisor Request Access Run this periodic function to request access to ChannelAdvisor for the specified AccountID. Before running this periodic function, enter connection information in the Parameter field using the following format: REQUEST ChannelAdvisor_AccountID ChannelAdvisor_ProfileID For example: STATUS ab12d3b4-f123-1234-1234-12a3c456e7d8 12345678 Note: This periodic function should be run one time for each account as part of initial setup of the ChannelAdvisor integration. In addition, once you establish a connection with ChannelAdvisor, you can change the Parameter field to the following format: STATUS ChannelAdvisor_AccountID ChannelAdvisor_ProfileID For example: STATUS ab12d3b4-f123-1234-1234-12a3c456e7d8 12345678 Run the periodic function to write information to the Application log about the status of the access to ChannelAdvisor. See ChannelAdvisor Setup. |
CASHIP |
PFCASHIP |
|
As needed |
ChannelAdvisor Ship Confirmation Upload Sends shipment confirmation messages to Channel Advisor. See Sending Shipment Confirmations to ChannelAdvisor for an overview. |
CPGIXUP |
PFRCPGEXUP |
|
Daily |
Customer Price Group SKU Exclusion Upload Submits the Customer Price Group SKU Exclusion Upload Process to upload customer price group item exclusion information from an external system to create, update, or delete records in the Customer Price Group SKU Exclusion table. See Customer Price Group SKU Exclusion Upload for an overview. |
IHDWOIT |
PFR0106 |
|
As needed |
Invoice Download Comparison Matches invoices created for the previous day to records in the IL Trigger table with a record type of IHD. If an invoice exists without a corresponding IHD trigger, the system creates an Add IHD trigger record and writes a message similar to the following in the Trace log: Periodic Function IHDWOIT may have created a IHD WOIT Transaction for Company#:7 Order # : 2844 Invoice #: 573. See Generic Invoice Download API for an overview on the Invoice Download process and the required setup in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) |
IMPSTLC |
PFR0122 |
Example: If the parameter is set to NPOS, the periodic function imports location records for system POS in Order Orchestration, and leaves the Ship for pickup flag for each imported location unselected. |
As needed |
Import Store Cross Reference Locations through Order Orchestration’s Discovery Web Service Uses Order Orchestration’s discovery web service to request information on all existing location associated with a specified system in Order Orchestration, and create Store Cross Reference records for locations if they do not already exist. See Importing Store Cross Reference Locations through Order Orchestration’s Discovery Web Service. |
INVOVRL |
PFINVOVR |
|
Daily |
Processes an inventory upload file if it is found in the directory defined in the CWDIRECTCP_UPLOAD_DIRECTORY property or uploaded through the File Storage API, updating the Item Location record with the on-hand quantity, or creating it if the Item Warehouse exists. See Batch Inventory Overlay Upload for more information. |
INVDWNL |
ILR0081 |
|
Weekly |
Inventory Download Creates inventory download triggers (File type ITW) for an item/SKU if:
See Generic Inventory Download API in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1). |
OBPROD |
PFR0127 |
|
As needed |
Order Orchestration Product Output File Generates a Product output file for import into Order Orchestration. This file contains product information for a specified company. See Order Orchestration Product Output File for details. |
OBPRLOC |
PFR0128 |
|
As needed |
Order Orchestration Product Location Output File Generates a Product Location output file for import into Order Orchestration. This file contains product location information for a specified company. See Order Orchestration Product Location Output File for details. |
OBINCIN |
PFR0129 |
|
As needed |
Order Orchestration Incremental Inventory Output File Generates an Incremental Inventory output file for import into Order Orchestration. This file contains inventory updates for a specified company. See Oracle Retail Order Orchestration Incremental Inventory Output File for details. |
OCDSFA |
PFR0203 |
|
Daily |
OCDS Import Future Availability Updates the Active PO flag for active PO items, and updates item warehouse quantities to support identifying when to release eligible active PO items to Order Orchestration for fulfillment. See Enterprise Order Integration (Future Receipts and Active PO/Pre-Order Processing) for background. |
OCDSITM |
PFR0202 |
FULL or INCREMENTAL |
As needed |
OCDS Import Product Data Generates requests to Omnichannel Cloud Data Service OCDS) for item-related data, including merchandise hierarchy, items, item prices, and item images. See Importing Enterprise Foundation Data through Omnichannel Cloud Data Service (OCDS) for an overview, and see OCDSITM Periodic Function for information on scheduling options. This function also deletes Enterprise Data History records older than the OCDS_JOB_HISTORY_RETENTION_DAYS defined through Working with Admin Properties. These records track activity for the OCDSITM and OCDSFA periodic functions. You can review history at the Enterprise Data Import History screen in Modern View. |
PCUPLD |
PFPRCCODUP |
|
Daily |
Price Code Upload Submits the Price Code Upload Process to upload price code information from an external system to create, update, or delete records in the Price Code, Price Code Customer, and Price Code Details tables. See Price Code Upload for an overview. |
PURGIJT |
ILR0026 |
|
Weekly |
Purge IJCT Trigger Records Purges IL Outbound Trigger records older than the number of days specified in the Outbound Interface Trigger File Purge Days (I14) system control value, using the following calculation: Last processed date is less than the current system date by the number of purge days and Status is X. |
RCVRTLG |
PFR0207 |
The name of each RTLOG log file to recover, separated by double pipes |
As needed |
Recover Sales Audit RTLOG to Object Storage Retrieves the RTLOG file specified in the Parameter for this periodic function, and resubmits the file to object storage for the Sales Audit Module of the Oracle Retail Merchandising Foundation Cloud Service, using the same process that was used in the SNDRTLG function. Use when? You would resubmit an RTLOG file if the SNDRTLG periodic function did not succeed when submitting the file to object storage for the Sales Audit Module, although no error was returned to the POST or PUT request messages. You would not use this function when an error was returned to the SNDRTLG function, because in this case the file is not saved to the FILE_STORAGE table. Instead, you should correct whatever caused the SNDRTLG to fail, such as an authentication issue, and then submit SNDRTLG again. Determining the file name to resubmit: The SNDRTLG periodic function saves each RTLOG file to the OMS-SALES-AUDIT container of the FILE_STORAGE table. You can use the getFiles web service request to request a list of records in the table, and identify the file name based on when the FILE_STORAGE record was created. Parameter format: Use the Parameter field for the periodic function to indicate the name of the RTLOG file that requires recovery. For example: RTLOG_1234567890_23456789012345678.zip. For more information: See:
|
REVXAHP |
PFREVXAHP |
Stored value card pay type code that uses the External Payment Service |
Daily |
Reverse Partial Auth for External Payment Service Generates SVC reversal request messages for the external payment service, provided the parameter specified is a stored value card pay type code that is configured to use the external payment service. See Stored Value Card Reversal with the External Payment Service in Stored Value Card Authorization Reversal for an overview. |
RIPRCUP |
PFRRIPRCUP |
|
Daily |
Pricing Upload Submits the Pricing Upload Process to upload records from the Pricing Upload table to the Special Pricing by Source table and QPM Detail table. See Pricing Upload Interface for an overview. |
RLTCSUP |
PFRBCC |
|
As needed |
Customer Upload to Oracle Retail Customer Engagement Sends all Order Administration sold to customers, excluding any sold to customers whose Ghost field in the Customer Sold To table is Y, to Oracle Retail Customer Engagement using the batch Customer Engagement Add or Update Customer Message. See Customer Engagement Batch Customer Conversion. Note that the ORCE File Service URL (M62) and ORCE Import Folder Path (M63)system control values must be specified for the company in order for this periodic function to run. |
RTLOG |
PFR0201 |
Store number in the Sales Audit module of the Oracle Retail Merchandising Foundation Cloud Service |
Daily |
Export Transactions to Sales Audit Module Exports sales and returns information to the Sales Audit module of the Oracle Retail Merchandising Foundation Cloud Service. Transaction information is collected in a temporary file throughout the day. The periodic function adds file header and footer information, deletes the temporary file, and creates a DAT file for the Sales Audit module. When integrating with Sales Audit module of the Oracle Retail Merchandising Foundation Cloud Service (Sales Audit module) 21.0 or above, you can use the SNDRTLG periodic function to submit the RTLOG file to object storage. See Integration with the Sales Audit Module of the Oracle Retail Merchandising Foundation Cloud Service. |
SLSUPLD |
PFR0109 |
|
Daily |
Upload Salesman Associates Submits the Salesman Associate Upload Process to upload salesman information from an external system to create or update records in the Salesman table. See Salesman Associate Upload for an overview and the required setup. |
SNDRTLG |
PFR0206 |
Store number in the Sales Audit module of the Oracle Retail Merchandising Foundation Cloud Service |
Daily |
Transmit Sales Audit RTLOG to Object Storage Retrieves the RTLOG file from the CWDIRECTCP_FTP_FOLDER, where the RTLOG periodic function placed it, and transmits the file to object storage. Object storage: Use of object storage is supported for the Sales Audit module of the Oracle Retail Merchandising Foundation Cloud Service (Sales Audit module) 21.0 and above. This function also saves a copy of the RTLOG file in the OMS-SALES-AUDIT container of the File Storage table. If this function fails to transit the file to file storage table, you can use the RCVRTLG periodic function to resubmit the file. See that periodic function for more information, and see Integration with the Sales Audit Module of the Oracle Retail Merchandising Foundation Cloud Service for background. |
STRUPLD |
PFR0110 |
|
Daily |
Upload Stores Submits the Store Upload Process to upload store information from an external system to create or update records in the Store Cross Reference table. See Store Upload for an overview and the required setup. |
SYNCRDB |
PFR0105 |
|
As needed |
Synchronize Remote Customers Submits unsynchronized customers to Oracle Retail Customer Engagement, using the Synchronize with remote DB field in the Customer Sold To table as a trigger. You would use this periodic function to support the interactive customer integration with Oracle Retail Customer Engagement. See Synchronizing Customer Information through a Periodic Function for more information. |
Inventory (INV) Periodic Functions
The table below lists the periodic functions associated with Inventory processing. The Parameter column is populated only if the periodic function allows you to define an additional parameter. The Schedule column represents how often you should generally run the periodic function. Your business requirements may require a different schedule.
Function | Program or Class | Parameter | Schedule | Description |
---|---|---|---|---|
CLROH99 |
PFRCLROH99 |
|
As needed |
Clear On Hand for Division 99 Allows you to clear the on-hand inventory for each warehouse whose Division is 99. The system clears the on-hand quantity for the warehouse in the Item Warehouse table and Item Location table. |
PFR0063 |
PFR0063 |
|
Daily |
Drop Ship On Hold Report Generates the Drop Ship Integration Items on Hold from Vendor report. |
PFR0064 |
PFR0064 |
|
Daily |
Drop Ship Revised Due Date Report Generates the Drop Ship Integration Items with Revised Due Date report. See Printing Drop Ship Reports (PDSR). |
PFR0065 |
PFR0065 |
|
Daily |
Drop Ship Pending Cancel Report Generates the Drop Ship Integration Items Pending Cancellation report. See Printing Drop Ship Reports (PDSR). |
PORST |
OER1018 |
|
As needed |
PO Reset Resets the open PO quantities in the Item Warehouse table based on purchase order detail lines that are open or held, or received into suspense or into a pending putaway warehouse location. |
RIUPLD |
PFR0084 |
|
As needed |
Retail Integration Item Upload Submits the retail integration item upload process. Once completed, if the Create Generic Item Download Trigger Records (I15) system control value is selected, the system submits the secondary job RISECU to create item download triggers. See Working with Retail Integration Item Upload (RIIU) and RI Item Upload Process. |
VNDUPLD |
PFR0086 |
|
As needed |
Vendor Upload Submits the vendor upload process. |
Order Entry (O/E) Periodic Functions
The table below lists the periodic functions associated with Order Entry processing. The Parameter column is populated only if the periodic function allows you to define an additional parameter. The Schedule column represents how often you should generally run the periodic function. Your business requirements may require a different schedule.
Function | Program or Class | Parameter | Schedule | Description |
---|---|---|---|---|
PURGEPR |
PFR0112 |
The number of days from the promotion end date that a completed promotion will be eligible for purge. Example: promo1 end date = 1/15/12 promo2 end date = 3/18/12 purge days = 15 If you run this periodic function on 3/20/12, the system deletes any promotion with an end date less than 3/5/12. In this example, the system deletes promo1 and retains promo2. |
As needed |
Purge Promotions When you run this periodic function, the system uses the current date - the purge days parameter to determine the promotions to purge. Any promotions whose end date is equal to or earlier than the calculated purge date will be purged. If the Parameter is set to 0, the system does not purge any promotions. The system purges promotions from the following tables:
|
SUMVIA |
OER1024 |
|
Daily |
Update Ship Via/Item Summary Runs a batch job to collect information on the current number of available order lines for each item/ship via combination in your company and populates the Ship Via Item Summary Header (OESVIH) table and Ship Via Item Summary Detail (OESVID) table. You can review the total open orders, shippable units, and oldest arrival dates for each item with a particular ship via assigned using the Ship Via/Item Inquiry (SVII) menu option. |
Properties
Properties define system-wide configuration settings for Order Administration.
-
The Working with Customer Properties (PROP) menu option contains properties that a user would update, such as system-wide configuration settings for forms, integrations, and system settings.
-
The Working with Admin Properties (CPRP) menu option contains properties that an administrator would update, such as system-wide configuration settings for email, logging, system and job monitoring, printing, and system settings.
Note:
If you update a property in the Working with Customer Properties (PROP) or Working with Admin Properties (CPRP) menu option, most of your updates take effect immediately.
Regional Settings
Regionalization is the process of creating software that is able to be translated more easily. Changes to the code are not specific to any particular market. Order Administration supports multiple decimal and thousand separators as well as multiple date formats.
This topic describes the configuration settings and features of the software that ensure that the base application can handle regionalization.
In this topic:
For more information: See Multi Currency by Offer (E03) for more information on how to configure the system to take orders in more than one currency.
Recommended Screen Size
In order to align screens correctly, the default size of the application window has been adjusted to 800 x 1200. Displaying the application in this window size is recommended for most screens except the Streamlined Order Inquiry (DORI) menu option.
Defining Localization Defaults During Installation
During installation, the system:
-
Sets the base locale for the application. See Setting the Default Locale for more information.
-
Prompts for the default date format for the application. See Setting the Default Date Format for more information.
-
Prompts for the base decimal separator and thousand separator for numeric fields in the application, such as price and weight. See Setting the Default Decimal and Thousand Separator Formats for more information.
-
Assigns the default locale and default date format to the admin user created during installation.
You can reset or override these defaults, as described below.
Setting the Default Locale
During installation, the system:
-
Stores the default locale in the DEFAULT_LOCALE property. When you create a new user or company, the system assigns the default locale to the user or company by default.
-
Defaults this locale to the Locale field in the Company table for the companies delivered with Order Administration.
-
Defaults this locale to the admin user that is created during installation.
Overriding the default locale: You can change the locale for users through Work with Users (WUSR), and you can change the locale for companies through Work with Companies (WCMP).
You can change the DEFAULT_LOCALE property through Work with Properties (PROP).
Note:
If any content is not supported in the user’s selected locale, the screen displays the English text.
Where are Locale Settings Applied?
Company locale: The locale specified for the company controls the language on generated reports and emails.
The company locale also controls the date and number formats available for use on reports generated through Oracle Analytics Cloud. See Oracle Analytics Cloud Date and Separator Formats.
User locale: The locale specified for the user controls the language for screen titles, field names, messages on screens (such as confirmation that a record has changed), and the labels of options available on screens.
The locale does not control:
-
The content of data fields, such as customer or vendor name or address
-
The descriptions of items and other data
-
The descriptions of menu options or of periodic functions or processes, although you can populate this seed data to your chosen locale at initial installation; contact your Oracle representative for more information
-
The contents of the online help or other documentation
-
The descriptions of menus
Supported Locales
Order Administration supports the following locales for companies and users:
-
English
-
French
-
German
-
Italian
-
Spanish
When the locale is changed for a user, it is necessary for the user to log off and then log back in, in order for the locale change to take effect.
Additional Localized Content
The following content can also be set to the language of the selected locale:
-
System Control Value names (Description field)
-
Secured Feature names (Description field)
-
Menu names (Description field; system-delivered menus only)
-
Menu Option names (Description field)
-
Match Code field names
-
Integration Layer Process names (Description field)
-
Order Hold Reason descriptions
-
Periodic Function titles (Description field; system-delivered functions only)
-
Asynchronous Job Control titles (Description field)
-
Inventory Transaction Code titles (Description field)
-
Application Area names (Description field)
-
Application Group Descriptions
-
Tickler Event names (Description field)
-
Order Line Activity names (Description field)
Note:
Updating this content will overwrite any custom entries, such as the names of periodic functions or order hold reason code descriptions.
Contact your Oracle representative for information on how to localize this content after initial installation.
Setting the Default Date Format
During installation, the system prompts for the default date format of Order Administration. The system:
-
Stores the default date format in the DEFAULT_DATE_FORMAT property. When you create a new user or company, this date format defaults.
-
Defaults this date format to the Date format field in the Company table for the companies delivered with Order Administration.
-
Defaults this date format to the admin user that is created during installation.
Note:
Regardless of the date format displayed on screens and reports, dates are stored in the database in CYYMMDD format.
Overriding the default date format: You can change the date format for users through Work with Users (WUSR), and you can change the date format for companies through Work with Companies (WCMP).
You can change the DEFAULT_DATE_FORMAT property through Work with Properties (PROP).
Note:
In order to have a consistent date format on all reports, the DEFAULT_DATE_FORMAT property and the company setting should be the same.
Where are Date Formats Applied?
Date Formats on Reports, Forms, and Emails
Company date format: Emails, reports and forms that are not generated using Oracle Analytics Cloud, display the date in the date format defined for the company.
Note:
Reports that are not associated with a company display the date in the format from DEFAULT_DATE_FORMAT property.
Oracle Analytics Cloud Date Formats
Reports that are generated using Oracle Analytics Cloud do not use the Date Format defined for the company; instead, they use the format defined in Oracle Analytics Cloud Date and Separator Format for the current company where the report is generated. See Reports and Forms Generated through Oracle Analytics Cloud and Oracle Analytics Cloud Date and Separator Formats for more information.
Date Formats on Screens
User date format: Unless as noted below, dates displayed on screens are in the date format defined for the user. This includes the dates on the Open, Held Order Recap Dollars pie charts and Order Statistics.
Note:
When you are manually entering a date on a screen, such as in a scan field, certain screens in the application require you to include forward slashes in the date. For example, if the Date Format defined for your user ID is MMDDYY, you need to manually enter the date as MM/DD/YY on the screen, such as 12/25/16 and not 122516. If you do not include the forward slashes, the system displays an error message indicating the valid date format and that slashes are required.
Company date format: The expected ship date included in the backorder card message on the Display Order History screen, indicating when a backorder card was generated for the order, is in the format defined for the company, so that the date format in the message matches the date format included on the backorder card/email.
Date Entries in System Control Values
User date format: Date entries in system control values, such as the Tax Inclusive Cutoff Date (E79), are in the date format defined for the user.
Date Format for User-Entered Dates
When a user enters a date in a message or text field, such as an order message or tickler note, the system stores and displays the date in the format it was entered. It is treated as text.
Date Formats in APIs
Dates in APIs do not use the format defined for the user or company. See each specific XML message in XML Messages for more information on the date format for each message.
Date Formats in Uploads
Dates in uploads do not use the format defined for the user or company. See each specific upload in Work with File Uploads (WUPL) for more information on the date format for each upload.
Calendar Widget
When you select a date from the calendar widget, the date is in the format defined for the user.
Setting the Default Decimal and Thousand Separator Formats
During installation, the system prompts for the following values to determine the default decimal and thousand separator of Order Administration.
-
Default decimal separator: The character format used to indicate the decimal place in a number. The system stores the default decimal separator in the DECIMAL_SEPARATOR property. This property is used for any numeric field that contains a decimal, such as price, cost, and weight.
-
Default thousand separator: The character format used to separate groups of thousands. The system stores the default thousand separator in the THOUSAND_SEPARATOR property. This property is primarily used on reports and is not entered by a user.
You cannot override these properties at the company or user level.
Note:
The above properties do not apply to reports generated through Oracle Analytics Cloud, as these reports use the BI Date and Separator Format defined for the company. See Reports and Forms Generated through Oracle Analytics Cloud and Oracle Analytics Cloud Date and Separator Formats for more information.
Supported Thousand and Decimal Separator Formats
Possible settings for the DECIMAL_SEPARATOR and THOUSAND_SEPARATOR properties are listed below.
Default Thousand Separator | Default Decimal Separator | Results |
---|---|---|
, (comma) |
. (period) |
4,294,967,295.00 |
. (period) |
, (comma) |
4.294.967.295,00 |
Where are Number Formats Applied?
Number Format on Home Screen
Default number format: The Home screen displays numbers using the characters defined in the DECIMAL_SEPARATOR and THOUSAND_SEPARATOR properties.
Number Format in Menu Options
Default number format: Screens in menu options display numbers using the characters defined in the DECIMAL_SEPARATOR and THOUSAND_SEPARATOR properties.
Number Format on My Jobs, My Docs, My Forms
Default number format: The Job Management (My Jobs), Document Management (My Docs), and Forms Management (My Forms) screens display numbers using the characters defined in the DECIMAL_SEPARATOR and THOUSAND_SEPARATOR properties.
Number Format of User Entered Numbers
Default number format: When a user enters a number, the correct decimal separator must be used and the thousand separator should not be entered since it is implied.
Example: To enter the number one thousand eleven and fifty cents:
-
if the default decimal separator is . (period), enter 1011.50
-
if the default decimal separator is , (comma), enter 1011,50
Number Format on Reports, Forms, and Emails
Default number format: Emails, reports and forms that are not generated using Oracle Analytics Cloud display numbers using the characters defined in the DECIMAL_SEPARATOR and THOUSAND_SEPARATOR properties.
Oracle Analytics Cloud format: Reports and forms generated using Oracle Analytics Cloud use the number format defined in Oracle Analytics Cloud for the locale in the Company table.
Number Format in APIs
Numbers in APIs do not use the characters defined in the DECIMAL_SEPARATOR and THOUSAND_SEPARATOR properties. See each specific XML message in XML Messages for more information on the number format used in each message.
Number Format in Uploads
Numbers in uploads do not use the characters defined in the DECIMAL_SEPARATOR and THOUSAND_SEPARATOR properties. See each specific upload in Work with File Uploads (WUPL) for more information on the number format used for each upload.
Reports and Forms Generated through Oracle Analytics Cloud
The following reports are generated through Oracle Analytics Cloud, and use the Oracle Analytics Cloud Date and Separator Formats:
-
Backorder Card Notification (GBOC)
-
Campaign Performance Report (PCPR)
-
Carryover Report (PCOR)
-
Cart Batch Recap Report (WSPS)
-
Cart Bin Picking Report (WSPS)
-
Credit Card Credit Acknowledgement (MREF)
-
Credit Card Authorization Listing (WSPS, RPAA, MDSP)
-
Credit Card Credit Register (MREF)
-
Deposit History Detail (PDHD)
-
Drop Ship Integration Items reports (PDSR)
-
Exchange Reason Report (PERR)
-
Gift Acknowledgement in graphical format (WSPS, MDSP)
-
Held Order by Pay Type Report (PHOP)
-
Held Order by Reason Code Reports (PHOR)
-
Item Upload Error Report (RIIU)
-
On Hand by Warehouse (POHW)
-
Online Credit Card Authorization Listing (PATL or SATH)
-
Order Broker Aging Report (WOBR)
-
Order Cancellation List by Item (PBRI or WBPC)
-
Order Hold Detail Report (MASO)
-
Order Receipt (OIOM, DORI)
-
Order Type Summary by Delivery Report (PDTS)
-
Password Change Report (PUSA)
-
Pick Authorization Error Report (WSPS)
-
Pick Slip in graphical format (WSPS, MDSP)
-
Pick Unit Report (WSPS)
-
Picking Pullsheet (WSPS)
-
Price Code Upload Errors Report (PCUPLD periodic function)
-
Price Override Reason Reports (PROR)
-
Print Remote Order Errors (OEOM)
-
Product Performance Reports (PPPR)
-
Promotion Analysis Report (POPA)
-
Promotion Upload Error Records Report (WPRO)
-
Purchase Order in graphical format (MDSP, MPOE, MPRP)
-
Purged Order List (PURGEOR periodic function)
-
Refund Check (MREF)
-
Refund Check Register (MREF)
-
Refund Writeoff Register (MREF)
-
Reset Audit Log for Quantity On B/O (MRBO)
-
Reset Audit Log for Quantity On Hand (MRIW)
-
Reset Audit Log for Quantity Printed (MRPC)
-
Reset Audit Log for Quantity Reserved (MRQR)
-
Reset Audit Log for SKU Quantities (MRSO)
-
Return Reason Report (PRRR)
-
Sales Journal (PROR)
-
Soldout Notification (MSON)
-
Stored Value Card Credit Register (MREF)
-
Tax Jurisdiction Report (PTJX)
-
User Authority Change Reports (PUSA)
Oracle Analytics Cloud Date and Separator Formats
The date and separator formats available for selection for a company are listed below. The possible date and separator formats are restricted based on the selected locales.
See Working with Companies (WCMP) for more information.
See Reports and Forms Generated through Oracle Analytics Cloud, above, for a listing of reports that use these formats.
Date and time formats for the following languages are supported in Oracle Analytics Cloud reports:
French
Format | Date | Decimal Separator | Thousand Separator | Sample Date | Sample Number | Sample Large Number |
---|---|---|---|---|---|---|
Belgium |
dd-mm-yyyy |
comma |
space |
3/7/2018 8:06 |
141.420,08 |
2.983.583,25 |
Canada |
yyyy-mm-dd |
comma |
space |
18-03-07 08:12:08 |
141 420,08 |
3 006 139,99 |
France |
dd/mm/yyy |
comma |
space |
07/03/18 14:22 PM |
121,25 |
3 006 139,99 |
Luxembourg |
dd/mm/yy |
comma |
space |
7/3/2018 14:24 |
121,25 |
3 006 139,99 |
Switzerland |
dd.mm.yy |
period |
Apostrophe |
07.03.18 14:26 |
121.25 |
3'006'139.99 |
English
Format | Date | Decimal Separator | Thousand Separator | Sample Date | Sample Number | Sample Large Number |
---|---|---|---|---|---|---|
Australia |
dd-mm-yyyy |
dot |
comma |
15-04-2018 00:44:42 |
256.53 |
2,983,583.25 |
Canada |
dd/mm/yy |
dot |
comma |
15/04/18 00:44:42 |
256.53 |
2,983,583.25 |
India |
dd/mm/yy |
dot |
comma |
4/15/2018 0:37 |
256.53 |
2,983,583.25 |
Ireland |
dd/mm/yy |
dot |
comma |
15/04/18 00:39:26 |
256.53 |
2,983,583.25 |
New Zealand |
dd/mm/yy |
dot |
comma |
15/04/18 00:41:55 |
256.53 |
2,983,583.25 |
South Africa |
yy/mm/dd |
dot |
comma |
18/04/15 00:42:54 |
256.53 |
2,983,583.25 |
UK |
dd/mm/yy |
dot |
comma |
15/04/18 00:44:42 |
256.53 |
2,983,583.25 |
US |
mm/dd/yy |
dot |
comma |
4/15/2018 0:45 |
256.53 |
2,983,583.25 |
German
Format | Date | Decimal Separator | Thousand Separator | Sample Date | Sample Number | Sample Large Number |
---|---|---|---|---|---|---|
Austria |
dd.mm.yyyy |
comma |
dot |
15.04.18 00:48:45 |
256,53 |
2.983.583,25 |
Germany |
dd.mm.yy |
comma |
dot |
15.04.18 00:50:08 |
256,53 |
2.983.583,25 |
Luxembourg |
dd.mm.yy |
comma |
dot |
15.04.18 00:51:38 |
256,53 |
2.983.583,25 |
Switzerland |
dd.mm.yy |
dot |
Apostrophe |
15.04.18 00:52:44 |
256.53 |
2'983'583.25 |
Italian
Format | Date | Decimal Separator | Thousand Separator | Sample Date | Sample Number | Sample Large Number |
---|---|---|---|---|---|---|
Italy |
dd/mm/yy |
comma |
dot |
15/04/18 00:54:54 |
256,53 |
2.983.583,25 |
Switzerland |
dd.mm.yy |
dot |
Apostrophe |
15.04.18 00:56:06 |
256.53 |
2'983'583.25 |
Spanish
Format | Date | Decimal Separator | Thousand Separator | Sample Date | Sample Number | Sample Large Number |
---|---|---|---|---|---|---|
Argentina |
dd/mm/yy |
comma |
dot |
15/04/18 01:00:20 |
256,53 |
2.983.583,25 |
Bolivia |
dd-mm-yy |
comma |
dot |
15-04-18 01:02:01 |
256,53 |
2.983.583,25 |
Chile |
dd-mm-yy |
comma |
dot |
15-04-18 01:03:13 |
256,53 |
2.983.583,25 |
Colombia |
dd/mm/yy |
comma |
dot |
15/04/18 01:04:16 |
256,53 |
2.983.583,25 |
Costa Rica |
dd/mm/yy |
comma |
dot |
15/04/18 01:05:30 |
256.53 |
2,983,583.25 |
Dominican Republic |
mm/dd/yy |
dot |
comma |
4/15/2018 1:06 |
256.53 |
2,983,583.25 |
Ecuador |
dd/mm/yy |
comma |
dot |
15/04/18 01:08:07 |
256,53 |
2.983.583,25 |
El Salvador |
mm-dd-yy |
dot |
comma |
04-15-18 01:16:33 |
256.53 |
2,983,583.25 |
Guatemala |
dd/mm/yy |
dot |
comma |
15/04/18 01:18:07 |
256.53 |
2,983,583.25 |
Honduras |
mm-dd-yy |
dot |
comma |
04-15-18 01:19:29 |
256.53 |
2,983,583.25 |
Mexico |
dd/mm/yy |
dot |
comma |
15/04/18 01:20:55 |
256.53 |
2,983,583.25 |
Nicaragua |
mm-dd-yy |
dot |
comma |
04-15-18 01:23:25 |
256.53 |
2,983,583.25 |
Panama |
Mm/dd/yy |
dot |
Comma |
04/15/18 01:24:49 |
256.53 |
2,983,583.25 |
Paraguay |
dd/mm/yy |
comma |
dot |
15/04/18 01:25:47 |
256,53 |
2.983.583,25 |
Peru |
dd/mm/yy |
comma |
dot |
15/04/18 01:31:04 |
256,53 |
2.983.583,25 |
Puerto Rico |
mm-dd-yy |
dot |
comma |
04-15-18 01:32:36 |
256.53 |
2,983,583.25 |
Spain |
dd/mm/yy |
comma |
dot |
15/04/18 01:33:42 |
256,53 |
2.983.583,25 |
Uruguay |
dd/mm/yy |
comma |
dot |
15/04/18 01:34:46 |
256,53 |
2.983.583,25 |
Venezuela |
dd/mm/yy |
comma |
dot |
15/04/18 01:35:47 |
256,53 |
2.983.583,25 |
Restarting Order Administration
Purpose: It is necessary to restart Order Administration in order for certain changes to take effect; see Restarting the Order Administration Application Servers.
When Cloud administration staff restart Order Administration, the system also looks at settings in Working with Admin Properties (CPRP) to determine the periodic process and its assigned periodic functions to run once Order Administration has restarted; see Running a Periodic Process on Server Startup.
Before restarting: Notify all users before restarting Order Administration, as restarting ends all currently open sessions and stops all active jobs.
Note:
If Cloud administration staff restart Order Administration without first stopping all active processes and completing the associated running jobs, the processes and jobs will not end normally. Any processes and jobs that did not end normally will need to be reset to inactive manually when you log back in to Order Administration.
Restarting the Order Administration Application Servers
Use the following steps to restart one or more of the Order Administration application servers.
-
Log in to the WebLogic Server Administration Console. The user ID you log in with must be part of the Administrators group.
-
On the home page, locate the Environment pane and click Clusters to advance to the Summary of Clusters page.
-
On the Summary of Clusters page, click the name of the cluster used for Order Administration to advance to the Settings for Cluster page.
-
On the Settings for Cluster page, click the Control tab to display the application servers for Order Administration. The State of the server indicates whether the application is currently running.
To stop one or more application servers that is currently running:-
Select the check box next to the server and click Shutdown > Force Shutdown Now. At the confirmation window, click Yes to shut down the server.
-
Refresh the screen until the State of the server is SHUTDOWN and the Status of Last Action is TASK COMPLETED.
To start one or more application servers that is currently shutdown:-
Select the check box next to the server and click Start. At the confirmation window, click Yes to start the server.
-
Refresh the screen until the State of the server is RUNNING and the Status of Last Action is TASK COMPLETED.
-
Running a Periodic Process on Server Startup
When Cloud administration staff restart Order Administration (see Restarting Order Administration), the system looks at the settings in Working with Admin Properties (CPRP) to determine the periodic process and its assigned periodic functions to run on server startup.
Why run a periodic process at startup? Typically, you would assign the periodic functions that start the async, e-commerce, integration layer jobs, and Drop Ship Background job to the periodic process that starts on server startup. However, you can assign any periodic function to the periodic process that runs on server startup. You can use the Work with Process Assignments Screen (Assigning Functions to a Periodic Process) in Working with Periodic Processes (WPPR) to assign periodic functions to the periodic process and select which of these periodic functions will run the next time you restart Order Administration. See Periodic Functions Available to Schedule for a list of periodic functions available to assign to the periodic process that is scheduled to run on server startup.
Scheduled jobs: When Order Administration executes the specified periodic process at server startup, the system schedules the periodic process to run one time. You can review the periodic process on the Scheduled Jobs Screen. TSee Scheduling Jobs for more information on scheduled jobs.
Note:
If you have scheduled the periodic process to run on server startup, do not define a job schedule for this periodic process. Instead, create one periodic process to run on server startup and a separate periodic process to schedule for other times. See Defining the Job Schedule for more information on setting up a schedule for a periodic process.
Application log: The system writes a message to the Application Log if its Logging Level is set to INFO and you do not set up the monitor properties correctly; for example: StartUpPeriodicProcess failed to start because Scheduling is not allowed on this server. If an error occurs, you need to correct the error and stop and restart Order Administration.
Monitor Property Settings
The Monitor Properties in Working with Admin Properties (CPRP) contain the settings required to have the system run a specified periodic process and its assigned periodic functions when you restart Order Administration.
Property Name | Description |
---|---|
STARTUP_ PERIODIC_ PROCESS_TO_RUN |
The name of the periodic process to run when you restart Order Administration. The process you enter must be a valid periodic process with assigned periodic functions. See Working with Periodic Processes (WPPR) for more information on creating a periodic process and how to assign periodic functions to it. |
STARTUP_ COMPANY_TO_RUN_ PERIODIC_ PROCESS |
The company number used to run a periodic function that requires a company to be defined. If none of the periodic functions require a company number, enter your default company number or 1. Valid values are 1-999. The system does not validate that your entry is a valid company number. |
Reviewing Application Settings in the Jenasys Properties File
Purpose: Use the jenasys.properties file on the Order Administration application server to review base configuration settings for Order Administration, such as where the specific parts of the Order Administration application are installed and how they should run.
Jenasys Properties File
Important:
The system updates the contents of this file during the installation process and you would typically not change the contents of this file.
Location of file: This file is normally saved on the application server at /domain/conf/jenasysproperties/, where domain is the WebLogic domain directory for Order Administration.
The settings in this file that Cloud administration staff may wish to review for troubleshooting purposes are listed below.
Setting | Description |
---|---|
LOG_DIR |
The directory on the Order Administration application server where the logs are stored. An example directory is properties\\serverconfig\\logging. |
config.dir |
The directory on the Order Administration application server where the system stores the server run-time data. An example setting is /domain/conf/OMSFiles, where domain is the WebLogic domain directory for Order Administration. |
oms.ui.classic.transform and oms.ui.classic.admin.transform |
Must be set to FORCE_SERVER in order to support Internet Explorer 9.0 or higher. This entry can be anywhere in the properties file. |
Scheduling Jobs
Purpose: You can use the job scheduler to schedule when a periodic process runs. You can define a periodic process to run once, daily, weekly, monthly, yearly, or at the start or end of a month.
In this topic:
How to Schedule a Job
Purpose: Use the following steps to schedule a periodic process to run based on a defined schedule.
-
Use the Working with Periodic Functions (WPER) menu option to create a periodic function for the job you wish to execute. See Periodic Functions Available to Schedule for a list of periodic functions that you may wish to schedule.
-
Use the Working with Periodic Processes (WPPR) menu option to assign the periodic function(s) to a periodic process.
-
Once you have created the periodic process, you can use the Execute Periodic Process screen (located in the Working with Periodic Processes (WPPR) or Executing Periodic Processes (EPRO) menu option) to define a schedule for the job. See Defining the Job Schedule.
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 in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information.
Execute process on server startup: You can also schedule a periodic process and its assigned periodic functions to start on server startup. See Running a Periodic Process on Server Startup for more information.
Defining the Job Schedule
Use the Execute Periodic Process screen (located in the Working with Periodic Processes (WPPR) or Executing Periodic Processes (EPRO) menu option) to define a schedule for a periodic process.
# | Step |
---|---|
1. |
At the Execute Periodic Process screen, 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 blank, 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. |
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. 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. |
|
Scheduled Jobs Screen
Overview: Use this screen to review the periodic processes scheduled to run at a specified time.
Note:
Any job monitor rules scheduled to run at a specified time also display on this screen; see Monitoring Jobs.
How to display this screen: Select Scheduled Jobs at the Commands screen.
To advance to the Commands screen:
-
Select the My Jobs icon (
) in the upper right area of a screen) to advance to the Job Management screen.
-
At the Job Management screen or other Admin screen (such as the About Application, Forms Management Screen, User Control, or System Messages screens), select Advanced Commands to advance to the Commands screen.
Note:
The Advanced Commands option will not display if you do not have authority to advanced commands; see User Configuration in the Administration Guide for more information on setting a user’s password and system authority.
Field | Description |
---|---|
Job name |
The name of the periodic process or job monitor rule that is scheduled to run at a specified time. Alphanumeric, 10 positions; display-only. |
Schedule |
A description of when the periodic process is scheduled to run. This description is based on the Frequency you defined for the periodic process.
Alphanumeric, calculated by the system; display-only. |
Next run |
The date and time the periodic process will next be executed. UNKNOWN displays if someone has deactivated the job scheduler. Alphanumeric, calculated by the system; display-only. |
Last run |
The date and time the periodic process was last executed. UNKNOWN displays if:
Alphanumeric, calculated by the system; display-only. |
Status |
The current status of the scheduled job. Valid values are:
Alphanumeric, 8 positions; display-only. |
User |
The user ID of the user that scheduled the periodic process. Note: When the system executes the periodic process, the system submits the job to the specified job queue using the name of the user that scheduled the job. Alphanumeric, 10 positions; display-only. |
Screen Option | Procedure |
---|---|
Delete a periodic process that is scheduled to run |
Select Delete for a scheduled job to remove it from the scheduler. The periodic process will no longer display in the list of scheduled jobs. If you wish to reschedule the job, you will need to use the First Execute Periodic Process Screen (Setting Parameters) to create a new job schedule. |
Deactivate each job in a scheduled status that is scheduled to run |
Select Deactivate Schedule. The system:
Note:
|
Activate each job in an Inactive status that is scheduled to run |
Select Activate Schedule. The system:
|
Refresh job schedule on the screen |
Select Refresh Schedule. The system:
|
Display information about Order Administration |
Select About. |
Advance to the Document Management Screen |
Select My Docs. |
Advance to the Forms Management Screen |
Select My Forms. |
Advance to the Job Management screen |
Select My Jobs. |
Advance to the Advanced Commands screen, where you can advance to additional commands |
Select Advanced commands. |
Return to the main menu |
Select Exit. |
Scheduled Jobs Troubleshooting
Scheduled Jobs Log
Order Administration writes a message to the Application log (APP.log) when:
-
you add a periodic process to the job scheduler
-
you remove a periodic process from the job scheduler
-
you deactivate the job scheduler
-
you activate the job scheduler
-
the job scheduler executes a scheduled periodic process and updates the next time the job is scheduled to run
-
an error occurs during job scheduling
See Using the JOBCLN Function to Resolve Job Status Across Servers for information on using the JOBCLN function to regulate and correct running jobs.
Troubleshooting Questions
Some possible troubleshooting questions and answers are:
Question | Possible Answer(s) |
---|---|
The Scheduled Jobs screen does not display my periodic process. |
|
Why is the Last run field set to UNKNOWN? |
|
Can I delete all jobs from the scheduler? |
You must delete each job from the scheduler individually. |
I created a periodic process to stop and restart asyncs, and asyncs did not start correctly. |
Do not create one periodic process to stop and restart asyncs. You need to allow a certain amount of time for the system to completely stop the aysncs before restarting the asyncs. Instead, create one periodic process to stop the asyncs and create a separate periodic process to start the asyncs. Depending on the typical amount of transactions that need to be processed before the asyncs can end, you should allow 5 - 30 minutes between stopping the asyncs and starting the aysncs. |
It looks like my scheduled job ran at the correct time, but I don’t see the expected results. Example: Asyncs were scheduled to start at 7AM this morning, but they are still inactive at 8AM. |
Make sure that the submitted job is not waiting to run behind another job in the queue. When the system executes a scheduled job, the job is placed in the specified job queue for the user that scheduled the job.
Note: If the scheduled job is to start or end asyncs, but the asyncs are already started or stopped, the scheduled job will run, but do nothing since the asyncs are already in the correct status. |
Can I change the parameters of a scheduled job? |
No, if you wish to change the parameters of a scheduled job, such as adding or removing a periodic function from the process, changing the scheduled time, or changing the job queue, you will need to remove the scheduled job from the job scheduler and create a new schedule for the job. |
Why is my scheduled job in an error status? |
Note: The system writes a description of the error to the Application log (APP.log). |
Using the JOBCLN Function to Resolve Job Status Across Servers
Use the JOBCLN periodic function resolve job status across all servers for batch jobs.
When to use? You might run the JOBCLN function when:
-
When a server shuts down unexpectedly.
-
Whenever a job status does not appear correct or consistent.
You can also include the JOBCLN function as the first job run through a periodic process that starts other functions for a server restart.
The JOBCLN function resolves status for jobs running through the following options:
-
Background Job Control (MBJC): see Running the JOBCLN Periodic Function to Correct the Async Jobs for details.
-
Working with Drop Ship Background Jobs (WPBJ): See Troubleshooting the CDC Async Job for details.
-
Working with Integration Layer Processes (IJCT): See Using the JOBCLN Function to Troubleshoot IJCT Jobs for details.
-
Other jobs: The JOBCLN function does the following:
-
For all other batch jobs at the Job Management (My Jobs) screen in RUN, MSG, ERR, and RMV status, confirm whether they are actually running, and if not:
-
Update the status to END.
-
Delete all Active Procedures (MACX) records.
-
-
For any batch jobs in the above statuses that are actually running, update the status to RUN and create an active procedure if needed..
-
For any batch jobs that are not actually running, do the following:
-
Update the job status to END.
-
Delete each corresponding Active Procedure (MACX) record if one exists.
-
-
For all active procedures related to these batch jobs (see Purge Active Procedures Across Users (MACX)):
-
If the related job is in END status, delete the active procedure.
-
If the job is not in END status and is not displayed in Display Active Batch Jobs (DABJ), delete the Active procedure.
-
-
Note:
The JOBCLN function does not update interactive user sessions (in the oms.job.queue.interactive job queue).
Authority required to run JOBCLN: To submit the JOBCLN periodic function, a user must be flagged as a Security Administrator, with a User Rank of 1.
Deleting an active procedure: When the JOBCLN function deletes an active procedure, it creates a User Audit record. See Tracking User, Authority, and Password Updates for more information on the User Audit table.
Multiple billing async jobs? If the Number of Billing Async Jobs to Start (F08) specifies to start more than one billing async job, you will need to end the async jobs manually and then restart them in order to launch the specified number of billing async jobs.
Setting Up Web Service Authentication
Overview: Oracle recommends the use of OAuth rather than basic authentication. With basic authentication, the user password will expire periodically and require a reset. Each of these authentication options is described below.
In this chapter:
Basic or OAuth Authentication
Basic authentication requires the requesting system to pass a user ID and a password to authenticate a web service request. The destination system validates the user ID and password.
When basic authentication is used, you should use the Working with Web Service Authentication (WWSA) rather than the Manage External Application Access page in Modern View.
OAuth requires the requesting system to provide an access token with the web service request. Oracle Cloud Services use IDCS (Oracle Identity Cloud Service) or OCI IAM (Oracle Cloud Infrastructure Identity and Access Management) as the authenticating service. The requesting system will use its configured client ID and secret to request an OAuth token from IDCS or OCI IAM and then include that token in service requests.
In addition to being more secure, OAuth provides better performance than basic authentication.
With OAuth authentication:
- The requesting system first passes a client ID and a client secret to an authenticating service, such as IDCS or OCI IAM.
- The authenticating service, such as IDCS or OCI IAM, generates a temporary token.
- The requesting system submits the token to the destination system, rather than a password and user ID as with basic authentication.
- The destination system validates the token and client ID with the authenticating service.
Note:
Order Management System and Order Administration, supports OAuth 2.0 for inbound and outbound requests.OAuth Support for Omnichannel Products
Product | Supports Receiving OAuth | Supports Sending OAuth |
---|---|---|
Order Broker |
19.0 or higher |
19.1.1 or higher |
Order Broker Cloud Service |
18.2 or higher |
19.1 or higher |
Order Orchestration |
23.2.401.0 |
23.2.401.0 |
Order Management System |
18.3 or higher; 19.0 or higher supports XOffice OnPrem validation of stores with parent ID. 19.0 or higher. See the Manage External Application page in Modern View for background. |
19.1 or higher |
Order Administration |
23.2.401.0 |
23.2.401.0 |
Customer Engagement |
18.0 or higher; 18.3or higher supports XOffice OnPrem validation of stores with parent ID. |
not currently supported |
Setting Up Inbound Authentication
Implementing Basic Authentication with IDCS or OCI IAM
When an external system calls an Order Administration web service, the external system sending the message to Order Administration must send authentication information in the HTTP header of the message.
To implement:
- Create a user profile in IDCS or OCI IAM for inbound web service authentication and assign the password in IDCS or OCI IAM. You can create a single user, or a separate user for different inbound messages.
- Create the web service authentication user, using the User Name defined in IDCS or OCI IAM, in Work with Web Service Authentication (WWSA) for the inbound web service message. No password entry is required or supported, because the authentication takes place through IDCS or OCI IAM.
Implementing OAuth through the Manage External Application Access page in Modern View
Typically, you would use the Manage External Application Access page in Modern View to:
- Review the clients that have already been created in IDCS or OCI IAM.
- Generate a new client for the XOffice On Premises application and assign web service access.
- Generate a new client for another application and assign inbound web service access.
For more information: See the Oracle Retail Omnichannel Web Service Authentication Configuration Guide on My Oracle Support (2728265.1) for web service authentication configuration instructions.
Validation of Inbound Requests
When Order Administration receives an inbound web service request:
- If the web service passes authentication, the web service continues with regular processing.
- If the web service fails basic authentication, the web service returns an error. If IDCS or OCI IAM is enabled, a 401 error is returned.
Order Administration Web Services Eligible for Authentication
You must define web service authentication, either through Work with Web Service Authentication (WWSA) or through the Manage External Application Access page in Modern View, for the following Order Administration web services.
- CWCustomer. This web service is used to process an Inbound Customer Message (CWCustomerIn) received from an external system. See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information.
- CWMessageIn. This web service works with any of the integration layer processes set up through Work with Integration Layer Processes (IJCT). See XML Messages Processed By the CWMessageIn Web Service for a list of the messages processed by the CWMessageIn web service and see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
- CWOrderIn,. This web service is used to process an Inbound Order XML Message (CWOrderIn) from an external system. See Generic Order Interface (Order API) in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information.
- CWPickIn. This web service is used to process a CWPickIn XML Message from an external system. See Generic Pick In API (Shipments, Voids, and Backorders) in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information.
- CWReceiptIn. This web service is used to process a PO Receipt In XML Message (CWReceiptIn) from an external system. See Purchase Order Receipt In API in the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information.
-
CWServiceIn. This web service is used to process the following messages received from an external system:
- Order Transaction History Message (CWOrderTransactionHistory) if its type attribute is CWOrderTransactionHistory. See Generic Order Transaction History API for more information.
- Order Line History In Message (CWOrdLnHstIn) if its type attribute is CWOrdLnHstIn. See Order Line History In API
For more information see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
- Item Availability Web Request XML Message (CWItemAvailabilityWeb) if its type attribute is CWItemAvailabilityWeb. See Item Availability API for more information.
- E-Commerce Cancel Request Message (CWCancel) – if its type attribute is CWCancel. See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) and see E-Commerce Cancel Process for more information.
- E-Commerce Catalog Request Message (CWCatRequest) if its type is CWCatRequest. See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1) for more information.
- CWProcessIn Message if its type attribute is CWProcessIn. See Using the CWProcessIn Message to Start a Periodic Process for more information.
See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).
- JMSQueue. This web service is used during Advanced Queuing to read from a queue in the queuing database.
- PrivateDataRequest RESTful web service. This web service is used to process a Get Personal Data Request and Forget Personal Data Request from an external system. See the Personal Data API in the Data Security guide on My Oracle Support (ID 2953017.1) for more information.
- ProcessIn. This RESTful web service is used to start a periodic process. See Using the ProcessIn REST Message to Start a Periodic Process for more information.
- Storage. This RESTful web service is used to upload, download, delete, or inquire on files imported or exported through the File Storage API.
Setting Up Outbound Authentication
Basic Authentication
Which outbound services require basic authentication? OAuth is not supported for the following:
Narvar Service: Used for authentication of RESTful web service requests to generate shipment notification emails through the Narvar Integration.
RICS Service: Used for authentication for the pre-order (backorder quantity update) notification message that is part of the Enterprise Order Integration (Future Receipts and Active PO/Pre-Order Processing).
OCDS Service: Used for authentication for RESTful web service requests sent to the Omnichannel Cloud Data Service. See Importing Enterprise Foundation Data through Omnichannel Cloud Data Service (OCDS) for background.
For more information: See the Work with Outbound Web Service Authentication Screen.
Web Service Authentication Process for Order Orchestration
You can configure Order Administration to use either basic authentication or OAuth authentication for an Order Orchestration web service. When Order Administration generates a message to send to Order Orchestration, it includes the web service authentication user and password in the HTTP header of the message.
The type of authentication you select must be supported by Order Orchestration. Web service authentication is available starting in version 15.0 of Order Broker, or Order Orchestration, and OAuth authentication for outbound requests to Order Orchestration is available in 18.2 or higher of Order Broker, or Order Orchestration.
-
Order Orchestration requires you to pass a valid web service authentication based on the settings defined at the Web Service User screen, using either basic authentication or OAuth.
- If the web service passes authentication, the web service continues with regular processing.
- If the web service fails basic authentication, the web service refuses the request with an error: Inbound Message failed validation.
If the message fails web service authentication: If the password used for web service authentication is invalid or expired, or the request for an OAuth token fails, the system writes an error message to the CWDirect log.
Order Orchestration Web Services Eligible for Authentication
You can define web service authentication for the following Order Orchestration web services:
- OOCS Discovery. The Location discovery request is used to request a listing of all locations set up in Order Orchestration for the specified system. See Importing Store Cross Reference Locations through Order Orchestration’s Discovery Web Service for more information.
-
OOCS Imports. Includes all imports using Order Orchestration’s Product, Product Location, and Incremental Inventory Import Process.
- Order Orchestration Product Output File: Used to import product information into Order Orchestration.
- Order Orchestration Product Location Output File: Used to import product location, attribute, and availability information into Order Orchestration.
- Oracle Retail Order Orchestration Incremental Inventory Output File: Used to import inventory updates into Order Orchestration.
-
OOCS Locate. Includes all requests related to the Routing Engine. See Order Orchestration Integration for more information.
- EchoTest: Used to test the connection to Order Orchestration.
- Fulfillments: Used to request a list of pickup and shipment orders assigned to the requesting location.
- Inventory Availability: Used to request current availability of active PO items as part of the ACTPO periodic function. See the ACTPO Periodic Function for Order Broker 20.2 or Higher, or Order Orchestration for more information.
- LocateItems: Used to request locations available for store pickup orders.
- OrderUpdate: Used to update the Under Review indicator for an order.
- ProductAvailability: Used to request product availability for one or more items based on one or more order types.
- StatusRequest and StatusListRequest: Used to request current order status for a list of orders.
- StatusUpdate: Used to request a status update to a pickup or shipment order.
- SubmitOrder: Used to request creation of a pickup order in the requesting location, or request selection of a location for shipment of an order.
-
OOCS Purchasing. Includes all requests related to the Supplier Direct Fulfillment module. See Interface with Order Orchestration’s Supplier Direct Fulfillment Module: Overview and Setup for more information.
- CreateDSOrder: Used to create a drop ship purchase order.
- CreateDSVendor: Used to create or update a vendor.
- GetDSChanges: Used to request a listing of changes to all drop ship purchase order lines since the last request for changes was processed.
- GetDSInvoices: Used to request information on invoices submitted by the vendor and approved since the last request for invoices was processed.
- SetDSAddressChange: Used to request a shipping address change for a drop ship purchase order.
- SetDSCancel: Used to request the cancellation of a line on a drop ship purchase order.
- SetDSCostChange: Used to request a change to the retailer or vendor unit price, or both, for a drop ship purchase order line.
Web Service Authentication Process for Customer Engagement
Releases earlier than 16.0: When Order Administration calls a Customer Engagement web service earlier than release 16.0, the web service looks at the AUTHENTICATION_SCHEME setting defined in Conflate to determine whether authentication is required. If the AUTHENTICATION_SCHEME is set to Org-User, the web service requires authentication. In this situation, the system requires you to pass a valid user ID and password, as defined in the USR_RELATE_USER table, and to also identify the organization to which the user belongs, based on the relevant element in the URL.
Note:
If you integrate with Relate 11.4 or earlier, you must upgrade to at least release 15.0 of Customer Engagement to use web service authentication.Release 16.0 or later: In release 16.0 of Customer Engagement and later, authentication is required.
- If the web service passes authentication, the web service continues with regular processing.
- If the web service fails authentication, the web service returns a 401 error: unauthorized.
Inbound OAuth authentication is supported in release 18.0 or higher of Customer Engagement. When using OAuth, the Client ID for Order Administration must be assigned an application role of API access in IDCS or OCI IAM.
If the message fails web service authentication: If the password used for web service authentication is invalid or expired, or the request for an OAuth token fails, the system writes an error message to the CWDirect log.
Oracle Retail Customer Engagement Web Services Eligible for Authentication
You can define web service authentication for the following Oracle Retail Customer Engagement web services:
- ORCE Customer. This web service is used to create and update customer information between Oracle Retail Customer Engagement and Order Administration. See Customer Engagement Loyalty Integration for more information.
-
ORCE File Service. This web service is used to transfer customer, sales, and item information XML files to Oracle Retail Customer Engagement 20.0+. See Customer Engagement File Transfer Service (FTS) for more information.
Note:
OAuth authentication is required for ORCE File Service. Also, the client ID specified must be assigned the FileReview role in Customer Engagement. - ORCE Loyalty. This web service is used to assign a loyalty card to a customer and process activity for the loyalty account. See Customer Engagement Loyalty Integration for more information.
- ORCE Purchase History. This web service is used to review a customer’s completed sales and return transactions across multiple channels using the Display Purchase History screen. See Customer Engagement Purchase History Integration for more information.
- ORCE Stored Value Card. This web service is used to process stored value card transactions between Order Administration and Oracle Retail Customer Engagement. See Customer Engagement Stored Value Card Integration for more information.
- ORCE Registry. This web service is used to review or place orders for the customer’s registries through Oracle Retail Customer Engagement. See Customer Engagement Customer Gift Registry and Wish List Integration for more information.
Vertex Interface
Purpose: The Vertex Interface provides a bridge between Order Administration and the Vertex Sales Tax system to calculate the tax information on your orders at strategic points, such as:
- order entry
- order maintenance
- pick slip preparation
- billing
Order Administration communicates with Vertex files to determine the appropriate tax rate at each stage of the order's life cycle. Vertex determines the appropriate tax rate based on the “ship-from” and “ship-to” addresses on the order.
The Vertex Sales Tax system stores the tax rates for each taxing jurisdiction in the United States and Canada, and provides the necessary reporting for each jurisdiction in which you sell or operate.
If you use the Vertex interface, you don't need to keep current with the tax rates and reporting requirements of each taxing jurisdiction, and you no longer have to maintain these rates on Order Administration. Also, the system does not consider any item tax exemptions set up through Working with Item Tax Exemptions (WITX) or Working with GST Tax Exemption Status (MGTX). Instead, you should use Vertex to set up any tax exemptions for items.
Note:
You cannot use both Vertex and tax-inclusive pricing (VAT) in the same company. See Tax Included in Price (E70) for more information on VAT.Compatibility:
- Order Management System version 19.2 or later, or Order Administration, is compatible with Vertex Indirect Tax O Series® On Demand 9.0, but continues to support integration with 7.0 and 8.0 using 7.0 messages.
- Order Management System version 15.1 or later, or Order Administration, is compatible with Vertex Indirect Tax O Series® On Demand 7.0 and 8.0. The 7.0 messages are used for both releases.
- Support for Vertex Indirect Tax O Series® On Demand 7.0 and 8.0 using 7.0 messages ends in September 2021.
For more information: See:
- Vertex Setup for information on setting up Order Administration to support communication with Vertex. Also, see your Vertex documentation for detailed information on setup requirements within Vertex.
- Vertex Troubleshooting
In this topic:
- Tax Calculation Processing Overview
- Tax Overrides, Customer Exemptions, and Item or Class Exceptions
Tax Calculation Processing Overview
Overview: The Vertex Interface passes order and tax information between Order Administration and Vertex at various points in the order cycle (from order entry to billing).
Vertex evaluates and calculates the tax amount on the order at each phase and updates transactions appropriately.
Communication between Order Administration and Vertex: When Order Administration needs tax information during order entry or maintenance, pick slip preparation, or billing, it sends a tax request message to Vertex using web services. The TAX_INT integration layer job defines the wsdl (Web Services Definition Language) file that controls the integration.
For troubleshooting purposes, Order Administration writes the tax request message to the Trace Log, masking the vertex user ID and password passed in the request. Additional processing is logged to the Application Log.
For more information: See Vertex Setup for more information on configuring the integration.
What is taxed? Based on its current data on tax rules for the shipping address on the order and the additional rules that you define for customer or item exceptions, Vertex indicates the tax amounts for merchandise, freight (order-level or line-level), handling charges, duty, shipper-item charges, and additional freight.
Tax Overrides, Customer Exemptions, and Item or Class Exceptions
Tax override: You can set the Tax override flag in the Order Detail table to Y when you create an order through the generic order API. If this flag is set to Y, Vertex does not calculate the tax amount for the item at any point in the order cycle and just uses the specified tax override amount; however, if there are any line-level freight, handling, or gift wrap charges, these charges may be subject to tax even if the order detail line has a tax override.
Similarly, you can override tax on freight through the order API
by specifying a freight_tax_amount
and setting the freight_tax_override
to Y.
Note:
- There is no way to set the Tax override flag through interactive order entry.
- The system does not set the Tax override flag in the Order Detail table unless there is a tax amount specified in the inbound order message. As a result, you cannot use this setting to create an order line with no tax amount in interactive order entry. The only way to exempt an order line from tax is to set up an item or product class exception in Vertex.
For more information: See the Send Tax to Tax Interface as Quote Not Invoice (L11) system control value for a discussion on how the system sends different request types to Vertex based on the setting of this system control value and whether the tax is overridden.
Customer tax exemptions: If a customer is flagged as tax exempt in Order Administration and has a tax identification number, the merchandise and charges on the customer’s orders are not taxable. Order Administration passes the exemption number to Vertex. Although Order Administration does not pass the customer’s tax exempt expiration date, order entry does not let you create an order flagged as tax-exempt if the customer’s expiration date has passed.
Item or item class exceptions: When you use Vertex, you need to set up item and product class exceptions in Vertex rather than in Order Administration. For example, if you have two item classes that are not normally taxable, you can map these item classes to product classes in Vertex. See Creating the Product Class under Vertex Setup for more information on mapping this information.
Note:
Even if an item on an order is not subject to tax, Vertex still calculates tax for any freight, handling charges, and gift wrap charges if the order is otherwise subject to tax.Vertex Setup
Overview: This document provides the steps needed to configure Order Administration to integrate with Vertex Indirect Tax O Series® On Demand so that Vertex calculates tax for orders during order entry, pick slip preparation, and billing.
Compatibility: Order Management System version 15.1 and later, or Order Administration, is compatible with Vertex Indirect Tax O Series® On Demand 7.0 8.0, and 9.0. For 8.0, Order Management System uses the 7.0 messages.
In this topic:
For more information: See Vertex Interface for an overview on the integration.
Before You Start: Taxability Considerations
Mapping Data from Order Administration to Vertex
Before you start the configuration steps described below, it is helpful to note the information in Order Administration that maps to corresponding values in Vertex.
OROMS | Vertex | Notes |
---|---|---|
company (WCMP) |
taxpayer |
Typically, the Order Administration company code matches the Vertex taxpayer code; however, if you specify a Company in the Default Values by Company XML File, it overrides the actual company code. You might define a company override if the Vertex taxpayer is already set up in Vertex and you need to configure Order Administration to map to the existing taxpayer. |
entity (WENT) |
taxpayer |
Typically, the Order Administration entity code matches the entity-level Vertex taxpayer code; however, if you specify an Entity in the Default Values by Company XML File, it overrides the actual entity code. You might define an entity override if the Vertex taxpayer is already set up in Vertex and you need to configure Order Administration to map to the existing taxpayer. Used if the Pass Entity Code to Tax Interface (F69) system control value is selected and you do not specify a company code and division code in the Default Values by Company XML File. Set up with the company taxpayer as the parent, and configure all required data at the entity-level taxpayer. The entity on an order is determined by the division assigned to the source code on the order header. If you specify a Company and a Division in the Default Values by Company XML File, the Division specified overrides the entity code. |
item class (WICL)/ long SKU department (WLSD)/ long SKU division (WLSV)/ long SKU class (WLSC) |
product class |
Assigned in Order Administration to the item/SKU (MITM). Used to map to the product class in Vertex in order to apply tax exceptions. See Creating the Product Class, below. |
customer class (WCCL) |
customer class |
Assigned in Order Administration to the customer. Maps to the customer class in Vertex to apply tax exemptions. Note:
|
Creating the Product Class
Purpose: In order to set up product classes for taxability purposes, you can map your company’s item class, long SKU department, long SKU division, and long SKU class combinations to product classes (taxability drivers) in Vertex. The particular categories mapped, and the order in which they are mapped, is user-defined, so that you can select the product class hierarchy that best matches the way you group and classify items.
Identified where? The Product_Class_Concatenation_Type in the Default Values by Company XML File identifies the sequence in which to concatenate the four product class code components, with leading zeros included.
What components can you include?
Component | Identified as Element Number: |
---|---|
item class (WICL) |
1 |
long SKU division (WLSV) |
2 |
long SKU department (WLSD) |
3 |
long SKU class (WLSC) |
4 |
The setting of the Product_Class_Concatenation_Type identifies the order in which to send these elements to Vertex in order to indicate an item or SKU’s product class.
Example:
You set the Product_Class_Concatenation_Type to 2341. This setting indicates to concatenate the product class elements as: long SKU division (2) + long SKU department (3) + long SKU class(4) + item class (1).
You enter an order for an item with the following assignments:
-
long SKU division: XYZ
-
long SKU department: 4
-
long SKU class: 6543
-
item class: FD
Vertex receives a product class assignment for the item of XYZ00046543FD. Note that leading zeroes are included (for example, the long SKU department of 4 is included as 0004).
Setup considerations: As a way to simplify the setup process, you can set the Product_Class_Concatenation_Type so that your most commonly used components are included first. For example, if you always use item class (1), sometimes use long SKU department (3) and never use long division (2)) or long SKU class (4), you can set the Product_Class_Concatenation_Type to 1324. Then when you set up product classes (taxability drivers) in Vertex, you only need to specify the item class (1) and long SKU department (3), as the integration concatenates those two values and leaves the rest of the product class blank.
Configuration Steps
Setup within Order Administration
System Control Values
-
Tax on Freight (B14): Must be selected.
-
Use Generic XML Tax Interface (J10): Must be set to VERTEX to have Order Administration communicate with Vertex.
-
Use Standard Tax Calculation if Tax Interface Fails (J13): Select this value to have Order Administration use the standard tax calculation if it does not receive a response from Vertex. If you select this value, you will need to set up tax rates at the SCF level (WSCF) and/or the postal code level (WZIP).
-
Pass Entity Code to Tax Interface (F69): Select this value to pass the entity associated with the source code on the order header to Vertex, provided you do not specify a Company and Division code in the Default Values by Company XML File. If you select this value, then you can set up product class or customer class tax exemptions at the entity level in Vertex.
-
Tax Included in Price (E70): Must be unselected if your company integrates with Vertex.
-
Send Tax to Vertex as Quote not Invoice (L11): Indicates whether billing should send a quotation or an invoice request message to Vertex when processing a shipment or a return.
Note:
When you change a system control value, stop and restart the background jobs (MBJC) and exit and re-enter Order Administration to have your changes take effect.
TAX_INT Integration Layer Job (IJCT)
For the TAX_INT job: Set the Communication type to Web Service and set the WSDL Document Name to:
-
CalculateTax90.wsdl for integration with Vertex 9.0
-
CalculateTax70.wsdl for integration with Vertex 7.0 or 8.0
See Vertex wsdl (Web Service Definition Language) File for more information.
Because the TAX_INT job is always in INTERACT status, you do not stop or restart the job for your change to take effect.
Note:
The TAX_INT job does not require a process queue.
Additional Setup in Order Administration
Create a customer class for exempt customers: Use Work with Customer Class (WCCL) to set up one or more classes of customers who are tax exempt, and then assign customers in Order Administration to the appropriate customer class. You can then set up the customer class(es) as tax exempt in Vertex. Similarly, set up product class exemptions and individual product (item) exemptions in Vertex. See Set up Data within Vertex for more information on setup steps in Vertex.
Note:
If the customer on an order is assigned to a customer class in Order Administration that does not correspond to a matching class in Vertex, Vertex calculates tax as if there is no customer class assignment.
Set up specific customer tax exemptions: Use Work with Customers (WCST) to set up specific customers as tax exempt, including specifying their Tax identification number and the Expiration date, or setting this information up for the customer in specific states or provinces. Order Administration passes this information to Vertex when a tax exempt customer places an order. It is not necessary to assign these customers to a particular customer class in order to flag them as tax exempt to Vertex.
Assign items and SKU’s to a product class hierarchy: Use Work with Items/SKU’s to assign items and SKU’s to the categories you use to identify product classes in Vertex, as described under Creating the Product Class.
Note:
It is not necessary to set up tax rates or other settings at the SCF level or the postal code level if you are using the generic tax integration with Vertex.
Set up Data within Vertex
Use the Sales Tax option within the Vertex Taxability Manager:
Set up company and entities as taxpayers in Vertex:
-
Set up a taxpayer for each company to integrate with Vertex. The taxpayer Code should match the company code and should be zero-filled (for example, company 3 in Order Administration = taxpayer Code 003 in Vertex). Assign the taxpayer to the appropriate jurisdictions, such as all U.S. states.
-
If you are sending entity information to Vertex, add a taxpayer for each entity for the related company, where the company taxpayer is the parent to the entity taxpayer. For example, if you are adding entity 100 for company 3, select taxpayer 003 in Vertex as the parent for taxpayer 100. Again, assign the taxpayer to the appropriate jurisdictions, such as all U.S. states.
-
If you would like to set up product class exceptions, use the Taxability Driver option in Vertex:
-
Input Field = Product Class
-
Code = the concatenated product class, as determined through Creating the Product Class
-
Taxpayer = your company and, optionally, entity
-
Taxability = Generally Taxable or 100% Exempt
-
Use the Taxability Mapping option to associate the taxability driver to predetermined taxability logic as defined by Vertex
-
-
Set up product classes for freight, additional charges, and handling and map them to the appropriate delivery charge categories:
Line Item Type Product Class OF
OF (Order Freight)
LD
LD (Line Duty)
LH
LH (line handling)
Note: If the S/H exclude tax? flag is selected for an additional charge code, then a line that uses this additional charge code for special handling is not subject to line handling (LH) tax. See Establishing Additional Charge Codes (WADC) for background.
AF
AF (additional freight and shipper item charges)
LF
LF (line freight)
Note:
If you use the integration with Vertex to calculate taxes, then the settings within Order Administration to control tax on freight and handling (such as system control values and settings at the SCF and postal code level) are not used.
-
Optionally, use the Customers option in Vertex to set up customer class exceptions:
-
Type = Customer Class
-
Code = customer class code
-
Taxpayer = your company and, optionally, entity
-
Taxability = set to 100% Exempt to indicate customers assigned to this customer class are exempt from tax
-
Note:
If the customer on an order is assigned to a customer class in Order Administration that does not correspond to a matching class in Vertex, Vertex calculates tax as if there is no customer class assignment.
Define a Tax Assist Rule for Canada:In order to tax Canadian orders, the deliveryTerm passed to Vertex must be set to SUP. You can define a tax assist rule in Vertex as follows:
If Destination.Country ="CA"
Set deliveryTerm="SUP"
Configuration Files
Use a text editor to edit the following files.
Important:
Make a backup copy of each of the files discussed below before making any changes. Also, it is important that you do not make any changes in these files beyond those outlined in these instructions.
Vertex wsdl (Web Service Definition Language) File
Purpose: The wsdl file controls web service communication and other settings between Order Administration and Vertex.
File location and name: The wsdl file you use for integration with Version 9.0 On Demand of Vertex is named CalculateTax90.wsdl, and is typically located on the application server at conf\cwdirectcpproperties\xslt\VertexWS\7.0 or conf\cwdirectcpproperties\xslt\VertexWS\9.0, based on the version of Vertex in use, where domain is the WebLogic domain directory for Order Administration.
Configuring the wsdl file:
-
Search for REPLACE_WITH_VERTEX_SERVER_NAME and replace any instance in the file with the name or IP address of the server running Vertex. For example, replace https://REPLACE_WITH_VERTEX_SERVER_NAME/vertex-ws/xsd/9.0/VertexInc_Envelope with https://SAMPLE_REPLACEMENT.vertexinc.com/vertex-ws/xsd/9.0/VertexInc_Envelope
-
Do not change anything else in the file.
Note:
After making any change to the wsdl, you need to restart Order Administration to have your changes take effect. See Restarting Order Administration for more information.
Vertex User ID and Password
Use the VERTEX_USERID and VERTEX_PASSWORD properties in Working with Customer Properties (PROP) to specify the user ID and password to use for connection to Vertex.
The user ID you specify should be assigned to the Vertex partition that includes the data that will be required by Order Administration.
The password entry here is encrypted. Also, the system masks the password for any transactions posted to the CWDirect Log or Trace Log.
Vertex URL
Use the VERTEX_SERVICE_ENDPOINT_URL in Working with Customer Properties (PROP) to define the URL used to communicate with Vertex. An example of the URL is https://partners1.ondemand.vertexinc.com/vertex-ws/services/CalculateTax90, if you integrate with release 9.0 of Vertex.
VertexWS XML File
Purpose: This file is required for the integration with Vertex and should not be changed.
File location: This file is typically located on the application server at /domain/conf/cwdirectcpproperties/VertexWS.xml, where domain is the WebLogic domain directory for Order Administration.
Property Name | Description |
---|---|
TAX_INT |
This setting indicates Order Administration communicates with Vertex. The setting for Vertex is: com.cwi.direct.interfaces.webservice.VertexWS |
Default Values by Company XML File
Purpose: Use this file to specify default values to send to Vertex for each company that will use the tax integration.
File location and name: A copy of this configuration XML file is required for each company that will use Vertex. The files are typically located on the application server at /domain/conf/cwdirectcpproperties/xslt/VertexWS/9.0, where domain is the WebLogic domain directory for Order Administration and 9.0 is the version of Vertex in use. The company number in the file name should be zero-filled; for example, the file name for company 49 is DefaultValues_049.xml.
Sample files: Your Order Administration installation includes a sample default values XML file for company 49 and for company 51. You can use these samples as starting points to build default values XML files for your companies.
Configuring the file: Each entry in the file is labeled by an ID, for which you enter the corresponding Value:
Default Value ID | Value |
---|---|
Company |
Optionally, use this field to enter an override company code to pass to Vertex that differs from the actual company number. See Configuring the Division and Company Codes for more information. |
Division |
Optionally, use this field to pass a division code to pass to Vertex. See Configuring the Division and Company Codes for more information. |
Product_Class_Concatenation_Type |
Indicates the sequence of the item class, long SKU department, long SKU division, and long SKU class to use when creating product classes (taxability drivers) for exceptions to default tax rules. See Creating the Product Class for setup considerations, and see Set up Data within Vertex for setup steps in Vertex. |
Call_Center_TaxAreaID |
The tax area ID to send to Vertex in order to identify your call center’s location. You can determine a location’s tax area ID in Vertex Central Home under Tools > Tax Area ID Lookup. |
Call_Center_Country |
This information is required by Vertex. |
Call_Center_City |
This information is required by Vertex. |
Call_Center_State |
This information is required by Vertex. |
Call_Center_PostalCode |
This information is required by Vertex. |
Call_Center_StreetAddress |
This information is required by Vertex. |
Default_Warehouse |
This information is required by Vertex. You also use the Warehouses XML File to indicate the tax area ID of each warehouse where you make shipments. |
Default_Warehouse_Country |
This information is required by Vertex. |
Default_Warehouse_City |
This information is required by Vertex. |
Default_Warehouse_State |
This information is required by Vertex. |
Default_Warehouse_PostalCode |
This information is required by Vertex. |
Default_Warehouse_StreetAddress |
This information is required by Vertex. |
Configuring the Division and Company Codes
These fields in the Default Values by Company XML File enable you to override
the Company
and Division
specified in the QuotationRequest, InvoiceRequest,
and DistributeTaxRequest
messages that
Order Administration sends to Vertex.
Typically, the Order Administration company code and entity code matches the Vertex taxpayer code and entity level taxpayer code; however, if you specify a Company and/or Division in the Default Values by Company XML File, it overrides the actual company code and entity code. You might define an override if the Vertex taxpayer is already set up in Vertex and you need to configure Order Administration to map to the existing taxpayer.
-
If you do not specify a Company here: Regardless of whether you specify a Division here, Order Administration passes:
-
Company
: The actual company code. -
Division
: If the Pass Entity Code to Tax Interface (F69) system control value is selected, this is the entity code related to the source code on the order header. If the Pass Entity Code to Tax Interface (F69) system control value is not selected, no Division is passed.
-
-
If you specify a Company here but not a Division: Regardless of the setting of the Pass Entity Code to Tax Interface (F69) system control value, Order Administration passes:
-
Company
: The Company code you enter here. -
Division
: None.
-
-
If you specify both a Company and a Division here: Order Administration passes the
Company
code andDivision
code you enter here.

Changes effective immediately: Changes you make to the default values by company file take place immediately. It is not necessary to stop and restart Order Administration.
Warehouses XML File
Purpose: This file provides the list of warehouses from which you ship merchandise, so that Vertex can apply the appropriate tax rules for the shipping location.
File location and name: Like the default values by company
XML file, a copy of this configuration file is required for each company
that will use Vertex. The files are typically located under /domain/conf/cwdirectcpproperties/xslt/VertexWS/9.0,
where domain is the WebLogic domain directory for Order
Administration and 9.0 is the version of Vertex in use. The company
number in the file name should be zero-filled; for example, the file
name for company 6 is Warehouses_006.xml.
Sample files: Your Order Administration installation includes a sample warehouses XML file for company 49 and for company 51. You can use these samples as starting points to build warehouses XML files for your companies.
Information in this XML file
First WarehouseValue element: The first WarehouseValue element at the beginning of the file indicates that the file provides a list of warehouse ID’s and their corresponding tax area ID values:
<WarehouseValue>
<ID>Warehouse</ID>
<Value></Value>
</WarehouseValue>
Do not change the default element.
Default warehouse tax area ID: The first warehouse entry
in the file should indicate a warehouse ID
of 000
and your company’s default tax area ID. For example,
if the tax area ID is 220250100
, the first entry
is:
<WarehouseValue>
<ID>000</ID>
<Value>220250100</Value>
</WarehouseValue>
For each warehouse: For
each warehouse where you will be processing shipments, enter the ID that
identifies the warehouse code in Order Administration, and enter the
tax area ID of the warehouse. For example, if warehouse 3 has a tax
area ID of 140430510
, enter:
<WarehouseValue>
<ID>003</ID>
<Value>140430510</Value>
</WarehouseValue>
Example: The following example defines tax area ID’s for warehouses 1, 2, and 3:
<WarehouseValues>
<WarehouseValue>
<ID>Warehouse</ID>
<Value></Value>
</WarehouseValue>
<WarehouseValue>
<ID>000</ID>
<Value>220250100</Value>
</WarehouseValue>
<WarehouseValue>
<ID>001</ID>
<Value>700151420</Value>
</WarehouseValue>
<Wxml2zarehouseValue>
<ID>002</ID>
<Value>140430510</Value><
/WarehouseValue>
<WarehouseValue>
<ID>003</ID>
<Value>140430510</Value>
</WarehouseValue>
</WarehouseValues>
Note:
Make sure that the Default Warehouse (A04) is one of the warehouses included in this file.
Changes effective immediately: Changes you make to the warehouse XML file take place immediately. It is not necessary to stop and restart Order Administration.
Vertex Troubleshooting
Purpose: Troubleshooting information includes:
Error in order entry: The message Error calling Tax Interface, check configuration
in order
entry indicates that one or more of the required files were not found.
See Configuration Files for more information.
Processing Errors
Troubleshooting for the integration between Order Administration
and Vertex begins with checking the TRACE.log
and CWDirect.log
files.
- The
TRACE.log
file is typically located under/domain/conf/OMSFiles/Logs/TRACE/
on your application server, wheredomain
is the WebLogic domain directory for Order Administration. - The CWDirect.log file is typically located under
/domain/log/CWDirect.log
on your application server, wheredomain
is the WebLogic domain directory for Order Administration.
Note:
In addition to the errors written to log files, you will also see an error message in order entry if the extended order line price is over a million:Error occured on CALL to program Cwwebservice
. Vertex does not support tax calculation for order line values that
high.
Error in TRACE.log File | Explanation | How to Correct: |
---|---|---|
Initial Configuration Issues |
||
ERROR TRACE - Class not found: ERROR TRACE - TAX_INT web service error: - null |
A required class was not installed during the initial installation process. |
Contact your Order Administration representative. |
ERROR TRACE - AxisFault exception in invoke method of com.cwi.direct.interfaces.webservice.VertexWS: exception on AXIS invoke: User login failed: invalid_user. ; nested exception is: User login failed: invalid_user. |
Possible causes:
|
Check the contents of the Vertex User ID and Password and confirm that the user ID and password exist in Vertex and have authority to the correct partition in Vertex. See Set up Data within Vertex Vertex Setup and your Vertex documentation for more information. After you change the user ID and password in the Vertex User ID and Password, you need to stop and restart Order Administration. See Restarting Order Administration for more information. |
ERROR TRACE - AxisFault exception in invoke method of com.cwi.direct.interfaces.webservice.VertexWS: exception on AXIS invoke: SAX processing failed on input stream SAX processing failed when attempting to create new element. (parent element=com.vertexinc.tps.xml.calc.parsegenerate.builder.ParticipantData, new element=null, local element name=PhysicalOrigin |
No physical origin is being passed. The physical origin is the address of the warehouse for the order detail line. Possible causes:
|
|
AxisFault exception in invoke method of com.cwi.direct.interfaces.webservice.VertexWS: exception on AXIS invoke: SAX processing failed on input stream Non-fatal error detected during SAX parsing. Verify document against schema or contact document supplier. (URI=null, line number=30, error=cvc-datatype-valid.1.2.1: '' is not a valid value for 'integer'.) |
The Default Warehouse (A04) is not listed in the Warehouses XML File . |
Warehouses XML File: Confirm that the Default Warehouse (A04) is included in this file. |
Tax Calculation Failing After Initial Setup |
||
ERROR TRACE - AxisFault exception in invoke method of com.cwi.direct.interfaces.webservice.VertexWS: exception on AXIS invoke: ; nested exception is: java.net.ConnectException: Connection refused: connect; nested exception is: java.net.ConnectException: Connection refused: connect |
Order Administration can no longer reach Vertex. |
Contact your Order Administration representative. |
ERROR TRACE - AxisFault exception in invoke method of com.cwi.direct.interfaces.webservice.VertexWS: exception on AXIS invoke: An error occured during CalcEngine.calculateTax. This may be an incorrect use of the calculation engine. Please contact your software vendor. Error trying to calculate tax. Cannot find tax areas. Please verify that the address or tax area id provided for the location is correct and retry. |
The postal code passed in the tax request message from Order Administration is incorrect, or is associated with a city that does not exist in Vertex. To confirm, log onto Vertex and advance to the Tax Area Lookup Tool, then search for the shipping address that is causing the error. A message such as the following indicates that the postal code is incorrect:
|
Correct the postal code information in Order Administration. |
ERROR TRACE - AxisFault exception in invoke method of com.cwi.direct.interfaces.webservice.VertexWS: exception on AXIS invoke: ; nested exception is: java.net.SocketException: No buffer space available (maximum connections reached?): connect |
The Order Administration server is out of memory. |
Reboot the Order Administration server. |
ERROR TRACE - AxisFault exception in invoke method of com.cwi.direct.interfaces.webservice.VertexWS: exception on AXIS invoke: (404)Not Found; nested exception is: (404)Not Found |
The URL specified for Vertex in the Vertex URL property is incorrect. |
See Restarting Order Administration for more information. |
Miscellaneous Log Messages |
||
WARN TRACE - WARNING: Responses for DISTRIBUTE not found in configuration xml. |
The log includes this message when Order Administration requests tax information for an order that includes a tax override. |
No need to correct; message is informational only. |
TRACE - message: com.sun.xml.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from server: An unit based tax rule cannot be applied to a line item with a quantitiy of zero. Please ensure that the quantity is not zero and retry. Please see the server log to find more detail regarding exact cause of the failure. |
Certain states, such as Tennessee, require a quantity for tax calculation, and this error occurs when the quotation request includes a zero quantity for freight or additional freight charges. |
Add a new rule in Vertex to change the quantity to 1 for the related product classes. |
Tax Calculation Rules
Situation | Explanation |
---|---|
New settings in Vertex apply when you use the Vertex Transaction Tester, but not when Order Administration requests tax information |
If you have Vertex configured to cache information for improved performance, it might be retrieving tax rules from cached information when Order Administration requests tax information. Caching does not apply when you use the Transaction Tester. Consult your Vertex documentation for more information on configuring caching. |
An item on an order is not taxable based on its item or product class settings in Vertex, or on the Tax override flag for the order line; but there is still tax on the order |
Even if an item on an order is not taxable, freight, handling, gift wrap, additional freight, and duty can still be subject to tax. |
You receive an order that includes an item with a tax override through the generic order interface, but the order line is still taxed |
Even if the |
You make a change to the Vertex wsdl (Web Service Definition Language) File , but the changes do not take effect |
Before your changes take effect, you need to restart Order Administration. See Restarting Order Administration for more information. |
You change the user ID and password in the Vertex User ID and Password, but the changes do not take effect |
Before your changes take effect, you need to restart Order Administration. See Restarting Order Administration for more information. |