Cloud Readiness / Oracle Warehouse Management Cloud
What's New
Expand All


  1. Update 21C
  1. Revision History
  2. Overview
  3. Feature Summary
    1. WMS Common
        1. Removing Empty Payload Elements
        2. UI Search Enhancements
        3. Key Changes in 21C for Unit of Measure (UOM)
        4. To Be Counted Flag and To Be Counted Timestamp Fields Added to Location Interface
    2. Inventory Operations
        1. Rename LPN Via Action Button in LPN Item Inventory View UI
        2. Inventory Attributes Now Supported Using IB Shipment Detail PATCH API
        3. Deallocate an IBLPN Using a REST API
    3. Inbound Logistics
        1. Define Order Waving Sequence Rules
        2. Validate User Input for Quality Control Questions
        3. Default Reason Code on Modify IBLPN
        4. Adjustment to FEFO Flag in Putaway
        5. Prevent Appending of Scanned Values During RF Transactions
    4. Outbound Logistics
        1. Group Orders in Task Based on First Pick in Pick Sequence
        2. Support for List of Values (LOVs) for Inventory Attributes
        3. Restrict Number of Orders in an LPN During Pack NC Active
        4. Wave Pick Info Interface Enhancements
        5. Introduce New Fields to Required Item Fields UI
        6. Remove Personal Information on Processed Orders
        7. Support Explicit Substitution Using Pick Confirmation REST API
        8. Support LPN and Inventory Attribute Substitution Using Pick Confirmation REST API
        9. Cancel a Task Using a REST API
        10. Break Task by Units/Packs/Cases Using a REST API
    5. WMS Mobile App
        1. New Receiving Transaction in WMS Mobile App
    6. Web Reports and Dashboards
        1. Additional Improvements to Web Reports Gen 2
    7. Warehouse Automation
        1. View MHE System for Allocated Inventory

Update 21C

Revision History

This document will continue to evolve as existing sections change and new information is added. All updates appear in the following table:

Date Product Feature Notes
09 JUL 2021     Created initial document.

Overview

This guide outlines the information you need to know about new or improved functionality in this 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.

GIVE US FEEDBACK

We welcome your comments and suggestions to improve the content. Please send us your feedback at owms-cloud-comms_us@oracle.com.

Feature Summary

Column Definitions:

Report = New or modified, Oracle-delivered, ready to run reports.

UI or Process-Based: Small Scale = These UI or process-based features are typically comprised of minor field, validation, or program changes. Therefore, the potential impact to users is minimal.

UI or Process-Based: Larger Scale* = These UI or process-based features have more complex designs. Therefore, the potential impact to users is higher.

Features Delivered Disabled = Action is needed BEFORE these features can be used by END USERS. These features are delivered disabled and you choose if and when to enable them. For example, a) new or expanded BI subject areas need to first be incorporated into reports, b) Integration is required to utilize new web services, or c) features must be assigned to user roles before they can be accessed.

Ready for Use by End Users
(Feature Delivered Enabled)

Reports plus Small Scale UI or Process-Based new features will have minimal user impact after an update. Therefore, customer acceptance testing should focus on the Larger Scale UI or Process-Based* new features.

Customer Must Take Action before Use by End Users
(Feature Delivered Disabled)

Not disruptive as action is required to make these features ready to use. As you selectively choose to leverage, you set your test and roll out timing.

Feature

Report

UI or
Process-Based:
Small Scale

UI or
Process-Based:
Larger Scale*

WMS Common

Removing Empty Payload Elements

UI Search Enhancements

Key Changes in 21C for Unit of Measure (UOM)

To Be Counted Flag and To Be Counted Timestamp Fields Added to Location Interface

Inventory Operations

Rename LPN Via Action Button in LPN Item Inventory View UI

Inventory Attributes Now Supported Using IB Shipment Detail PATCH API

Deallocate an IBLPN Using a REST API

Inbound Logistics

Define Order Waving Sequence Rules

Validate User Input for Quality Control Questions

Default Reason Code on Modify IBLPN

Adjustment to FEFO Flag in Putaway

Prevent Appending of Scanned Values During RF Transactions

Outbound Logistics

Group Orders in Task Based on First Pick in Pick Sequence

Support for List of Values (LOVs) for Inventory Attributes

Restrict Number of Orders in an LPN During Pack NC Active

Wave Pick Info Interface Enhancements

Introduce New Fields to Required Item Fields UI

Remove Personal Information on Processed Orders

Support Explicit Substitution Using Pick Confirmation REST API

Support LPN and Inventory Attribute Substitution Using Pick Confirmation REST API

Cancel a Task Using a REST API

Break Task by Units/Packs/Cases Using a REST API

WMS Mobile App

New Receiving Transaction in WMS Mobile App

Web Reports and Dashboards

Additional Improvements to Web Reports Gen 2

Warehouse Automation

View MHE System for Allocated Inventory

WMS Common

Removing Empty Payload Elements

You have the option in Oracle WMS Cloud  to share information to external systems through output interfaces (for example, inventory history, shipment confirmation payload). There are certain scenarios where some of these output interface payloads exposed to rest api endpoints can be pretty huge depending upon the data present. As part of the 21C update, you will be able to configure whether to remove empty data elements. In certain scenarios  you would not have used all the data elements for the corresponding entity involved. The feature for removing empty data elements will help  to reduce the payload size  which reduces the load on the integration layer and for systems that are subscribing to the relevant output.

  • To reduce the payload size, we have introduced an ability to remove empty fields or empty data elements. You will be able to enable the feature based on  configuration  in the Output Interface Config Web UI.
  • You will be able to enable or disable the empty data elements by output interface type. This gives you the flexibility to disable empty data elements for Shipment Confirmation file and have empty data elements for LPN Inventory Interface types for example.
  • Removal of empty data elements is applicable for interface format of type “XML”. If the interface type is not XML, then the configuration option will be disabled.

The following image shows the Remove Empty Elements Flag in Oracle WMS Cloud:

Remove Empty Elements Flag

Steps to Enable

  1. Navigate to the Output Interface configuration screen.
  2. Click on the edit pane and select the interface format  “XML” and select the field Remove empty elements flag.

Key Resources

UI Search Enhancements

WAVE INQUIRY - INTRODUCE ORDER DETAIL STATUS FILTER ON WAVE INQUIRY DETAIL SUB UI

