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 ScreenForms Management ScreenJob 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:  

  • This information is displayed only if the user’s Rank is set to 1 through Advanced Commands. See Administration Guide for more information.

  • Orders entered in a company flagged as inactive do not count towards the current order volume. If a company is flagged as inactive, the Menu Driver Screen displays a message indicating This company is flagged as inactive and should not be used to process live orders. See Working with Companies (WCMP) to review the Active company setting for a company. 

  • If the originating location for a retail pickup or delivery order is Order Administration, the system does not increase the order count for the order. The system identifies the originating location as Order Administration if the request_system_cd in the fulfillment response message matches the system code in the OROB System (K50) system control value. In this situation, the system prefaces the E-commerce order number in the Order Header Extended table with ORIG#: 9999-001, where ORIG#: indicates the order was created as a result of OROB fulfillment assignment, 9999 is the order number, and 001 is the ship to number.

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:

  • control information (metadata) to define message properties used to manage the message.

  • payload, or the actual data, in the message.

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

  1. A user or a process in Order Administration calls an outbound integration layer process to send information to an external system.

  2. 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.

  3. The system sends the message to the outbound queue defined for the integration layer process.

  4. 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

  1. 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.

  2. 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.

  3. 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:

  • Log in to the WebLogic Server Administration Console.

  • On the home page, locate the Services pane and click JMS Modules to advance to the Summary of JMS Modules page.

  • On the Summary of JMS Modules page, click the name of the JMS module used for Order Administration to advance to the Settings for JMS Module page.

  • On the Settings for JMS Module page, click the JMS resource used for Order Administration to advance to the Settings for JMS Resource page.

  • On the Settings for JMS Resource page, select the Connection Factories tab to display the foreign connection factory for Order Administration. The system defaults the Local JNDI Name defined for the connection factory to the JMS_QUEUE_FACTORY property.

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:

  • Use the following SQL command to create a queue table:

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.

  • Use the following SQL command to create a queue:

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.

  • Use the following SQL command to start the queue:

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:

  • PROCESS = the name of the Order Administration process that sends or receives the message.

  • DIRECTION = the direction of the message.

    • IN = the message is inbound to Order Administration.

    • OUT = the message is outbound from Order Administration.

Example:  

  • CUST_SRCH_OUT = The queue receives messages from the CUST_SRCH process in Work with Integration Layer Processes (IJCT) in Order Administration.

  • CUST_SRCH_IN = The queue sends messages to the CUST_SRCH process in Work with Integration Layer Processes (IJCT) in Order Administration.

3.

Queue information is delivered for the processes in Working with Integration Layer Processes (IJCT).

Verify the following:

  • On the Integration Layer Process screen, verify Message Queue defaults for the Communication type.

  • On the Work with Integration Layer Process Queues screen verify the queues that run for the process. The Inbound queue and/or Outbound queue is the name of the associated queue in the database used for queue processing.

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:

System Control Values

System Control Value Description

Use Auto Authorization Interface (C14)

Defines whether you are using the interface to electronically transmit authorization and deposit information for your credit card orders to an authorization service.

Consolidated Invoice (B49)

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.

On-line Authorizations (B89)

Defines whether the system performs online credit card authorization during order entry.

See Performing Online Credit Card Authorizations for an overview and required setup.

Maximum Number of Retries on Credit Card Orders (E74)

Determines the maximum number of times to attempt to authorize an order before flagging the order for cancellation.

Credit Card Authorization AVS Hold Exemption/Bypass (E61)

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.

Authorize Full Amount During Order Entry (G99)

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.

Authorization Number for Authorizations Under $1.00 (I08)

Defines the authorization number the system automatically applies to credit cards that require authorizations that are under one dollar.

Online Auth Verification Only (I96)

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 Values

Number Assignment Description

Transaction Sequence #

Assigns the next available number to the credit card authorization.

Displaying the Item Image

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.

Communication Method

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.

Order Types

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.

Pay Types

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.

Pick Slip Generation

If you wish to generate pick slips only for orders that contain pre-paid payment methods and/or credit cards that have received an authorization, you can create a pick slip generation template with the Preauthorized orders only field selected.

