1 Feature Summary

This chapter describes the feature enhancements in this release.

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.

  • 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?
New and Updated Options
Transaction History - Item Lookup	EICS	Small	Enabled	No
Transaction History - Date/Time Display	EICS	Small	Enabled	No
Stock Authorization - Late Sales	EICS	Medium	Disabled	Grant permissions.
Stock Authorization - Item Lookup Link	EICS	Small	Enabled	No
Stock Authorization - Variance Display	EICS	Small	Enabled	Ensure price is integrated into SIOCS.
Ad Hoc Stock Counts	SOCS	Small	Enabled	No
Item Basket - Item Lookup Jump	EICS	Small	Enabled	No
UIN Auto Navigation	SOCS	Medium	Enabled	No
Container Discrepant Display	EICS	Small	Enabled	No
Transaction History - Time Display	EICS	Small	Enabled	No
Purchase Order - Not Before Date	SOCS	Small	Enabled	No
Stock Count Authorize Recovery Batch - Input	EICS	Small	Enabled	No
Delivery Bay	SOCS	Small	Disabled	Configuration.
Jet Desktop - Redwood Theme	EICS and SOCS	Small	Enabled	No
External Service Administration UI	EICS	Small	Disabled	Grant permission.
Cleanup Batches	EICS	Small	Enabled	No
File Transfer Service	EICS	Medium	Enabled	Yes
SIOCS Standalone	EICS	Medium	Enabled	Yes

New Feature Descriptions

This section describes the new features.

Transaction History

Two changes have been made to Transaction History:

1. Transaction History will now also display next to the date the time the transaction was executed.

2. On the desktop client, Item Lookup will have a punch out to see the transaction history for that item.

Transaction History Details

Transaction History will be accessible not just from the menu options, but also through Item Lookup on the desktop.

The Transaction History section can be accessed by clicking the Transaction History collapsible panel. When clicked, it will display the transaction history records for the item as it is currently displayed in the Transaction History screen. The number of transaction history records displayed will be based on the system configuration Search Date Range Default for Transaction History. The user must have the Access Transaction History permission for this collapsible panel to be visible.

Stock Count Changes

Stock Count Authorization

Several usability modifications have been made to the Stock Count authorization screen:

• Several new fields have been added that will display the value variance. This price used for the variance calculation is taken at the time of the last snapshot taken. This allows for a consistent value during the authorization process.

The dialog will also show the user the price used as well as the type of price.

• An additional usability feature has been made. When clicking on the item, the Item Lookup screen will open up in a new tab. This will allow the user to select and view the transaction detail information for that item or any other pertinent item information needed to make a decision around the stock position of the item.

The multiple location field can now be accessed through the multi-location indicator, while the UIN area can be accessed through the hyperlink on the UIN field.

• A new button has been added to allow the user to apply late sales information to the stock count. This feature can be hidden or displayed to the user based on permissions.

Permissions

PERMISSION	TOPIC	DESCRIPTION
Apply Late Sales	Stock Counts	With this permission, the Apply Late Sales button will be available to the user in the Stock Count Authorization Detail screen.

Stock Count Authorization Details

The user will be able to see the current Price of the item, Price Type, and Price Variance. Price Variance for an item is calculated as follows:

• Price * (SOH - Count qty) if the stock count was not recounted.

• Price * (SOH - Re-count qty) if the stock count was recounted.

Clicking the Apply Late Sales button refreshes the snapshot to incorporate the late sales for the items in the stock count. This button is visible only when the child count is in New or In-Progress state. The user must have the Apply Late Sales permission for this button to appear on the screen.

Authorization Detail - UIN

If the item is a UIN item, clicking the icon in the UIN column displays the Authorization - UIN popup.

Authorization Detail - Multi Locations

If the item has the Multi-Loc column set to Yes, it will be a hyperlink. The system displays the Authorization Detail Multi Locations popup if the user clicks the Yes hyperlink.

Adhoc Stock Counts - Delete Item

The user will now have the ability to delete items from an adhoc stock count in case something was accidently scanned.

Usability Changes

Several additional changes have been made to enhance the user experience.

Item Basket - Desktop

The Item ID has been made a hyperlink on the Item Basket dialog. Clicking the link opens the Item Detail screen for that item in a new tab in the browser.

UIN Navigation - SOCS Client

When a UIN item, or a UIN is scanned on the Mobile Unit, the screen will not automatically move to the UIN area of the Item Detail screen as well as alert the user a UIN item was scanned.

These changes have been implemented in the following dialogs:

• Direct Store Delivery

• Return to Vendor

• Customer Order Management dispatching

