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.

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?
Jet Mobile	SOCS	Very Large	No	Yes Download app, configure, and deploy by third-party MDM. Ensure new inventory adjustment reason codes are added to the Oracle Retail Merchandise Foundation Cloud Service (RMFCS) environment by manually entering them or updating to the same patch level.
Store Orders	EICS, SOCS	Large	No	Yes Requires direct integration to be enabled with RMFCS.
E*Waybill	EICS, SOCS	Large	No	Yes Requires direct integration to be enabled with RMFCS/ Oracle Fiscal Document Generation (FDG) and set up in EICS.
Customer Order Auto Pick	EICS, SOCS	Large	Yes	No
RTV Request Restriction	EICS, SOCS	Small	Yes	Yes Requires permission to be granted to preserve current functionality.
Transfer Request Context	EICS, SOCS	Small	No	Yes Requires store system options to be set.
Bulk Data Integration	EICS	Medium	No	No
REST Services	EICS	Small	No	Yes Requires new API call from third-party application.

New Feature Descriptions

This section describes the new features.

Jet Mobile

To better support the current challenges in the retailer’s environment, including the challenge to fully staff a store, retailers are driven to be more efficient. SIOCS is releasing a new Android application based on the Jet Mobile technology to support this challenging environment. Direct feedback from retailers, the new Redwood design philosophy, and UX specialists were leveraged to provide a new efficient and refreshing experience.

The goals for the new UI were as follow:

• Simplify existing workflows

• Execute tasks in a chained workflow versus multiple distinct flows

• Provide more insights to the user for better decision making

• Reduce workflow clicks

• Default where possible to reduce user input

• Leverage the Redwood theme

• Allow mixed mobile technology deployments (Mobile Application Framework (MAF) and Jet):

  • Quick UI is focused on execution, MAF is used for mobile management

  • Quick flows will be in addition to regular full functional flows

• Dashboard/single launch path

• Reuse of security permission/role assignment/configuration where possible to reduce setup time

The result of this effort can be summed up in the following approximate improvements:

• 20% fewer steps to create and complete a single item inventory adjustment

• 30% fewer steps to perform an Advanced Shipment Notice (ASN) receipt

• 50% fewer steps to move between tasks

• Seven step process for a single customer order fulfilment

All this will result in less training time, less clicking around the app, and will provide more time to execute inventory tasks.

The new application is primarily focused on the efficient fast execution of tasks. This means that if the retailer would like to perform advanced inventory functions such as in store replenishment, track serial numbers, execute multi-customer order picking, have multi item inventory adjustment, and reference historical data, they will need to use the MAF application. However, if the retailer would like to scan an item, quickly adjust the shelf inventory, print a new label, and place an ad hoc store order all in the same dialog, the Jet Mobile UI can provide this experience.

The Jet Mobile UI will have the following functions available:

• Item Lookup

• ASN level transfer receiving

• Quick container receiving for transfers and Direct Store Delivery (DSD)

• Quick orders external order quantity review

• Simplified customer order fulfilment

• Item maintenance (inventory adjustment, ticket print, store order)

• Quick count (snapshot less counting)

Full flow features and several dialogs from the MAF Mobile client have not yet been incorporated in the Jet mobile dialog:

• RFID, UIN, and GS1 extended attributes

• DSD receiving, transfer request, shipment and detailed transfer receiving, RTV request and shipping, multi-item inventory adjustments, In Store Replenishment, full stock counts, detailed ticket printing, item basket, and multi‑customer order picking.

Below are some of the highlights for each of the different areas. For specific information, review the respective functional sections in the Oracle Retail Store Operations Cloud Service User Guide which have a detailed functional overview. Technical information on how to deploy it and more can be found in the Oracle Retail Store Operations Cloud Service Mobile Guide.

At this point, the Jet Mobile UI is only available on Android 10 and above.

Dialogs

The following dialogs will be available in the Jet Mobile client. For more complete information on what is all possible in each dialog, see the Oracle Retail Store Operations Cloud Service User Guide:

• Open Transactions:

  • Task list of open transactions that the user has access to in Jet Mobile.

  • Navigate to the transaction from this area.

  • Notify another user of an open transaction.

  • Search by quick date range (for example, Last 3 days)

