4Supported Entity Operations

Describe Entity

GET …/wms/lgfapi/v10/entity/{entity_name}/describe/

The describe operation is unique in that it is common and can be used on any entity. It returns a formatted representation of the entity’s metadata including any filterable “parameters” and all field definitions. This is the primary tool for obtaining details about a specific entity.

Response components:

• parameters – A list of fields that can be used for filtering of the entity.
• fields – Field definitions and metadata for the entity.
  • type – The field data type
  • allow_blank – String fields only. Is an empty string value permitted?
  • max_length – String fields only. Max string length permitted.
  • required – Does the field require data.
  • default – If the fields is not required, the default value when no value is provided.

Location

These topics give descriptions for APIs that complete actions related to location in the Warehouse.

Update Active Inventory

The update_active_inventory API allows you to adjust the inventory quantity in an active location for a specific item. Only a single location and item may be updated per request.

Note: This is a new API meant to replace the existing legacy `update_active_inventory` API. The legacy API will eventually be retired so no further enhancements will be made to it. New functionality will instead be added to this API as part of the lgfapi suite.

Regardless of the method used to identify the location, the following input is valid:

Category	Name	Type	Required	Description
options	item_barcode	String	C	Item identifier.
options	item_code	String	C	Item identifier.
options	item_alternate_code	String	C	Item identifier.
options	adjustment_qty	Numeric	C	Non-zero adjustment quantity.
options	actual_qty	Numeric	C	Non-negative final quantity.
options	batch_nbr	String	N	Batch tied to target inventory.
options	expiry_date	Date	N	Expiration date tied to target inventory.
options	invn_attr_X	String	N	Attributes A-O tied to the inventory.
options	reason_code	String	Y	Recorded on inventory history.
options	transaction_ref_nbr	String	N	Recorded on inventory history.
options	locn_capacity_check_flg	Boolean	N	Validate locations max units and volume?
options	company_id	Integer	N	Item’s company.
options	company_code	String	N	Item’s company’s code.

• Only one of `item_barcode`, `item_code`, or `item_alternate_code` is allowed.
• Only one of `actual_qty` or `adjustment_qty` is allowed.
• If positive change in quantity:
  • The provided `batch_nbr` will be created if it does not exist.
• Only one of `company_id` or `company_code` is allowed.
  • Although not required by the API, the company context may be necessary if there is ambiguity when identifying the item to adjust. This is common in 3PL scenarios where the same identifying information may be present for different items across companies for which the user is eligible.

Location Lookup by ID

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

The caller knows the unique `id` value of the active location, which is added to the request URL. No additional `parameters` data is required from the request body.

Location Lookup by Filters

POST .../entity/location/update_active_inventory/

Category	Name	Type	Required	Description
parameters	barcode	String	Y	Location’s barcode.
parameters	facility_id	Integer	N	Location’s facility.

• Only a single location may be updated per request.
  • The `__in` lookup is not supported for `barcode`.
• `facility_id` supports string lookup by `code` using the double-underscore notation:
  • facility_id__code

Example Request Body:

{
"parameters": {
"facility_id__code": "FAC-1",
"barcode": "LOCN1"
},
"options": {
"item_barcode": "ITEM1234",
"adjustment_qty": -10,
"batch_nbr": "BATCH1234",
"expiry_date": "2020-01-02",
"invn_attr_a": "A",
"invn_attr_b": "B",
"reason_code": "RC",
"transaction_ref_nbr": "TX123457890",
"company_code": "COM-1"
}
}

Serial Number Tracked Items

This API also accepts serial numbers to cater to serial number tracked items or SKUs.

For positive adjustments, the serial numbers sent can be:

• New serial numbers (or)
• Serial numbers existing in the warehouse that are delinked and not associated with any other inventory

For negative adjustments, the serial numbers sent should be the ones that are already present in the location where inventory is being updated.

The following is an example request for serial number adjustments:

{

"parameters": {

"facility_id code": "FAC-1", "barcode": "LOCN1"

},

"options": {

"item_barcode": "ITEM1234", "adjustment_qty": -3, "batch_nbr": "BATCH1234",
        "invn_attr_a": "A",

"invn_attr_b": "B",

"reason_code": "RC", "transaction_ref_nbr": "TX123457890", "serial_nbr_list":
        [

"SrlNbr1", "SrlNbr2", "SrlNbr3"

]

}

}

Locate LPN or Pallet

The Locate LPN/Pallet API allows you to locate an LPN/ Pallet to its respective destination location.

You can locate an Inbound or Outbound LPN to its respective destination using the following POST requests:

Inbound LPN

POST .../entity/iblpn/{id}/locate/

POST .../entity/iblpn/bulk_locate/

Outbound LPN

POST .../entity/oblpn/{id}/locate/

POST .../entity/oblpn/bulk_locate/ 

Example requests for Locate IBLPN and OBLPN:

POST .../entity/iblpn/bulk_locate/
{
"parameters": {
"id__in": [1, 2, 3]
},
"options": {
"location_barcode": "R1-R2-RB1-Rl1",
"depalletize_on_putaway": false
}
}

POST .../entity/oblpn/bulk_locate/
{
"parameters": {
"container_nbr__in": ["LPNPTW0102"]
},
"options": {
"location_barcode": "R1-R2-RB1-Rl1",
"depalletize_on_putaway": false
}
}

You can locate a Pallet to its respective destination using the following POST requests:

Pallet

POST .../entity/pallet/{id}/locate/

POST .../entity/pallet/bulk_locate/

Example Request for Locate Pallet:

POST .../entity/pallet/bulk_locate/
{
"parameters": {
"id__in": [1, 2, 3]
},
"options": {
"location_barcode": "R1-R2-RB1-Rl1",
"depalletize_on_putaway": false
}
}

The following validations should be performed while locating the LPN/ Pallet and the system should return an error message.

Validations	For LPN	For Pallet	Error Response
Inbound LPN is not present in the System	Yes		"LPN not found" .
IBLPN in "In Receiving", "Consumed" & "Cancelled" Status	Yes		"LPN is not in valid status"
IBLPN in Allocated Status & Company Parameter "ALLOW_MOVING_OF_ALLOCATED_LPNS" is set to No	Yes		"Locating Allocated LPN is restricted"
Inbound Pallet or Outbound Pallet is not present in the System		Yes	"Pallet not found".
Inbound/ Outbound Pallet with status other than In facility		Yes	"Pallet is not in valid status"
OBLPN in Status Other than In Packing/ In Picking/ Packed/ Picked	Yes		"OBLPN is not in valid status"
On Locating IBLPN/OBLPN which is having lock code with "Prevent Putaway " flag enabled.	Yes		"Cannot locate LPN, having lock code %Lock Code% which prevents putaway"

Location Validation	Error Response
Location passed in the API if location is not present in the facility	"Location not in current facility"
When location doesn't have enough capacity based on (Units/weight/Volume)	"Location doesn't have enough capacity for %Parameter due to which capacity check failed%"
When location is permanent not matching with the SKU present in the LPN	"Cannot locate, Location is dedicated for SKU %SKU dedicated for location%"
When location with Multi SKU flag disabled & Incoming LPN is Multi SKU LPN	"Cannot locate, Location is not allowed for multi SKU"
When location is marked with Restrict Batch, If the incoming SKU with Batch Number is not matching with the SKU +Batch number combination present in the location.	"Cannot locate, Location prevents different inventory Batch combination for a SKU. "
When location is marked with Restrict Inventory Attribute, If the incoming SKU with Inventory Attribute value is not matching with the SKU +Inventory Attribute value combination present in the location.	"Cannot locate, Location prevents different inventory attribute combination for a SKU. "
When location is marked with "Prevent Putaway Flag"	"Cannot locate, Location is Locked"
When location passed is other than QC location for IBLPN with "Quality Check" Status	"Cannot locate to other than QC location"
When location passed is other than Drop or staging location for an OBLPN or Outbound pallet	"Cannot locate to %location type of given location%"
When drop location passed is configured for IB sorting with criteria value defined, if the Incoming LPN/Pallet breaks the criteria value	"Cannot locate, Drop location criteria value is not matching"
When drop location passed is configured for OB sorting with criteria value defined, if the Incoming LPN/Pallet breaks the criteria value	"Cannot locate, Drop location criteria value is not matching"

Parameters

Name	Required	Type	Default	Description
facility_id		Integer		Facility context by id.
facility_id__code		String		Facility context by code.
company_id		Integer		Company context by id.
company_id_code		String		Company context by code.
container_nbr		String		The allowed parameter filter conditions are "container_nbr" and "container_nbr__in"
id		Integer		The allowed parameter filter conditions are "id" and "id__in":

Request Options Parameters

Name	Required	Type	Default	Description
location_barcode	X	String
depalletize_on_putaway		Boolean	False

Location Size Type

POST .../entity/location_size_type

This operation is used to add single or multiple location size types.

If you have a new facility and you want to copy the same location size type from your current facility, you can first GET the list by querying the location_size_type entity, then POST the applicable data to this operation for the target facility.

Example body request

{

"fields": {

"company_id": 1,

"size_type": "TEST_SIZE_001",

"description": "Test Size 001"

}

}

Inventory

Link Serial Numbers

POST …/wms/lgfapi/v10/entity/inventory/{id}/link_serial_nbrs/

This operation is used to link one or more serial numbers to a single inventory record. The “id” value of the target inventory record is required in the URI.

Category	Parameter	Type	Required	Default	Description
options	serial_nbr_list	Array of Strings	X		A list of serial number strings to be linked to the target inventory record.

Bulk Update Inventory Attributes

POST …/wms/lgfapi/v10/entity/inventory/bulk_update_inventory_attributes/

This operation is used to update the inventory attributes of one or more inventory objects. Inventory in a Received or Located IBLPN and inventory in an active location may be modified. Inventory history adjustment records will be written for each inventory record successfully modified.

The attributes individually are not necessarily required, but in total at least one attribute must be provided to indicate a change. Additionally, an attribute value may or may not be required as dictated by other configuration such as the corresponding item’s attribute requirements or the location allowing mixing of attributes. Furthermore, the inventory cannot be or have been allocated.

An empty string is a valid value to indicate removing the value from the corresponding attribute. Any attribute that is omitted from the request data will retain its current value.

The “parameters” section of the request body is required in addition to the “options” section outlined below. Only the “id” parameter filter is valid. It may be used as “id__in” with an array of values.

Category	Parameter	Type	Required	Default	Description
options	invn_attr_a	String	C		Target attribute value.
options	invn_attr_b	String	C		Target attribute value.
options	invn_attr_c	String	C		Target attribute value.
options	invn_attr_d	String	C		Target attribute value.
options	invn_attr_e	String	C		Target attribute value.
options	invn_attr_f	String	C		Target attribute value.
options	invn_attr_g	String	C		Target attribute value.
options	invn_attr_h	String	C		Target attribute value.
options	invn_attr_i	String	C		Target attribute value.
options	invn_attr_j	String	C		Target attribute value.
options	invn_attr_k	String	C		Target attribute value.
options	invn_attr_l	String	C		Target attribute value.
options	invn_attr_m	String	C		Target attribute value.
options	invn_attr_n	String	C		Target attribute value.
options	invn_attr_o	String	C		Target attribute value.
options	commit_frequency	Integer		1	0 = Roll back on first error. 1 = Commit per object.

