- Revision History
- Overview
- Feature Summary
-
- WMS Common
- Inventory Operations
- Inbound Logistics
- 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
- Web Reports and Dashboards
- Warehouse Automation
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. |
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.
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 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 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 |
UI or |
|
||
To Be Counted Flag and To Be Counted Timestamp Fields Added to Location Interface |
||||||
Inventory Attributes Now Supported Using IB Shipment Detail PATCH API |
||||||
Support Explicit Substitution Using Pick Confirmation REST API |
||||||
Support LPN and Inventory Attribute Substitution Using Pick Confirmation REST API |
||||||
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
- Navigate to the Output Interface configuration screen.
- Click on the edit pane and select the interface format “XML” and select the field Remove empty elements flag.
Key Resources
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
- 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
- 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.
-
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.
- Pack UOM
- Case UOM
- 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.
- 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
- 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
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.
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:
- Go to the Wave Template screen.
- Navigate to the Wave Template Search sub-UI.
- Click on the Order Sequence Rule Button in the wave template search sub-UI.
- Create the Order Sequence Header, by defining rule name, description and template type as Wave template.
- Create the Order Sequence Detail, by populating columns which needs to considered for sequencing the orders.
- 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
- In the RF Inbound Modify Case (inbound.cwrfmodcase) module, set the screen parameter “reason-code” with a valid reason code.
- 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
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.).
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.
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:
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
- Go to the Task creation screen (Module:TaskCreationView).
- Go to the Task creation >> details screen.
- Select a task creation sequence and click the Ordering Criteria Button in the Task creation >> details screen.
- 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:
- From the Column Formatting Rule UI, click Create.
- Select the Facility or * to apply the rule to all Facilities.
- Provide a rule name value (ensure that for that company-facility combination, rule name value is unique)
- Set the data type as “NUMERIC” or “ALPHANUMERIC”
- Set the min/max value and precision, if data type is numeric
- Select “*” as value for entity
- Select the Active Flag to enable the rule and click Save.
- From the Column Formatting Rule Detail UI, click Create.
- 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
- If you do not have an item specific LOV configuration, in matching scope select “*” and in matching value provide “*” and configure LOV value
- Repeat for all other valid LOV values
To create LOV values for formatting rule from new input interface (Column Formatting Rule):
- 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
- Define values for action_code, seq_nbr, matching_scope, matching_value, lov for detail information in interface file
- Name the file according to the template (sample file name: CFR_Columnformattingrule_21C.xls)
- 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.
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
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
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