1 Feature Summary
Oracle Retail Store Inventory Operations Cloud Services includes the following applications:
-
Oracle Retail Enterprise Inventory Cloud Service (EICS)
-
Oracle Retail Store Operations Cloud Service (SOCS)
This chapter describes the feature enhancements in this release.
Note:
Defect fixes from prior monthly Hot Fixes are also included in this 26.1.201.0 update.
Noteworthy Enhancements
This guide outlines the information you need to know about new or improved functionality in the Oracle Retail Store Inventory Operations Cloud Services 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 impacted 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 to users is moderate.
-
Large: These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.
-
-
Delivered: Identifies whether the feature is Enabled or Disabled upon initial delivery.
- 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.
Table 1-1 Noteworthy Enhancements
| Feature | Module Impacted | Scale | Delivered | Customer Action Required? |
|---|---|---|---|---|
| External Workflow Validation |
SOCS |
Small |
Yes |
No |
| Required Extended Attribute Inventory Adjustments | SOCS | Small | Yes | No |
| NFC Connected Scanner | SOCS | Small | Yes | No |
| Warehouse Inventory | SOCS | Small | Yes | Remove any warehouse specific integration not related to store actions. |
| Quality of Life Changes | SOCS | Small | Yes | Assign new permission for DSD creation from PO. |
| REST Services | EICS | Medium | Yes | No |
New Feature Descriptions
This section describes the new features.
External Workflow Validation
Many retailers have been looking for a solution on how to perform proprietary validations on a transaction, or validations that are very specific to their business process with SIOCS and cloud solutions in general.
This release introduces the first step where a retailer can define their own custom validation and make a transaction pass or fail within SIOCS.
This works as follows:
After confirming/completing an inventory transaction in SIOCS, the UI will have the ability to make a REST call to an external system that allows a retailer to build a process that will allow for custom validation or other processes. The result of such a custom validation should be a valid or false response. With a false response, SIOCS will be able to get the reason for the response and prompt the user on the UI screen that the validation failed and display the custom validation message. Similar to our own validation, with a false response the transaction will not be confirmed/completed. A valid/positive validation result can also prompt the user, but is optional and will of course complete the transaction.
In addition, a timeout option can be configured so in case the external third-party extension does not operate quickly enough, SIOCS will not error out and will allow the transaction to move on, or fail, depending on the configuration setting.
A new permission is added that will control access to the configuration screen.
| Permission | Topic | Usage |
|---|---|---|
| Access External Workflow Validation Administration | Admin | With this permission, the user will have access to the External Workflow Validation Administration screen in the desktop application. |
Some specific features:
- The REST call from SIOCS should be synchronous so the transaction in SIOCS does not complete until after the custom service has a value return.
- The REST call will happen after Oracle’s internal SIOCS validation.
- Depending on the functional area, SIOCS will be able to provide a set of transaction data that can include, but is not limited to the transaction ID, the transaction type, item, quantity, and info attributes. This will allow for simple validation rules so that the retailer can just use the data from the REST call. In more complex validation situations, additional data may be needed from RDS or external systems.
- No log will be kept to track the failure or calls made beyond standard cloud tracking.
- Service return will contain a valid/invalid response and a message. The message can be an error for an invalid response or a warning/confirmation for a valid response.
Only the failure message is prompted and in the case of a positive message, the system may or may not get the message back and just show a toast message.
At this point, only a single functional area, inventory adjustments has been enabled. Additional areas will be added based on priority and business needs.
External Workflow Validation Administration Screen
Grid (List) Fields
The list displays the list of validation services in the system. Records cannot be created.
- Name - Name of the workflow action to validate.
-
Active - This indicates whether the validation service is active or deactivated.
If the external workflow validation is enabled or not (Yes/No):
- If not enabled, the external workflow validation service is not integrated for that workflow action.
- If enabled, the external workflow validation is contacted, and it is integrated for this action.
- Description - Description of the workflow validation service.
- Ignore Service Failure - Yes/No - This indicates whether the system has to ignore any technical failure or timeout and allow the user to continue the operation on the UI.
- Override Timeout - This indicates whether the system has to override the default timeout to call the external service.
- Read Timeout Seconds - This provides the read timeout seconds to determine how long the system will wait for the response from the external system. This is in case the administrator sets to override the timeout.
- Update Date - Date/time the record was last updated.
- Update User - User that last updated the record.
Detail (Apply) Block
- Edit - Will allow for the selected row (upon clicking edit) in the grid to be editable in the Detail block.
- Apply - If there are no values in the required fields, the system should display a missing required data message.
- Cancel - Will clear out the Detail Block. No updates are made.
- Name - Name of the workflow action.
- Active - This indicates whether the validation service is active or deactivated.
- Description - Description of the workflow action.
- Ignore Service Failure - This indicates whether the system has to ignore any technical failure or timeout and allow the user to continue the operation on the UI.
- Override Timeout - When enabled, it allows the user to set the timeout values to be used for the selected external service.
- Read Timeout Seconds - This option allows the user to specify a timeout to be used when reading the response from the external service call.
For more information, see the Oracle Retail Enterprise Inventory Cloud Service Administration Guide and Oracle Retail Store Inventory Operations Cloud Services Implementation Guide.
Required Extended Attribute Inventory Adjustments
Extended attributes have been enhanced in the Inventory Adjustments dialog.
The screen where you can select the extended attribute or make a decision to add one now allows the scan or entry of a GS1 databar. In earlier versions of SIOCS, this screen did not allow the scanning of a barcode. This needed to be done on the item list of Item Detail screen of the dialog.
In addition, those extended attributes flagged as "required” on setup will be required when manually capturing attributes on the Attributes Entry screen. Validation for required attributes will also be validated upon confirming the transaction. At least one set of attributes must be captured when an extended attribute is required.
Note:
Additional dialogs that capture extended attributes will be enhanced in the future. At this point only the Inventory Adjustments dialog will allow for the scanning and validation of required attributes.Extended Attributes Screen
NFC Connected Scanner
For mobile Android devices such as the SUNMI L2S that support NFC natively, we now allow those tags to be scanned directly using the device’s built-in NFC reader. This enables the mobile scanner to identify NFC tags without requiring an external scanner.
Warehouse Inventory
In prior versions, SIOCS displayed warehouse inventory by requiring the retailer to periodically upload warehouse inventory positions and integrating warehouse message related to inventory movement. Some of those could have been shipments from a warehouse to another warehouse or vendor, receipts from a warehouse, or vendor, or warehouse inventory adjustments.
With this release, for those retailers using direct integration with MFCS, SIOCS has made accurate warehouse inventory positions much easier to manage. SIOCS will now be reading the inventory positions from a warehouse directly from MFCS. Virtual warehouse inventory will be aggregated from MFCS to physical warehouse levels.
This change means that it is not necessary anymore to periodically upload warehouse inventory positions nor integrate some of those specific warehouse related messages of inventory movements within the warehouse or between warehouse/supplier mentioned above. Keeping them in place will not cause any issues, but SIOCS will ignore that data.
Note:
Inbound to SIOCS warehouse related integration such as shipments to the store and transfers created for shipments to the store are still required.Quality of Life Changes
The following small changes have been introduced to improve usability, and make operations and find data easier:
- The Stock Locator screen has the label changed to be more accurate. The label now shows the last received date/time, and not the “Receiving today” label any more. This label was not accurate since it displayed the last time inventory was received.
- The transfer dialog already had the context type and value, however the value field was not enabled. Similar to the transfer document dialog, the context value will now always be enabled, regardless of the context type.
- The outgoing shipment notification message now includes the External transfer doc ID, and not just the SIOCS transfer internal Doc ID. In addition, it also now includes a reason code.
-
When creating a transfer shipment from the transfer dialog, the user will have the ability to default the item and quantities from the transfer document in addition to just defaulting items, or not defaulting any items or quantities.
This allows for more flexibility when the retailer leverages the transfer document approval process as a picking process so all items with their quantities have already been added.
- A new batch process has been added to delete store location with status D.
-
To ensure users will validate quantities with true inventory when doing a DSD, a new permission is added to allow the option to default remaining PO quantity when creating a DSD receipt.
Permission Topic Usage Allow DSDreceiptcreation withdefaultremainingquantity DSD Receiving With this permission, the user will be able to use the “Apply Item(s) and Remaining quantity” when receiving a new delivery using Direct Store Delivery flow or from the Purchase order items when creating a delivery. -
For stock counts, unit and amount when using “daily processing,” a new parameter has been created when executing Unit and Amount stock counts. The system option for default timeframe for Unit/problem line and Unit and Amount stock counts was the same. With this change there is one for unit/problem line and one for Unit and Amount count. This allows better alignment with business process.
In addition, the stock count snapshot batch used for Unit and Amount stock counts will allow for an override process when running.
REST Services
Similar to prior releases, SIOCS put extra work into REST services and their documentation. In this release, the following updates have been made:
- The swagger-ui will be publicly accessible. The documentation is the same as existed before but now is easier to navigate and browse.
- REST service outbound calls have three new additional settings:
-
Override Timeout:
This is a new option that defaults to Off (false).
When enabled, it allows the user to set the timeout values to be used for the selected external service.
If disabled, any timeout values will not be applied.
-
Connect Timeout seconds:
This option allows the user to specify a timeout to be used when connecting to the external service.
The default is no value (blank), which applies no timeout value.
The minimum value is 1 (1 second) and the maximum value is 60 (1 minute).
-
Read Timeout seconds:
This option allows the user to specify a timeout to be used when reading the response from the external service call.
The default is no value (blank), which applies no timeout value.
The minimum value is 1 (1 second) and the maximum value is 600 (10 minutes).
-
Technical Changes
This section describes the technical changes in this release.
General Updates
As with all updates for SIOCS, there are several technical changes that have been made:
Several purging batches have had minor modifications to improve performance and reliability:
- Ticketing purge was tuned with higher bulk commits.
- Failed POS transactions will match now the MPS failed message concept. Failed message will not be purged until the “Days to Hold Failed Sales Posting” parameter criteria has been met.
- Purge DSD and Purge PO will account for PO header to be NULL.
- ItemPriceToHistory batch leverages DB parallel processing.
Batch Execution Updates
Currently when SIOCS is integrated with POM and Retailers are using POM for scheduling the batches, the user is not able to provide dynamic dates for the jobs that accept the execution date.
This update of SIOCS introduces a new method when entering dates. Retailers will be able to use the existing parameters column in POM and SIOCS will interpret and apply the execution date dynamically.
On the SIOCS side, there will be an update to the APIs to interpret the param keys to its relevant values and pass it to batch jobs during execution.
The retailer will be able to define the following four valid optional param keys in POM to send it to SIOCS for execution date:
- Today =The system takes execution date =current SIOCS server date.
- Today-N = would take the current server date, and reduce it by N days
- Today+N = would take the current server date, and increase it by N days
- date=yy-mm-dd (date provided by the user)
Note:
Currently when a date is not passed, the system (SIOCS) takes execution date = the current SIOCS server date.This update is generic for all the batches. For example, the retailer wants to generate a unit and amount stock count for the scheduled date (execution date) for the current date+2 days. The user in POM would set the parameter value to Today+2. Assume current date=Feb 4th 2026 and the user provides Today+2 in POM. In that case, SIOCS will set date parameter=Feb 6 2026 and generate the stock count.