Delink Serial Numbers

The Delink Serial Numbers API allows users to delink a list of serial numbers from an existing inventory in order for the system to write appropriate serial number records.

Note: Every serial number that is delinked from the targeted inventory should have corresponding serial Number History records. The Serial Number History UI should display the serial number with delinked action codes for IBLPN, OBLPN, and Active inventories.

You can delink a serial number using the following POST request:

POST .../{version}/entity/inventory/{id}/delink_serial_nbrs/

Additional details for this API include:

• The delinking is successful for IBLPN and OBLPNs when the 'SERIAL_NUMBER_TRACKING_LEVEL' company parameter is set to 2.
• The delinking is successful for only OBLPNs when the 'SERIAL_NUMBER_TRACKING_LEVEL' company parameter is set to 1.
• The delink process is successful if the targeted inventory is non-decimal tracked.
• The system returns an error message if the targeted inventory is not linked with any serial number.
• The delink process is unsuccessful if the inventory associated with any LPN is either in Consumed, Shipped, Delivered, Cancelled, or Lost status.
• The corresponding serial number history for delinking is recorded in the SerialNbrHistoryView UI screen for serial numbers that are delinked from IBLPNs/OBLPNs/Active inventories.

Sample Data format JSON

{
"options" : {
"serial_nbr_list": [
"SN1",
"SN2",
"SN3"
]
}
}

XML

<request>
<options>
<serial_nbr_list>
<list-item>SN1</list-item>
<list-item>SN2</list-item>
<list-item>SN3</list-item>
</serial_nbr_list>
</options>
</request>

Get Inventory History

The Inventory History API allows you to query inventory histories for default Companies and Facilities configured for the user. Previously, inventory history was not supported or exposed as an entity in lgfapi. Now, users can fetch the inventory history as an entity since it has been exposed to the lgfapi.

You can get inventory history details with paginated results using the following GET request:

GET....../entity/inventory_history

To fetch non-paginated result by specific 'ID':

GET....../entity/inventory_history/{id}

To fetch paginated result by query string parameters:

GET....../entity/inventory_history?key1=value1&key2=value2

To check for object existence or modification:

HEAD .../entity/inventory_history?key1=value1&key2=value2
HEAD .../entity/inventory_history/{id}

Query String Parameters

Since inventory history is a large table, to avoid performance issues, certain combinations of query string fields are required when querying using query parameters. One of the following combinations must be used (in addition to any other field):

• company_id__code, facility_id__code, group_nbr
• company_id__code, facility_id__code, history_activity_id, status_id
• company_id__code, facility_id__code, history_activity_id, item_code
• company_id__code, facility_id__code, history_activity_id, item_alternate_code
• company_id__code, facility_id__code, history_activity_id, container_nbr

Item

These topics give descriptions for APIs that complete actions related to items in the Warehouse.

Image Upload

The image_upload API allows you to update an image either by Item ID or Item by Filter.

Assumptions

• Only one item may be updated per request.
• An error will be returned if no items are found.
• An error will be returned if more than one item is found.

Item by ID

POST .../entity/item/{id}/image_upload/

Item by Filters

POST .../entity/item/image_upload/

Supported Item Filter Attributes

The "parameters" section of the request body supports item filters when using this URL style.

• company_id (Required)
  • This additionally allows filtering on company code: "company_id_code"
• barcode
• part_a
• part_b
• part_c
• part_d
• part_e
• part_f
• item_alternate_code

Example Request Body Parameters

{
"parameters": {
"company_id_code": "COM1",
"barcode": "ABC123"
}
}

Request Image Data

Regardless of which URL is used, the image data is passed in the request body's "options" section in the "image_data" key. Data is required to be base64 encoded.

Example Request body options:

{
"options": {
"image_data": "ABC123"
}
}

Item Image

Currently the full representation of item GET does not include the item image ('image_data') since that can be large. However if a request specifies the `fields` query string parameter and the 'image_data' field is specified, we will return the field and value.

This will return the id and image data for one or more items.

GET .../entity/item/?fields=id,image_data

This will return the id and image data for a specific item.

GET .../entity/item/{id}/?fields=id,image_data

The 'fields` parameter may still be combined with other filters per normal functionality:

GET .../entity/item/?fields=id,image_data&barcode=ITEM123&...

Putaway

These topics give descriptions for APIs that complete actions related to putaway in the Warehouse.

Putaway Priority

This operation allows you to determine the order in which Putaway Types are triggered for putaway.

POST .../entity/putaway_priority

If you have a new facility and you want to copy the same Putaway Priority rules from your current facility, you can first GET the list by querying the putaway_priority entity, then POST the applicable data to this operation for the target facility.

Example body request:

{

"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": false,

"radius": 1,

"radial_increment": 1

}

}

Directed Putaway Location

The Directed Putaway Location API now allows you to determine the putaway location for a given Inbound LPN or Pallet via a POST request, so that you can locate the LPN/Pallet to its respective destination.

You can determine the putaway location for an IBLPN using the following POST request:

POST .../entity/iblpn/directed_putaway_location/

Parameters

Name	Required	Type	Default	Description
facility_id		Integer		Facility context by id.
facility_id__code		String		Facility context by code.
company_id		Integer		Company context by id.
company_id_code		String		Company context by code.
container_nbr	X	String

You can determine the putaway location for a pallet using the following POST request:

POST .../entity/pallet/directed_putaway_location/

NOTE: Oracle WMS Cloud will check the putaway type associated with the IBLPN/ Pallet and check the respective putaway method priority configured for the putaway type. The system then determines the putaway location honoring the putaway method priority rule.

Parameters

Name	Required	Type	Default	Description
facility_id		Integer		Facility context by id.
facility_id__code		String		Facility context by code.
company_id		Integer		Company context by id.
company_id_code		String		Company context by code.
pallet_nbr	X	String

Request Options Parameters

Name	Required	Type	Default	Description
recalculate_putaway_type_flg		Boolean	False
validate_critical_dimensions_flg		Boolean	False

Example Request

POST .../entity/iblpn/directed_putaway_location/
{
"parameters": {
"container_nbr": "LPNPTW0102"
},
"options": {
"recalculate_putaway_type_flg": false,
"validate_critical_dimensions_flg": false
}
}
POST .../entity/pallet/directed_putaway_location/
{
"parameters": {
"pallet_nbr": "LPNPTW0102"
},
"options": {
"recalculate_putaway_type_flg": false
}
}

Putaway Type

POST .../entity/putaway_type

This operation is used to add single or multiple putaway type.

If you have a new facility and you want to copy the same putaway type from your current facility, you can first GET the list by querying the putaway_type entity, then POST the applicable data to this operation for the target facility.

Example body request:

{

"fields": {

"company_id": 1,

"pa_type": "TEST_PA_001",

"description": "Test PA 001",

"pallet_position_required_flg": false,

"depalletize_on_putaway_flg": false

}

}

Putaway Type Calculation Rule

POST .../entity/putaway_type_calc_rule

This operation is used to add single or multiple putaway type cal rules.

If you have a new facility and you want to copy the same putaway type cal rule from your current facility, you can first GET the list by querying the putaway_type_cal entity, then POST the applicable data to this operation for the target facility.

Example body request:

{

"fields": {

"facility_id": 1,

"company_id": 1,

"description": "TEST-001",

"priority": 1,

"final_putaway_type_id": 256860,

"sql_selection_id": 76886,

"enabled_flg": true

}

}

Waves

These topics give descriptions for APIs that complete actions related to waves in the Warehouse.

Run Manual Wave

The Run Manual API allows you to invoke a manual wave. The following are some potential scenarios and reasons for running the wave using a Rest API:

• External systems or PaaS Solutions can be built with the option to run a manual wave screen. These systems may have their own order entry or display screen and running an API will allow them to invoke waves.

  The following are some ways for calling the Manual Wave:

  Using the Wave Template ID:

  POST .../entity/wave_template/{id}/run_manual/

  Note: ID corresponds to a valid Wave template ID. The API body should contain the list of corresponding Order detail IDs for which the wave is run.

  Using the Wave Template Name:

  POST .../entity/wave_template/run_manual/

Note: The API body should include facility id/code, company id/code, wave template name, and corresponding Order Detail ID's, or Order Number and Sequence number combination.

Run Template

The Run Template API allows you to invoke the wave template.

The following are some ways for calling the Wave Template API:

Using the Wave Template ID

• POST .../entity/wave_template/{id}/run_template/

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

Using the Wave Template Name

• POST .../entity/wave_template/run_template/

Note: The API body should include facility id/code and the wave template name.

• The wave template name provided in the body should correspond to the default facility code or to your eligible facility.
• If the company parameter "ONLY_ONE_WAVE_PER_FACCO" is configured to ‘No’ and if there is already a wave running, the system will not allow you to invoke the wave to send in the API request.

Undo Wave

The Undo Wave API allows you to invoke the wave template. With the introduction of this API, external systems or PaaS solutions can be integrated which will allow you to undo a wave without accessing the web UI screen.

The following are some ways for calling the Undo Wave API:

Using the Wave Template ID

• POST .../entity/wave/{id}/undo

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

Using the Wave Run Number

• POST .../entity/wave/undo/

Note: The API body should include facility id/code and the wave run number.

When the parameter UNDO_WAVE_EVEN_AFTER_PICKING is set to 'No,' the system will not undo a Wave if picking is started. If the parameter is set to 'Yes,' the application allows undo wave even after picking has started.

Pick-Pack

These topics give descriptions for APIs that complete actions related to picking and packing in the Warehouse.

Pick Confirm

The Pick Confirm API allows you to perform cubed or non cubed picking. Also:

• The Pick Confirm API supports picking of multiple allocations in a single payload.
• If one or more Pick updates fail we report an error only for the first failed Pick.
• If the First Pick fails, then the rest of the Picks in the payload does not get Picked.

Note: This is a new API meant to replace the existing legacy `pick_confirm` API. The legacy API will eventually be retired so no further enhancements will be made to it. New functionality will instead be added to this API as part of the lgfapi suite.

This API supports features of the legacy API including the following new parameters:

• mhe_mode_flg - true/false; default true
• async_flg - true/false; default true
• short_flg - true/false; default false
• Replaces using the legacy "action_code" = "SHORT".

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

POST ..lgfapi/v10/pick_pack/pick_confirm/

Request Parameters

Pick List

These represent the parameters required for a single pick/short:

Name	Required	Type	Default	Description
facility_id		Integer		Facility context by id.
facility_id__code		String		Facility context by code.
company_id		Integer		Company context by id.
company_id___code		String		Company context by code.
wave_nbr	X	String		Associated wave.
order_nbr	X	String		Associated sales order.
item_alternate_code	C	String		Item identifier.
item_barcode	C	String		Item identifier.
qty	X	Number	0	Quantity to be acted upon.
batch_nbr		String		Inventory batch/lot.
uom_qty		Number		Filter on Case or Pack quantity when searching for allocations.
allocation_uom		String		"UNITS", "PACKS", or "CASES".
reason_code		String		Reason for short.
pick_location	C	String		From location.
from_container_nbr	C	String		From container.
to_container_nbr	C	String		LPN inventory is packed into. Not required for short.
update_inventory_on_short_flg		Boolean	False	Also short source inventory on pick short?
close_container_status		String	"packed"	Final OBLPN status: "picked" or "packed".
short_on_close_flg		Boolean	False	Should any remaining unpacked quantity shorted?
mhe_system_code	C	String		MHE system.
short_flg		Boolean	False	Is this a short?

Validations

• Facility must be in user's eligible facilities and not be ambiguous.
• Possible if there is a Store and a DC with the same code.
• Company must be in user's eligible companies.
• If facility or company context is not included in the input parameters, user defaults are used.
• User cannot pass both "facility_id" and "facility_id__code" in the same request.
• User cannot pass both "company_id" and "company_id_code" in the same request.
• "mhe_system_code" is required if "mhe_mode_flg" is True.
• Only one of "item_alternate_code" or "item_barcode" is allowed.
• Only one of "pick_location" or "from_container_nbr" is allowed.
• "to_container_nbr" is required for "pick" operation, but is not required for "short".

Request-Level Flags

Name	Required	Type	Default	Description
mhe_mode_flg		Boolean	True	When true, enforce that "mhe_system_code" is provided.
async_flg		Boolean	True	Run API asynchronously?

The following is an example JSON request:

{

"mhe_mode_flg": false, "async_flg": false,
        "pick_list": [{

"facility_idcode": "FAC", "company_id": 1, "wave_nbr": "WAVE001", "order_nbr": "ORDER001",
        "item_barcode": "ITEM1234", "qty": 10,

"from_container_nbr": "IBLPN0001",
        "to_container_nbr": "OBLPN0001", "short_flg": false

}]

}

The following is an example XML request:

<request>

<mhe_mode_flg>false</mhe_mode_flg>

<async_flg>false</async_flg>

<pick_list>

<list-item>

<facility_idcode>FAC</facility_idcode>

<company_id>1</company_id>

<wave_nbr>WAVE001</wave_nbr>

<order_nbr>ORDER001</order_nbr>

<item_barcode>ITEM1234</item_barcode>

<qty>10</qty>

Close LPN

The close_lpn API allows you to close an LPN during picking/packing. This API replaces the legacy pick confirm API when the action code is closed. While performing pick and pack operations (either non cubed active picking or cubed picking), the Close action code indicates to WMS that the Outbound LPN being picked needs to be closed.

Note: This is a new API meant to replace the existing legacy `close_lpn` API. The legacy API will eventually be retired so no further enhancements will be made to it. New functionality will instead be added to this API as part of the lgfapi suite.

This API supports features of the legacy API including the following new parameter:

• async_flg - true/false; default true

Close LPN API can be called using the following POST request:

POST ..lgfapi/v10/pick_pack/close_lpn/

Request Parameters

The following table provides details about the query string parameters:

Name	Required	Type	Default	Description
facility_id		Integer		Facility context by id.
facility_id__code		String		Facility context by code.
company_id		Integer		Company context by id.
company_id_code		String		Company context by code.
to_container_nbr	X	String		To OBLPN.
close_container_status		String	"packed"	Final OBLPN status: "picked" or "packed".
short_on_close_flg		Boolean	False	Should any remaining unpacked quantity shorted?
update_inventory_on_short_flg		Boolean	False	Also short source inventory on pick short?
reason_code		String		Reason for short.
async_flg		Boolean	True	Run API asynchronously?

The following is an example JSON request:

{

"facility_idcode": "FAC",
        "company_id": 1, "to_container_nbr": "OBLPN001", "close_container_status":
        "picked", "short_on_close_flg": true, "async_flg": true

}

Wave Complete

The Wave Complete API replaces the legacy API when the action code is Complete. This is an indicator to inform WMS that all picks are completed for that wave, and there are no more picks outstanding.

Note: This is a new API meant to replace the existing legacy `close_lpn` API. The legacy API will eventually be retired so no further enhancements will be made to it. New functionality will instead be added to this API as part of the lgfapi suite.

This API supports features of the legacy API including the following new parameter:

• async_flg - true/false; default true
  • When false:
    • Instead of submitting a celery task at the end for later processing, it should be immediately processed and a response returned.
    • On success, return a 204 - "No Content" HTTP response status with no response body.
    • When true: Return HTTP response status 202 - "Accepted" with no response body.
      • Signals that we received the request and it was successfully submitted for processing.

The Wave Complete API can be called using the following POST request:

POST ..lgfapi/v10/pick_pack/wave_complete/

The following table provides details about the query string parameters:

Name	Required	Type	Default	Description
facility_id		Integer		Facility context by id.
facility_id__code		String		Facility context by code.
company_id		Integer		Company context by id.
company_id___code		String		Company context by code.
wave_nbr	X	String		Associated wave.
update_inventory_on_short_flg		Boolean	False	Also short source inventory on pick short?
close_container_status		String	"packed"	Final OBLPN status: "picked" or "packed".
reason_code		String		Reason for short.
mhe_system_code		String		MHE system.
async_flg		Boolean	True	Run API asynchronously?

The following is an example JSON request JSON:

{
 "facility_id__code": "FAC",
 "company_id": 1,
 "wave_nbr": "WAVE001",
 "update_inventory_on_short_flg": true,
 "async_flg" true
}

Get Next Pick

The Get Next Pick REST API allows you to pick inventory based on the location pick sequence during picking from the Oracle WMS Cloud Mobile App or an external system using WMS APIs. This API follows the same underlying logic used in the text based Mobile RF picking transaction.

Note: The Oracle WMS Cloud Mobile App is one example of where this API will be leveraged. However, this API can be used in other scenarios.

The Get Next Pick API should give one pick from allocation records based on the location pick sequence when there are multiple allocation records that exist for a given Order/OBLPN.

The following is a sample GET request for Get Next Pick:

• GET .../entity/allocation/get_next_pick

Sample request for get next pick based on OBLPN:

• GET .../entity/allocation/get_next_pick?container_nbr=

Sample request for get next pick based on Order Number:

• GET .../entity/allocation/get_next_pick?order_nbr=

Get Reponse:

• Get next pick should give information associated with the inventory that is getting picked including:
  • Order Number : Order number against which the inventory is getting picked
  • Destination Facility: For Store Order Destination facility associated with the order
  • Customer Name: For Customer Order Customer name associated with the order
  • IBLPN: IBLPN number from which the inventory that needs to picked
  • OBLPN: OBLPN number in which the respective inventory is getting picked
  • Location: Location from which the inventory is getting picked (Active/ Reserve)
  • Item Code : Respective Item Code
  • Item Alternate Code: Respective Alternate Item Code
  • Inventory Attributes (A-O) : Attributes associated with the inventory.
  • Batch Number: Batch number associated with the inventory.
  • Expiry Date: Expiry date associated with the inventory.
  • Quantity : Pending quantity that needs to be picked for respective allocation record (Allocated Qty - Packed Qty)

Trailer

These topics give descriptions for APIs that complete actions related to trailers and the Warehouse.

First Available

The first_available API allows you to identify yard locations with available capacity. After fetching this API, you will get the first yard location with capacity based on the yard location putaway sequence. If the putaway sequence is not configured, the fetch will display according to the yard location pick sequence. After you get the location, you can use the locate to yard API to update the trailer location to the yard.

Identify yard location by capacity:

GET
        .../entity/location/yard/first_available

Request

The following are the Query String Filters for this API:

Name	Required	Type	Default	Description
facility_id		String		Facility context by id.
facility_id__code		String		Facility context by code.

• Only one of "facility_id" or "facility_id__code" is allowed per request.
• If no additional context is provided, the user's default facility/company will be used.

Example Requests

GET .../entity/location/yard/first_available?facility_id=1

The following is an example GET request for facility ID:

GET .../entity/location/yard/first_available?facility_id=1

The following is an example GET request for facility ID code:

GET .../entity/location/yard/first_available?facility_id_code=STRAJB01

Locate to Yard

The locate_to_yard API allows the caller to update a trailer’s location to or within the yard.

Regardless of the method used to identify the trailer, the following input is valid:

Category	Name	Type	Required	Description
options	location_barcode	String	Y	Barcode of yard location.

Trailer Lookup by ID

POST  .../entity/trailer/{id}/locate_to_yard/

The caller knows the unique `id` value of the trailer, which is added to the request URL. No additional `parameters` data is required from the request body.

Example Request Body:

{
"options": {
"location_barcode": "LOCN-1"
}
}

Trailer Lookup by Filters

POST .../entity/trailer/locate_to_yard/

Category	Name	Type	Required	Description
parameters	trailer_nbr	String	Y	Trailer number to be moved.
parameters	company_id	Integer	N	Trailer’s company.

• Only a single trailer may be moved per request.
  • The `__in` lookup is not supported for `trailer_nbr`.
• `company_id` additionally supports string lookup by `code` using the double-underscore notation:
  • company_id_code

Example Request Body:

{
"options": {
"location_barcode": "LOCN-1"
},
"parameters": {
"facility_id": 1,
"company_id_code": "COM-1",
"trailer_nbr": "TRLR-1"
}
}

Remove from Yard

The remove_from_yard API allows the caller to release a trailer from its current yard location.

Trailer Lookup by ID

POST .../entity/trailer/{id}/remove_from_yard/

The caller knows the unique `id` value of the trailer, which is added to the request URL. No additional `parameters` data is required from the request body.

Trailer Lookup by Filters

POST .../entity/trailer/remove_from_yard/

Category	Name	Type	Required	Description
parameters	trailer_nbr	String	Y	Trailer number to be removed.
parameters	facility_id	Integer	N	Trailer’s facility.
parameters	company_id	Integer	N	Trailer’s company.

• Only a single trailer may be moved per request.
  • The `__in` lookup is not supported for `trailer_nbr`.
• `facility_id` and `company_id` both additionally support string lookup by `code` using the double-underscore notation:
  • facility_id__code
  • company_id_code

Example Request Body:

{
"parameters": {
"facility_id": 1,
"company_id_code": "COM-1",
"trailer_nbr": "TRLR-1"
}
}

Load

These topics give descriptions for APIs that complete actions related to Loads in the Warehouse.

Check_In

The check_in API allows the caller to check-in an inbound or outbound load to a dock door.

Regardless of the method used to identify the load, the following input is valid:

Category	Name	Type	Required	Description
options	dock_nbr	String	Y	Dock door for check-in.

Load Lookup by ID

POST .../entity/load/{id}/check_in/

The caller knows the unique `id` value of the trailer, which is added to the request URL. No additional `parameters` data is required from the request body.

Example Request Body:

{
"options": {
"dock_nbr": "DOCK-1"
}
}

Load Lookup by Filters

POST .../entity/load/check_in/

