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.

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

Merch Hierarchy Restrictions and Non-Ranged Items

EICS

Medium

Yes

Permission required and system option to turn on.

Item Lookup Pricing

SOCS

Small

Yes

No

Auto Ranging Third-Party Stock Counts

EICS

Small

Yes

Change requires system option setting.

VPN Display

SOCS

Small

Yes

No

Batch Ad Hoc Web Service

EICS

Small

Yes

May need to update the custom service when calling if desired functionality is needed.

Ticket Printing Web Service

SOCS

Small

Yes

Requires optional web service implementation.

Purging Open Stock Counts

EICS

Small

Yes

No

Direct Integration

EICS

Large

No

Requires that a request is logged.

REST Services

EICS

Small

Yes

Requires new API call from third-party application.

Automatic Purging of MPS Staged Messages EICS Small Yes No

New Feature Descriptions

This section describes the new features.

Merch Hierarchy Restrictions and Non-Ranged Items

A feature has been added to SIOCS that allows the retailer to configure which users can see which merchandise hierarchies. This fine tuning allows retailers who have multiple brands to improve the efficiency of users by restricting some users to only see some hierarchies in drop-down lists. Another example is where a full line store has fresh prepared items, while a convenience store does not. The user of the convenience store can have a permission that does not include the department of fresh prepared items.

In addition, the non-ranged item functionality has been extended to Item Lookup to prevent users from looking for items that have not been ranged to their store. This does not impact other dialogs.

Details

Some retailers have different companies/divisions/brands in their company where there will be a requirement to not allow everyone in the system to see all of the merchandise hierarchies (departments) within the system. Merchandise Hierarchy Departments will have data permissions assigned to them to enable a retailer to restrict user visibility to specific departments.

As a new department comes into the system, it will get added as a Department data permission. The data permission will not be assigned to users as it gets added. Meaning, the department would need to be added to a user's role as a permission.

A system setting, Filter Merchandise Hierarchy, will be validated. If it is set to Yes, then a user must have data permission for the department in order for it to appear within the hierarchy selections within the application. If the setting is set to No, the system will not validate the user’s department data permissions and all departments will be available.

This is applicable on the mobile and desktop applications wherever the department drop-down list is displayed.

Example:

  • Company: Big Company

  • Three brands in the same system:

    • Brand A - High-end women’s fashion stores:

      • Stores 1, 2, 3

      • Departments: 1010-Handbags, 2020-Evening Gowns

    • Brand B - Athletic stores:

      • Stores 4, 5, 6

      • Departments: 3030-Athleticwear, 4040-Running Shoes

    • Brand C - Lower-end men’s and women’s fashion stores:

      • Stores 7, 8, 9

      • Departments: 5050-Men’s outerwear, 6060-Women’s tops

  • Store User 1 is at Store 1 and only has department permissions for 1010 and 2020.

    If the Filter Merchandise Hierarchy is:

    • Yes, Store User 1 will only see 1010 and 2020 in their department selections.

    • No, Store User 1 will see all of the available departments: 1010, 2020, 3030, 4040, 5050, and 6060.

This Filter Merchandise Hierarchy system setting affects the following when set to Yes:

  • It restricts the departments that appear in drop-down list selections, that is, ticket search, item basket search, item lookup, product group component, and so on.

  • It restricts the Item Lookup results to the user’s departments (even if a department was not selected as search criteria).

  • It does not restrict items on transactions to certain departments, that is, the user can add items for any department to a transaction.

  • It does not restrict viewing a transaction using different search criteria.

Example:

  • The user has permissions for hierarchy A, B, C, and not for D.

  • In a hierarchy drop-down list on Item Basket Search, the user will see: A, B, and C (not D).

  • If the user does a search on Item Basket, for example to return all In Progress baskets and does not use department as the search, the system will return baskets that are for all of the departments, A, B, C, and D, even though the user does not have permissions for Department D.

  • The user can view/edit (assuming proper edit permissions) as usual.

Item Lookup Desktop and Mobile UX

Data Permission: Type: department

System option: Allow Item Lookup for Non-Ranged Items

  • Topic: Admin

  • Values: Yes/No

  • Default: Yes

  • Yes - The user can look up non-ranged items in Item Lookup. This is the case even if the system is configured to not allow for non-ranged items, Allow Non-Ranged items = No.

  • No - Non-ranged items cannot be looked up in item lookup.

Filter Merchandise Hierarchy

  • Topic: Admin

  • Values: Yes/No

  • Default: No

  • Yes - Hierarchies / departments will be filtered to those that are for the user's permissions.

  • No - Hierarchies / departments will not be filtered for the user's permissions, all will be available.

If the Filter Merchandise Hierarchy is set to Yes, the list of items returned will be restricted to those departments for which the user has department data permissions. If it is set to No, the system will return the list of items based upon all departments without restriction.