• Item Lookup:

  • Display all standard item information.

  • The Item Lookup dialog allows for the creation of an inventory adjustment without the need to approve. After the user indicates a reason code and a quantity, saving this will automatically create an approved inventory adjustment.

  • The user will have the ability to print an item report and also an item ticket. This quick print concept defaults the format and what should be printed to allow a user to resolve any ticket issues.

  • When noticing something wrong on the shopfloor with an item, the user will have the ability to add an item to an investigative item basket. This investigative basket can be used in the MAF item basket workflow or MAF stock count process.

  • Related Items will have the ability to not only display a list of related items, but also be able to display them in a matrix format, allowing a quick overview of available inventory by secondary attributes.

    

• Quick Orders:

  • Allows users to select an area of the store to review external corporate created order quantities and to update them as needed. Using a SIOCS defined area versus plan-o-gram or review by order allows for more flexibility to define which items should be reviewed together. A user can, for example, work on all ordered items from the breakfast area, despite the fact they are across multiple merchandise hierarchies, suppliers, and orders.

  • Provides default filtering to only work on items with a minimum configurable set quantity so a user does not have to review every possible item.

  • Tolerances at the item level allow the user to not edit quantities, or only modify them within a corporate defined limit (for example, 10% more or less). Tolerances can be either a percentage or a Unit of Measure (UOM).

  • The dialog provides additional data such as historical sales or forecast information, last receive, next delivery date, price information, and quantities to enable the best possible decision.

  • While reviewing store order quantities, an update to available inventory positions can be made at the same time. Available inventory can be updated as a single available bucket or as multiple buckets for backroom and shopfloor depending on the system configuration.

  • While the user is reviewing the order quantity, possibly updating the shelf quantities, they can also refresh the item ticket if it does not reflect the correct price.

  • In case something is wrong with the item quantity and further investigation is needed for an item, the user will be able to add the item to an investigative item basket or remove it.

  • The screen order of different components can be managed and changed by the user. As an example, it is possible to move the inventory bucket fields above the store order information or to the bottom of the screen.

  • This feature is only available if direct integration with RMFCS is enabled or the REST service with an external third-party system is used.

    

• Simplified Customer Orders and Curbside Pickup:

  • After accepting or rejecting the order, the user is brought immediately to the picking screen.

  • The picking screen allows the user to capture a location for temporarily storing the items until ready for pickup. If sequencing is turned on, the user will have the ability to see locations where the item could be available for picking.

  • For orders that need to be shipped out, the user has the ability to go directly to the delivery screen. For pickup orders, after completing the pick, the user will go to the open transaction screen. Standard BOL screens are available for entering relevant information for the manifest system.

  • In case of an order cancellations, the user will have the ability to review the cancelled items and accept the reverse pick. This allows them to move the inventory back to the shopfloor/backroom where applicable.

  • Pickup order in SIOCS support two models:

    • Simple pickup where the customer walks into the store, and the sales associate provides the items to the customer and marks the order as completed.

    • Curbside pickup allows the retailer to deploy a custom app to communicate customer information such as parking spot, car color, and license plate to SIOCS. SIOCS will prompt the user of the curbside pickup and provide this data, as well as a counter on how long the customer has been waiting.

  • It is possible to ship more than once against the same order (based on configuration), but the shipment does need to be closed.

  • Any order started in Jet or MAF has to be completed in their respective workflows.

  • It will be possible to generate a report for delivery, or contacting the manifest service when shipping.

  Note: A store rejection does not indicate that the order is cancelled. It is from the store’s perspective, but the Order Management System can decide to reroute to another store or cancel it.

  

• Inventory adjustments:

  • As mentioned under Item Lookup, users will be able to make an inventory adjustment without having to formally approve the adjustment.

    Note: Users still need the correct permissions to execute such a transaction.

  • Several additional dialogs, Item Maintenance and Quick Store Orders, have been enabled with a simplified inventory adjustment system. This allows the adjustment of inventory for the shopfloor, backroom, and delivery bay quantities. Adjusting these will create an inventory adjustment from stock on hand to out.