Category	Name	Type	Required	Description
parameters	load_nbr	String	Y	Load for check-in.
parameters	facility_id	Integer	N	Load’s facility.
parameters	company_id	Integer	N	Load’s company.

• Only a single load may be moved per request.
  • The `__in` lookup is not supported for `load_nbr`.
• `facility_id` and `company_id` both additionally support string lookup by `code` using the double-underscore notation:
  • facility_id__code
  • company_id_code

Example Request Body:

{
"parameters": {
"facility_id__code": "FAC-1",
"company_id_code": "COM-1",
"load_nbr": "LOAD-1"
},
"options": {
"dock_nbr": "DOCK-1"
}
}

Check_Out

The check_out API allows the caller to check-out an inbound or outbound load from a dock door.

Load Lookup by ID

POST .../entity/load/{id}/check_out/

The caller knows the unique `id` value of the trailer, which is added to the request URL. No additional `parameters` data is required from the request body.

Load Lookup by Filters

POST .../entity/load/check_out/

Category	Name	Type	Required	Description
parameters	load_nbr	String	Y	Load for check-in.
parameters	facility_id	Integer	N	Load’s facility.
parameters	company_id	Integer	N	Load’s company.

• Only a single load may be moved per request.
  • The `__in` lookup is not supported for `load_nbr`.
• `facility_id` and `company_id` both additionally support string lookup by `code` using the double-underscore notation:
  • facility_id__code
  • company_id_code

Example Request Body:

{
"parameters": {
"facility_id__code": "FAC-1",
"company_id_code": "COM-1",
"load_nbr": "LOAD-1"
}
}

Ship Load

The Ship Load API allows you to ship a load by uploading the load via ID or filter.

Category	Name	Required	Type	Description
parameters	load_nbr	X	string	Load for shipping
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

Load Lookup by ID

POST .../entity/load/{id}/ship/

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

Load Lookup by Filters

POST .../entity/load/ship/

Example Request Body:

{
"parameters": {
"facility_id__code": "FAC-1",
"company_id_code": "COM-1",
"load_nbr": "LOAD-1"
}
}

This API includes the following features:

• Supports the ship load transaction for a load that is in the Loaded/ Loading Started /Checked Out status.
• An error is displayed if the load is in a "Cancelled", "Ship Load In Progress", or "Shipped" status.
• The shipload transaction can be performed either by providing the id or code for the company/facility along with the load number.
• A Ship Load confirmation file is generated after the load is shipped.

Once a load is shipped via the Ship Load API, the following applies to Inventory History Transaction (IHT) records:

• Inventory history IHT -3 '3 - Container Shipped' is written with respect to each container present on the load.
• For shipped loads with OBLPNs associated with asset inventory history, IHT- 58 '58 - Asset Shipped' is written with respect to each OBLPN associated with an asset.
• Inventory history IHT- 60 '60 - Load Shipped File' is written for the outbound Load shipped.

The Ship Load API supports the following validations:

Ship Load API supports Order type with ''Single Order on multiple Loads':

• If "Single Order on multiple Loads" is set to "Do not Allow" in the order type, the system displays the error message: "Load has Order/s marked to Prevent one order on different loads with Error."
• When an order is in Packed status but only some of the packed OBLPNs are loaded.
• When an order is in Packed status but some OBLPNs are loaded to different loads.
• For OBLPNs with pending audit if the Company parameter "ALLOW_LOAD_SHIP_WITH_AUDIT_PENDING" is set to no.

Company Parameter REQD_FIELDS_FOR_SHIPPING is defined:

• When the required fields configured for the parameter 'REQD_FIELDS_FOR_SHIPPING ' are not defined for the targeted load.
• When one of the container item on the load is serial number tracked and the number of serial numbers allocated do not match with the count of serial numbers present in the container.

Serial Number Validations

• If company parameter ALLOW_LOAD_SHIP_WITH_AUDIT_PENDING = False and company parameter SERIAL_NUMBER_TRACKING_LEVEL is 1 or 2
• If company parameter SERIAL_NUMBER_TRACKING_LEVEL is 0 or Non serial tracked items exist and company parameter ALLOW_LOAD_SHIP_WITH_AUDIT_PENDING = False
• This API will not show you any warning message like the UI or RF, and it will proceed with the Ship Load transaction.
• The Ship Load API does not generate multiple outbound files.

Container

These topics give descriptions for APIs that complete actions related to containers in the Warehouse.

The “iblpn” and “oblpn” entities are derived from the “container” entity and have access to all of the following entity operations, in addition to their own.

Get Sales Orders

GET …/wms/lgfapi/v10/entity/container/{id}/orders/

Returns a paginated representation of “order_hdr” entities for all sales order(s) allocated against the inbound or outbound container.

Lock Container

POST …/wms/lgfapi/v10/entity/container/{id}/lock/

Apply one or more inventory locks to the target inbound or outbound container.

Category	Parameter	Type	Required	Default	Description
options	lock_code_list	Array of Strings	X		Inventory lock code(s) to be applied.

Bulk Lock Container

POST …/wms/lgfapi/v10/entity/container/bulk_lock/

Apply one or more inventory locks to one or more inbound or outbound container(s).

The “parameters” section of the request body is required in addition to the “options” section outlined below. Only the “id” parameter filter is valid. It may be used as “id__in” with an array of values.

Category	Parameter	Type	Required	Default	Description
options	lock_code_list	Array of Strings	X		Inventory lock(s) to be applied.
options	commit_frequency	Integer		1	0 = Roll back on first error. 1 = Commit per object.

Unlock Container

POST …/wms/lgfapi/v10/entity/container/{id}/unlock/

Remove one or more inventory locks to the target inbound or outbound container.

Category	Parameter	Type	Required	Description
options	lock_code_list	Array of Strings	X	Inventory lock code(s) to be removed.

Bulk Unlock Container

POST …/wms/lgfapi/v10/entity/container/bulk_unlock/

Remove one or more inventory locks from one or more inbound or outbound container(s).

The “parameters” section of the request body is required in addition to the “options” section outlined below. Only the “id” parameter filter is valid. It may be used as “id__in” with an array of values.

Category	Parameter	Type	Required	Default	Description
options	lock_code_list	Array of Strings	X		Inventory lock(s) to be removed.
options	commit_frequency	Integer		1	0 = Roll back on first error. 1 = Commit per object.

Palletize Container

POST .../entity/container/{id}/palletize/

Allows you to palletize an Inbound or Outbound LPN.

The “parameters” section of the request body is required in addition to the “options” section outlined below. Only the “id” parameter filter is valid. It may be used as “id__in” with an array of values.

Category	Name	Required	Type	Description
parameters	Container_nbr	X	String	IB or OB LPN to be linked. “_in” lookup is not supported.
parameters	Facility_id		Integer	Container’s facility
Parameters	Company_id		Integer	Container’s company

Example

{
"parameters": {
"facility_id": 1,
"company_id": 1,
"container_nbr": "LPN-1"
}
}

• Both `facility_id` and `company_id` also support filtering on `code` as well.

Category	Name	Required	Type	Description
parameters	Facility_id		string	Container’s facility
Parameters	Company_id		string	Container’s company

{
"parameters": {
"facility_id__code": "FAC-1",
"company_id_code": "COM-1",
"container_nbr": "OBLPN-1"
}
}

Functional Request Data

Category	Name	Required	Type	Default	Description
options	pallet_nbr	X	string		Pallet number to be used for palletizing IB or OBLPN's.
options	pallet_position		string		Position of Inbound or OBLPN during palletization.
options	allow_mix_pa_types_flg		boolean	False	whether to allow mixing of LPN's with different PA types on a single pallet.
options	allow_mix_dest_shipto		string		valid values to be passed are Validate Ship To Validate Destination Validate Ship To and Destination Ignore Ship To and Destination

{
"options": {
"pallet_nbr": "PLT001",
"pallet_position": "01",
"allow_mix_pa_types_flg": false
"allow_mix_dest_shipto": Ignore Ship To and Destination
}
}

Depalletize Inbound / Outbound LPN

Allows you to depalletize an Inbound or Outbound LPN so you do not have to use RF guns for performing depalletization in automated guided facilities.

Identify container by ID:

POST .../entity/container/{id}/depalletize/

• The specific inbound or outbound LPN's id value is known and is provided in the URL.
• No additional `parameters` data in the request body is required.

Identify container by Filters

POST .../entity/container/depalletize/

• lgfapi provides mechanism to determine the container entity to be dissociated with pallet.
• The `parameters` section of the request body will allow for the users to identify the specific OBLPN

Category	Name	Required	Type	Description
parameters	Container_nbr	X	String	IB or OB LPN to be linked. “_in” lookup is not supported.
parameters	Facility_id		Integer	Container’s facility
Parameters	Company_id		Integer	Container’s company
parameters	type		String	Container’s type “I” or “O”.

{

"parameters": {

"facility_id": 1,

"company_id": 1,

        "container_nbr":
        "LPN001",

"type": "O"

}

}

• Both `facility_id` and `company_id` also support filtering on `code` as well.

Category	Name	Required	Type	Description
parameters	facility_id_code		string	Container’s facility
Parameters	company_id_code		string	Container’s company

{

"parameters": {

        "facility_id__code":
        "FAC-1",

        "company_id__code":
        "COM-1",

        "container_nbr":
        "LPN001",

"type": "O"

}

}

Quality Check Approve

Quality Check Approv allows you to accept QC marked containers.

API URL: Lookup by ID:

POST.../entity/iblpn/{id}/qc_reject/

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

API URL:Lookup by Filters:

POST.../entity/iblpn/qc_reject/

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	container_nbr	X	string	IBLPN subjected to QC

Category	Name	Type	Description
Options	vendor_perf_code	String	Vendor performance code, users want to pass for the QC transaction
Options	lock_code	string	Unallocatable lock code bring the QC rejected inventory within WMS

• 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.
• Lock code is an optional parameter. If users do not send the lock code, the rejected LPNs should get cancelled. If the lock code parameter is populated with a unallocatable lock code, the system should mark the LPN as received with QC status as QC Rejected. Users cannot provide allocatable lock codes to reject an IBLPN.

Bulk Reject URL

POST.../entity/iblpn/bulk_qc_reject/

Request Body:

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

{ 
    "parameters": { 
        "id__in": [1, 2, 3] 
     }, 
    "options": { 
        "lock_code": "KHLOC01"
        "vendor_perf_code": "KHVND001",
        "commit_frequency": 1, 
    } 
}

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.

Additionally, users should be able to send either container ID or container number in the parameter body. Hence, if users are sending container IDs, they can send as "id_in": [40129, 20138]. If users are sending container number, they can send [KHLPN01, KHLPN02].

Updates

• Lock code is an optional parameter. If users do not send the lock code, the rejected LPNs should get cancelled. If the lock code parameter is populated with a unallocatable lock code, the system should mark the LPN as received with QC status as QC Rejected.
• The system should capture the following inventory histories;
  • IHT-74- QC rejected
  • IHT- 48- Shipment status changed
  • IHT- 22- Lock container before shipment verification
