1. Release Notes
  2. Feature Summary

1 Feature Summary

The enhancements below are included in this release.

Column Definitions

SMALL SCALE: These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.
LARGER SCALE: These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.
CUSTOMER ACTION REQUIRED: Indicates if you must take action before these features can be used. These features are delivered disabled and you choose if and when to enable them.


FEATURE


SCALE

CUSTOMER
ACTION REQUIRED
SYSTEM MANAGEMENT ENHANCEMENTS
Job Controls and Monitoring

LARGE

Optionally, run the JOBCLN function as described.
Order Broker Integration Enhancements

LARGE

Run or schedule the BROKER_ORD process using the new periodic functions, in the same way you manage the existing BROKER process, and set the new property, as described.
Payment Reauthorization

LARGE

Schedule the REAUTH periodic function and select the new system control value, as described.
Use Status List Request in Pick Slip Generation

MEDIUM

Optionally, change the system control value, as described.
Pre-Order Processing

SMALL

None
Deposit Processing

SMALL

None
MODERN VIEW ENHANCEMENTS
Order Broker Line Statistics

SMALL

None
Modern View Build Information

SMALL

None
BROWSER ENHANCEMENT
Enhanced Browser Support

MEDIUM

Begin use of the new URL, as described.

Job Controls and Monitoring Enhancements

The following enhancements will enable you to monitor process activity across servers and better resolve job status.

Display Active Batch Jobs (DABJ)

With this release, the Display Active Batch Jobs screen (DABJ) displays batch jobs that are currently running across all servers. If a batch job is not displayed, it is not actually running, regardless of the status of the job on the Job Management screen, or the status of the process that submitted the job.

Additionally, the server information displayed on the screen has been updated to include:

  • The Host Name, indicating the server host name that is hosting the OMS application and is running the job identified by the row. The host is where the application physically resides (within an application server). The host may be a virtual machine (VM) or physical hardware.

  • The App Server Name, indicating the name of the actual application server instance that is running the job.

  • The Last Program, indicating the last program called by the job, for troubleshooting purposes.

Jobs submitted through the ProcessIn request message now display on the Display Active Batch Jobs screen, for consistency with other submitted jobs.

Display Job History (DJHY)

With this release, the server information displayed on the Display Job History screen (DJHY) has been updated to include:

  • The Host Name, indicating the server host name that is hosting the OMS application and is running the job identified by the row. The host is where the application physically resides (within an application server). The host may be a virtual machine (VM) or physical hardware.

  • The App Server Name, indicating the name of the actual application server instance that is running the job.

Purge Active Procedures Across Users (MACX)

The Purge Active Procedures Across Users screen (MACX) now restricts the ability to delete an active procedure for a job that is actively running on any server. If you attempt to delete a job and it is actively running, an error will be displayed.

When you use Purge Active Procedures Across Users to manually delete an active procedure for a job that is not running, the system writes a record in the User Audit table.

Use the JOBCLN Function to Resolve Job Status Across Servers

With this release, the JOBCLN periodic function has been changed to resolve jobs displaying incorrect statuses without requiring all servers be restarted.

The following will now occur when the job is run:

  • When started, checks to confirm that another instance of the job is not running.

  • Performs a status check and cleanup for:

    • Background async jobs (MBJC)

    • Integration layer jobs (IJCT)

    • Drop Ship (CDC) async job (WPBJ)

    • Other batch jobs displayed at the Job Management (My Jobs) screen

The status checks and cleanup performed include the following:

  • Resets the status of the job to be consistent with whether the job is currently running. For example, changes the status to ACTIVE if the job is running, and changes it to INACTIVE if the job is not actually running.

  • If the job requires an active procedure, confirms that there is an active procedure record when the job is running, or deletes any active procedure records when the job is not actually running.

  • Deletes additional Ending records for jobs if there is more than one.

  • Corrects the status of the job that is displayed at the Job Management screen.

  • Creates a Job History record if necessary when it changes the status of a job.

  • Writes a message to the APP.log about changes made.

  • Writes a message to the User Audit table about any active procedure changes.