• Item Maintenance:

  • Item maintenance is a dialog focused on user efficiency in a shelf oriented environment. The user will have the ability to scan an item or label, place an item request order, adjust the quantity on the shelf, print a label, or add it to an investigative basket for future review.

  • Adjusting the shelf will generate an approved inventory adjustment in the backend.

  • Adding an order quantity will generate an approved item request store order. The retailer can indicate if minimum order quantities are required.

  • The dialog has four sections: Inventory, Order, Sales history, and Forecast information. These can be turned on/off or moved around. Note that for forecast information integration with a forecast system is needed, similar to the MAF Store Order dialog.

  • In addition to a variety of inventory information such as available inventory information, forecast, and historical sales data, the user will also be able to see the current retail price, the next promotion information, on order and inbound quantities, and the location the idea may exist in (if sequencing is turned on). This information will provide insights on what to order but also if a promotional ticket should be printed or not.

• Quick Count:

  • Quick count is a process that allows a user to scan an item on a shelf, adjust available inventory, shopfloor, backroom or delivery bay quantities. When moving to the next item, the system will generate the appropriate inventory adjustment.

  • What is unique about this dialog is that the first scan/entry from the user will set the value of that item. Subsequent changes are increases only by default.

  • Quick count is meant for a quick count and adjustment without going through snapshot or authorization logic. It is primarily focused on items that are only on the shopfloor for quick adjusting to a more accurate inventory position.

  • Similar to other quick dialogs, the user will have the ability to print a ticket, or add/remove the item from an item basket.

• Quick Receiving:

  • Quick receiving allows a user to scan a container which will be fully received. Unlike the MAF client, in addition to transfer container receiving, this dialog has also been enhanced to allow also for Direct Store Delivery (DSD).

  • To increase scanning speed for the user, containers will be processed behind the scenes and the status will be updated as they are fully received.

  • A status screen will provide a summarized data at the Advance Shipment Notice (ASN) level to indicate which ASNs were partially received or fully received.

    

• Notifications:

  • Access and view notifications

  • Navigate to referenced transaction

  • Forward open transactions to other users

  • Group closure when reviewing transaction

  • Addition of notes to the notification

Common Features

Several features across the Jet UI have been enabled and improved in this first release from the MAF UI. Significant time has been spent to optimize the user experience and provide intuitive navigation.

• Quick Actions is a dialog allowing the user to move from one functional area to another without having to go through a menu selection.

  

• Customer flexible attributes are enabled in the Jet Mobile dialogs where applicable.

• Sort ascending or descending lists of transaction or items.

• Recently edited allows the user to see the last 10 transactions they edited. The user can select that transaction and move into it, as long as the user has the right permissions. Only Jet mobile changed transactions are listed in this dialog.

• Item list scan navigation allows, based on user preferences, the user to stay on the list screen when scanning items or go to a detail item screen. This flexibility allows for speedier list updates when the user just wants to record item quantities and does not need to see all the detail.

• When scanning a barcode, SIOCS will convert this barcode scan to a SKU number. In most cases, the SKU number does not match the scanned value. The new Jet Mobile client will provide a scan detail area that shows the original scan value, and in case of a type-2 or GS1 databar, it will also display the components within the barcode.

• Users will have the ability to move from one store to another without having to re-login.

• The ability to work in Cases, Standard Unit of Measure, or Transaction Unit of Measure will be available to change at a global level for the user.

• The application will be fully internationalized, allowing the user to select different languages.

• Several preferences are available for the user to define. These preferences can often be overridden at the local level. The preference settings are saved to the user’s profile as the default for each new session started by the user. For example, when setting the preference to Cases, the user can change this while working to SUOM, however when logging out and logging back in, the UOM type will default back to Cases. Some of the preferences that are available to be configured:

  • Display images or not

  • When scanning a barcode. navigate to the item detail screen or stay on the item list screen

  • Increase, decrease, or review quantities when scanning

  • SUOM, Cases, or Transaction UOM

• Most lists screens will have a filter bar that allows the user to reduce the items in the list without having to go to a search screen.

• When leveraging plan-o-gram information, the retailer will be able to see a list of locations on most item-specific screens.

• Users will have access to the standard reports SIOCS provides for generating a PDF that can be printed.

• A notes area will be provided in most transaction dialogs and notifications to capture additional information.

• Info screens will be enabled to allow for Custom Flexible Attributes capture. Those attributes will be available under the info screen with the regular attributes.

Store Orders

This release of SIOCS will have integration with RMFCS. In this process, RMFCS will send semi-automated replenished orders flagged for review in submit or worksheet status and transfers in Input and Submitted status to SIOCS . SIOCS will be able to make modifications to these store orders and transfers and have them manually or automatically approved and sent back to RMFCS. In addition, several new features were added:

• Pack rounding

• Allowed tolerance deviation from the original recommended order quantity. This can also be used to just review corporate created orders, but not change any quantities when the tolerance is set to zero.

• Submit allows one user to indicate the order is ready for approval, while another user can move it to approved.

Note: Store Order integration (both transfers and orders) with RMFCS will only be integrated if direct ICL integration is enabled.

Tolerance

Tolerances define how much the store order quantity can deviate from the external store order quantity.

Tolerances will be validated for items on externally created store orders. Tolerances come into the system from merchandising and are defined on the item/location. They can be set as a percentage or UOM, one will be sent, not both. Tolerances will be validated if they exist. A tolerance of zero, means that the store order quantity must match the external order quantity exactly; the quantity field will be defaulted to the external order quantity and disabled.

Tolerance UOM: The system will take the external order quantity and add the Tolerance UOM to it to get the upper range, and subtract the Tolerance UOM to get the lower range. Only for SUOM, not applicable to cases.

• Example: External Order qty = 100 units. Tolerance UOM = 10. Entered User Quantity must be 90-110.

• For Tolerance %: The system will take the % value x the External Order Quantity to get the tolerance quantity. That tolerance quantity will be added to the external order quantity for the upper range and subtracted from the external order qty to get the lower range.

• Example: External Order qty = 100 units. Tolerance % = 7. Tolerance Qty = 7% x 100 = 7 units Entered User Quantity must be 93-107 units.

Pack Rounding

A new menu option is introduced that will round the item quantities on the store order up to the next multiple of the supplier case size. Example: Pack Size is 12. The user enters in a quantity of 20. Round will round up to 24.

• Available for store orders that are editable.

• System, External, and manually created store orders

• Externally created store orders from RMFCS that are for a supplier (Purchase Order) will have the Case Pack Round indicator set to Yes, thus requiring the user to round the store order.

Submit Menu Options

Depending on the configuration, a user will have the ability to submit a store order for a manager to approve.

Cancel Submit will set the store order back to In Progress status:

• Will be available for store orders in Submitted status.

• The user must have the Cancel Submit Store Orders permission to have this option.

Submit will set the store order to Submitted status which is still an editable state. Submit will perform all functionality of the approve option with the exception of integration which will not take place:

• Available for New and In Progress store orders.

• The user must have the Submit Store Orders permission for the option to be available.

Customer Order Auto Pick

Auto picking in SIOCS happens when a warehouse or supplier delivery happens for a customer order. Often these deliveries are pre-packaged and can be automatically associated to the customer order as picked. However, in prior releases of SIOCS the assumption was made that a single fulfilment order can only have one method of picking. Or a retailer configures the system to auto pick on deliveries, but would not pick from stock, or the retailer would pick from stock, but not auto pick.

In the last few years, retailers have been seeking more flexibility on how to fulfill an order, so SIOCS will start allowing the picking of a single fulfilment order through both local store inventory and delivered quantities from an external system. So practically, a customer order of 10 units for item A, can be picked for 3 units from store inventory and receive a delivery for 7 units which are cross docked to the order. Reservation of the inventory will still happen at the time of the customer order arriving, so available might be driven negative for a period of time.

Details

The following table describes how the current configuration can be set and what the effects will be on the picking and reservation process.

Reserve Customer Order Inventory On Receiving	Auto Pick on Receipt	Customer Order Exists at receipt	Result at receiving
Yes	No	Yes	Reserve on Receipt of the order. (no auto picking). Manual pick is allowed
Yes	No	No	Reserve when CO comes in after receipt (no auto picking) Manual pick is allowed
No	Yes	Yes	Reserved when CO came in BEFORE receipt. Auto picking will take place.  If full quantity is auto picked, customer order will be set to Ready to Ship or Ready for Pickup. If full quantity is not auto picked, the customer order will be in New status.
No	Yes	No	Reserve when CO comes in after receipt. Auto picking will take place.  If full quantity is auto picked, customer order will be set to Ready to Ship or Ready for Pickup. If full quantity is not auto picked, the customer order will be in New status.
No	No	Yes	Reserved when CO came in BEFORE receipt. No Auto Picking, possible manual picking.
No	No	No	Reserve when CO comes in after receipt. No Auto Picking, possible manual picking.