• Stock Counts

• Transfer receiving and shipping

Transaction History - Display Time

The Transaction History screen will now display the time next to the date. This enables a user to better see the sequence of when inventory changes were made in relation to each other.

Container Receiving - Discrepant Flag

The receiving container dialogs in the transfer and Direct Store Delivery area did not display in prior releases did not display if a container had discrepancies or not. This made is difficult to revalidate the accuracy of a container receipt.

This has been rectified by adding a Discrepant label on any container on these respective container list screens.

DSD Receiving Containers

A label called Discrepant will be displayed in red color.

Tsf Rcv Containers

Purchase Order List - Display Not Before Date

The Purchase Order List screen will start displaying the Not Before date of the order. This allows users to faster spot the orders they are working on by eliminating those that have not yet arrived in the store.

Stock Count Authorize Recovery Batch - Input

When entered by the user, the existing Stock Count Authorize Recovery batch is updated to take in the following input parameters, if entered by the user:

• Stock Count ID

• Data Set ID (that is, Stock Count ID)

These fields already existed in the Job Admin screen however the store ID input parameters were ignored by the batch if the stock count ID was provided. From release 19.4, the batch will validate both parameters and only run for the count and/or store provided.

Both of them are optional fields. If user does not enter any input information, the job will work as before and execute for all stock counts and stores.

Delivery Bay

Delivery Bay is a feature that has been present in SIOCS since its launch. However, documentation did not cover this concept. Some additional information was added in the DSD and Transfer sections of the documentation.

A delivery bay in the store is an area where inventory is received at the time the truck arrives in the store. In a normal fast passed process, this inventory will be moved to the shopfloor or put away in the backroom and be immediately available for use. However, in some cases, the delivery load is so large, or no people are available, to manage this as part of the on-going process. For such retailers, the delivery bay allows the receiving of inventory, but does not mark this inventory as available until the next day.

A batch process runs at night that will mark this inventory as available for sale.

Direct Store Delivery Details

Receive on Shop Floor: The default will be based on the store parameter Direct Delivery Default to Shop floor Receiving. If set to Yes, the check box will default to marked.

You are required to have Receive Direct Delivery on Shop Floor permission to change the value.

This indicates whether the system delivery will default to receive inventory into the shop floor instead of automatically receiving into the backroom or delivery bay.

If this is set to receive on the shop floor, the system increments the shop floor inventory bucket instead of the backroom or delivery bay bucket. If a capacity is defined for the item and Direct Delivery Receive Item Capacity is set to Yes, the maximum shop floor quantity will equal the capacity; otherwise, the shop floor will be updated to the entire receipt amount. If the capacity is used and if the receiving quantity is excess, the balance is incremented to delivery bay or backroom depending on the Replenishment - Delivery Bay Inventory parameter.

If Receive on Shop Floor is not set on the delivery, the system increments the backroom or delivery bay bucket depending on the Replenishment - Delivery Bay Inventory parameter. If this parameter is on, the system will increment the delivery bay bucket instead of the backroom. This will increase SOH.

Transfer Receiving Details

Receive on Shop Floor: The default will be based on the store parameter Direct Delivery Default to Shop floor Receiving. If set to Yes, the check box will default to marked.

You are required to have Receive Direct Delivery on Shop Floor permission to change the value.

This indicates whether the delivery will default to receive inventory into the shop floor instead of automatically receiving into the backroom or delivery bay.

If this is set to receive on the shop floor, the system increments the shop floor inventory bucket instead of the backroom or delivery bay bucket. If a capacity is defined for the item and Direct Delivery Receive Item Capacity is set to Yes, the maximum shop floor quantity will equal the capacity; otherwise, the shop floor will be updated to the entire receipt amount. If the capacity is used and if the receiving quantity is excess, the balance is incremented to delivery bay or backroom depending on the Replenishment - Delivery Bay Inventory parameter.

If Receive on Shop Floor is not set on the delivery, the system increments the backroom or delivery bay bucket depending on the Replenishment - Delivery Bay Inventory parameter. If this parameter is on, the system will increment the delivery bay bucket instead of the backroom. Regardless, the stock on hand will be updated.

The Receive on Shopfloor check box will only display for deliveries from a store or warehouse.

Jet Desktop - Redwood Theme

The SIOCS desktop user interface has been refreshed to align better with Redwood, Oracle's new user experience design language.

This change has only been made to the PC client. Fonts, drop down boxes, entry fields, and general color scheme have all been updated. A good example is the Item Lookup screen shown below. The workflow has been kept the same.

External Service Administration UI