Notify Property Settings

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:  

  • You can also flag specific customers as tax-exempt in Order Administration by specifying a Tax identification number and Expiration date.

  • If the customer on an order is assigned to a customer class in Order Administration that does not correspond to a matching tax code in AvaTax, AvaTax calculates tax based on the tax code assigned to the product class.

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:

  1. 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.

  2. 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:

  • I = Invoice; use invoice tax calculations during billing.

  • O = Order; use order tax calculations during billing.

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

PurposeOrder 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.

Shows the screen specific link and 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.

Order Inquiry scan screen image

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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:

  1. 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,

  2. Entity: If a From email alias is specified here for the email notification type, use this address; otherwise,

  3. Company: If a From email alias is specified at the Change Company Screen (WCMP), use this address; otherwise,

  4. 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:

  1. 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,

  2. 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,

  3. 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:

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:

Additional system control values related to email generation: 

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.

  • The server might be blocking emails. Ask your system administrator if the virus scanner is currently blocking port 25, as this block can prevent emails from being distributed.

  • Check your “Junk” email folder to make sure that the system is not flagging the email as junk.

  • To send emails, the Order Administration application server must be set up as an email server.

  • Use the Testing Email Generation (UEML) menu option to generate a test email.

  • The Outbound XML version for the EMAIL_OUT process needs to be set to the highest available version to generate certain emails (backorder, soldout, stored value card, quote confirmation), because the system uses the CWEmailOut message to generate HTML email notifications, and these notification types require information that was added to the CWEmailOut message in later versions.

  • Confirm that the email configuration described under Email Generation Setup has been completed.

  • Confirm that the Email notification flag for the order type is selected and that the Send email flag at the Order Type Email Selection Screen is also selected.

  • Confirm that the XML only? flag for the email text template is not selected; if it is, the system generates the Outbound Email XML Message (CWEmailOut) rather than the actual email. See HTML Email or Outbound Email XML Message?

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

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

Question Answer

Which browsers can I use for Order Administration?

You can use the most current version of the following browsers:

  • Mozilla Firefox

  • Microsoft Edge

  • Chrome (desktop)

  • Safari

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:

  • Clear your browser cache or browser history, and then return to Order Administration.

  • If clearing your browser cache or history does not correct the issue, use a Disk Cleanup option for your PC, and then return to Order Administration.

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:

  • 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, you must clear your cache to remove the information from your cache so that the screen can display correctly.

  • Order Administration screens may not display information correctly if you are using Internet Explorer and Compatibility Mode is turned on.

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,

Calendar Prompt Icon

The current date is in bold; however, you need to select the date by clicking it. The current date is not selected automatically.

Calendar Prompt Window

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?

  1. Go to the properties for the desktop.

  2. Select the Settings tab.

  3. Confirm that the Screen Resolution is set to at least 1152 by 864 or higher. If the resolution is higher, confirm that the aspect ratio is the same (for example, 1280 by 800).

  4. Click the Advanced button.

  5. Confirm that the DPI setting is Normal Size (96 DPI).

How do I restart Order Administration?

See Restarting 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:

  • F3 = Exit

  • F4 = Prompt for valid values

  • F5 = Refresh the screen content

  • F6 = Create a new record

  • F9 = Accept entries or Submit a process

  • F11 = Reject

  • F12 = Return to the previous screen

  • F13 (shift + F1) = Exit the menu option

  • F21 (shift + F9) = Generate a listing

  • F24 (shift + F12) = Select a different company

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.

F14 shortcut hover