• If the inventory in the QC marked IBLPN is serial tracked the IHT 74 should be broken based on the serial number if the Enable split by serial nbr flag is turned on.
• Can perform the quality check from an external QC module without accessing the OCWMS platform.

API URL:Lookup by ID:

POST.../entity/iblpn/{id}/qc_approve/

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

API URL: Lookup by Filters

 POST.../entity/iblpn/qc_approve/

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	container_nbr	X	string	IBLPN subjected to QC

Category	Name	Type	Description
Options	vendor_perf_code	String	Vendor performance code, users want to pass for the QC transaction

• 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.
• If more than one object is found, an error should be returned.

Bulk Approve URL

POST.../entity/iblpn/bulk_qc_approve/

Request Body:

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

{ 
   "parameters": { 
       "id__in": [1, 2, 3] 
   }, 
   "options": { 
       "vendor_perf_code": "KHVND001",
       "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.

Additionally, users should be able to send either container ID or container number in the parameter body. Hence, if users are sending container IDs, they can send as "id_in": [40129, 20138]. If users are sending container number, they can send [KHLPN01, KHLPN02].

Updates

The system should proceed with the following updates after successful approval of the QC marked IBLPNS.

• The LPN status should be received with QC status as QC approved
• The system should capture the following inventory histories;
  • IHT-73- QC approved
  • IHT- 48- Shipment status changed**
• If the inventory in the QC marked IBLPN is serial tracked the IHT 73 should be broken based on the serial number if the Enable split by serial nbr flag is turned on.
• -The Verification History view UI screen should create a record for the QC approval of the respective IBLPN-s.

Quality Check Reject

The Quality Check Reject API allows you to reject QC marked containers, so you can perform the quality check from an external QC module without accessing the OCWMS platform.

Task

These topics give descriptions for APIs that complete actions related to tasks in the Warehouse.

Next Task

The next_task API allows you to determine the next task via an API operation.

You can search for the next task using the following GET request:

GET .../entity/task/next_task

The following table provides details about the query string parameters:

Name	Required	Type	Default	Description
facility_id		Integer		Facility context by id.
facility_id__code		String		Facility context by code.
location_barcode		String		User's current location.
task_type		String		Required task type.
ordering_rule		String		Order tasks by rule name.

Facility ID/Facility Code

• If a value isn't provided, the user's default facility context will be used.
• Task look up is done relative to the user's facility and eligible company contexts.

Location Barcode

• If provided, search for task within the same location area (if available) and/or pick sequence (if available).

Task Type

• If provided, search for task only of the given type.

Ordering Rule

• If provided, order the found tasks by the corresponding field(s) and return the top result.
• The value accepted by the API is that of the Task Ordering Rule's description.

The following is an example GET request using location barcode:

GET .../entity/task/next_task?location_barcode=MY_LOCN_BRCD&task_type=MY_TASK_TYPE&ordering_rule=MY_RULE

Hold Task

The Hold Task API allows you to hold a task which is in ready status. With this api, external systemd can change one or more task statuses to ‘Held’ from ‘Ready’. You can exclude tasks that are not currently required to be executed by the assigned user without accessing the web UI. Users who have the Task/ Can hold/release task permission enabled should be able to put a task on ‘Held’ status.

The following are some ways for calling the Hold task API:

Using the Task ID:

• POST.../entity/task/{id}/hold/

Note: No additional parameters data in the request body is required.

Using the Task Number:

• POST.../entity/task/hold/

Note: The API body should include facility id/code, company id/code and task number.

Using the Bulk Task Hold:

• POST.../entity/task/bulk_hold/

Note: The API body should task number list. Users can also provide the commit frequency as an option. 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 will commit per object.

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	task_nbr	X	string	Task which needs to be on hold

Using the Bulk Hold Task

POST.../entity/task/bulk_hold/

	POST.../entity/task/bulk_hold/
	{ 
	   "parameters": { 
	         "id__in": [01, 02, 03] 
	    }, 
	   "options": { 
	        "commit_frequency": "0",
	    } 
	}

Note: The API body should task number list. Users can also provide the commit frequency as an option. 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 will commit per object.

Release Task

The Release Task API allowd you to release a task which is in 'Held’ status. With this API, external systems can change one or more task statuses to ‘Ready’ from ‘Held’. These tasks can be executed by the assigned user without accessing the web UI. Users who have the Task/ Can hold/release task permission enabled should be able to put a task on ‘Held’ status.

The following are some ways for calling the Release Task API:

Using the Task ID:

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

Note: No additional parameters data in the request body is required.

Using the Task Number:

POST.../entity/task/release/

Note: The API body should include facility id/code, company id/code and task number.

Using the Bulk Task Release:

POST.../entity/task/bulk_release/

Note: The API body should have the task number list. Users can also provide the commit frequency as an option. 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 will commit per object.

The bulk request API allows you to release task ids belonging to the same company in a given request. The API will not support a request containing task ids belonging to multiple companies.

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	task_nbr	X	string	Task which needs to be released

Using the Bulk Release Task

POST.../entity/task/bulk_release/

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_release/
{ 
   "parameters": { 
         "id__in": [01, 02, 03] 
    }, 
   "options": { 
        "commit_frequency": "0",
    } 
}

Note: The API body should have the task number list. Users can also provide the commit frequency as an option. 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 will commit per object.

The bulk request API allows you to release task ids belonging to the same company in a given request. The API will not support a request containing task ids belonging to multiple companies.

Assign Task

The new Assign Task API allows you to assign a task to another user. For example, a task may require equipment handling like a forklift. The warehouse manager can assign the task to a specific user who can handle a forklift with this API without accessing the Web UI. However, you can assign a task with this API only if the Task/ Assign User Permission is enabled.

The following are some ways for calling the Assign Task API:

Using the Task ID:

• POST.../entity/task/{id}/assign_user/

Options

Category	Name	Type	Required	Description
Options	assigned_user	string	X	user who is being assigned to the task

Note: You need to provide the ‘assigned_user’ in the request body as this is a post operation of tasks to assign users.

Using the Task Number:

• POST .../entity/task/assign_user/

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	task_nbr	X	string	Task which needs to be updated

Options

Category	Name	Type	Required	Description
Options	assigned_user	string	X	user who is being assigned to the task

Note: The API body should include facility id/code, company id/code and task number. You are also required to provide the ‘assigned_user’ in the request body as this is a post operation of tasks to assign users.

Using the Bulk Task Release:

• POST.../entity/task/bulk_assign_user/

POST.../entity/task/bulk_assign_user/
{ 
   "parameters": { 
         "id__in": [01, 02, 03] 
    }, 
   "options": { 
         "assigned_user": "KHALL01",
         "commit_frequency": "0",
    } 
}

Note: The API body should have the task number list. You are also required to provide the ‘assigned_user’ in the request body. You can send the commit frequency as an option as well. 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 will commit per object.

• If the status of one or more of the selected tasks goes to Processing Started, completed, In Drop between Zones, Cancelled the return error and will not assign any user to the task.
• If task equipment and user equipment eligibility check fails for the assigned user, the API will return an error.

Change Priority

The Change Task Priority API allows you to change the priority of a task which is in Ready, Held or Created s status. External systems can also change the task priority of one or more tasks based on the urgency of other tasks which need to be executed on a priority. However, you can change the task priority with this API only if the Task/ Change task priority Permission is enabled.

The following are some ways for calling the Change task Priority API:

Using the Task ID:

• POST.../entity/task/{id}/change_priority/

Options

Category	Name	Type	Required	Description
Options	priority	integer	X	Priority code of the task (3, 20 etc)

Note: You need to provide the task priority in the request body as this is a post operation of tasks to change the task priority.

Using the Task Number:

• POST .../entity/task/change_priority/

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	task_nbr	X	string	Task which needs to be updated

Options

Category	Name	Type	Required	Description
Options	priority	integer	X	Priority code of the task (3, 20 etc)

Note: The API body should include facility id/code, company id/code and task number. You are also required to provide the task priority in the request body as this is a post operation of tasks to change the task priority.

Using the Bulk Task Release:

• POST.../entity/task/bulk_change_priority/

{ 
   "parameters": { 
         "id__in": [01, 02, 03] 
    }, 
   "options": { 
         "priority": "3",
         "commit_frequency": "0"
    } 
}

Note: The API body should have the task number list. You are also required to provide the task priority in the request body. You can send the commit frequency as an option as well. 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 will commit per object.

IBLPN

These topics give descriptions for APIs that complete actions related to IBLPNs in the Warehouse.

The “iblpn” entity is derived from the “container” entity and therefore also has access to all of its entity operations, in addition to the following:

Direct Consume

POST …/wms/lgfapi/v10/entity/iblpn/{id}/direct_consume/

Category	Parameter	Type	Required	Default	Description
options	reason_code	String	X		Used for inventory history tracking.

Consume a Received or Located IBLPN and update its inventory to zero. This will write IBLPN consumed inventory history records.

direct_consume

The `options` parameters, `transaction_ref_nbr`, may now be passed in the request body. This parameters will be added to any CNTR_CONSUMED inventory history records created as part of the API’s execution. The inventory history field `ref_code_3` will now be set as “TRN”. The value of `ref_value_3` will be that of `transaction_ref_nbr` or an empty string.

Category	Name	Type	Required	Description
options	transaction_ref_nbr	String	N	Max length of 250 characters.

Modify Item Quantity

The IBLPN modify_item_qty API allows the caller to adjust item inventory in a “Received” or “Located” IBLPN. You can only update a single IBLPN and item per request.

Regardless of the method used to identify the IBLPN, the following input is valid:

Category	Name	Type	Required	Description
options	item_barcode	String	C	Item identifier.
options	item_alternate_code	String	C	Item identifier.
options	adjustment_qty	Numeric	Y	Non-zero adjustment quantity.
options	batch_nbr	String	N	Batch tied to target inventory.
options	expiry_date	Date	N	Expiration date tied to target inventory.
options	invn_attr_X	String	N	Attributes A-O tied to the inventory.
options	reason_code	String	Y	Recorded on inventory history.
options	transaction_ref_nbr	String	N	Recorded on inventory history.

• Only one of `item_barcode` or `item_alternate_code` is allowed.
• IBLPN inventory matching is restrictive and does not support wildcard searches:
  • If no `batch_nbr` is provided, only match IBLPN inventory without a batch.
  • If no `expriy_date` is provided, only match IBLPN inventory without expiration.
  • If no `invn_attr_X` value is provided for A-O, it will be treated as blank.

IBLPN Lookup by ID

POST .../entity/iblpn/{id}/modify_item_qty/

Caller knows the unique `id` value of the IBLPN, which is added to the request URL. No additional `parameters` data is required from the request body.

IBLPN Lookup by Filters

POST .../entity/iblpn/modify_item_qty/

Category	Name	Type	Required	Description
parameters	container_nbr	String	Y	IBLPN to be adjusted.
parameters	facility_id	Integer	N	IBLPN’s facility.
parameters	company_id	Integer	N	IBLPN’s company.

• Only a single IBLPN may be moved per request.
  • The `__in` lookup is not supported for `container_nbr`.
• `facility_id` and `company_id` both additionally support string lookup by `code` using the double-underscore notation:
  • facility_id__code
  • company_id_code

Example Request Body:

{
"parameters": {
"facility_id__code": "FAC-1",
"company_id ": 2,
"container_nbr": "IBLPN1234"
},
"options": {
"item_barcode": "ITEM1234",
"adjustment_qty": -10,
"batch_nbr": "BATCH1234",
"expiry_date": "2020-01-02",
"invn_attr_a": "A",
"invn_attr_b": "B",
"reason_code": "RC",
"transaction_ref_nbr": "TX123457890"
}
}

Composite Create

POST …/wms/lgfapi/v10/entity/iblpn/composite_create/

This operation allows for the creation of a Received or Located IBLPN along with one or more inventory records in a single request. Furthermore, it allows for the creating and/or association of the inventory’s corresponding batch and inventory attribute, where applicable. This API follows all of the same validations and extended actions, such as writing inventory history, as the standalone create (POST) APIs for each entity, but brings them together in a single API.

Furthermore, this API takes advantage of allowing for the input of nested data, such as batch and inventory attribute, which will allow for those objects to be created or retrieved if they already exist. The use of the related objects “id” value is still permitted as well. All objects must have the same facility and company context as the IBLPN being created, and must still pass all standard user eligibility validations.

When the Composite Create API is called, an error will be returned if the appropriate serial number information is not provided for any serial number tracked items:

This change avoids the requirement of making multiple API calls to complete the linking.

Note: Customers using composite_create for serial number tracked items should ensure that serial number information is shared in the composite create itself.

The following is an example body for composite create:

{
    "fields": {
        "facility_id": 269,    <== Will be inherited by objects
        "company_id": 48,  <== Will be inherited by objects
        "iblpn": {
            "container_nbr": "IBLPN000001",
            "status_id": 30,
            "curr_location_id": 28536,
            "length": 1.1234567,
            "width": 2.34567890,
            "height": 3.123
        },
        "inventory": [    <== List of dictionaries, one per inventory record.
            {
                "item_id": 1,
                "expiry_date": "2019-01-01",
                "curr_qty": 1.2345,
                "batch_number_id": 1,
                "invn_attr_id": 2,
                "serial_nbr_list": [ <== Single Inventory can have multiple serial numbers.
                    "SN1",
                    "SN2",
                    "SN3"
                   ]
            }
        ]
    },
    "options": {
        "reason_code": "IT",
        "validate_serial_nbrs_flg": false
    }
}

This API also has unique data structure requirements that mimic those of the individual entity’s create (POST) field inputs. It also allows for the definition of a global context where “facility_id” and “company_id” may be defined at the top level of the data and inherited by each object, if not defined on the object.

Category	Parameter	Type	Required	Default	Description
fields	facility_id	Integer	C		“id” value of Facility. Not required if defined on the IBLPN or per object.
fields	company_id	Integer	C		“id” value of Company. Not required if defined on the IBLPN or per object.
fields	iblpn	Dictionary	X		Field value definitions for the IBLPN being created. These are the same as if using a standalone POST request for creating an IBLPN.
fields	inventory	Array	X		A list of one or more inventory objects to be created and associated with the given IBLPN.
options	reason_code	String	X		Used for inventory history tracking.

The following is an example of JSON request data where the facility/company context is defined at the top level and using the “id” values of “batch_number_id” and “invn_attr_id” to associate those objects that already exist. The defined top-level facility and company will be applied to the iblpn and inventory objects being created. The existing batch and inventory attribute objects being associated to the inventory must be of the same context.

Note: even though “inventory” does not have a “company_id” field, the company is determined from the associated item’s company and must also pass validations.

{
"fields": {
"facility_id": 1,
"company_id": 1,
"iblpn": {
"container_nbr": "IBLPN000001",
"status_id": 30,
"curr_location_id": 28536
},
"inventory": [
{
"item_id": 1,
"curr_qty": 1.2345,
"batch_number_id": 1,
"invn_attr_id": 1
}
]
},
"options": {
"reason_code": "IT"
}
}

The following is an example of JSON request data where the facility/company context is defined per object and using the “id” values of “batch_number_id” and “invn_attr_id” to associate those objects that already exist. Also demonstrates creating multiple inventory records for different item/batch/attribute combinations in a single IBLPN:

{
"fields": {
"iblpn": {
"facility_id": 1,
"company_id": 1,
"container_nbr": "IBLPN000002",
"status_id": 10
},
"inventory": [
{
"facility_id": 1,
"item_id": 1,
"curr_qty": 1.2345,
"batch_number_id": 1,
"invn_attr_id": 1
},
{
"facility_id": 1,
"item_id": 2,
"curr_qty": 10,
"batch_number_id": 2,
"invn_attr_id": 2
}
]
},
"options": {
"reason_code": "IT"
}
}

The following is an example of JSON request data where the facility/company context is defined at the top level and the “id” values of “batch_number_id” and “invn_attr_id” have been replaced with nested objects to create and associate those objects, which may or may not already exist:

{
"fields": {
"facility_id": 1,
"company_id": 1,
"iblpn": {
"container_nbr": "IBLPN000003",
"status_id": 10
},
"inventory": [
{
"item_id": 3,
"curr_qty": 1,
"batch_number_id": {
“batch_nbr”: “BATCH001”,
“item_id”: 3,
“expiry_data”: “2019-01-01”
},
"invn_attr_id": {
“invn_attr_a”: “A”,
“invn_attr_b”: “B”,
“invn_attr_c”: “C”
}
}
]
},
"options": {
"reason_code": "IT"
}
}

Vendor Performance Code

The Vendor Performance Code API allows you to to fetch the vendor performance code as an entity. Only the GET and HEAD http methods are supported for this API.

The following are some ways for calling the Vendor Performance Code API:

• GET....../entity/vendor_perf_code/

Note: The system will display paginated results when users use the above URL.

Using the Task ID

• GET....../entity/vendor_perf_code/{id}/

Note: The system will display non paginated results when users use the above URL

Quality Check Approve/Reject

The QC Approve API allows you to approve QC marked IBLPNs. You can perform quality check by using external quality check modules with custom verification methods without accessing the UI or RF QC complete module in Oracle WMS Cloud.

QC Approve

The following are some ways for calling the QC Approve API:

Using the Wave Template ID:

• POST.../entity/iblpn/{id}/qc_approve/

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

Using the Container Number:

• POST.../entity/iblpn/qc_approve/

Note: The API body should include facility id/code, company id/code and container number. You can also send the Vendor Performance code as an option in the API request body.

Using the Bulk QC Approve:

• POST.../entity/iblpn/bulk_qc_approve/

Note: The API body should have either the container IDs or container numbers in the. You can also send the Vendor Performance code as an option in the API request body.

Once quality check is approved, the container status becomes Received with QC status as QC approved.

QC Reject

The following are some ways for calling the QC Reject API:

Using the Wave Template ID:

• POST.../entity/iblpn/{id}/qc_reject/

Note: You can send the Vendor Performance code and Lock code as options in the API request body.

Using the Container Number:

• POST.../entity/iblpn/qc_reject/

Note: The API body should include facility id/code, company id/code and container number. You can also send the Vendor Performance code and Lock code as options in the API request body.

Using the Bulk QC Approve:

• POST.../entity/iblpn/bulk_qc_reject/

Note: The API body should have either the container IDs or container numbers in the. You can also send the Vendor Performance code Lock code as options in the API request body.

If you do not send the unallocatable lock code, the rejected LPNs get cancelled. If the lock code parameter is populated with a unallocatable lock code, the system marks the QC rejected LPNs as received with QC status as QC Rejected. You cannot provide allocatable lock codes to reject an IBLPN.

OBLPN

The “oblpn” entity is derived from the “container” entity and therefore also has access to all of its entity operations, in addition to the following.

mark_delivered

POST …/wms/lgfapi/v10/entity/oblpn/{id}/mark_delivered/

Updates a Shipped OBLPN to Delivered status and writes container delivered inventory history.

create_from_iblpn

The OBLPN create_from_iblpn API allows you to create an OBLPN in Outbound Ready status and allocate inventory from a designated IBLPN in a single request. Additionally allows the caller to trigger packing of the OBLPN.

POST .../entity/oblpn/create_from_iblpn/

Assumptions

1. All allocation data must have the same facility and company context as the OBLPN.
   • Allocations may be for multiple sales orders from multiple IBLPNs for different items as long as the facility/company context is consistent with the created OBLPN.
2. Sales order status will be recalculated on success.
3. IBLPN status will be recalculated on success.
4. Inventory history is only written if the OBLPN is packed.

Request Body Data

The request body data utilizes the 3 categories in the following ways:

1. `fields` – The initial data required to create the OBLPN.
2. `parameters` – List of data defining allocations.
3. `options` – Additional functional data.

OBLPN Fields Data

The OBLPN’s initial data is defined in the `fields` section of the request under the `oblpn` key. This is similar to the request body data requirements when creating an LPN directly through the entity’s create mechanism.

Supported fields:

Name	Type	Required	Description
facility_id	Integer	Y	OBLPN’s facility.
company_id	Integer	Y	OBLPN’s company.
container_nbr	String	Y	OBLPN’s container number.
curr_location_id	Integer	N	OBLPN’s location.
lpn_type_id	Integer	N	Associated LPN Type.
length	Numeric	N	OBLPN’s length dimension.
width	Numeric	N	OBLPN’s width dimension.
height	Numeric	N	OBLPN’s height dimension.

• If providing `lpn_type_id` - `length`, `width`, and `height` are not valid.

Example Request Body:

"fields": {
"oblpn": {
"facility_id": 1,
"company_id": 1,
"container_nbr": "OBLPN-1",
"lpn_type_id": 5
}
}

Allocation Parameters Data

Allocation data is defined in the `parameters` section of the request in the `allocations` key. The data is a list of objects, each linking one sales order detail to one IBLPN for the given inventory and quantity. An order detail or IBLPN may be referenced across multiple allocation definitions within the same request. Each of the following allocation scenarios is supported:

• Single order detail from single IBLPN.
• Single order detail from multiple IBLPNs.
• Multiple order details from single IBLPN.
• Multiple order details from multiple IBLPNs.

Category	Name	Type	Required	Description
allocations	order_nbr	String	Y	Sales order identifier.
allocations	iblpn_nbr	String	Y	IBLPN identifier.
allocations	qty	Numeric	Y	Non-zero quantity to allocate.
allocations	order_dtl	Object	Y	Nested object identifying the sales order detail.

• Sales order status must be less than “Packed”.
• IBLPN status must be “Received”, “Located”, or “Partially Allocated” and have the necessary available unallocated quantity.

The nested `order_dtl` object requires one of two definitions in order to identify the sales order detail.

Identify Sales Order Detail by Sequence Number

If the order detail’s unique sequence number is known to the user, this may be provided in the request and is the only piece of data necessary to identify the correct detail for the given sales order number.

Category	Name	Type	Required	Description
order_dtl	seq_nbr	Integer	C	Sales order detail’s unique sequence number.

Example Request Body:

"parameters": {
"allocations": [
{
"order_nbr": "ORDER-1",
"order_dtl": {
"seq_nbr": 1
},
"iblpn_nbr": "IBLPN-1",
"qty": 1
}
]
}

Identify Sales Order Detail by Attributes

The sales order detail may also be identified by its attributes. At least one of the following pieces of information is required. If more than one order detail is identified, an error will be returned. Additionally, this is a restrictive search in that any omitted data will not be treated as a wildcard.

• If no `batch_nbr` is provided, only match order detail(s) without a batch.
• If no `invn_attr_X` value is provided for A-O, it will be treated as blank.

Category	Name	Type	Required	Description
order_dtl	item_barcode	String	C	Item identifier.
order_dtl	item_alternate_code	String	C	Item identifier.
order_dtl	batch_nbr	String	N	Batch identifier.
order_dtl	invn_attr_X	String	N	Attributes A-O tied to the order detail.

Example Request Body:

"parameters": {
"allocations": [
{
"order_nbr": "ORDER-2",
"order_dtl": {
"item_barcode": "ITEM2",
"batch_nbr": "BATCH-1",
"invn_attr_a": "A",
"invn_attr_b": "B"
},
"iblpn_nbr": "IBLPN-2",
"qty": 2
}
]
}

Additional Options Data

Functional request data in the `options` section:

Category	Name	Type	Required	Description
options	pack_flg	Boolean	N	Pack the OBLPN? (Default = False)

• OBLPN will be routed regardless of the `pack_flg` value.
• If `pack_flg` = True:
  • OBLPN will be updated to “Packed” status.
  • The created allocations will be completed.
  • The sales order detail(s) will be updated.
  • OBLPN’s final weight and volume will be calculated.
  • Inventory history will be written.

Example Request Body:

"options": {
"pack_flg": true
}

Full Request Body Example:

The following example would create a packed OBLPN allocated from two different IBLPNs for the same order.

{
"fields": {
"oblpn": {
"facility_id": 1,
"company_id": 1,
"container_nbr": "OBLPN-1"
}
},
"parameters": {
"allocations": [
{
"order_nbr": "ORDER-1",
"order_dtl": {
"seq_nbr": 1
},
"iblpn_nbr": "IBLPN-1",
"qty": 2
},
{
"order_nbr": "ORDER-1",
"order_dtl": {
"item_barcode": "ITEM-1",
"batch_nbr": "BATCH-1",
"invn_attr_a": "A",
"invn_attr_o": "O"
},
"iblpn_nbr": "IBLPN-2",
"qty": 5.52
}
]
},
"options": {
"pack_flg": true
}
}

Link OBLPN with asset

POST …/wms/lgfapi/v10/entity/oblpn/{id}/link_asset

links asset (reusable tote) to oblpn.

Assumptions

• Only one OBLPN may be linked to one asset per request.
• OBLPN must be within user's eligible facilities/companies.

Request Body Data

The request body data utilizes the 3 categories in the following ways:

1. `parameters` – allows user to identify the specific oblpn
2. `options` – Additional functional data.

Parameters

Category	Name	Type	Required	Description
Parameters	container_nbr	String	Y	OBLPN to be linked. "__in" lookup is not supported
Parameters	facility_id	Integer		Container's facility.
Parameters	company_id	Integer		Container's company.

Example Request Body:

{
"parameters": {
"facility_id": 1,
"company_id": 1,
"container_nbr": "OBLPN-1"
}
}

Note: Both facility id and company id also support filtering on “code”.

Additional Options Data

Functional request data in the `options` section:

Category	Name	Type	Required	Description
options	asset_nbr	String	Y	Asset to be linked. May be created as part of this API.
options	asset_seal_nbr	String		Optionally tracked seal number.
Options	replace_container_nbr_with_asset_flg	boolean		Rename OBLPN to match asset upon linking?
options	validate_lpn_type_flg	boolean		Validate the LPN type of the OBLPN with the LPN type of the asset

{
"options": {
"asset_nbr": "ASSET-01",
"asset_seal_nbr": "SEAL-001",
"replace_container_nbr_with_asset_flg": true
"validate_lpn_type_flg": true
}
}

• If the Asset already exists in the system, then it will be made "In Use" status and update the Asset OBLPN field with the corresponding OBLPN, Destination field with the OBLPN destination of the linked OBLPN and Seal Nbr field with corresponding seal nbr passed in the API
• If Original OBLPN is renamed while interfacing (i.e. when "replace_container_nbr_with_asset"= true), system will update the following:
  • Populate OBLPN field with the Asset Nbr,
  • Destination field with the OBLPN destination
  • Seal Nbr field with corresponding seal nbr passed in the API
• OBLPN type in the Asset table will not get updated with the OBLPN type of the OBLPN
• If the Asset interfaced is new, then a new record is created in the Asset UI with the status "In Use" with corresponding OBLPN, Seal and destination.
• If the Original OBLPN is renamed with Asset nbr while interfacing (i.e. when "replace_container_nbr_with_asset"= true), system updates the OBLPN field with the Asset Nbr, Destination field with the Original OBLPN's destination and Seal Nbr field with corresponding seal nbr passed in the interface
• If the OBLPN is already linked to an asset and another Asset Nbr is passed in the interface for linking with OBLPN, the original asset number needs to be updated back to status "In-warehouse" while the new asset number is updated back to status "In-use".
• In case if the OBLPN is already linked to an asset/seal and another seal nbr is passed in the API, then update the seal nbr field with the corresponding seal.
• If the Asset interfaced in the API is new to the system, then a new record is created in the Asset table
• The fields "asset_nbr" and "asset_seal_nbr" is updated with corresponding data in the oblpn.
• If Original OBLPN is replaced with Asset Nbr while interfacing (i.e. when "replace_container_nbr_with_asset"= true), system should update the Container table as mentioned below:
  • LPN Nbr is updated with the Asset Nbr
  • Asset Nbr and Asset Seal Nbr is updated with the corresponding value passed in the API
  • OBLPN Type field is not updated with the OBLPN type of the Asset
  • "Ref OBLPN Nbr" field is updated with original OBLPN Nbr
• The following Inventory History records are created:
  • IHT 57 - Asset Received – This record is not written if the Asset interfaced in the API is new to the system
  • IHT 31- OB Container Modified is written if the OBLPN is renamed with Asset Nbr while linking.

Pallet

These topics give descriptions for APIs that complete actions related to Pallets in the Warehouse.

Sort LPN

The Sort LPN API allows you to sort an LPN to a Pallet in a sort location mimicking what the RF Inbound Sorting process does. The RF modules include: RF Sort LPN, and RF Inbound Sort Location.

You can sort an LPN to a pallet in a sort location with the following POST request:

POST .../entity/pallet/sort_lpn/

The following table provides details about the Input Parameters/Filters used to identify the target pallet:

Name	Required	Type	Default	Description
facility_id		integer		Facility context by id.
facility_id__code		string		Facility context by code.
company_id		integer		Company context by id.
company_id___code		string		Company context by code.
pallet_nbr	X	string		Target sort pallet.

• The pallet will be created if it doesn't exist.
• The requesting user's default facility/company context will be assumed if overrides are not provided.

Functional Options

Name	Required	Type	Default	Description
container_nbr	X	string		LPN being sorted to pallet.
sort_zone	X	string		Destination sort zone.
sort_location_barcode	X	string		Destination sort location.
sort_to_inventory		string	"pallet-call-directed-putaway"	Sort method.
allow_received_status_flg		boolean	False	Allow sorting of IBLPN in Received status.
allow_picked_status_flg		boolean	False	Allow sorting of OBLPNs in Picked status.

• Default valid LPN statuses:
• Located
• Allocated
• Packed

The following is an example body for Sort LPN to Pallet:

{
"parameters": {
"facility_id": 1,
"company_id_code": "FOO",
"pallet_nbr": "PALLET001"
},
"options": {
"container_nbr": "LPN001",
"sort_zone": "ZONE01",
"sort_location_barcode": "BRCD001",
"sort_to_inventory": "pallet-call-directed-putaway"
}
}

Response Status

• 204 - No content
• Operation successfully completed.
• 400 - Validation error
• 500 - Internal server error

Sort LPN Close Pallet

The Sort LPN/Close Pallet API is used as part of the inbound sorting process which groups LPNs to pallets in sort locations. This API mimics the RF IB Sort LPN module which calls the Sort LPN Close IB Pallet back end entry point with parameters.

You can Sort LPNs and Close Pallet with the following POST requests:

POST .../entity/pallet/close_inbound_sorting/

POST .../entity/pallet/{id}/close_inbound_sorting/

The following table provides details about the Input Parameters/Filters used to identify the target pallet:

Name	Required	Type	Default	Description
facility_id		integer		Facility context by id.
facility_id__code		string		Facility context by code.
company_id		integer		Company context by id.
company_id___code		string		Company context by code.
pallet_nbr	X	string		Target sort pallet.

• The pallet will be created if it doesn't exist.
• The requesting user's default facility/company context will be assumed if overrides are not provided.

The following table details the functional options:

Name	Required	Type	Default	Description
create_replen_task_flg		boolean	True	Generate a replenishment task on close?
task_type_description		string		Required type description for generated replen task. Valid when create_replen_task_flg = True.

Default valid LPN statuses:

• Located
• Allocated
• Packed

The following is an example body for Create Replenishment Task Flag:

{
"parameters": {
"facility_id": 1,
"company_id_code": "FOO",
"pallet_nbr": "PALLET001"
},
"options": {
"create_replen_task_flg": true,
"task_type_description": "My Task Type"
}
}

Response

Response Status:

• 204 - No content
  • Operation successfully completed.
• 400 - Validation error
• 500 - Internal server error

Replenishment

These topics give descriptions for APIs that complete actions related to Replenishment in the Warehouse.

Replenish to Active

The replenish_to_active API allows you to complete an open replenishment task for an active location.

You can replenish to active with the following POST request:

POST .../lgfapi/v10/replenishment/replenish_to_active/

Parameters

The following table provides details about the Input Parameters/Filters:

Name	Required	Type	Default	Description
facility_id		integer		Facility context by id.
facility_id__code		string		Facility context by code.
company_id		integer		Company context by id.
company_id___code		string		Company context by code.

• Used if the replenishment is in a context other than the requesting user's default.
• The requesting user's default facility/company context will be assumed if values are not provided.
• Either "facility_id" or "facility_id__code" may be used, but not both.
• Either "company_id" or "company_id___code" may be used, but not both.

The following table details the functional options:

Name	Required	Type	Default	Description
task_id	C	integer		"id" of task to be completed.
task_id__task_nbr	C	string		Business key for task to be completed.
replen_location_id	C	integer		"id" of active location to be replenished.
replen_location_id__barcode	C	string		Barcode of active location to be replenished
qty		decimal	Allocation Qty	Quantity to replenish.

• Either "task_id" or "task_id__task_nbr" is required.
• Either "replen_location_id" or "replen_location_id__barcode" is required.
• If 'qty' is not provided, the full allocation quantity of the associated allocation will be used.
  • If 'qty' is provided, it must be greater than 0.

The following is an example body for Replenish Location ID Barcode:

{
"facility_id" 1,
"company_id_code": "COMPANY",
"task_id": 1,
"replen_location_id__barcode": "LOCN1"
}

Replenishment Zone

POST .../entity/replenishment_zone

This operation is used to add one or more replenishment zones.

If you have a new facility and you want to copy the same replenishment zones from your current facility, you can first GET the list by querying the replenishment_zone entity, then POST the applicable data to this operation for the target facility.

Example Body Request

{
"fields": {
"facility_id": 1,
"code": "TEST_RZ_001",
"description": "Test RZ 001"
}
}

Sales Order Header

These topics give descriptions for APIs that complete actions related to Sales Orders in the Warehouse.

Get IBLPN(s)

GET …/wms/lgfapi/v10/entity/order_hdr/{id}/iblpns/

Returns a paginated representation of all IBLPN(s) allocated to the sales order.

GET OBLPN(s)

GET …/wms/lgfapi/v10/entity/order_hdr/{id}/oblpns/

Returns a paginated representation of all OBLPN(s) allocated to the sales order.

Bulk Lock

POST …/wms/lgfapi/v10/entity/order_hdr/bulk_lock/

This operation is used to apply, and optionally create, an order lock to one or more orders.

The number of orders that can be modified by this operation in a single requests is configured by the value of the requesting user’s “Rows per Page” attribute.

The “parameters” section of the request body is required in addition to the “options” section outlined below. One or more parameters are used to determine the order(s) for which the operation will be applied. The allowed filter parameters are:

• 'id'
• 'order_nbr'
• 'facility_id'
• 'company_id'
• 'erp_source_hdr_ref'
• 'erp_source_system_ref'
• 'orderdtl__erp_source_line_ref'
• 'orderdtl__erp_source_shipment_ref'
• 'orderdtl__ship_request_line'

Category	Parameter	Type	Required	Default Value	Description
options	lock_code	String	X		Order lock to be applied.
options	lock_description	String		Value of lock_code	Description of order lock. Only used when creating a new order lock.
options	comments	String		“”	Additional info for the order’s applied lock.
options	allow_allocate_flg	Boolean		False	Order lock attribute. Only used when creating a new order lock.
options	autocreate_lock_flg	Boolean		False	When true, the order lock will be created in addition to be applied, if it does not already exist.
options	commit_frequency	Integer		0	0 = Roll back on first error. 1 = Commit per object.

Bulk Unlock

POST …/wms/lgfapi/v10/entity/order_hdr/bulk_unlock/

This operation is used to remove an order lock from one or more orders.

The “parameters” section of the request body is required in addition to the “options” section outlined below. One or more parameters are used to determine the order(s) for which the operation will be applied. The allowed filter parameters are:

• 'id'
• 'order_nbr'
• 'facility_id'
• 'company_id'
• 'erp_source_hdr_ref'
• 'erp_source_system_ref'
• 'orderdtl__erp_source_line_ref'
• 'orderdtl__erp_source_shipment_ref'
• 'orderdtl__ship_request_line'

Category	Parameter		Type	Required	Default Value	Description
options	lock_code		String	X		Order lock to be removed.
options	commit_frequency		Integer		0	0 = Roll back on first error. 1 = Commit per object.

Print

These topics give descriptions for APIs that complete actions related to Printing in the Warehouse.

Print Shipping Label

GET.../wms/lgfapi/v10/print/label/shipping/?label_designer_code=foo

Returns the ZPL representation of the label

POST .../wms/lgfapi/v10/print/label/shipping

Submits the label for printing

The “parameters” section of the request body is required in addition to the “options” section outlined below. One or more parameters are used to determine the order(s) for which the operation will be applied.

Category	Name	Type	Required	GET Request	POST Request	Comments
options	label_designer_code	string	X	X	X	Label designer template to be printed
options	printer_name	string			X	Default's to cwuser.default_label_printer.
options	label_count	integer			X	Number of labels to print. Must be greater than 0. Default = 1.

API Filters

Functions like a bulk operation for identifying one or more IBLPN(s) to be printed: id Including "in" lookup

• facility_id
• company_id
• container_nbr
• Including "in" lookup

Example Query String for GET

GET.../wms/lgfapi/v10/print/label/shipping/?label_designer_code=foo&facility_id__code=FAC1&company_id_code=COM1&container_nbr=IBLPN1

Example Request Body for POST

{
"parameters": {
"facility_id__code": "FAC1",
"company_id_code": "COM1",
"container_nbr": "IBLPN1"
},
"options": {
"label_designer_code": "label_1",
"printer_name": "PRINTER1",
"label_count": 1
}
}

Response Body Data

On success, a 200 - OK status is returned.

The standardized bulk response body is returned. This will have aggregate information for all IBLPN(s) processed as well as the counts and any details.

For a GET request, the ZPL data bill be base64 encoded in the "data" section.

{
"record_count": 2,
"success_count": 1,
"failure_count": 1,
"data": {
"IBLPN_1": "VGhpcyBpcyBaUEwgY29kZQ=="
},
"details": {
"IBLPN_2": "Some error message."
}
}

Print LPN Label

GET.../wms/lgfapi/v10/print/label/ib_container/?label_designer_code=foo

Returns the ZPL representation of the label.

POST .../wms/lgfapi/v10/print/label/ib_container

Submits the label for printing.The “parameters” section of the request body is required in addition to the “options” section outlined below. One or more parameters are used to determine the order(s) for which the operation will be applied.

Category	Name	Type	Required	GET Request	POST Request	Comments
options	label_designer_code	string	X	X	X	Label designer template to be printed
options	printer_name	string			X	Default's to cwuser.default_label_printer.
options	label_count	integer			X	Number of labels to print. Must be greater than 0. Default = 1.

API Filters

• Functions like a bulk operation for identifying one or more IBLPN(s) to be printed:
  • id
    • Including "in" lookup
  • facility_id
  • company_id
  • container_nbr
    • Including "in" lookup

Example Query String for GET

GET.../wms/lgfapi/v10/print/label/ib_container/?label_designer_code=foo&facility_id__code=FAC1&company_id_code=COM1&container_nbr=LPN1

Example Request Body for POST

{
"parameters": {
"facility_id__code": "FAC1",
"company_id_code": "COM1",
"container_nbr": "OBLPN1"
},
"options": {
"label_designer_code": "label_1",
"printer_name": "PRINTER1"
}
}

Response Body Data

On success, a 200 - OK status is returned

For a GET request, the ZPL data bill be base64 encoded in the "data" section.

{
"record_count": 2,
"success_count": 1,
"failure_count": 1,
"data": {
"IBLPN_1": "VGhpcyBpcyBaUEwgY29kZQ=="
},
"details": {
"IBLPN_2": "Some error message."
}
}

Print Pallet Label

GET.../wms/lgfapi/v10/print/label/pallet/?label_designer_code=foo

Returns the ZPL representation of the label

POST .../wms/lgfapi/v10/print/label/pallet

Submits the label for printing

The “parameters” section of the request body is required in addition to the “options” section outlined below. One or more parameters are used to determine the order(s) for which the operation will be applied.

Category	Name	Type	Required	GET Request	POST Request	Comments
options	label_designer_code	string	X	X	X	Label designer template to be printed
options	printer_name	string			X	Default's to cwuser.default_label_printer.
options	label_count	integer			X	Number of labels to print. Must be greater than 0. Default = 1.

API Filters

• Functions like a bulk operation for identifying one or more IBLPN(s) to be printed:
  • id
    • Including "in" lookup
  • facility_id
  • company_id
  • container_nbr
    • Including "in" lookup

Example Query String for GET

GET.../wms/lgfapi/v10/print/label/pallet/?label_designer_code=foo&facility_id__code=FAC1&company_id_code=COM1&pallet_nbr=pallet1

Example Request Body for POST

{
"parameters": {
"facility_id__code": "FAC1",
"company_id_code": "COM1",
"pallet_nbr": "pallet1"
},
"options": {
"label_designer_code": "label_1",
"printer_name": "PRINTER1"
}
}

Response Body Data

On success, a 200 - OK status is returned

For a GET request, the ZPL data bill be base64 encoded in the "data" section.

{
"success_count": 1,
"failure_count":0,
"data": {
"OBLPN_1": "VGhpcyBpcyBaUEwgY29kZQ=="
}
}

Report

These topics give descriptions for APIs that complete actions related to Reporting in the Warehouse.

Custom Inventory Summary

Allows you to execute the custom inventory summary report for only a single item per request. This request returns the result set as a file attached to the response.

If output format is pipe-delimited, use the following:

GET.../report/custom_inventory_summary/?facility_id__code=FAC1&company_id_code=COM1&item_code=ITEM1

If output format is XML use the following:

GET.../report/custom_inventory_summary.xml?item_code=<item_code>&company_id=<company_id>&facility_id=<facility_id>

The “parameters” section of the request body is required in

Parameter	Type	Required	Default	Description
facility_id	integer	C		Required facility context.
facility_id__code	string	C		Required facility context.
company_id	integer	C		Required company context.
company_id_code	string	C		Required company context.
item_code	string	X		Specific item for the report.
write_header_line_flg	boolean		False	Include the header line with field names?

• Either `facility_id` or `facility_id__code` is required
• Either `company_id` or company_id_code` is required

Company Parameter

POST .../entity/company_parm

This operation is used to add single or multiple company parameters.

If you have a new facility and you want to copy the same Company Parameters from your current facility, you can first GET the list by querying the company_parm entity, then POST the applicable data to this operation for the target facility.

Example Body Request

{
"fields": {
"company_id": 1,
"parm_key": "TEST_PARM_001",
"parm_value": "test"
}
}

Facility Parameter

POST .../entity/facility_parm

This operation is used to add single or multiple facility parameters.

If you have a new facility and you want to copy the same facility parameters from your current facility, you can first GET the list by querying the facility_parm entity, then POST the applicable data to this operation for the target facility.

Example Body Request

{
"fields": {
"facility_id": 1,
"prog_key": "FACILITY_PARM",
"parm_key": "TEST_PARM_001",
"parm_value": "test"
}
}

SQL Selection (Rule Tree)

POST .../entity/sql_selection

This entity is unique in that the API will allow the user to create the entire rule tree in a single request instead of needing the create and link each parent/child object individually (it can still be done this way if the user chooses to do so). This is accomplished using the `children` list field. This is an abstract field that does not exists on the object itself, but rather defines the `parent_id` link, which will be handled by the API automatically.

To illustrate a complex example, the following request body could be used to create this rule structure as seen from the UI:

Example Body Request

{
"fields": {
"facility_id": 1,
"sql_operator_id": 2,
"children": [
{
"column_name_id": 107,
"sql_operator_id": 5,
"column_value": "B"
},
{
"sql_operator_id": 1,
"children": [
{
"column_name_id": 1379,
"sql_operator_id": 7,
"column_value": "100"
},
{
"column_name_id": 35,
"sql_operator_id": 7,
"column_value": "50"
}
]
}
]
}
}