E*Waybill

SIOCS will be enabling integration with the Oracle Fiscal Document Generation tool (FDG) to allow the creation of E*Waybills. This is a legal document required in many countries where the government requires the pre‑registration of shipments. The retailers can configure SIOCS using store configurations to incorporate obtaining the E‑Way bill document in the shipment process, if the E-Way bill is mandatory in the country where they are operating. In SIOCS, a generic term Fiscal Document is used to refer to the E-Way bill document and Fiscal Doc ID to refer to the E-Way bill ID. The areas where the E-Way bill ID is used are Transfer Shipment, RTV Shipment, and Customer Order Deliveries.

Details

When the shipment is submitted in SIOCS, the Oracle Fiscal Document Generator (FDG) system picks up the shipment submitted and sends the shipment details along with some tax-related information to a third-party system which in turn sends the details to the government system.

The government system validates the details submitted and sends the Fiscal Document ID back, if the shipment has been approved. Once this ID reaches SIOCS, the shipment is ready to be dispatched.

The detailed process on how the Fiscal document for shipments (Transfer, RTV, and Customer Order Deliveries) is obtained is as follows:

• Capture Vehicle/Driver Details:

  • The vehicle number, vehicle country of the vehicle used for the shipment, driver name, and driver license number should be captured before submitting, if configured. The retailers have the flexibility to configure which one of these details need to be captured, depending on the rules and regulations applicable in the country where the store is operating. These configurations are done at the store level.

  • These details are captured in the Edit Shipment screen of the respective transactions.

• On Submit of the shipment:

  The process of requesting a Fiscal Doc ID for the shipment starts when the user submits the shipment. Once the submit is done:

  • The Fiscal Doc ID request gets a unique Request ID.

  • Once the request is made, there should be no change in the shipment details (items, quantities, and so on).

  • The status of the shipment will be Submitted and the status of the Fiscal Doc request will be Waiting for Fiscal Doc ID.

  • The request ID and status of the request can be viewed from the Info screens of the respective transactions.

  • SIOCS should not be able to move shipments from submit to dispatch unless the Fiscal Doc ID has been received.

  • However, if the user has the Allow dispatch without Fiscal Doc ID security permission, the shipment can be shipped without the Fiscal Doc ID.

• Once the Fiscal Doc ID is received and is available for the shipment:

  • The status of the request is updated to Fiscal Doc Approved and the shipment then can be dispatched.

  • The Fiscal Doc ID will be associated with the shipment only if the shipment is in Submitted status or Dispatched status (if the user had override permission to dispatch before the Fiscal Doc ID arrived).

  • A notification will be created informing the user that the shipment is now ready for dispatch, if the shipment has not been dispatched already.

  • External Link: When the Fiscal Doc ID is communicated to SIOCS, there is a possibility that an external link (URL) will also be sent. This URL enables the retailer to print the Fiscal document, whenever needed. Any user with the Access Fiscal Doc URL security permission can access this URL.

• Cancelling the request:

  If the user does a Cancel Submit of the shipment, the Fiscal Doc ID will become invalid if there is already one. In case the Fiscal Doc ID is received post Cancel Submit, it will be rejected/ignored. The Shipment has to go through the Submit process again to obtain the new Fiscal Doc ID in order to be dispatched.

• Transfer and Vendor Deliveries:

  The warehouse and supplier will also need to obtain the Fiscal Doc ID before they dispatch the shipment. SIOCS is able to leverage the Fiscal Doc ID from the deliveries sent from a warehouse and also for the deliveries from vendors to identify the delivery.

• Scan Bar:

  SIOCS will allow a user to scan the Fiscal Doc ID and retrieve the transaction with it, similar to ASN, Container, and so on, in the Transaction List screens of Transfer Shipment, RTV Shipment, Customer Order Deliveries, Transfer Receiving, and DSD Receiving.

Configurations: The Store Inventory system provides the retailer with a lot of flexibility to handle the Fiscal Doc mandate based on the rules and regulations that prevail in the area in which the store is located. The configurations are set at the store level and further at the Transaction type level.

The configurations to enable obtaining the Fiscal Doc ID are as follows:

• Restrict shipment dispatch after submit

  A shipment cannot be dispatched without a Fiscal Doc ID. The system automatically requests a Fiscal Doc ID on Submit when this store parameter is set to Yes. Once the Fiscal Doc ID is available, the user is notified about it and the shipment can be dispatched.

  This parameter is available separately for each transaction type (Transfer shipment, RTV Shipment, Customer Order Delivery). This allows the user to set the Fiscal Document mandate only for the transaction for which it is necessary.

• Capture Vehicle Details on submit

  The details related to the vehicle and the driver used for the transportation of the items are needed to be sent to the government in order to obtain the Fiscal Doc ID. In SIOCS, this can be achieved by setting the store parameter Capture Vehicle Details on submit. This configuration can be set at the Transaction Type level (Transfer Shipment, RTV Shipment, Customer Order Delivery) and the values for these fields can be captured through the respective Edit <transaction> screens. The value captured for these fields are not persisted in the SIOCS database.

The retailers are offered the flexibility to make all or some of these details mandatory to be captured based on the rules and regulations of the area in which the store is operating. The store parameters that enable the retailer to configure this are as follows:

• Vehicle Number Required for Transfer Shipment

• Vehicle Country Required for Transfer Shipment

• Driver Name Required for Transfer Shipment

• Driver License Number Required for Transfer Shipment

The configurations mentioned above can be set at the Transaction Type level (Transfer Shipment, RTV Shipment, Customer Order Delivery).

View Fiscal Doc Information: The user can view the Fiscal Doc Request ID, Request Status, Reject Reason (if rejected), Fiscal Doc ID, and Ext Link in the Info screen of the respective transactions.

Search Criteria Screen: Fiscal Doc related fields are also included as part of Search Criteria screens of Transfer Shipment, RTV Shipment, Customer Order Deliveries, Transfer Receiving, and DSD Receiving.

To better understand how the Fiscal Doc related fields are accommodated in the screens, refer to the respective shipping areas in the Oracle Retail Store Operations Cloud Service User Guide.

RTV Request Restriction

A new permission is introduced to allow a user to accept quantities on a Return to Vendor (RTV) request above the quantity requested by the merchandise system.

Permissions

Allow Over Accepting

RTV

With this permission, the user will be allowed to accept quantity more than the Requested quantity in the RTV Request. Without this permission, the user will not be allowed to accept qty more than the Requested qty.

Transfer Request Context

When creating a transfer request, SOCS will now have the ability to make the context field required when creating a new RTV request. In addition, it will be put on the notification created for transfer requests.

Store Parameters

Context Type/Value required for Transfer (new)

This configuration decides whether the capturing of context type and value is mandatory or not before requesting a transfer.

Values: Yes/No

Bulk Data Integration

To support implementation and initial data migration better, SIOCS added two new File Transfer Service (FTS) flows:

• Support for UINs attached to transactions.

• Support for closed and open RTV documents, and the shipments going along with these.

REST Services

Similar to prior releases, SIOCS has added new REST services. In this release, the following services have been added:

• ItemISN allows the import of Secondary Item Scan Numbers. These numbers are used as a reference to a merchandise created SKU or as a secondary reference to a unique identification number (UIN).

• Warehouse inventory will override the existing warehouse inventory position.

• Inventory Adjustment - find, read, create, update, and approve.

• Sequencing - Find Area, Read Area, Create Area, Overwrite Area, Delete Area, Create/Add Item, Update/Modify Item, and Delete Item.

• Store orders - find, read, approve, and cancel. (Note: no edit of qty or add item yet.)

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

Technical Updates

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

• Various performance enhancements in batches, including Cleanup Items batch.

• Continued enhancement around deployment and configurations.

SIOCS Data Access Schema (DAS - Golden Gate) Changes

Replicated views in SIOCS DAS have been renamed as DAS_* in this release. See the DAS view Data Model in Doc ID 2910995.1. Note that the DAS replication view structure has not changed in this release.

Oracle Retail Integration Cloud Service User Configuration

A self-serve capability has been added for customers to manage the Oracle Retail Integration Cloud Service (RICS) integration user when SIOCS NextGen is integrated with RICS release 19.x. The Customer Administration User must create an IDCS user with the required RIB admin groups (ribAdminGroup / ribAdminGroup_preprod) to access the publisher endpoints. The same user credentials must then be configured on the Credential Administration screen. For further details, see the Integration chapter, Security Considerations section of the Oracle Retail Enterprise Inventory Cloud Service Administration Guide.