Notes:

  • You might run the JOBCLN function when:

    • A server shuts down unexpectedly, or

    • Whenever a job status does not appear correct or consistent.

  • The changes made vary depending on the requirements of each job and its current status, including appropriate statuses, whether the job requires an active procedure, and how the job is displayed at the Job Management screen.

  • The JOBCLN function can only be run by a user flagged as a Security Administrator, with a User Rank of 1.

Integration Layer Processes (IJCT)

The Work with Integration Layer Processes option (IJCT) has been changed to restrict updating status incorrectly as follows:

  • Removed the Change Status option.

  • Changed the Start option to confirm that the process is not already running and, if so, display an error.

  • Changed the End option to confirm that the process is not already ended and, if so, display an error.

Note:

The JOBCLN periodic function should now be used to reset statuses and other data.

Async Background Job (MBJC)

The Work with Background Jobs (MBJC) screen has been changed to restrict updating statuses incorrectly as follows:

  • Removed the Change Status option.

  • Changed the Start option to confirm that the process is not already running and, if so, display an error.

  • Changed the End option to confirm that the process is not already ended and, if so, display an error.

Note: The JOBCLN periodic function will now be used to reset statuses and other data.

Drop Ship Background Jobs (WPBJ)

The Work with Drop Ship Background Jobs (WPBJ) has been changed to restrict updating statuses incorrectly as follows:

  • Removed the Change Status option.

  • Changed the Start option to confirm that the process is not already running and, if so, display an error.

  • Changed the End option to confirm that the process is not already ended and, if so, display an error.

Note:

The JOBCLN periodic function will now be used to reset statuses and other data.

Parent topic: Feature Summary

Order Broker Integration Enhancements

New BROKER_ORD Integration Layer Process

With this release, we created a new BROKER_ORD integration layer process in IJCT to submit new orders and send status updates for canceled orders to Order Broker. The existing BROKER integration layer process no longer handles these messages.

Additionally, the BROKER_ORD process:

  • is available at the Work with Job Monitor screen (WJMO),

  • will have the BROKER_ORD active procedure listed at the Purge Active Procedures Across Users screen (MACX) when running,

  • is listed at the Display Active Batch Jobs screen (DABJ) when running, and

  • has new periodic functions to start and stop the BROKER_ORD process.

Note:

Both the BROKER and BROKER_ORD integration layer processes need to be running if Order Management System is integrated with Order Broker.

To schedule the BROKER_ORD process, use the following periodic functions:

  • STRBRO (ILSTRTBROK): Starts the BROKER_ORD process.

  • ENDBRO (ILENDBROK): Ends the BROKER_ORD process.

BROKER Integration Layer Process Submits the Status List Request

With this release, the BROKER integration layer process now sends the status list request for updates from Order Broker, rather than the individual status inquiry request for each order.

When the BROKER process generates the status list request, it includes orders within each company based on their Order Broker status, sending all orders in a company that are in the same status before beginning to send orders in the next status. For example, it sends all orders in K status in company 1 before beginning to send orders in O status in company 1.

The sequence is:

  • Acknowledged (K)

  • Posted (O)

  • Polled (P)

  • Accepted (A)

After checking for orders in Accepted status, the process generates the fulfillments request.

Note:

Between processing each group of orders as described above, the process checks to see if the BROKER job is in Ending status. If so, it ends the job before processing the next group of orders by status.

Set Maximum Number of Orders in Status List Request

The BROKER process and pick slip generation will now use a new OROB_MAXIMUM_STATUS_LIST_REQUEST_ORDERS property, available in Work with Customer Properties (PROP), to determine the maximum number of request IDs to include per status list request. Defaults to 500, and should not exceed 1000.

Also with this release, the performance of the BROKER process has been enhanced.

Parent topic: Feature Summary

Payment Reauthorization

Reauthorize an Expired Credit Card

With this release, we added the option to attempt to reauthorize an expired credit card authorization when there is a pending fulfillment currently on the order.

A new REAUTH periodic function generates reauthorization requests for orders where there is at least one order line in a Printed status whose authorization date and time have passed. Note: This function will not run if the Periodic Process is named REAUTH_JOB.