The system will validate the Allow Item Lookup for Non-Ranged Items system setting. If it is set to Yes and the user scans/enters a non-ranged item, the item will be returned. If the setting is set to No and the user scans/enters a non‑ranged item, the system will not return the item. Note: The Allow Non-ranged Items system setting is not validated here, the setting described above takes precedence.

The Include Non-Ranged check box will be displayed on the screen as a search option if the Allow Item Lookup for Non‑Ranged Items system setting is set to Yes. If the setting is No, the check box will not be displayed on the screen and non-ranged items will not be included.

Entering an item ID to search on ignores all other criteria entered with a few exceptions. The system will validate the Allow Item Lookup for Non-Ranged Items system setting. If it is set to Yes and the user keys in a non-ranged item, the item will be returned. If the setting is set to No and the user keys in a non-ranged item, the system will not return the item. Note: the Allow Non-ranged Items system setting is not validated here, the setting described above takes precedence.

Ad Hoc and Customer Order Picking Tolerance

Data Permission: Merch hierarchy

Tolerances are set up at the class hierarchy level, displaying only those departments for which a user has data permissions.

Item Lookup Pricing

The main Item Lookup screen has been improved by adding the price type in addition to the price value. This allows a user to immediately understand if the current price is a promotion, clearance, or regular price.

This image shows the Item Lookup screen.

Auto Ranging Third-Party Stock Counts

This new feature allows better fine tuning of the third-party stock count upload by allowing the retailer to configure if an item on the third-party file should be auto ranged or not, or if a UIN should be auto ranged or not. It also allows a combination of ranging a UIN or item.

Even if an item and a UIN is allowed to be ranged, the UIN will not be ranged unless the item is already ranged. This is due to SIOCS not having the required attributes to range UIN items correctly. Since the UIN item cannot be ranged, the UIN will not be able to be ranged either.

System option: Auto ranging of items for U&A stock counts

  • This is used to determine whether auto ranging is allowed for items and UINs.

  • Topic: Admin

  • Values: Allow auto ranging items, Allow auto ranging UINs, Allow Auto ranging items & UINs, and Not Allowed.

  • Default: Allow Auto Ranging Items & UINs

  • Allow auto ranging items

    This setting will allow auto ranging for items but not UINs.

  • Allow auto ranging UINs

    This setting will allow auto ranging for UINs but not items.

  • Allow Auto ranging items & UINs

    This allows auto ranging for items and UINs.

  • Not Allowed

    With this setting, the system will not allow either.

VPN Display

To reduce confusion when scanning a Vendor Product Number (VPN) that references the same item for different suppliers, the Item Select dialog will ignore the different suppliers unless it is a dialog where the supplier is important, such as Direct Store Delivery (DSD). This improvement means that a user will not see the same item listed multiple times.

Details

In the scan bar within Container Lookup, Stock Count, Customer Order, RFID Locator, Print Item, Transfers, Transfer Shipment, Transfer Receiving, Inventory Adjustment, Item Basket, Customer Order Picking, Customer Order Deliveries, and Instore replenishment features.

  • If an item has multiple suppliers and the VPN for the item is the same at more than one supplier, when a user scans the VPN in the place of Item ID, the SKU should be returned only once (distinct) in the Select Scanned Item popup (that is, multiple items popup).

    Example: If the user scans VPN 1, the scan should return Item 1 and Item 3 in the multiple items popup and Item 1 should be returned once.

    Item 1 - VPN 1 - Supplier 1

    Item 1 - VPN 1 - Supplier 2

    Item 3 - VPN 1 - Supplier 3

  • When a user scans a VPN which matches to different SKUs, all distinct SKUs should be returned in the result.

    Example: If the VPN is the same for two different items supplied by two different suppliers, if the user scans VPN 1, then both the items should be displayed in the multiple items popup. In the below scenario, the scan should return Item 1, Item 2, and Item 3.

    Item 1 - VPN 1 - Supplier 1

    Item 2 - VPN 1 - Supplier 2

    Item 3 - VPN 1 - Supplier 3

  • Exceptions: DSD, RTV, Store Orders, and Supplier Lookup

    In DSD, RTV, and Store Orders (if restriction is Supplier), where the user is trying to add a supplier to the transaction (Supplier Lookup screen) and also in the independent Supplier Lookup feature, if the VPN scan results in the same item multiple times, the items have to be displayed as is so the system can continue with the correct supplier.

Batch Ad Hoc Web Service

The batch ad hoc service batch has been improved by adding Store as a parameter component. This allows for better fine tuning when calling the service.

Ticket Printing Web Service

A new web service has been introduced for printing tickets to increase performance. In the current version of SIOCS, all ticket printing, regardless if it is a single ticket or multiple tickets, goes through either Bluetooth or a web service. The web service printing creates a record on the MPS integration table which spins off a process after a certain amount of time.