Note:  Shortcuts are not available on the system management screens (Document Management ScreenJob Management ScreenForms 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:

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:

  • 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:

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: 

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 (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:

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:

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:

This image shows the detail included in the logs.

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 LogOrder 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:

  • the processing that occurs in the Order Administration job scheduler

  • email notification processing

  • when a user creates, changes, or deletes a record in Order Administration

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:

  • an error occurs during processing

  • the job sends 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

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.

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).

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

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:

  • any outbound integration layer job that has program ILR0022 defined as its Outbound program, including any jobs that you create.

  • specific inbound integration layer jobs:

    • CUSTHIST

    • CUSTSRCH

    • INV_INQUIRY

    • INVTRANIN

    • ORDLINHIST

    • ORDTRNHIST

    • PROCESSIN

    • RETURNIN

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:

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:

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:

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.

  • 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 = this job runs queries not related to the other jobs listed on the Work with Job Monitor screen.

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 (Rules Icon).

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 (Rules Icon).

Refresh the screen with the most recent Update DateUpdate TimeTransaction 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:

  • Unscheduled = The rule has been created, but it not in use.

  • Scheduled = The rule has been created and scheduled, but is not currently running.

  • Running = The rule is actively running.

  • Ending = The rule is in the process of ending.

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:

  • Daily: the system monitors the job for this rule every day.

  • Weekdays: the system monitors the job for this rule every Monday, Tuesday, Wednesday, Thursday, and Friday.

  • Weekends: the system monitors the job for this rule every Saturday and Sunday.

  • Monday: the system monitors the job for this rule every Monday.

  • Tuesday: the system monitors the job for this rule every Tuesday.

  • Wednesday: the system monitors the job for this rule every Wednesday.

  • Thursday: the system monitors the job for this rule every Thursday.

  • Friday: the system monitors the job for this rule every Friday.

  • Saturday: the system monitors the job for this rule every Saturday.

  • Sunday: the system monitors the job for this rule every Sunday.

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:

  • Update Time: The system evaluates the job’s last update date and time to determine if the job meets the rule’s conditions.

  • Transaction Time: The system evaluates the job’s last transaction date and time to determine if the job meets the rule’s conditions.

  • Query: The system evaluates the results of the query specified for the rule to determine if the job meets the rule’s conditions.

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:  

  • Alert After is set to 10 minutes

  • Sleep Time is set to 5 minutes

  • Start Time is set to 08:00.

Result:

  • Based on the Sleep Time, the system first evaluates the job’s status at 8:05 (5 minutes after the start time). The number of minutes specified as the Alert After has not passed.

  • Based on the Sleep Time, the system then evaluates again at 8:10, and at that point the Alert After has been met. The system generates the alert.

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:

  • Alert After: How long to wait before generating the initial alert.

  • Re-alert After: How long to wait between checking whether to generate additional alerts.

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:  

  • Sleep Time is set to 5 minutes

  • Alert After is set to 5 minutes

  • Start Time is set to 8:00

  • Re-alert After is set to 10 minutes.

Result:

  • The system first evaluates the job’s status at 8:05 (based on the Sleep Time) and generates the first alert (based on the Alert After time of 5 minutes).

  • The system checks again at 8:10 (based on the Sleep Time) and finds that the Re-alert After time has not elapsed.

  • The system then checks again at 8:15 (based on the Sleep Time) and finds that the Re-alert After time has elapsed, so it generates another alert.

  • The next time that another alert will be generated is 8:25.

  • The system continues to check every 5 minutes, and generates the re-alert each time an additional 10 minutes has passed.

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:

  • Email: Send an email to the specified To Email.

  • Periodic Process: Run the specified periodic process. Note:When the Action Type is Periodic Process, define a From EmailSubjectTo Email, and Email Text to have the system send an email alert if the condition for the job monitor rule still exists after running the periodic function. The system will continue to send an email alert until the condition is no longer met or the end time is met.

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.

Order Orchestration Configuration process flow.

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:

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 the 

Order 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.

Send Order Administration or ORCE customer number to Order Orchestration? The Send ORCE Customer ID to OROB (M71) system control value controls whether to send the customer’s ORCE customer ID or the Order Administration customer number as the customer_no in the SubmitOrder request message to Order Orchestration. The ORCE customer ID is specified in the submit order request message to Order Orchestration only if:
  • 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

  • retail pickup

  • ship-for pickup if the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to NEVER or blank

You have confirmed shipment of the order from an Order Administration warehouse to the store.

Received by Store

  • retail pickup

  • ship-for pickup if the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to NEVER or blank

The order has been received by the store location but not yet picked up by the customer.

Partial Fulfill

  • retail pickup

  • store pickup

  • ship-for-pickup if the Use OROB for Ship for Pickup Fulfillment Assignment (M34) system control value is set to NEVER or blank

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:

  • 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:

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:

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

Purpose: Use the Payment Configurations page to configure the merchants and payment methods used through integration with Oracle Retail EFTConnect. The Work with Authorization Service (WASV) option displays the merchant accounts that you create and work with in the Payment Configurations page.

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:

  • the From company number whose data you wish to copy.

  • the To company number.

  • Y or N setting indicating whether the system should delete the data in the To company before copying.

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

  • Clears (updates to 0) all daily buckets.

  • Clears (updates to 0) the TD (today) fields in all tables.

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.

See Order Status and Activity Reports.

DSLJRN

ACR0216

 

Daily

Daily Sales Journal

Generates the Daily Sales Journal.

See Order Status and Activity Reports.

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 arrival date - reservation lead days = today’s date, then the system reserves the stock and updates the Future order flag to N.

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.

See Working with the Marketing Download Extract.

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.

See Working with Interactive Reservation (MIRV).

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.

See Printing the Sales Journal (PDSJ).

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:

  • there are no open orders for the customer.

  • there are no open refunds for the customer.

  • there are no open returns for the customer.

  • there is no open A/R for the customer.

  • there are no open ticklers for the customer.

  • there are no catalog requests for the customer.

  • there are no open memberships for the customer.

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:

  • JOBHISTORY table where the End Date is greater than the number of days configured in the oms.job.history.purge.retain.days property.

  • JENASYSJOB table where the End Date is greater than the number of days configured in the  oms.job.purge.retain.days property.

  • JOB_RUN_HISTORY table where the End Date is greater than the number of days configured in the oms.job.history.purge.retain.days property along with all previous matching job records to that job as those would not have an End Date.

  • JOB_RUN_HISTORY table including related record in JENASYSJOB where the End Date is empty AND the job is NOT running.  If the job is done and the last record didn't get any End Date populated, purge that record and any previous related records to that job.

    If a record is found without an End Date is not running, use the Start Date and only if that is greater than the number of days configured in JOB_HISTORY_PURGE_DAYS property to determine if it will be purged.

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:

  • have not had any activity for the Order Purge Days (C62) defined in the System Control table. For example, if the purge days is 365, a closed or canceled order will be eligible for purging if the order has not been entered, shipped, or maintained for one year. The system checks the Order Transaction History table for the most recent activity.

  • do not have any pending returns or refunds.

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

  • Resets the reserved quantity of items in inventory, as stored in the Item Warehouse table. The system uses the information in the Reserved Order Line table to determine the correct quantities of items reserved on open or held orders. See Reset Reserve Quantity (MRQR).

  • Resets the backorder quantity of items in inventory, as stored in the Item Warehouse table. See Reset Backorder Quantity (MRBO).

  • Resets the SKU open quantity, On hold quantity, and Quantity order direct ship in the SKU table based on the current open orders for the SKU. See Reset SKU Open Order Quantity (MRSO).

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:

  • Selects all open (Status is A or O) Authorization History records whose authorization service is eligible for authorization reversal (the Send authorization reversal field for the Merchant Account through the Payment Configurations option in Modern View is selected).

  • For each record selected, the system calculates the age of the authorization by determining the elapsed days between the current date and the authorization date.

  • If the elapsed days is equal to or greater than the Reauthorization days defined for the pay type, and the authorization service defined for the pay type allows authorization reversals (the Send reversal for the authorization service is selected), the system sends an authorization reversal request to the authorization service.

  • The system creates an Authorization History Reversal record to indicate that the authorization reversal request was attempted. If the authorization service accepts the reversal request, the system updates the record with the date of the approval.

Note:

  • This function applies only to credit cards configured through the Payment Configurations option in Modern View. Note that this function applies only to credit cards that are configured through the Payment Configurations option in Modern View. It does not apply to gift cards or to PayPal.

  • You should not use this function if your payment provider, such as Adyen, sends a temporary PENDING status for voids (reversals), because the REVERSE periodic function does not create the authorization header record required by the EFTSTA periodic function when it checks the status of pending transactions.

RFRECON

PFR0008

 

Monthly

Refund Reconciliation and Purge

Purges refund checks once you have reconciled or voided the checks. Generates the Check Reconciliation List.

See Reconciling Checks (MREC).

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.

See Releasing Orders from Time Hold.

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.

See Integration Layer Processes.

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.

See Starting the Background ASYNC 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

See Placing Suspended Stock (SUSP).

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

  • Updates all of the fields defined in the Order Control Summary table for the current transaction date.See Reviewing Operations Control Summary (FLSH)
  • Updates the actual value fields and Last updated fields defined in the Threshold Values table.

  • Monitors the threshold values to determine if a threshold has been breached.

  • For each breached threshold that has an email address defined and whose Email interval is reached, generates a Threshold Monitor Breach email.

  • Updates the actual value fields and Last updated fields defined in the Threshold Values table.

  • Monitors the threshold values to determine if a threshold has been breached.

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:

  • OO tickler event to determine if any open orders qualify for an OO event rule. Also, determines if any existing OO ticklers can be resolved. See OO (Aged Open Orders) Event Processing.

  • UP tickler event to determine if any unconfirmed pick tickets qualify for a UP event rule. Also, determines if any existing UP ticklers can be resolved.See UP (Unconfirmed Pick Tickets) Event Processing.

  • Next notification date for an existing open or in process tickler to determine if the system sends an email to the tickler supervisor notifying him of the aged tickler.

See Workflow Management Overview and Setup.

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.

See Work with File Uploads (WUPL) and Price Code Upload.

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.

See Work with File Uploads (WUPL) and Promotion Upload.

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.

See Working with Vendor Upload (LVUP).

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:

  • RCVD and Confirmed if the response is ACCEPT and update deposit transaction history.

  • RCVD and Unconfirmed if the response is DECLINE/ERROR and update deposit transaction history.

  • PENDING:

    • If the ELO_POLL_COUNT_THRESHOLD in CPRP has not been exceeded, increase the poll count by 1 and leave the record in SENT status.

    • If the ELO_POLL_COUNT_THRESHOLD in CPRP has been exceeded, set the transaction to RCVD and UNCONFIRMED, and update deposit transaction history.

Afterward, when you process deposits through SDEP:

  • If the record is confirmed, it is included in the totals on the Auto Deposit Confirmation report.

  • If the record is unconfirmed, it is included on the Unconfirmed Deposits Listing report. You can work with unconfirmed deposits through the Manage Rejected Deposits option in Modern View.

Note:

  • 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.

  • You can run this job as often as needed; however, since the poll count increases each time the job runs, running it more often increases the likelihood of exceeding the ELO_POLL_COUNT_THRESHOLD.

  • The reports mentioned above are generated through deposit processing.

  • The Manage Rejected Deposits option displays unconfirmed deposit records only after you run deposit processing.

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.

See Printing and Interpreting Refund Due Lists (MRDU).

REFPROC

CSR0533

 

Monthly

Refunds Processed

Generates the Processed Refund Register.

See Printing the Processed Refund Register (PPRR).

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:

  • Produces the Stored Value Card Credit Register.

  • Writes an order transaction history message: F Stored Value Card refund created.

  • Adds the stored value card item defined in the Default SVC Refund Item Number (I73) system control value to the order at no charge and performs pick slip preparation. Note: The system will not generate a stored value card refund unless the stored value card refund item has available inventory. If the item does not have available inventory, the stored value card refund remains unprocessed.

  • Generates a pick slip for the stored value card item if the Default Pick Generation Template for SVC Refund Processing (I75) system control value indicates a pick slip generation template.

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:

  • the stored value card was declined by the service bureau for activation

  • the stored value card was billed without a number assignment

See Stored Value Card Purchase and Activation.

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.

See Printing the Carryover Report (PCOR).

LOBSTAT

PFR0034

 

Daily

Reset Line of Business Stats

Updates line of business order queue statistics.

See Updating the 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

  • Position 1 = Set to Y or y if the store cross-reference records should be created with the Ship for Pickup flag selected; otherwise, you would typically set the first position to N.

  • positions 2-11 = The code identifying the system associated with the locations. Must be a valid system code in Order Orchestration.

Example:  If the parameter is set to NPOS, the periodic function imports location records for system POS in Order Orchestration, and leaves the Ship for pickup flag for each imported location unselected.

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:

  • the Create Generic Inventory Download Trigger Records (I32) system control value is selected.

  • the record matches the trigger rules for the INV_DOWNLD process in Integration Layer Job Control (IJCT).

  • there is at least one Item Warehouse record that matches all criteria.

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.

See Printing Drop Ship Reports (PDSR).

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.

See Working with Vendor Upload (LVUP).

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:

  • Promotion

  • Promotion Discount

  • Promotion Customer

  • Promotion Item Exclusion

  • Promotion BOGO

  • Promotion Item Category

  • Promotion Source

  • Promotion BOGO by Price Code

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:

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.

  1. Log in to the WebLogic Server Administration Console. The user ID you log in with must be part of the Administrators group.

  2. On the home page, locate the Environment pane and click Clusters to advance to the Summary of Clusters page.

  3. On the Summary of Clusters page, click the name of the cluster used for Order Administration to advance to the Settings for Cluster page.

  4. 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.

  1. 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.

  2. Use the Working with Periodic Processes (WPPR) menu option to assign the periodic function(s) to a periodic process.

  3. 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.

  • Now = Execute the periodic process immediately. Note: If you select Now, the system does not add the periodic process to the Job Scheduler.

  • Once = Schedule the periodic process to run once, and only once, at a specified date and time in the future.

  • Daily = Schedule the periodic process to run once a day at a specified time.

  • Weekly = Schedule the periodic process to run once a week, at a specified time, on a specified day of the week.

  • Monthly = Schedule the periodic process to run once a month on a specified day and time.

  • Month Start = Schedule the periodic process to run once a month on the first day of the month at a specified time.

  • Month End = Schedule the periodic process to run once a month on the last day of the month at a specified time.

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:

  • Now = You do not need to define additional parameters.

  • Once = You must specify the Date and Time to execute the process. The system validates that the Date is greater than or equal to today. If you enter today's date, the system validates that the Time is greater than or equal to the current time.

  • Daily = You must specify the Time to execute the process.

  • Weekly = You must specify the Time and Day of week to execute the process.

  • Monthly = You must specify the Time and Day of month to execute the process.

  • Month Start = You must specify the Time to execute the process.

  • Month End = You must specify the Time to execute the process.

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.

  • If the periodic process is scheduled to execute immediately (you selected Now in the Frequency field), select Execute or Execute & Save Overrides to execute the periodic process and optionally, save the job parameters.

  • If the periodic process is scheduled to execute at a specified time in the future (you selected a value other than Now in the Frequency field), select Schedule. The system adds the periodic process to the job scheduler and does not execute the periodic process until the specified time is reached.

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.

  • Select Once for the Frequency.

  • Enter the current date in the Date field.

  • Enter 190000 (7 PM in military time) in the Time field.

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:

  • Select Once for the Frequency.

  • Enter the current date in the Date field.

  • Enter 150000 in the Time field.

Second Schedule:

  • Select Once for the Frequency.

  • Enter tomorrow's date in the Date field.

  • Enter 080000 in the Time field.

Execute the periodic process every morning at 6 AM.

Example:  Start asyncs every morning at 6 AM.

  • Select Daily for the Frequency.

  • Enter 060000 in the Time field.

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:

  • Select Weekly for the Frequency.

  • Select Monday for the Day of week.

  • Enter 060000 in the Time field.

Second Schedule:

  • Select Weekly for the Frequency.

  • Select Tuesday for the Day of week.

  • Enter 060000 in the Time field.

Third Schedule:

  • Select Weekly for the Frequency.

  • Select Wednesday for the Day of week.

  • Enter 060000 in the Time field.

Fourth Schedule:

  • Select Weekly for the Frequency.

  • Select Thursday for the Day of week.

  • Enter 060000 in the Time field.

Fifth Schedule:

  • Select Weekly for the Frequency.

  • Select Friday for the Day of week.

  • Enter 060000 in the Time field.

Run the periodic process every week on Mondays at 10 AM.

Example:  Run the weekly status reports every Monday at 10 AM.

  • Select Weekly for the Frequency.

  • Select Monday for the Day of week.

  • Enter 100000 in the Time field.

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.

  • Select Monthly for the Frequency.

  • Enter 25 in the Day of month field.

  • Enter 190000 in the Time field.

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.

  • Select Month Start for the Frequency.

  • Enter 080000 in the Time field.

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.

  • Select Month End for the Frequency.

  • Enter 210000 in the Time field.

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:

  1. Select the My Jobs icon (My Jobs Icon) in the upper right area of a screen) to advance to the Job Management screen.

  2. 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.

  • If the frequency is Once, the schedule displays as: At HH:MM:SS on DD/MM/YYYY. For example: At 12:30:00 on 04/05/2007.

  • If the frequency is Daily, the schedule displays as: At HH:MM:SS every day. For example: At 12:30:00 every day.

  • If the frequency is Weekly, the schedule displays as: At HH:MM:SS every week on DAY. For example: At 12:30:00 every week on Monday.

  • If the frequency is Monthly, the schedule displays as: At HH:MM:SS every month on day XX. For example: At 12:30:00 every month on day 15.

  • If the frequency is Month Start, the schedule displays as: At HH:MM:SS every first day of the month. For example: At 12:30:00 every first day of the month.

  • If the frequency is Month End, the schedule displays as: At HH:MM:SS every last day of the month. For example: At 12:30:00 every last day of the month.

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:

  • someone has deactivated and then reactivated the job scheduler.

  • the periodic process has been submitted to the job scheduler, but has not yet been executed.

  • the server has been restarted and the job has not run yet.

