2 Feature Summary
The enhancements below are included in this release.
Noteworthy Enhancements
This guide outlines the information you need to know about new or improved functionality in the Oracle Retail Order Management Suite Cloud Service update and describes any tasks you might need to perform for the update. Each section includes a brief description of the feature, the steps you need to take to enable or begin using the feature, any tips or considerations that you should keep in mind, and the resources available to help you.
Column Definitions
-
Feature: Provides a description of the feature being delivered.
-
Module Impacted: Identifies the module associated with the feature, if any.
-
Scale: Identifies the size of the feature. Options are:
-
Small: These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.
-
Medium: These UI or process-based features are typically comprised of field, validation, or program changes. Therefore the potential impact on users is moderate.
-
Large: These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.
-
-
Delivered: Is the new feature available for use immediately after upgrade or must the feature be enabled or configured? If no, the feature is non-disruptive to end users and action is required (detailed steps below) to make the feature ready to use.
-
Customer Action Required: 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 | Module Impacted | Scale | Delivered | Customer Action Required? |
|---|---|---|---|---|
| New and Updated Features | ||||
| Order Administration Cloud Service | ||||
|
Order Administration: EFTConnect CyberSource Decision Manager Authorizations |
Order Administration and EFTConnect |
Small |
No |
Yes |
|
Order Administration – Sales Audit Integration |
Large |
No |
Yes |
|
|
Order Administration – Modern View Contact Center |
Small |
No |
Yes |
|
|
Order Administration – Modern View Contact Center |
Small |
Yes |
No |
|
|
Order Administration – Modern View Contact Center |
Medium |
Yes |
No |
|
|
Order Administration |
Small |
Yes |
No |
|
|
Order Administration: Oracle Digital Assistant (ODA) Property |
Order Administration |
Small |
No |
Yes |
|
Order Orchestration Cloud Service |
||||
|
Oracle Retail Store Inventory Operations Cloud Service (SIOCS) Integration |
Order Orchestration – Inventory Integration |
Small |
No |
Yes |
|
EFTConnect Cloud Service |
||||
|
EFTConnect |
Small |
Yes |
No |
|
Order Administration Enhancements
Order Administration: EFTConnect CyberSource Decision Manager Authorizations
With this update, authorizations that were placed in a Decision Manager REVIEW status during an authorization with CyberSource through an Ecommerce system now support receiving back a REJECT or ACCEPT response using the Check Status of Review Authorizations From EFTConnect (EFTFRD) periodic function.
Previously, Order Administration only checked for a change in status on records that were in REVIEW status when the original authorization was sent from Order Administration to EFTConnect CyberSource because the transaction had to be already in EFTConnect and as those order payment methods would have been on a “PF” system hold.
Now, order payment methods passed with specific data in the Order API are used to identify a record in REVIEW status and put into the proper state in Order Administration, so that it can be picked up by the EFTFRD periodic function for checking the status. The Order API must include the following information for the order payment method to be identified as a payment under Decision Manager REVIEW:
-
The order payment method is an EFTConnect pay type.
-
The vendor_response code is an EFTConnect Result Code of 32 or 33.
-
The transaction_id and auth_number are populated.
-
The Use Fraud Checking is selected on the Payment Configurations Merchant Account screen for the EFTConnect account associated to the pay type.
A new service is available through EFTConnect 25.1.201.1 and above to leverage the CyberSource transaction_id for checking the status.
Note:
This is only available for EFTConnect CyberSource. Adyen and OPI support is in development planning.For order payment methods that meet the requirements, the system will apply the following holds and be included when the EFTFRD periodic function is run:
-
FS (Fraud Scoring Hold) Order Header System Level Hold
-
PF (Payment Fraud Scoring Hold) Pay Type System Level Hold
Upon receiving the response back from EFTConnect, the system will follow the logic for all orders that are on the ‘PF’ hold:
-
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 the result is ACCEPT, the order and pay type holds will be released and the order can now follow normal processing.
-
If a '404' HTTP Response is received back, this indicates it's an invalid transaction_id and should not be resent again. OACS will update the holds to:
-
Order Header System Level Hold = AT (CREDIT CARD AUTHORIZATION HOLD)
-
Pay Type System Level Hold = AV (UNAVAILABLE TO IDENTIFY)
-
Order Administration: Sales Audit (ReSA) Liability Integration
With this update, several enhancements have been introduced to improve the integration with the Sales Audit (ReSA) module of the Oracle Retail Merchandising Foundation Cloud Service, including the ability to manage liability transactions for Advance Capture payments.
ALERT: The Outbound XML Message Version must be set to 9.0 for the INVOIC_OUT Integration Layer Job in IJCT when using the ReSA Liability Integration.
-
Introduced Liability Integration for Advance Capture Payments
-
Liability Transaction Support: Liability transactions (creation and reversal) are now supported for Advance Capture payments, which includes online banking and similar pre-captured payment types.
-
LIT Trigger Records with Key Prefixes
-
LIA: Created when Advance Capture payments are added to an order (liability creation).
-
LIR: Created when Advance Capture overpayments are refunded (liability reversal – overpayment refunds).
-
LIW: Created when Advance Capture payments are written off (liability reversal – write-offs).
-
-
-
New Integration Layer and Configuration Options
-
New System Control Value: "Payment Liability Integration Format" allows for the enabling/disabling of the liability integration feature. When set to RTLOG, liability triggers are generated and processed. (Note: If using the liability integration and the existing ReSA integration for Sale and Return transactions, the INVOIC_OUT job must use outbound XML version 9.0 or higher.)
-
New Number Assignment (A75): Sequence number for RTLog transactions now uses a dedicated number wheel entry for consistent and unique transaction numbering. This applies to all RTLog transactions including, but not limited to, liability transactions.
-
New Integration Job (IJCT Process): The LIABIL_OUT process handles all liability-related triggers and orchestrates the staging of liability transactions in the INT_RESALOG table, which are later included in the RTLog export to ReSA.
-
Control and Resiliency: New periodic functions allow for scheduling the start (STRLIA) and stop (ENDLIA) of the liability integration job. The job is also resilient against server restarts and can be cleaned up automatically if interrupted.
-
Purge Logic: Liability trigger records are now included in system-controlled purges, ensuring no data buildup in staging tables.
-
-
Updated Data Mapping and RTLog File Structure
-
Enhanced THEAD Record: The RTLog file's THEAD record has been extended to 593 characters to add four new reference fields, allowing for improved tracking and reconciliation.
-
Transaction Numbering: All relevant transactions (SALE, RETURN, ADJUSTMENT, and PREPAY) now use the next sequential number from the new number wheel instead of the invoice number, ensuring consistency across the system.
-
Reference Fields: Reference fields now capture key data, such as the OACS Order Number or Invoice Number, to support improved auditability.
-
-
Liability Transaction Processing Logic
-
Record Creation: For each liability event (add, overpayment refund, overpayment write-off), three records are created in the INT_RESALOG table:
-
THEAD: Transaction header, including detailed reference information.
-
TTEND: Tender details per Advance Capture payment, with appropriate field values (signs for creation [P] or reversal [N], tender type group, amounts, and last four digits for cards as per configuration).
-
TTAIL: Transaction tail summarizing record counts.
-
-
Multi-payment Handling: When an order includes multiple Advance Capture payments, a separate TTEND record is created for each payment.
-
-
Special Scenarios and Integration Improvements
-
Refund Payment Flexibility: Liability triggers are created for overpayment refunds issued in the form of a check or stored value card credit when the original payment was Advance Capture.
-
Suppression of Records: Overpayment refund credit invoices are suppressed from INT_RESALOG to prevent duplicate posting of the reverse liability transactions.
-
Partial Write-off Guidance: Due to system limitations, multiple partial write-offs against a single rejected deposit are not recommended, as this may overstate liability reversal amounts.
-
These enhancements collectively deliver greater accuracy, flexibility, and compliance for customers managing liability accounting in OACS when using Advance Capture payments and integrating with ReSA. For detailed configuration and usage guidance, see the updated Oracle Retail documentation and online help resources.
Note:
Currently this integration is limited to Online Banking payments submitted through the Order API (payment_captured=Y).
Note:
Order Administration has known limitations when using consolidated invoice, and/or when resetting a trigger record manually through WOIT that could cause a duplicate transaction to be sent in the RTLog. An enhancement to correct this functionality is in active development.Order Administration: Modern View Order Summary Performance Enhancements
With this update, Modern View Order Summary performance has been improved to improve switching between tabs and performing functions, especially on large orders.
The following is a short summary of benefits:
-
Users can suppress non-critical snackbars entirely.
-
More stable and scalable behavior due to fewer backend round-trips and optimized data handling. The system has been enhanced to gather information behind the scenes when you view an Order Summary, especially for big or complicated orders.
-
Cleaner, more maintainable code paths that lower regression risk.
Suppress Non-Critical Snackbars
MV Preferences now allow Time Before Auto-Dismiss = 0 seconds. When set to 0, auto-dismiss snackbars are not shown; required/critical snackbars still display. All users, by default, are set to 5 seconds.
User benefits include the following:
-
Less distraction during high-volume workflows (for example, Order Unlock, Add Line, Edit Line, Edit Ship To).
-
Per-user control – no need to reconfigure.
Enhanced Data Loading Between Tabs
Opening each tab in a MV Order now calls only the necessary service. Unnecessary calls to previous-page services (for example, orderinfo, returns) have been removed.
User benefits:
-
More efficient tab loads and navigation between tabs.
-
Reduced backend traffic improves responsiveness under load.
Optimized Order Summary to Load Faster and More Reliably
The system now fetches data for many items once instead of looking up information for one item at a time. Data is now organized in a way that enables an improved and more reliable search.
User benefits:
-
Large orders now load in less time, as a result of improved information collection from the database, so you spend less time waiting. Previously, our system would often ask the database for information many times, which slowed things down. Now, smarter methods are used to gather all the needed data at once, making the entire process much faster.
-
There are fewer delays and interruptions, so your work is smoother and more efficient.
-
Order Summary is now more dependable, and the improvements make it easier to use.
Order Administration: Price Override with the Price Table Override Reason
Price table premiums (that is, free gifts) can now be applied when the price override reason code is populated, the order detail line matches the value in Price Table Level Override Code (E05) system control value, and there is an actual price populated. In addition, the actual price is used to override the price on the line without using the price table levels.
Note:
The Maximum Level setting in the Price Tables is not supported with this feature.
Order Administration: Oracle Digital Assistant (ODA) Property
An admin property has been added to hold the allow list ODA URL for the Oracle Digital Assistant (ODA) integration. The value is delivered and should only be overridden if needed by a cloud administrator.
oms.oda.cloud.service.csp.url = wss://*.digitalassistant.oci.oraclecloud.com
Order Orchestration Enhancements
Order Orchestration: Oracle Retail Store Inventory Operations Cloud Service (SIOCS) Integration
With this update, Oracle Retail Store Inventory Operations Cloud Service (SIOCS) Integration has been modified to support calling the Inventory REST service.
Setting Up the Integration
The Add/Edit/View External Service has been modified for the SIOCS Integration Inventory External Service Type:
-
"Authentication Type" has been added with the following options:
-
Application OAuth
-
Basic
-
OAuth (default for Add)
-
-
Based on the selection for the Authentication Type, additional fields are displayed or hidden:
-
Application OAuth (Recommended selection):
-
Client ID is display only and has the value of the OOCS Client.
-
Scope is available and optional (defaults to empty).
-
-
Basic:
-
User ID and Password are both available and required.
-
-
OAuth:
-
OAuth URL is available but is not required. If there is no value passed in, OAuth will internally pick up the IDCS URL in which OOCS is deployed. If specified, will be used.
-
Scope is available and optional (defaults to empty).
-
Client ID and Client Secret are both available and required (defaults to empty).
-
-
-
A new integration to the SIOCS REST Inventory service will be used for both Application OAuth and OAuth authentication options.
-
When Application OAuth is selected, the system will use the OOCS Client ID and Client Secret for authenticating.
-
Existing timeout, threshold and wait times configured for the service will be used.
Important:
The SIOCS Inventory REST service requires a product and location to be passed into the request to retrieve inventory from OOCS. This is different from the SOAP message. The SOAP message is only sent in a product to retrieve all locations with inventory and automatically creates the new product location record. If the product location does not exist yet, it will not update the inventory with this call.
-
-
The existing SOAP integration will continue to work when configured for Basic authentication.
EFTConnect Enhancements
EFTConnect: Removed Unsupported Symbols
With this update, symbols that cause declines with payment processors, such as CyberSource, have been removed from the first and last name attributes of the billing and shipping addresses when mapping to the authorization and authorization + capture messages.
Symbols removed are:
-
# Number sign or Hash
-
* Asterisk
-
_ Underscore