The new web service will validate the number of tickets that need printing and if a small number (for example, printing from the handheld is always a single ticket), will bypass the MPS tagging table.

To enable this, the retailer will have to connect this service to their printer server similar to the existing print service.

System option: Maximum number of Tickets to use synchronous call

  • Values: 0 to 99999

  • Default: 0

  • Topic: Admin

This configuration will determine the integration method for ticket printing based on the number of tickets set. Zero indicates to use the MPS staging process only. Regardless of mobile or desktop, SIOCS will send the ticket to the MPS table for processing (unless Bluetooth printing is used).

If the value set here is greater than zero, the system will do a direct synchronous call to the printer service when the number of tickets is equal to or less than the number of tickets set in this parameter.

Example: If the value set here is 5 and the number of tickets submitted to print is anything from 1 to 5, the system will do a direct synchronous call to the printer service bypassing the MPS staging process. If the number of tickets printed is above 5, it will be an MPS staged process.

This behavior occurs for both the mobile and desktop applications.

Purging Open Stock Counts

A new batch process has been introduced to allow the retailer to control the existence of abandoned open stock counts. This can happen due to a third-party count not executed, or a user who started an ad hoc count and left it alone before approving.

This batch does not delete Adhoc stock counts. A separate batch already exists for that.

System Configuration: Days To Hold Unexecuted Stock Counts

  • Default value: 30

  • Range: 0 to 90

The new purge batch process deletes stock counts that meet all of the following conditions:

  • Type = Unit, Unit and Amount, or Problem Line

  • Status = New or In progress

  • A schedule date/timestamp older than the Days To Hold Unexecuted Stock Counts parameter value.

    That is, Schedule date/timestamp + <Days To Hold Unexecuted Stock Counts> is >= Current date/timestamp.

Direct Integration

New in this release is the enablement of the direct table-based integration between the Store Inventory Operations Cloud Service (SIOCS) and Retail Merchandising Foundation Cloud Service (RMFCS). Enabling this feature will remove Retail Integration Bus (RIB) integration for foundation data from RMFCS and transactions between RMFCS and SIOCS such as transfers, receipts, shipments, and RTVs.

Due to the significant impact on integration between RMFCS and SIOCS, enabling this feature requires a Service Request to be submitted in My Oracle Support.

Note: SIOCS still requires the RIB for integration with third parties such as a warehouse or supplier.

REST Services

Several new services have been added to SIOCS to support integration from third-party systems through REST services. Some operations, such as updates and creates, of these services are meant for third-party deployments where the retailer would prefer to not use the RIB component of Oracle Retail Integration Cloud Service (RICS), but rather a direct REST service import. Those create/update operations should not be used when Oracle Retail Merchandising Foundation Cloud Service is deployed as this data is integrated over RICS as part of the deployment.

REST services are added for the following areas: Item Price, Ticket create/update, manifest, and item UIN.

Note: These services are not meant for initial data load, data seeding integration jobs exist for those.

Automatic Purging of MPS Staged Messages

With this release, the Purge Processed attribute of the Global MPS Work Types will be enabled by default. The option to alter this setting has been removed from customer Administration users.

The Message Processing System (MPS) within SIOCS is built for processing staged messages and should not be used for audit or historical usage. Both inbound messages to and outbound messages from SIOCS that have been successfully processed are meant to be purged immediately. Note that unprocessed/failed messages are not purged.

For more details, see the MPS Work Type section in the Technical Maintenance Screens chapter of the Oracle Retail Enterprise Inventory Cloud Service Administration Guide.

Technical Updates

As with all updates for SIOCS, there are several technical changes that have been made:

  • Various performance enhancements in batches, including purging item batch.

  • Merge versus insert configuration of data seeding to improve performance.

  • Continued enhancement around deployment and configurations.

Additional Notes

The SIOCS provisioning process has been changed to not create additional IDCS Client apps to access FTS APIs starting with SIOCS release 23.1.201.0.

If the FTS client ID exists in Oracle Identity Cloud Service (IDCS), retailers can continue to use it. The detailed steps to access the existing FTS IDCS client are available in the Oracle Retail Enterprise Inventory Cloud Service Administration Guide.

If the FTS client ID does not exist in Oracle Identity Cloud Service (IDCS), the Customer Administration users must create their own client credential IDCS application. The detailed steps to create the FTS IDCS client are available in the Oracle Retail Enterprise Inventory Cloud Service Administration Guide.

Reports User Configuration

The SIOCS provisioning process has been modified to remove the Oracle system operator user for reports integration. The Customer Administration User must create an IDCS user with the required IDCS BI groups assigned to access the report endpoints. The same user credentials must then be configured on the Credential Administration screen. Refer to the Reporting chapter, Security Considerations section of the Oracle Retail Enterprise Inventory Cloud Service Administration Guide for further details.