In Wave Inquiry, the Order Status and To Order Status fields have been updated  to From Order Hdr Status  and To Order Hdr Status.  To/From Order Dtl Status have also been added as filters. You can now search the order details based on the detail status from the Wave Inquiry Detail UI. When orders have multiple details, there is a possibility that the order header status is different than the detail status (for example: Order Header has two details, one detail is allocated and the other is in created status  (order header  is in Partly Allocated status). The order detail status filter and order detail status column help you to search order details based on the status and see the respective order detail status.

Order Detail Status

The From and TO order details status have been updated to From Order Dtl Status  and To Order Dtl status.

From Order Dtl Status and To Order Dtl Status both support the following values:

  • Created
  • Partly Allocated
  • Allocated
  • In Picking
  • Picked
  • In Packing
  • Packed
  • Loaded
  • Shipped
  • Cancelled

From Order Dtl Status  and To Order Dtl status are displayed below the Order Header Status.

“Order Status” has also been renamed to “From Order Hdr Status” in the Wave Inquiry Detail Sub UI.  "To Order Status"  has also been renamed to "To Order Hdr Status" in the Wave Inquiry Detail Sub UI.

Steps to Enable

You don't need to do anything to enable this feature.

Key Resources

Key Changes in 21C for Unit of Measure (UOM)

NOTE:  The following changes are added for future use and its recommended not to configure these fields or use the functionality until it is recommended in further official release announcements.

USER INTERFACE (UI) CHANGES

  1. A new UOM Configuration action button is added to the Company and Facility UI. This action button is disabled, by default.

New permissions are added in the Group UI. The following fields are intended to future releases.

    • company / Can configure company wt vol dim UOM
    • facility / Can configure facility wt vol dim UOM
  1. You can add screens for UOM UI and UOM class which is intended for future usage. New permissions related to UOM class and UOM UI are also added to the Group UI which is not recommended to be configured for now.

NOTE: We highly recommend users not to add or configure these fields until UOM feature is released.

  1. Changes in ITEM UI

    • In the edit pane of the Item UI, the Primary UOM can be added to the data grid with value defaulted to Units. This field is disabled, by default and is intended for future releases.
    • In the drill-down page of the Item UI, the two new fields is displayed and is disabled by default.
      1. Pack UOM
      2. Case UOM
  2. Changes in ITEM Facility
    • In the edit pane of the Item Facility UI, the Primary UOM is disabled by default and is used for future purpose.
  1. New fields are added to the Input Interface. These fields can be added to the data grid and are intended for future releases:
    Input Interface New fields
    Item

    primary_uom_code, case_uom_code, pack_uom_code, weight_uom_code, volume_uom_code, dimension_uom_code

    Item facility

    primary_uom_code

    Item Pre-Pack

    uom_code, weight_uom_code, volume_uom_code, dimension_uom_code

    Purchase Order uom_code
    IB Shipment

    uom_code, weight_uom_code, volume_uom_code, dimension_uom_code

    Order uom_code
    Work Order

    uom_code for work order kit and uom_code for work order component

    Planned OB Load

    weight_uom_code, volume_uom_code for Load and weight_uom_code, volume_uom_code for Stop

    OB Load

    weight_uom_code, volume_uom_code for Load and weight_uom_code, volume_uom_code for stop

  2. You can now send the uom_code of pack, cases and units using the field uom_code Purchase Order, IB Shipment Work Order KIT, and Order. This field can perform appropriate conversion as well.

You can now send the uom_code of pack, cases and units using the field uom_code Purchase Order, IB Shipment Work Order KIT, and Order. This field can perform appropriate conversion as well.

Steps to Enable

You don't need to do anything to enable this feature.

Key Resources

To Be Counted Flag and To Be Counted Timestamp Fields Added to Location Interface

Two fields have been added to the Location Interface file. These allow you to flag locations to be considered for cycle counting. By introducing the “to be counted flag” in the Location Input UI, you have an additional way of specifying the to be counted flag for a location through interface along with existing options of specifying the to be counted flag through the UI and through patch action using a REST API.

The following columns have been added to the location interface file:

FIELD BEHAVIOR
to_be_counted_flg User should be able to enter true, false, yes, no, 1, 0.
to_be_counted_ts User should be able to enter date/time. Date/time is assumed to be in the time zone of the user's facility. In other words, it should be the date/time viewed by the user in the UI. 

Steps to Enable

You don't need to do anything to enable this feature.

Key Resources

Inventory Operations

Rename LPN Via Action Button in LPN Item Inventory View UI

For scenarios where you may need to rename a LPN, a new action button "Rename LPN" is available in the LPN Item Inventory View UI.

  • This button will allow editing and saving an LPN number.
  • On clicking OK, a popup prompting for "LPN Nbr" will be displayed. Once LPN number is entered, user will have an option to confirm if they want to proceed.

Confirm Message

  • The action button will be active and can be invoked for:
    • IBLPN Status : RECEIVED/LOCATED/RESERVED/PARTLY ALLOCATED/ALLOCATED/LOST.
    • OBLPN Status : OUTBOUND CREATED/IN PICKING/PICKED/IN PACKING/PACKED.
  • The button is inactive or grayed out when the “container/Rename LPN” group permission is not set.
  • On successfully renaming the LPN, if container.ref_lpn_nbr is empty, then it will be set to the original LPN number.

NOTE: Renaming an LPN number can have operational impacts and may lead to redoing some operations. Some operations that may need to be redone include the following:

  • Reprint labels if any.
  • Regenerate any files that may have this information.
  • Resend integration messages, such as some MHE messages sent with the previous container number.
  • Validation for old/new LPN numbers that changed will not happen if they have already been used in "Required LPN number" on Orders and IB Shipment details.

Steps to Enable

To enable the  Rename LPN action button, enable the “container/Rename LPN” group permission.

Key Resources

Inventory Attributes Now Supported Using IB Shipment Detail PATCH API

Now, you can send inventory attributes A to O using the IB Shipment Detail PATCH API.

Example Request

PATCH .../wms/lgfapi/v10/entity/ib_shipment_dtl/123/

where 123 is the id of the IB Shipment Detail that needs to be updated.

JSON sample of the request body:

{

"fields": {

"invn_attr_id": {

"invn_attr_a": "a",

"invn_attr_b": "b",

"invn_attr_c": "c"

},

"cust_field_1": "cust1"

}

}

VALIDATIONS

  • If invn_attr_id is provided, additional validations are needed
    • IB shipment header status should less than Receiving-Completed. 
    • the IB Shipment detail should not have started receiving. received_qty should be 0.
    • If the ib shipment detail has po_dtl_id already populated, meaning its linked to a PO, we will not support updating the invn attributes and the validation will fail
    • If these validations fail, the request should fail (so any other fields like custom fields provided in this request will not be updated even though they may have more lenient validations).
  • Validate that the invn-attribute record matches the facility/company.
  • If no invn_attr_id are provided then the current validations for custom fields should apply

Steps to Enable

Review the REST service definition in the REST API guides, available from the Oracle Help Center > your apps service area of interest > REST API. If you're new to Oracle's REST services you may want to begin with the Quick Start section.

Deallocate an IBLPN Using a REST API

The deallocate API allows you to de-allocate IBLPN which is in Partially Allocated/Allocated status through an API

API URL: LOOKUP BY ID 

POST.../entity/LPN/{id}/deallocate/

  • No additional `parameters` data in the request body is required.

API URL: LOOKUP BY FILTERS 

POST.../entity/iblpn/deallocate/

Category Name Required Type Description
parameters facility_id   Integer Facility context by id
parameters

facility_id__code

  string

Facility context by code

parameters

company_id   Integer

Company context by id

parameters

company_id__code

  string

Company context by code

parameters

lpn_nbr X string

IBLPN which needs to be De-allocated

  • If facility and/or company are provided, set login context accordingly.
  • Only one of `facility_id` or `facility_id__code` may be provided.
  • Only one of `company_id` or `company_id__code` may be provided.

BULK_CANCEL URL

POST.../entity/iblpn/bulk_deallocate/

Request Body:

The transaction is meant for the task entity. Hence, the users are required to send the following parameters in the body. 

POST.../entity/task/bulk_deallocate/

{

"parameters": {

"id__in": [01, 02, 03]

},

"options": {

"commit_frequency": "0",

}

}

The commit frequency is by default set to 0. If it is set to 0, the system should roll back on first error/ If the commit frequency is set to 1, the system should  commit per object. ID can be sent in bulk_deallocate or LPN numbers can also be shared.

Steps to Enable

Review the REST service definition in the REST API guides, available from the Oracle Help Center > your apps service area of interest > REST API. If you're new to Oracle's REST services you may want to begin with the Quick Start section.

Inbound Logistics

Define Order Waving Sequence Rules

Now you can define the ordering sequence for the orders selected for allocation and picking. The new Ordering Sequence Rule UI allows you to define what fields  you want to select to order your orders and the sequence. Defining the ordering sequence allows you to  prioritize the orders that need to be fulfilled first. Previously, Oracle WMS Cloud selected orders to be allocated and picked based on the order priority and created date time. Now, you have the flexibility to choose from 200 + fields from Order Header, Order Detail, and Item tables. The Order Sequence Rule is available for Picking Waves.

PICKING WAVE TEMPLATE

A new Order Sequence Rule button is introduced in the Wave Template Searches Sub UI of the Picking Wave Template screen. Order Sequence Rule allows user to define the columns which can be utilized for sequencing the orders which are determined for allocation.

NOTE: Prioritization of orders is not recommended to be used when a picking wave is run with a replenishment rule associated to the wave template. Replenishment might not honor the order prioritization logic.

ORDER SEQUENCE RULE

This screen allows user to create a rule name, description and template type.

  • Rule Name: User can define the rule name, so that this rule can be linked to a particular wave template search.
  • Description:  User can define description for the rule.
  • Template Type: User can select whether this order sequence rule is required for Wave Template (Picking Wave) or Work Order Wave Template.
  • Order Sequence Rule

ORDER SEQUENCE RULE DETAIL

This screen allows user to define the columns which can be used to sequence the orders which are determined for allocation.

  • Sequence Nbr: User can define the sequence for a given column so that it can be considered accordingly for sequencing the orders.
  • Order by column:  User can select the order columns based on which orders can be sequenced and subject for allocation.
  • Sort By: User can select Ascending or Descending, based on this selection, value of the column will be sorted to create the order sequencing.

Order Sequence Rule Details

WAVE TEMPLATE SEARCHES SUB UI

This screen allows user to link the order sequence rule created in the above section to a particular Wave Template Search.  Since wave template search determines the list of orders that need to be subjected for allocation, the order sequencing rule sequences the orders determined by the wave template search.

  • A new field “Order Sequence Rule” is introduced on the wave template search. This allows you to select the order sequence rule created for the picking wave.

Rule for Picking Wave

Example:

The following are a list of orders which are determined for allocation:

Order Header Number Order Detail SKU Order Header Priority Order Detail Create Time Order Detail Order Qty
ORD1 SKU1 3 18-4-2021 15
ORD1 SKU2 3 16-3-2021 25
ORD2 SKU3 2 15-4-2021 10
ORD3 SKU4 4 18-2-2021 15

For the above data,  the following example shows a few rules and how the order will be sorted:

  • Order Sequence Rule Header:  RULE1
  • Order Sequence Rule Detail:
    • (Seq-1) Ord Hdr Priority (Ascending)
    • (Seq-2) Ord Dtl Ord Qty (Descending)

For the above RULE1 orders will be sequenced as defined below:

Sequence RULE1
1 SKU3
2 SKU2
3 SKU1
4 SKU4

WAVE GROUP

Similar to a picking wave, when you define the order sequencing rule on the wave template search for Wave Group, the system will sequence the orders that need to be subjected for allocation before distribution. After applying the order sequencing rule, orders are distributed across the wave template associated with the wave group.

NOTE:  The order sequencing rule is not for determining the orders for allocation. It’s only to sequence the orders are subjected for allocation.

Steps to Enable

For a Picking Wave:

  1. Go to the Wave Template screen.
  2. Navigate to the Wave Template Search sub-UI.
  3. Click on the Order Sequence Rule Button in the wave template search sub-UI.
  4. Create the Order Sequence Header, by defining rule name, description and template type as Wave template.
  5. Create the Order Sequence Detail, by populating columns which needs to considered for sequencing the orders.
  6. Populate the Order sequence rule for the Wave Template search.

Key Resources

Validate User Input for Quality Control Questions

In 21C, the system now validates user responses when answering a quality control question in the RF Quality Control (QC) Complete transaction (rf.inbound.cwrfqccomplete). If you set up a verification question requiring yes/no in VerificationQuestionView, the response will need to match the yes/no Answer Input Type that was set or otherwise the user will receive an “invalid entry” message.

Input Type Validation Behavior
Yes/No

You cannot provide values other than Yes/No values.


Accepted values: Y/N, or Yes/No (case agnostic).

NOTE:Translatable. Input should be fixed to English language alone

If you provide any other value, “Invalid input” error will appear.

Text

You should be able to provide alphanumeric values.

 

The answers provided by the users will also be recorded in Verification History View under entered value and next to Answer Input Type.

Steps to Enable

You don't need to do anything to enable this feature.

Key Resources

Default Reason Code on Modify IBLPN

This enhancement helps with scenarios such as Receipt Adjustments where a receipt adjustment reason code can be configured on the module for an RF screen that is dedicated to Receipt Adjustments.. In 21C, you can configure a default reason code on Modify IBLPN where you can configure the reason code for an RF screen.

A new screen parameter “reason-code” has been added to  RF Inbound Modify Case (inbound.cwrfmodcase) which accepts a string value.

  • If the reason code screen parameter is not set with any value, you are prompted for a reason code after the quantity in the IBLPN is modified.
  • However, if the parameter is set with a valid value, you are not prompted for a reason code code after the quantity in the IBLPN is modified.  Instead the value from this screen parameter will be used as the reason code.
  • Regardless of how the reason code has been captured (via user prompt OR from the screen parameter), the value is used on the IHT-4 and IHT-17 transaction records.

NOTE: If an invalid reason code is configured on the screen parameter, you will encounter an error message when the corresponding RF screen is launched.  You can correct the reason code on the screen parameter and re-launch the RF screen.

Steps to Enable

  1. In the RF Inbound Modify Case (inbound.cwrfmodcase) module, set the screen parameter “reason-code” with a valid reason code.  
  2. This enables the default reason code functionality for the module.

Key Resources

Adjustment to FEFO Flag in Putaway

Prior to 21C, in the Putaway Priority UI, when a putaway priority record is configured with the Consider FEFO flag, you can putaway inventory to a location that has a higher priority date than the incoming inventory, so that the inventories with lesser priority dates stay in front of the inventories with higher priority dates during picking.

For example:

Let’s say you receive a shipment of milk with a priority date of 7/30/21. You have two locations where you store milk. In the first location, you have inventory with a priority date of 7/15/21, and in the second location, you have inventory with a priority date of 8/30/21. Prior to 21C, if you had the Consider FEFO flag enabled, the system would direct incoming inventory to the second location. This method is most suitable for push-back racks as the incoming inventory will be prioritized ahead of the older inventory.

In 21C, Putaway Priority is enhanced to support FEFO operation for gravity feed mechanisms and also where the picking happens from the opposite direction of putaway. As a result, you can putaway inventory to a location that has a lesser priority date than the incoming inventory so that the inventories with lesser priority dates stay in front of the inventories with a higher priority date during picking.

The default state of the Storage Priority drop-down is blank (which indicates that FEFO operation is not enabled for the putaway priority record).

The Storage priority drop-down has the following options for  you to choose from;

  • Less than or equal to priority date (default option when Consider FEFO flag used to be checked). Customers who had to consider FEFO flag set to “yes”, will see the storage priority drop-down defaulted to Less than or equal to the priority date.
  • Greater than or equal to the priority date.
  • The Behavior of the Storage priority drop-down options is elaborated with the following table:

    Options

    Behavior

    Blank

    This is the default state of the Storage priority. When set to blank, the priority dates will not be considered for the putaway priority record.

    Less than equals to priority date

    This is the state of the Storage priority for the putaway priority records which had the Consider FEFO flag turned on.


    When selected, the you  can putaway inventories with a lesser expiry date than the location inventory expiry date.


    NOTE: This mode is suitable for Push back Racks.

    Greater than or equal to priority date

    When selected, you can putaway inventories with a higher expiry date than the location inventory expiry date.

    NOTE: This mode is suitable for Gravity feed Racks.

The Storage priority field now honors the Location Size Type or the Replenishment Zone in the putaway priority. As a result, the Storage priority options now compare the incoming inventory's priority date with the location inventory priority date of the locations within the location size type or the replenishment zone.

NOTE: The Storage priority field Is applicable to SKUs which track expiry dates. If an SKU is not tracking expiry dates, then the FEFO operation is not honored for a putaway priority record.

PALLET PUTAWAY

If a pallet contains multiple LPNs of the same SKU having the same expiry date across the LPNs, the pallet will be allowed to putaway to a suitable location following the FEFO operation when the Storage priority field is turned on.

If a pallet contains different expiry dates across the LPNs of the same SKU, you will be able to putaway the pallet to the eligible locations if the putaway priority does not have the storage priority flag configured. Additionally, If the putaway priority matches with the first LPN's expiry date in the Pallet, users should be able to putaway the pallet to the eligible locations.

NOTE:  Multi SKU LPN or pallet putaway is not being handled as part of this enhancement..

UPDATES TO PUTAWAY PRIORITY REST API

The Consider FEFO Flag in the PUTAWAY Priority UI has been renamed to Storage Priority. To reflect this change, the ’storage_priority_id ’ has been added as a parameter. Parameter consider_fefo_flg is still available to be send in the request.

Name

Required

Type

Default

Description

storage_priority_id

 

Integer

 

"1” indicates "Less than or equal to priority date" and "2” indicates "Greater than or equal to priority date"

If the storage priority id parameter is not populated, then the consider_fefo_flg will be considered to populate the storage priority in the Putaway Priority UI. If both the storage priority id and consider fefo flag parameter values are populated, then the value populated for the storage priority id parameter will take precedence.

Sample Post URL: POST .../entity/putaway_priority

Sample Request Body

{   

"fields":

{

        "facility_id": 1, 

       "priority": 1, 

       "putaway_type_id": 256860, 

       "putaway_method_id": 1,

        "putaway_search_mode_id": 0, 

       "locn_type_id": 3, 

       "locn_size_type_id": 0, 

       "replenishment_zone_id": 35995, 

       "consider_fefo_flg": true,

        "storage_priority_id": 1,  

      "radius": 1, 

       "radial_increment": 1 

   }

}

NOTE: The GET support for the putaway priority will fetch the storage priority id parameter in the return body instead of the consider fefo flag parameter. For more info on the API , refer to the REST API Guide.

Steps to Enable

You don't need to do anything to enable this feature.

Key Resources

Prevent Appending of Scanned Values During RF Transactions

There are certain prompts while performing warehouse floor operations where users are asked to enter information  via Pop Up Dialog Boxes. Certain warehouse operations will result in prompting and defaulting the input value so that the user can confirm the prompted value or override with a different value. When you are overriding the defaulted value while using scanners, the defaulted value will get appended to the scanned value which can result in discrepancies. With this feature, popup dialog boxes  default batch numbers have the text highlighted so that the scanned value will overwrite the batch number. You will not be forced to manually delete the characters before scanning.

Certain warehouse floor operations prompt for value input and if the value is known earlier, the system will default the value. If you want to override the value, manual deletion is required, which is not easy in RF handheld devices.  Example (While performing Receiving, we prompt for batch number as a pop-up screen. If the batch number is present on the shipment detail, the system defaults the batch number based on item settings. You will see the defaulted text selected which ensures that you can scan a new value without the defaulted value getting appended.

DIALOGUE POPUP SCREEN BEHAVIOR WHEN TEXT IS DEFAULTED

  • When a value is prepopulated, the text will be highlighted using a reverse color of the text. Upon hitting enter/tab, the system will accept the selected text.
  • Typing something else will delete all selected text and replace it with typed or scanned text. If you want to edit or add to it, press an arrow key which removes the selection and lets the user edit. If the user presses tab or enter, then  the text is accepted as is.
  • if the user presses any arrow key, the selection is removed.
  • once an arrow key is pressed, any character typed will get appended or will overwrite the characters depending on where the cursor is, as normal behavior in RF.
  • if the you press any other key (other than arrows, tab or enter), the system will delete the selected text and start from scratch.

EXAMPLE:

The following shows an example of an Inbound Shipment to be received:

Shipment SKU Batch Number Shipped Qty Received Qty
ASN1 ABC B1 100 0
ASN1 XYZ B2 80 0

Both item's ABC and XYZ have been enabled to prompt for batch number always (item's batch prompt for receiving is set to "Always Prompt").

  • User Scans the Shipment ASN1.
  • User is prompted for LPN
  • User scans LPN001 barcode
  • Item barcode scan prompt is displayed
  • User Scans barcode for ABC sku.
  • User is prompted to enter Qty.
  • User enters qty of 20
  • The system displays a pop up screen of batch number and batch number "B1" is defaulted and text B1 is selected. If you want to proceed by scanning the value system will not append the scanned value.
    • Impact without the change: Prior to this change, If  you wanted to change the batch number, entry has to be deleted, typically users scan the batch number to proceed further. Typically batch number would be scanned, If you scan the batch number we appended the batch number to the defaulted value, so we could end up receiving above shipment with batch number of "B1B1"

NOTE:  The change is currently applicable for dialog popups that allow  a barcode type.

  • The change described above is not applicable for expiry date popup dialogs.
  • The change described above is not applicable for the Inventory Attributes screen which displays after a sku barcode scan.

Steps to Enable

You don't need to do anything to enable this feature.

Key Resources

Outbound Logistics

Group Orders in Task Based on First Pick in Pick Sequence

This feature enhances overall picking efficiency and reduces the time consumed to complete the task. In 21C, a new flag “Extended Grouping” is added to the Ordering Criteria UI in the Task Creation template screen that allows you to group the orders in the task based on the Pick sequence. After you configure the Location Pick Sequence and Order Number in the Ordering criteria and enable the extended grouping for the order number, the system creates a task based on the Pick sequence and this ensures that the orders are not split into multiple tasks.

  • The Extended Grouping flag is added to the Ordering Criteria UI in the Task Creation template. This flag is disabled, by default.
  • If there are multiple ordering criteria sequences defined for the task type, you can enable this flag for ONLY one ordering criteria sequence with a break by count greater than zero.
  • This extended grouping flag supports all the Order by column values provided if the break by count is greater than zero. For example, if you want to pick only two items for a task, the Order by column value can be set to an alternate item code and the Break by count can be set to 2.

EXTENDED GROUPING MECHANISM

Let’s say you have a task with orders allocated to different picking locations from each other and this requires you to move across the location to complete the task. To improve the efficiency of the picker, you can enable the Extended grouping flag where the system groups the order based on the pick sequence and the break by the count you define for the ordering criteria.

The system groups all of the allocations in the wave to fulfill each group of orders. (In the following example, two orders that that are closest in the pick sequence are grouped as per the ordering criteria defined in the same task. The system looks at the rest of the allocations and the allocations that satisfy the two orders that have the same task. For example, let’s say you have a picking wave with the following configuration:

Order Item Quantity
Ord01 Item01 10
Ord02 Item02 10
Ord03 Item03 10
Ord04 Item04 10
Ord05 Item05 10
Ord06 Item06 10
Sequence Nbr Order By Column Break By Count
1

From active location pick sequence

0
2

Order Hdr Order Nbr

2

NOTE: Only one ordering criteria sequence is allowed to have a non-zero Break by count when configuring extended grouping.

When enabling Extended Grouping for Ordering criteria in Task Creation Template with the above Ordering criteria configuration, the system creates tasks for allocation by location pick sequence as you can see  in the following table:

  • Groups the order based on the break by count and the pick sequence and creates a task. Here, the break by count is 2 and therefore, Ord01 and Ord04 are grouped into first task.
  • After the task is created, the system looks at the other pending allocations in the wave, and if any allocations have the same order as ord01 and Ord04, (for example, Ord01 in loc13 and Ord04 in loc22.) The system groups Ord01, Ord04, Ord01(Loc13), and Ord04 (Loc 22) into one task (Task010.).
  • Similarly, the system groups the orders, Ord03 and Ord02 and checks for other allocations with the  same orders, here Ord02(loc15) and Ord03 (loc20) into another task (Task011.)

    Order Item Location Location - Pick Sequence Allocated Quantity Enabling Extended Grouping Without Extended Grouping

    Ord01

    Item01

    Loc01

    01

    5

    Task010

    Task001

    Ord04

    Item04

    Loc03

    03

    5

    Task010

    Task001

    Ord03

    Item03

    Loc05

    05

    5

    Task011

    Task002

    Ord02

    Item02

    Loc07

    07

    5

    Task011

    Task002

    Ord06

    Item06

    Loc09

    09

    5

    Task012

    Task003

    Ord05

    Item05

    Loc11

    11

    5

    Task012

    Task003

    Ord01

    Item01

    Loc13

    13

    5

    Task010

    Task004

    Ord02

    Item02

    Loc15

    15

    5

    Task011

    Task004

    Ord06

    Item06

    Loc17

    17

    5

    Task012

    Task005

    Ord03

    Item03

    Loc20

    20

    5

    Task011

    Task005

    Ord04

    Item04

    Loc22

    22

    5

    Task010

    Task006

    Ord05

    Item05

    Loc24

    24

    5

    Task012

    Task006

    In case the Ordering criteria is defined without enabling extended grouping:

  • The system groups in the order of pick sequence and task is created for 2 orders at the same time. That is, when the wave is run, Ord01 is split into 2 tasks (Task001 and Task004) respectively.

  • Without extending grouping, the system creates multiple tasks for the same wave to satisfy a single order.

NOTE: The extended grouping feature works in conjunction with the existing break by Quantity or Break by Weight or Break by volume fields defined in task creation template.

Steps to Enable

  1. Go to the Task creation screen (Module:TaskCreationView).
  2. Go to the Task creation >> details screen.
  3. Select a task creation sequence and click the Ordering Criteria Button in the Task creation >> details screen.
  4. Enable Extended Grouping flag for any one the ordering criteria sequence (this ordering sequence should have Break by count greater than zero).

Key Resources

Support for List of Values (LOVs) for Inventory Attributes

By defining a List of Values (LOV) for Column Formatting Rules, you can prevent occurrences of incorrect data entry for inventory attributes and have consistent data for inventory attributes. In update 21C, you can configure a valid List of Values (LOV) for inventory attributes (A-O) in the Column Formatting Rules UI. The specified configuration will restrict the values that you can enter for inventory attribute fields in UI/RF screens and when using API's.

For example, if inventory attribute B is used to track country of origin, you can configure an active column formatting rule for inventory attribute B with ‘MEX’, ‘USA’ and ’CAN’ as LOV’s. The system will display an error, when you enter “US” or “United States of America” as values for inventory attribute B in UI/RF/API’s.

CHANGES TO COLUMN FORMATTING RULE UI

Column Formatting Rule

  • You can configure Column Formatting Rules for both Numeric data type and Alphanumeric data type
  • You must enable the Active Flag option to consider Column Formatting Rule for validation
  • Newly added fields in Column Formatting Rule UI  (module: ColumnFormattingRuleDefinitionView)
Column Formatting Rule UI Fields Description
Data type

You can configure data type as either “NUMERIC” or “ALPHANUMERIC”.


If you configure data type as alphanumeric, minimum value, maximum value and precision fields will not be applicable.

Rule Name

Rule Name along with facility and company is used to uniquely identify each column formatting rule. For a given facility & company combination, rule name can’t be the same for two or more column formatting rules.

Entity

You can currently configure “*” as valid value for entity.

NOTE:

  • All existing Column Formatting Rules configured will be updated with values for Rule Name and Entity fields (value will be *). You will be able to edit values for Rule Name field in UI

  • Only one rule can be active at a time for the same inventory attribute/facility/company code combination

  • The system will not validate Formatting Rules against existing data. However, any new data will validate against Formatting Rules that you setup.

  • Any edits to Column Formatting Rules will be tracked in the application logs. If a particular lock code has the treat as attribute value populated, then Column Formatting Rules can't be created against that attribute

NEW COLUMN FORMATTING RULE DETAIL UI TO CONFIGURE VALID LOV

Column Formatting Rule Detail UI

  • You can create and update a valid List of Values (LOV) for the column formatting rule
  • You can configure LOV’s by item (matching scope as “ITEM_CODE” and matching value as the item code) or you can have a generic configuration for LOV (matching scope as “*” and matching value as “*”)
  • Newly added fields in the Column formatting Rule Detail UI
    Column Formatting Rule Detail UI Fields Description

    Rule Name, Facility, company, Column name, Data type, Entity

    Informational fields populated from column formatting rule.

    Matching Scope You can choose between two options.
    Matching Value

    If matching scope is “ITEM_CODE”, you can enter the item code for which the LOV value is defined.

    If matching scope is “*”, you can enter “*”.

    LOV

    You can enter values (LOV) that will be used in validation of column name mentioned in formatting rule, LOV data can be numeric or alphanumeric depending on data type.

NOTE:

  • If the data type is numeric, when you define LOV values, they should be within the minimum and maximum value  and should not exceed the precision defined, or else the system will display an error message.

  • Any edits to Column Formatting Rule Detail fields will be tracked in the application logs.

FORMATTING RULE VALIDATIONS IN UI/RF/APIs FOR INVENTORY ATTRIBUTES

  • You must enable the Active Flag to consider Column Formatting Rule for validation.
  • If you have configured column formatting rules without LOV’s
    Data type Validations
    Numeric

    You should enter inventory attribute value within the min value and max value defined for the rule. Else system will display error.

    You should not enter more than the precision defined after decimals.

    Alphanumeric

    You have not configured LOV, so there is no formatting rule validation.

  •  If you have configured column formatting rules with LOV’s
    Data type Validations
    Numeric

    You should enter inventory attribute value that matches any one of the LOV’s configured in the rule. If LOV values are 1 and 2. you can either enter 1 or 2 for inventory attribute, if you enter 3 or any other value, system will throw an error.

    Alphanumeric

    You should enter inventory attribute value that matches any one of the LOV’s configured in the rule.

    NOTE: the system looks for exact match (includes case) while comparing entered value against LOV to reduce data inconsistency. For example, if LOV is ‘red’, you must enter only ‘red’ and system will throw error if you enter ‘REd’ or ‘RED’.

In the following example:

  • for "KNITEM01", the LOVs considered for validation are "IND", "AUS". If you enter “CHN” as a value for inventory attribute C for ITEM01, the system will display an error.
  • For all other items (since there are no item specific LOV's defined), generic configuration (*, *)  is considered and the LOV considered for validations are "CHN", "IND", and "AUS". You can enter “IND” or “CHN”, but if you enter “INDIA” as a value for inventory attribute C fo ITEM02,  the system will display an error.
    Column name Matching Column Matching Value LOV
    Inventory Attribute C Item code KNITEM01 IND
    Inventory Attribute C Item code KNITEM01 AUS

    Inventory Attribute C

    * * IND

    Inventory Attribute C

    * * AUS

    Inventory Attribute C

    * * CHN

NOTE:

  • The new column formatting rule LOV validations are not applicable, when you provide inventory attribute information through input interfaces.

  • If you configure column formatting rules with different values for the same inventory attribute across different facilities, note that inter-facility transfer can have challenges due to the data inconsistency for inventory attribute values among the facilities.

RF SCREENS

Once you configure formatting rules, inventory attribute values entered in the following RF transactions will be validated with the configured LOV values:

  • RF Receive by shipment
  • RF Receive by Load
  • RF Cycle Count Location
  • RF Cycle Count LPN
  • RF Create LPN
  • RF Sort and Receive.
  • RF Split IBLPN
  • RF Modify LPN
  • RF NC Active Picking

Validation will happen after you enter a value in the inventory attribute field. If the attribute fails, the formatting rule validation, the system displays error message. For example, when you configure “RED”, “MAROON” and “PINK” as LOV values for inventory attribute B, if you enter “MERON”, the system will display the following error:

Error Message

NOTE:

  • If you need to enter values with decimals and negative values, you must configure the company parameter barcode valid characters to allow "." or "-".
  • If the LOV’s configured have special characters, you must configure the company parameter barcode valid characters to allow those special characters.

UI SCREENS

Once you configure formatting rules, inventory attribute values entered in the following UI transactions will be validated with the configured LOV values:

  • Purchase Order Inquiry
  • Order Inquiry
  • Work Order Inquiry
  • Inbound Shipment Inquiry
  • IBLPN Inquiry
  • Mass Update Inventory attributes
  • Bulk Update Order details

After you click save, if any attributes fail the formatting rule validations, the system displays error message with information on which attributes failed validation. For example, when you configure “RED”, “MAROON” and “PINK” as LOV values for inventory attribute B. If you enter “MERON”, the system will display the following error:

Meron Error

APIs

  • You can interface inventory attribute data in a few REST APIs to create new inventory records. Once you configure Column Formatting Rules for a particular inventory attribute, Oracle WMS Cloud will validate for the relevant inventory attribute. API operations will fail when formatting rules are not honored.
  • The system applies formatting rules using the following API trigger points:
    API Description
    Composite Create

    POST …/entity/iblpn/composite_create/

    Bulk Update Inventory Attributes

    POST …/entity/inventory/bulk_update_inventory_attributes/

    Update Active Inventory

    POST …/entity/location/{id}/update_active_inventory/

NOTE:

  • There will be some additional processing required for validating the formatting rules, so customers using Bulk Update Inventory Attributes cannot expect the same performance levels with formatting rules enabled.

  • In bulk update inventory attributes API, when the commit frequency is set to 1, if some of the inventory IDs provided fail the column formatting rule validations,  the error response will include  inventory ID details  in the fail validation.

  • When you perform one of the above operations, if any of the attributes fail the validations, the system will send a response that includes the attributes which failed the validation.

NEW INPUT INTERFACE TO UPLOAD COLUMN FORMATTING RULES AND LOV

  • A new input interface “Column Formatting rule” is introduced to create/update Column Formatting Rules and upload LOV values for column formatting rules.

  • The system supports only “xls” format for Column Formatting Rule interface file (sample file name: CFR_Columnformattingrule_21C.xls).

  • A combination of the rule name, company, and facility is used to create/update Column Formatting Rules.

  • You can create Column Formatting Rules with or without LOV values through the new input interface.

NOTE: You can create/update column formatting rules and LOV values only for the user logged in company and facility and for “*” facility (applies to all associated facilities.)

For more information on the new input interface see the Interface Specifications document. 

Steps to Enable

To create LOV values for formatting rule from UI:

  1. From the Column Formatting Rule UI, click Create.
  2. Select the Facility or * to apply the rule to all Facilities.
  3. Provide a rule name value (ensure that for that company-facility combination, rule name value is unique)
  4. Set the data type as “NUMERIC” or “ALPHANUMERIC”
  5. Set the min/max value and precision, if data type is numeric
  6. Select “*” as value for entity
  7. Select the Active Flag to enable the rule and click Save.
  8. From the Column Formatting Rule Detail UI, click Create.
  9. If you want to configure different LOV values for different items, in matching scope select “ITEM_CODE” and in matching value provide the item code for which LOV value is defined and configure LOV value
  10. If you do not have an item specific LOV configuration, in matching scope select “*” and in matching value provide “*” and configure LOV value
  11. Repeat for all other valid LOV values

To create LOV values for formatting rule from new input interface (Column Formatting Rule):

  1. Define values for rule_name, company_code, facility_code, column_name_code, entity, action_code, data_type, active_flg for header information in interface file
  2. Define values for action_code, seq_nbr, matching_scope, matching_value, lov for detail information in interface file
  3. Name the file according to the template (sample file name: CFR_Columnformattingrule_21C.xls)
  4. Process the file through input interface UI for Column Formatting Rule

Key Resources

Restrict Number of Orders in an LPN During Pack NC Active

This change optimizes the overall picking process, as it reduces the number of LPNs to pick the inventory, and if you use a conveyor system, your throughput could increase. In 21C, you can pack more than one order in an OBLPN using the RF Pack NC active transaction (rf.outbound.cwrfpackncactiveorder). This is available for non-cubed picking. You will be able to set a limit of orders that can be added to an OBLPN.

A new screen parameter is added, break-picks-by-order-count that accepts integer values.

  • This parameter works only if the screen parameter:
    • “break-picks-by” is set to Order.
    • "nc-or-cubed-mode" is set to Non-Cubed Picking.
  • For Non-Tasking Mode, on scanning an OBLPN which is already having inventory associated with the orders, where a number of orders associated with the OBLPN are greater than the value configured value in the parameter, then the user will see an error message "Cannot pick more than%Value configured in parameter% Orders in an OBLPN".
  • For Tasking Mode, when multiple orders are allocated, once the number of orders in an OBLPN reaches the value configured in the new screen parameter, for the next pick if it belongs to a different order, the system prompts the user to scan a different OBLPN.
Parameter Value Type Description

break-picks-by-order-count

Numeric: Integer Value

Default value (Blank): You are allowed to pick only one order in an OBLPN when the parameter "break-picks-by" is set to Order.


Set to Zero: When the parameter value is set to zero, you are allowed to pick any number of orders in the OBLPN during picking. You will not be limited with respect to combining the number of orders in an OBLPN.


Greater than Zero:  When the parameter value is set to greater than zero, then during picking, you can pick less than or equal to a number of orders value configured in the screen parameter.

NOTE: If the value in the parameter is set to 1, you will not see any difference, as the existing parameter "break-picks-by" set to Order will allow only one order per OBLPN. The ‘break-picks-by-order-count” parameter is not significant if the existing parameter "split-allocs-on-close-by" is set to "Split Allocs by Order". A new parameter is not significant if the existing parameter "auto-pack-one-uom" is set to  "Auto pack one UOM".

When the value in the parameter is not an integer value then the system will fall back to existing behavior, limiting one order per OBLPN.

During tasking mode, the system prompts to open an OBLPN even though the number of orders in the OBLPN is less than the configured value in the parameter “break-picks-by-order-count”, this case occurs when there is an already open OBLPN for the next pick, the system prompts with open OBLPN.

Steps to Enable

The RF parameter ‘break-picks-by-order-count’ should be set with an integer value in the RF Pack NC Active {order} (rf.outbound.cwrfpackncactiveorder) module.

Key Resources

Wave Pick Info Interface Enhancements

Oracle WMS Cloud has a facility to generate Wave Pick Info messages which are used by host systems for integration purposes along with MHE systems to perform picking and/or print software to generate and print labels/packing slips/dispatch documents. In 21C, additional fields (inventory attributes A-O and expiry date) are added in the Output Interface-Wave Pick Info for better integration with other software systems, so that external system can pick the respective inventory.

The following fields added in the Wave Pick Info file are available only from the 21C version:

  • Inventory Attribute A
  • Inventory Attribute B
  • Inventory Attribute C
  • Inventory Attribute D
  • Inventory Attribute E
  • Inventory Attribute F
  • Inventory Attribute G
  • Inventory Attribute H
  • Inventory Attribute I
  • Inventory Attribute J
  • Inventory Attribute K
  • Inventory Attribute L
  • Inventory Attribute M
  • Inventory Attribute N
  • Inventory Attribute O
  • Expiry Date

Steps to Enable

You don't need to do anything to enable this feature.

Key Resources

Introduce New Fields to Required Item Fields UI

The following fields are now available in the Required Item Fields drop-down UI.

Source

Column Name

Item Detail

Hazard Statement

Item Detail

Hazmat Packaging Description

Item Detail

Shipping Temperature Instruction

Item Detail

retail price

Item Detail

unit net cost

Item Detail

UN Nbr

Item Detail

UN Class

Item Detail

UN description

Item Detail

expected qty instruction

Item Detail

special code 1

Item Detail

special code 2

Item Detail

LPNs per tier

Item Detail

tiers per pallet

Item Detail

full OBLPN type

Item Detail

case OBLPN type

Item Detail

pack OBLPN type

Item Detail

carrier commodity description

Item Detail

shipping uom

You now have more flexibility in selecting the required item fields that need to be populated for items before you can receive them to your facility.

Steps to Enable

You don't need to do anything to enable this feature.

Key Resources

Remove Personal Information on Processed Orders

The system now gives you the option to hide customer information.  The button “Remove Personal Info” on the "Order Headers" UI was added so the you can remove personal information on selected customer orders.

This button will be enabled if you have the following permission: order hdr / Can Remove Order Personal Info:

Permission Action button UI

order hdr / Can Remove Order Personal Info

Remove Personal Info Order Header
  • The Remove Personal Info button requires the permission "remove_pi" on order_hdr entity.
  • Activates only for statuses Shipped/Cancelled/Delivered.
  • The button asks for your confirmation to make sure that you want to hide customer data.
  • This action is not meant for facility orders (where dest-facility/shipto-facility are populated).
  • You have to commit each order separately, report on how many succeeded, and out of how many example: "9 orders selected; PI Removed: 6; Facility orders skipped: 2; Error encountered: 1".
  • Entry into keyed log will be added with one record per order.

  • The list of specified fields will be updated only if they are already populated. They will be ignored if they are blank:
    • order_hdr.cust_nbr
    • order_hdr.cust_name
    • order_hdr.cust_addr
    • order_hdr.cust_addr2
    • order_hdr.cust_addr3
    • order_hdr.cust_phone_nbr
    • order_hdr.cust_email
    • order_hdr.cust_city
    • order_hdr.cust_state
    • order_hdr.cust_ziporder_hdr.cust_country
    • order_hdr.cust_contact
    • order_hdr.shipto_name
    • order_hdr.shipto_addr
    • order_hdr.shipto_addr2
    • order_hdr.shipto_addr3
    • order_hdr.shipto_city
    • order_hdr.shipto_state
    • order_hdr.shipto_zip
    • order_hdr.shipto_country
    • order_hdr.shipto_phone_nbr
    • order_hdr.shipto_email
    • order_hdr.shipto_contact
    • order_hdr.spl_instr

Steps to Enable

If there are steps to enable, define them here for each feature:

Key Resources

Support Explicit Substitution Using Pick Confirmation REST API

The Pick Confirmation API helps an external system to understand which inventory is picked, so that respective updates can be done accordingly. If you track inventory attributes and you specify this information in the Pick Confirm API, external systems will be able to pick the inventory that matches the inventory attributes values, so that Oracle WMS Cloud will perform the correct updates.

In 21C, the Pick Confirm API is extended to support Inventory Attributes and Expiry Dates, which helps you to pick inventory with specific attribute values and expiry dates when multiple allocations are present for a given order detail.

The Pick Confirm API can be called using the following POST request:

POST ..lgfapi/v10/pick_pack/pick_confirm/

  • New fields are available in the Pick Confirm API  that allows you to send inventory attribute values and expiry dates in the pick request.
  • When allocated inventory is attribute tracked and if inventory attribute values are not passed during the picking request then the system will pick the respective allocation based on the details passed in the API.
  • During a pick request, if the attribute value sent does not match with the attribute value allocated for an order detail, then an error is displayed as a response.
  • For expiry tracked items, if the expiry date does not match with the allocated inventory, then an error is displayed as a response. If  you are not passing the expiry date in the pick.
  • request, the system will pick the allocated inventory based on the other values (like, Batch, Pick location, etc...) passed in the API.

    "invn_attr_a"

    "invn_attr_f"

    "invn_attr_k"

    "invn_attr_b"

    "invn_attr_g"

    "invn_attr_l"

    "invn_attr_c"

    "invn_attr_h"

    "invn_attr_m"

    "invn_attr_d"

    "invn_attr_i"

    "invn_attr_n"

    "invn_attr_e"

    "invn_attr_j"

    "invn_attr_o"

  • In the Pick Confirm API,  you can send the expiry date in the following field in the pick request.
    • "expiry_date": Expiry date of the inventory which needs to be picked, "2022-11-01".
  • Sample pick confirm API request with inventory attributes and expiry date defined:

{   

 "mhe_mode_flg": false,

 "async_flg": false,

 "pick_list":

 {

  "facility_id__code": "QATST01",  

  "company_id__code": "QATSTPC",

  "wave_nbr": "WVQATSTPC074939",

  "order_nbr": "CPORD052720C12",

  "item_barcode": "RUG90",

  "qty": 5,

"invn_attr_a": "IND",

"invn_attr_b": "PAPER",

"invn_attr_f": "A4",

"expiry_date" : "2022-11-01",

"batch_nbr":"CPBAT0708C12",

"pick_location":"ACTLOC1",

"to_container_nbr":"CPOBLPN052721C11",

     }

]

}

From MHE Pick Confirmation UI:

Inventory Attribute values and expiry date values sent in the MHE Pick Confirmation API request can be viewed from the ”From MHE Pick Confirmation UI” in the newly introduced columns (Attribute A to Attribute O and Expiry Date). These new columns will be hidden, by default.

NOTE: There is no change in the API URL for the Pick Confirmation API with respect to inventory attribute, and expiry date support in the API. Refer to REST API Guide for detailed information on the API.

Steps to Enable

Review the REST service definition in the REST API guides, available from the Oracle Help Center > your apps service area of interest > REST API. If you're new to Oracle's REST services you may want to begin with the Quick Start section.

Support LPN and Inventory Attribute Substitution Using Pick Confirmation REST API

In 21C, the Pick Confirm API is enhanced to support substitutions where you can substitute or replace an inventory with another available inventory via Pick Confirm API. The Pick Confirm API can be called using the following POST request:

POST ..lgfapi/v10/pick_pack/pick_confirm/

  • New fields are added in the Pick Confirm API to send the original allocation information so that inventory can be substituted.

The following new fields are introduced in the Pick Confirm API to support substitution:

  • orig_iblpn_nbr : If you want to substitute the initially allocated IBLPN with a different IBLPN, then the initially allocated LPN number should be sent in the orig_iblpn_nbr field, and the LPN which you want to pick against the original allocation should be sent in the existing from_container_nbr field of picking API.
  • orig_batch_nbr : If you want to substitute the initially allocated batch number with the different batch number, then the initially allocated batch number should be sent in the orig_batch_nbr field, and the batch number which you want to pick against the original allocation should be sent in the batch_nbr field of picking API.
  • orig_expiry_date : If you want to substitute the initially allocated expiry date with the different expiry date, then the initially allocated expiry date should be sent in the orig_expiry_date field, and the expiry date which you want to pick against the original allocation should be sent in the expiry_date  field of picking API.
  • orig_inventory_Attribute_A to Orig_Inventory_Attribute_O : If you want to substitute the initially allocated inventory attribute with the different inventory attribute value, then the initially allocated inventory attribute value date should be sent in the orig inventory attribute field, and the inventory attribute value which you want to pick against the original allocation should be sent in the inventory attribute field of picking API.

During substitution, if the inventory which is getting substituted is not matching with the inventory (Batch Number/ PO Number/ Shipment Number/ Inventory Attribute values) information specified on the respective order detail, then the substitution will not happen.

The following is the sample pick request for substitution:

{    

 "mhe_mode_flg": false,

"async_flg": false,

"pick_list":

[

    {        

 "facility_id__code": "QATST01",

"company_id__code": "QATSTPC",

"wave_nbr": "WVQATSTPC074939",

"order_nbr": "CPORD052720C15",

"item_barcode": "RUG90",

         "qty": 5,

" orig_iblpn_nbr ": " IBLPN04"

" orig_batch_nbr ": " CPBAT0708C18 "

" orig_expiry_date ": "2023-11-01 "

" orig_inventory_attribute_a ": "US"  

"invn_attr_a": "IND",

"invn_attr_b": "PAPER",

"invn_attr_f": "A4",

"expiry_date" : "2022-11-01",

"batch_nbr":"CPBAT0708C12",

        "from_container_nbr":"IBLPN05",

        "to_container_nbr":"CPOBLPN052721C11",

      }

]

}

NOTE: Prior to 21C, the Pick Confirm API supported implicit substitution of the batch numbers. As we have enhanced the Pick Confirm API to support substitution, it’s recommended to use explicit substitution for the batch number (sending the original batch number which is allocated for the respective order detail).

  • When you send information in the original fields of pick confirm API to perform substitution, then implicit substitution for batch number is not supported.

  • Please refer to the REST API Guide document for detailed information on the API.

  • There is no change in the API URL for the Pick Confirmation API with respect to substitution support in the API. Substitution across different active locations is not allowed through the pick confirm API.

  • Substitution across different active locations is not allowed through the pick confirm API.

Steps to Enable

Review the REST service definition in the REST API guides, available from the Oracle Help Center > your apps service area of interest > REST API. If you're new to Oracle's REST services you may want to begin with the Quick Start section.

Cancel a Task Using a REST API

The Cancel Task API allows you to cancel a task which is in ready/held status through an API so that the tasks not yet picked up can be cancelled. Also, a supervisor might want to cancel a task part of the wave.

API URL:  LOOKUP BY ID

POST.../entity/task/{id}/cancel/

  • No additional `parameters` data in the request body is required.

API URL: LOOKUP BY FILTERS 

POST.../entity/task/cancel/

Category Name Required Type Description
parameters

facility_id_code

  Integer

Facility context by id

parameters

facility_id__code

  string

Facility context by code

parameters

company_id_code  

Integer

Company context by id

parameters

company_id__code  

string

Company context by code

parameters

task_nbr X

string

Task which needs to be on hold

  • If facility and/or company are provided, set login context accordingly.
  • Only one of `facility_id` or `facility_id__code` may be provided.
  • Only one of `company_id` or `company_id__code` may be provided.

BULK_CANCEL URL

POST.../entity/task/bulk_cancel/

Request Body:

  • The transaction is meant for the task entity. Hence, the users are required to send the following parameters in the body. 

POST.../entity/task/bulk_hold/

{

"parameters": {

"id__in": [01, 02, 03]

},

"options": {

"commit_frequency": "0",

}

}

The commit frequency is by default set to 0. If it is set to 0, the system should roll back on first error/ If the commit frequency is set to 1, the system should  commit per object.

Steps to Enable

Review the REST service definition in the REST API guides, available from the Oracle Help Center > your apps service area of interest > REST API. If you're new to Oracle's REST services you may want to begin with the Quick Start section.

Break Task by Units/Packs/Cases Using a REST API

The new split LPN for Replenishment API allows third party integration systems or Product as a service (PaaS) to split and existing replenishment  allocation of type "REPLEN_CS_PK_UNITS". This  would be most conducive if you have an LPN  that contains more than one unit of a UOM, and it does not fit in a conveyor belt.

You can split the LPN by its UOM, and it can fit on the conveyor and be used for allocations created during Mode 2 Replenishment. You can pass a fully or partly allocated container number in the API call.

This container number is considered your source LPN. In the request parameter, you can pass inventory information (such as item, batch, expiry date, or inventory attributes a-o), quantities for the source LPN UOM that is being tracked, and more. This information will be used to track the new LPN along the conveyor, and it will create a new task with task type "REPLEN_LPN."

NOTE: The Split LPN for Replenishment API does not support item’s tracking serial numbers, and it will be added in a future release.

URLS:

POST .../wms/lgfapi/v10/entity/iblpn/<id>/split_lpn_for_replen

POST .../wms/lgfapi/v10/entity/iblpn/split_lpn_for_replen

REQUEST PARAMETERS

Parameters (Filters)

  • Only applicable when `id` is not present in the URL.
Name Required Type Default Description
facility_id C Integer   Facility context by id.
facility_id__code C String   Facility context by code.
company_id C Integer   Company context by id.
company_id__code C String   Company context by code.
container_nbr X String   Container/Source LPN pulled for split.
  • If facility and/or company are provided, set login context accordingly.
  • Only one of `facility_id` or `facility_id__code` may be provided.
  • Only one of `company_id` or `company_id__code` may be provided.

Example:

{

"parameters": {

"facility_id__code": "FAC",

"company_id": 1,

"container_nbr": "LPN123"

}

}

REQUEST PARAMETERS - OPTIONS

Name Required Type Default Description
item_barcode C String   one of item_barcode
item_alternate_code C

String

  one of item_barcode
batch_nbr  

String

  batch specified on the inventory in the source LPN.
expiry_date  

String

  expiry of inventory in the source LPN.
invn_attr_a to  

String

  inventory attributes A to O specified on the inventory.
qty_in_uom X     new parameter. Total Qty in UOM.(2 units/2 cs/2 pks)
new_container_nbr_list X list of Strings   new parameter. List of new LPN numbers
perform_lpn_barcode_checks Optional Boolean true

Validations against Barcode Type configured and BARCODE_VALID_CHARS allowed.

location_barcode Optional

String

  must be of location type DROP
task_type_description X

String

  Description of REPLEN_LPN task type

Example:

{

"options": {

"item_barcode": "ITEM123"

"batch_nbr": "BTCH123"

"invn_attr_a": "AA123"

"qty_in_uom": 2

"new_container_nbr_list": ["lpn1","lpn2"],

"location_barcode": "LOC1",

"task_type_description": "Full LPN Replenishment - PM"

}

}

Full Request Body Examples

Request with `id` in URL:

POST .../wms/lgfapi/v10/entity/iblpn/<id>/split_lpn_for_replen

{

"options": {

"item_barcode": "LOAD123",

"batch_nbr": "BTCH123",

"invn_attr_a": "AA123",

"qty_in_uom": 4,

"new_container_nbr_list": ["lpn1","lpn2","lpn3","lpn4"],

"location_barcode": "LOC1",

"task_type_description": "Full LPN Replenishment - PM"

}

}

Request without `id` in URL:

POST .../wms/lgfapi/v10/entity/iblpn/split_lpn_for_replen

{

"parameters": {

"facility_id__code": "FAC",

"company_id": 1,

"container_nbr": "LPN123"

},

"options": {

"item_alternate_code": "ITEM123"

"qty_in_uom": 4,

"new_container_nbr_list": ["lpn1","lpn2","lpn3","lpn4"],

"location_barcode": "LOC1",

"task_type_description": "Full LPN Replenishment - PM"

}

}

Steps to Enable

Review the REST service definition in the REST API guides, available from the Oracle Help Center > your apps service area of interest > REST API. If you're new to Oracle's REST services you may want to begin with the Quick Start section.

WMS Mobile App

New Receiving Transaction in WMS Mobile App

A new receiving transaction is now available in the Oracle WMS Mobile App. The new module “Receiving” allows you to receive LPNs associated to a Shipment or Purchase Order. This transaction uses the Receiving Rest API added in update 21B.

Receiving Transaction

In this transaction, you are prompted to scan a Trailer Number, Dock Door, and Purchase Order or Shipment Number. Purchase Order/Shipment Number is a required field. If you scan a Dock Door, and the dock door has been associated with an appointment, then the system will populate the information based on the appointment. If you have the Palletize LPN toggle enabled, you will be prompted to provide a pallet number.  In this transaction we introduced a new concept: LPN mode and SKU mode.

If the LPN mode toggle is enabled, you will be prompted to scan a LPN and then the SKUs or inventory that belong to the LPN. If this toggle is disabled, you will be receiving using SKU mode. This mode is great if you receive LPNs that contain the same inventory multiple times since you are first asked to scan the SKU and quantity, and then the LPN information.  You can keep scanning the LPNs  until you need to change another set of inventory or LPNs that contain a different SKU.

ITEMS NOT CURRENTLY SUPPORTED IN THE RECEIVING API

The following is a summary of items that are not currently supported:

  • WMS currently supports only receiving of normal items. Support for attribute, batch , expiry and serial tracking items will be added in a later release.

NOTE: When you pass batch number / expiry date for a batch / expiry tracking item in cartonized receiving, you are allowed to successfully receive the LPN via API. Even if you do not pass batch number / expiry date for a batch / expiry tracking item in cartonized receiving, you can successfully receive the LPN via API.

  • LPN as a Physical Pallet
  • Detailed receiving for cartonized LPNs
  • Handling over-receipt warning message
  • QC flow
  • Xdock flow

Steps to Enable

You don't need to do anything to enable this feature.

Key Resources

Web Reports and Dashboards

Additional Improvements to Web Reports Gen 2

COMPANY PARAMETER CHANGES

The company parameter "WR2_FILTER_DATETIME_IN_FACILITY_TZ" allows the DateTime clauses in the web report gen2 to be interpreted based on the your current facility timezone instead of interpreting the DateTime based on the server time. However, the data returned by the report will still display the output based on the server time, by default. As before that can be converted to facility time using the available conversion function.

Another company parameter WR2_EVAL_FORMULAS_IN_DB provides better performance for some functions. When the company parameter "WR2_EVAL_FORMULAS_IN_DB" default value is set to Yes:

  • If the Company ID is set to 0, then the value is updated to Yes. 
  • If no value is set, the default value for the parameter is updated to Yes.

NOTE: Some functions used in reports can be evaluated either at the database level or at the Web Reports application level. In all cases, it is faster to evaluate it in the database. The default behavior has been changed to perform this for all customers except for those that have explicitly updated the WR2_EVAL_FORMULAS_IN_DB to no. Note there are some innate differences between how Web Reports and databases evaluate formulas. Equivalent formulas may return inconsistent data in some situations. Mathematical equations may have differing levels of precision, which can alter the result. Date functions are known to have some divergent behavior as well.

IMPROVEMENTS FOR JOINS IN REPORTS

The default joins in Gen2 have been improved so that in most common reports, you will not need to edit the joins. New categories have also been added to Web Reports Gen 2 to improve the user experience and eliminate the use of aliases for most common reports. With these new categories, you no longer need to create aliases and complex joins for the most common reports:

  • ib_container as clone of container with filter type = 'I'
    • from_inventory.container_id to be joinable to ib_container
  • iblpn_location as clone of location
    • iblpn_container.location_id to be joinable to ib_location.id
  • pallet_location as clone of location
    • pallet.location_id to be joinable to pallet_location
  • ob_container as clone of container with filter type = 'O'
    • to_inventory.container_id to be joinable to ob_container
  • ob_location as clone of location
    • ob_container.location_id to be joinable to ib_location.id
  • destination_company as clone of company
    • order_hdr.destination_company_id to be joinable to destination_company
  • dest_facility as a clone of facility
    • order_hdr.dest_facility_id to be joinable to dest_facility
  • shipto_facility as a clone of facility
    • order_hdr.shipto_facility_id to be joinable to shipto_facility

FLATTENED VIEW FOR ITEM HIERARCHY DEFINITION

To allow easier report creation, Web Reports Gen2 has been updated to include a flattened view for item hierarchy definition, so item hierarchy codes 1 through 5 and group code can be more easily included in reports without the need for aliases and complex joins.

NEW CATEGORIES

  • cc_summary_adjustment_dtl
  • cc_summary_adjustment_hdr
  • storage_priority
  • putaway_priority renamed to storage_priority_id

ib_inventory_alloc_view

This category allows you to determine the allocated quantity for an inventory record. It is the same as the Inventory Gen2 category, but it has an outer joined with allocation.from_inventory_id and alloc_qty. This category doesnt show allocations in status greater than 90.

Steps to Enable

You don't need to do anything to enable this feature.

Key Resources

Warehouse Automation

View MHE System for Allocated Inventory

ALLOCATION UI - VIEW MHE SYSTEM CODE COLUMN

You can now see your MHE system code in the Allocation UI. This will help you know the allocations associated with your respective MHE system.

DETAILS OF THE FEATURE

A new column “MHE System” is now in visible in the Allocation Inquiry UI (Module: AllocationView). This column displays the MHE System associated with the respective allocation. “MHE System” has also been added to the filter criteria for the Allocation UI. This allows users to search the allocations based on MHE system code in the Allocation UI.

Steps to Enable

You don't need to do anything to enable this feature.

Key Resources