Alphanumeric, calculated by the system; display-only.

Status

The current status of the scheduled job.

Valid values are:

  • SCH = Scheduled. The job is actively scheduled and will run at its next scheduled time, defined in the Next run field.

  • INACTIVE = Inactive. The job is not on the schedule and will not run until it is activated.

  • ERROR = Error. The job could not be scheduled due to some error. The system writes a description of the error to the Application log (APP.log). Possible error reasons:

  • by the time you select to schedule the job on the Second Execute Periodic Process Screen (Selecting Functions), the scheduled time has passed.

  • You deactivated the job scheduler, and by the time the job scheduler was reactivated, the time the scheduled job was supposed to run has passed and it is not scheduled to run again. For example, it was supposed to run one time today at 12:00:00, but at that time the scheduled job was INACTIVE.

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:

  • removes all of the scheduled jobs from the schedule and updates their status to INACTIVE.

  • updates the Next run and Last run fields for each scheduled job to UNKNOWN.

  • will not execute any jobs until you reactivate the job scheduler.

Note:  

  • If you schedule a new job after you have deactivated the job scheduler, the system adds the job to the scheduler in an active, or scheduled (SCH), status.

Activate each job in an Inactive status that is scheduled to run

Select Activate Schedule.

The system:

  • updates all jobs that are in an INACTIVE status to a SCH (scheduled) status and adds them back to the job schedule.

  • updates the Next run field to the next time each job is scheduled to run.