The External Service Administration screen is used to set up integration information to connect with external/third-party systems, such as the specific URL for the external web service connection.

Security Permission: Access External Service Admin

List Buttons:

• Save: Persists currently altered information and refreshes the screen.

• Refresh: Refreshes the screen with currently persisted information.

• Reset: Clears out all the editable fields for the selected row.

• Filter: Enables and disables filtering properties in the table.

List Attributes:

• ID: An identifier for the external service.

• Description: A description of the external service.

• Service Type: The type of web service (for example: SOAP, REST).

• Service URL: The URL of the service location to access.

• Update Date: The last update date.

• Update User: The user who updated the record last.

Detail Panel

Detail Panel in Edit Mode

Detail Buttons:

• Edit: Places the detail information displayed into edit mode.

• Apply: Applies the entered data to the record and updates the list information.

• Cancel: Places the panel back into display mode without applying the information.

Detail Attributes:

• ID: An identifier for the external service.

• Description: A description of the external service. The description can only be changed in the translation administration.

• Service Type: The type of service: SOAP or REST.

• Service URL: The URL used to connect to the service.

• Security Type: The type of security associated with the service. For REST, the valid values are None and OAuth2 Client Credentials. For SOAP, the valid values are SOAP Policy A and OAuth2 Client Credentials.

Cleanup Batches

The scheduled batch jobs that perform cleanup of system, old completed, temporary, or expired data have been moved to systems operations. The scheduling and execution of these batch jobs is necessary for the functioning of the application. Each of these jobs will be scheduled to run by default on a cycle, often daily improving overall system health.

Most of these cleanup batch jobs have a retention policy that is configurable in the system configuration. The system configuration is available to standard customer accounts where they can set those configurations within a specified range.

File Transfer Service

Overview

File Transfer Service (FTS) replaces SFTP in the new Cloud Architecture.

The services allow a retailer to manage uploading and downloading files to Oracle Cloud Infrastructure Object Storage, which is an internet-scale, high-performance storage platform that offers reliable and cost-efficient data durability. For each customer environment, buckets which are logical containers for storing objects will be created in Object Storage. Any type of data, regardless of content type, is stored as an object. Access to the buckets is through a pre-authenticated request (PAR), which is a URL that requires no further authentication to use to upload to or download files from the bucket. To retrieve a PAR, you must use the appropriate file transfer REST service. The primary role of these services is to ensure that only valid external users can call the service by enforcing authorization policies.

Details

Oracle Cloud Infrastructure Object Storage is an internet-scale, high-performance storage platform that offers reliable and cost-efficient data durability.

File Transfer Service (FTS) for the Store Inventory Cloud Services is available as JSON REST services. These APIs allow you to manage uploading and downloading files to Object Storage.

Access to files is through a Pre-Authenticated Request (PAR), which is a URL that requires no further authentication to upload or download to the application's Object Storage. To retrieve a PAR, you must use the appropriate FTS services.

The FTS APIs enable external applications to import files to and export files from Object Storage used by the solutions.

These APIs provide the following services:

• Ping to check FTS Service health

• List storage prefixes

• List files in Object Storage

• Move files from Object Storage

• Delete files from Object Storage

• Request Upload PAR

• Request Download PAR

The general process flow below describes how the external solution application interacts with the FTS service for transferring files to the cloud solution service:

1. The external application gets an Oauth2 token from IDCS.

2. The external application makes an FTS request with the Oauth2 token to request Pre-Authentication.

3. Once the PAR is received, the external application uploads a file to Object Storage using the URL included within the response.

4. The file uploads to the application Object Storage and will be processed by cloud application batches.

In addition to public FTS endpoints, the SIOCS cloud application also provides a File Transfer Service User Interface to view files in the cloud solution Object Storage, to upload and download files interactively once logged into the SIOCS client application. Refer to the File Transfer Service UI section for details.

For more information on how to execute these APIs and additional information, see the Oracle Retail Enterprise Inventory Cloud Service Administration Guide.

SIOCS Standalone

SIOCS can deploy with a Merchandise system either through a shared pluggable database model or without a shared pluggable database (that is, standalone).

In the shared pluggable deployment, initial foundation and price data will be seeded using the File Transfer Service.

Standalone deployment will provide an ability to integrate with a third-party or an on-premise merchandising system. This deployment will require field enablement. For third-party merchandise systems, it will require file extracts SIOCS can consume. For on-premise versions of Oracle Retail Merchandising System (RMS), that have extraction capabilities, the extracted files will still need to be transformed into the format SIOCS can process.

In both deployment models, ongoing transactions and subsequent updates to foundation data will still leverage Retail Integration Bus (RIB).