A new system control value, Perform Reauthorization for Expired Authorizations (M61), controls whether the new REAUTH periodic function is enabled.

Criteria that control the selection of orders eligible for reauthorization include:

  • There is at least one line in a Printed status where the pick status is blank-Open, M-Manifest submission, O-CarryOver, P-Packed, R-Reprinted or S-Suspended.

  • Ship for pickup orders are included only if Payment at POS for Ship for Pickup Orders (L60) is set to N.

  • Store pickup orders are included only if Payment at POS for Store Pickup (M16) is set to N.

  • Retail pickup and delivery orders are not included.

  • The payment method must have Reauthorization days greater than 0 and not empty and the Card type must be Credit Card or Gift Card.The order must not have a system hold of AR, described below.

  • The authorization history record must be expired and not used:

    • It is considered expired if the elapsed days is equal to or greater than the the Reauthorization days defined for the pay type (WPAY). The system calculates the age of the authorization by determining the elapsed days (and time) between the current date and the authorization date. 

    • The status must be A (Authorized) or O (Authorized, but not yet used.)

  • The payment method must not be PayPal.

For each authorization history record that meets the above criteria, OMS will void the expired authorization history record and send a new authorization request message.

  • The amount to reauthorize is the amount originally authorized minus the amount partially deposited.

  • The amount will not be reduced based on status of the order lines.

  • If the amount is less than 1.00, and there is a value in Authorization Number for Authorizations Under $1.00 (I08), OMS will not send an authorization request and will create a new authorization history record specifying this authorization number.

If reauthorization is successful, a new authorization history record is created to indicate the reauthorization approval, as well as an Order Transaction history message. Normal processing continues for the order.

If the reauthorization is not successful and the authorization amount was greater than 1.00 but less than the pay type dollar limit set up on the credit card pay type and Default Credit Card Authorization Number for Soft Declines (F93) is populated, the authorization will be forced as if it was successful. A new authorization history record is created to indicate the reauthorization approval, as well as an Order Transaction history message. Normal processing continues for the order.

If reauthorization is not successful, the system:

  • Puts the order on hold with a system hold reason of AR (Declined Credit Card Reauthorization).

  • Voids any pending pick slips, and generates a trigger for a VOID CWPickOut message, if you are using the generic Pick Out API.

    • Voids only picks in M-Manifest submission, O-CarryOver, P-Packed, R-Reprinted or S-Suspended.

    • Drop ship picks will not be voided and no communication will be sent to external systems.

  • Creates an authorization history record to indicate the reauthorization failure, as well as an Order Transaction History message.

  • Sends an order status update message to Order Broker, if necessary, setting the Under Review flag to Y for each distinct request ID with an open line.

  • Generates a tickler, if tickler event rules are configured (WTEV).

  • For each sourcing Delivery or Retail Pickup order where the originating order was put on AR hold, the system will:

    • Put the order on hold with a system hold reason of AU (Broker Order Under Review).

    • Voids any pending pick slips, and generates a trigger for a VOID CWPickOut message, if you are using the generic Pick Out API.

      • Voids only picks in M-Manifest submission, O-CarryOver, P-Packed, R-Reprinted or S-Suspended.

      • Drop ship picks will not be voided and no communication will be sent to external systems.

Hold and Release Orders using OB Under Review setting

Checking the Under Review setting in Order Broker:

  • Pick slip generation puts an order on hold using a system hold reason of AU (Broker Order Under Review) if the Order Broker status list or inquiry response message indicates that the order is under review. This includes fulfilling orders created to fulfill an originating order.

  • The BROKER integration layer process removes the AU (Broker Order Under Review) if the response indicates that the order is no longer under review.

New hold reason codes created automatically: The new AR and AU hold reason codes are created automatically with this release. If there are existing hold reason records using these codes, they are overwritten, using the new descriptionAR and AU System Hold Restrictions

Orders on AR or AU system holds can only be released under the following conditions:

  • Orders on an AR system hold, can only be released with a valid authorization.

  • Orders on an AU system hold, can not be released manually. The order must be canceled or updated through the BROKER integration layer process once the Under Review flag is set to No in Order Broker.