Refresh job schedule on the screen

Select Refresh Schedule.

The system:

  • removes any scheduled jobs that are no longer scheduled to execute at a future time.

  • adds any newly scheduled jobs that are scheduled to execute at a future time.

  • Updates the Next run, Last run, and Status fields for existing scheduled jobs.

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.

  • Periodic processes selected to run Now run immediately and are never included in the job scheduler.

  • The Next run time for the periodic process has passed and the job was not scheduled to run again.

Why is the Last run field set to UNKNOWN?

  • The periodic process has been submitted to the job scheduler, but has not yet been executed.

  • The job scheduler has been deactivated, which updates the Last run field to UNKNOWN.

  • The server has been restarted and the job has not run yet.

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.

  • If the job queue is a single threaded queue, the job will fall behind any other jobs that are already waiting to process in that queue.

  • If the job queue is a multi threaded queue, the job will execute immediately.

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?

  • By the time you select to schedule the job on the Second Execute Periodic Process Screen (Selecting Functions), the scheduled time has passed.

  • You deactivated the job scheduler, and by the time the job scheduler was reactivated, the time the scheduled job was supposed to run has passed and it is not scheduled to run again. For example, it was supposed to run one time today at 12:00:00, but at that time the scheduled job was INACTIVE.

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:

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.

  • 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

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:  

  • You can also flag specific customers as tax-exempt in Order Administration, and specifying a Tax identification number and Expiration date.

  • 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.

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:

  1. 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.

  2. 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.

  3. 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

  4. 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.

  5. 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 and Division code you enter here.

Steps for configuring the Division and Company Codes.

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, where domain is the WebLogic domain directory for Order Administration.
  • The CWDirect.log file is typically located under /domain/log/CWDirect.log on your application server, where domain 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:

No tax areas were found during the lookup. The address fields are inconsistent for the specified asOfDate. (Street Information=24 PRIME PKWY, Postal Code=01701, City=NATICK, Sub Division=null, Main Division=MA, Country=USA, As Of Date=20060627)

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.

  1. Correct the URL in the Vertex URL property.

  2. Stop and restart Order Administration.

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 tax_override flag is set to Y in the inbound order message, Order Administration does not apply a tax override unless the inbound order message also specifies a tax amount greater than zero for the order line.

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.