Parent topic: Feature Summary

Using Status List Request in Pick Slip Generation

Use OROB Status Inquiry List Web Service (M05)

Changed this system control value to support the following settings for use in pick slip generation:

NO or blank (formerly N): Pick slip generation sends individual status inquiry requests for each eligible order to Order Broker. If the response from Order Broker indicates that an order or line is:

  • Canceled: No pick slip is generated, and the system puts the order on hold using the Order Broker Hold Reason (Cancel) (L02) system control value.

  • Under Review (and not canceled): No pick slip is generated, and the system puts the order on hold using the AU hold reason (BROKER ORDER UNDER REVIEW). This hold reason is created automatically.

  • Otherwise, pick slip generation continues and creates the pick slip for eligible order lines.

CANCELED (formerly Y): Pick slip generation uses the status list request for all eligible orders, with each request including no more than the maximum number of request IDs specified in the OROB_MAXIMUM_STATUS_LIST_REQUEST_ORDERS property, with the request specifying that the response should include orders only if their status is Canceled. If Order Broker indicates that an order or line is:

  • Canceled: No pick slip is generated, and the system puts the order on hold using the Order Broker Hold Reason (Cancel) (L02) system control value.

  • Otherwise, pick slip generation continues and creates the pick slip for eligible order lines, regardless of whether the order is flagged as Under Review.

ALL: Pick slip generation uses status list request for all eligible orders, with each request including no more than the maximum number of request IDs specified in the OROB_MAXIMUM_STATUS_LIST_REQUEST_ORDERS property. If Order Broker indicates that an order or line is:

  • Canceled: No pick slip is generated, and the system puts the order on hold using the Order Broker Hold Reason (Cancel) (L02) system control value.

  • Under Review (and not canceled): No pick slip is generated, and the system puts the order on hold using the AU hold reason (BROKER ORDER UNDER REVIEW). This hold reason is created automatically.

  • Otherwise, pick slip generation continues and creates the pick slip for eligible order lines.

Parent topic: Feature Summary

Pre-Order Enhancements

With this release, the PREORDER periodic function now supports releasing ship-for-pickup orders, in additional to brokered backorders.

Note:

Although Order Management System supports releasing both brokered backorders and ship-for-pickup orders to Order Broker in pre-order processing, not all fulfilling systems in Order Broker support the ship-for-pickup order type.

Parent topic: Feature Summary

Deposit Processing Performance

Deposit processing has been enhanced to increase performance.

Parent topic: Feature Summary

Order Broker Line Statistics

With this release, we added an Order Broker Lines option to the Batch Job Statistics page in Modern View to enable a system administrator to see that Order Broker records are being processed. This new option enables a user to display the number of Order Broker records in the currently selected company, broken out by current status. All order lines sent to or received from the Order Broker for shipment or customer pickup will be counted under the current status of the record.

Note:

You may use these statistics as a way for troubleshooting the integration with Order Broker. If status counts are not changing when you refresh, this may indicate a problem with the integration.

Parent topic: Feature Summary

Modern View Build Information

Added Modern View build information to the About the Application window in Modern View.

This window now includes a Modern View Build entry, indicating:

  • Date and time stamp, such as 20201016220043PM.

  • JET version, such as 8.3.0.

  • JRAF version, such as 8.3.0.

This information is not included in the About Application screen in Classic View.

Note:

You can display the About the Application window in Modern View by expanding the drop-down under the online help icon in the upper right corner of the screen, and selecting About Application.

Parent topic: Feature Summary

Browser Support

With this release, Order Management System Classic View and Modern View now support the current versions of the following browsers:

  • Mozilla Firefox

  • Microsoft Edge

  • Chrome (desktop)

  • Safari

Microsoft has deprecated Internet Explorer 11 in Windows 10 and recommends using Edge as the default browser. Refer to the Oracle Software Web Browser Support Policy for additional information.

Note:

Important: With this release, the URL to log into Order Management System no longer ends with OMS.html. If the URL was formerly https://SERVERNAME:PORT/jenasys/OMS.html, it is now https://SERVERNAME:PORT/jenasys.

Parent topic: Feature Summary