1. Oracle Warehouse Management Cloud REST API Guide
  2. Overview

4Supported Entity Operations

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.

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_code, facility_code, group_nbr
  • company_code, facility_code, history_activity_id, status_id
  • company_code, facility_code, history_activity_id, item_code
  • company_code, facility_code, history_activity_id, item_alternate_code
  • company_code, facility_code, history_activity_id, container_nbr

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.

Related Topics

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"
    }
}

Item

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

Related Topics

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"
    }
}

Trailer

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

Related Topics

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.

Related Topics

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.

Related Topics

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

Pick-Pack

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

Related Topics

Pick Confirm

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

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_id__code": "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_id__code>FAC</facility_id__code>

<company_id>1</company_id>

<wave_nbr>WAVE001</wave_nbr>

<order_nbr>ORDER001</order_nbr>

<item_barcode>ITEM1234</item_barcode>

<qty>10</qty>

<from_container_nbr>IBLPN0001</from_container_nbr>

<to_container_nbr>OBLPN0001</to_container_nbr>

<short_flg>false</short_flg>

</list-item>

</pick_list>

</request>

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_id__code": "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)

Task

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

Related Topics

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

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:

Related Topics

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.

Example Request Body:

{
    "options": {
        "reason_code": "IT",
        "transaction_ref_nbr": "TX12345"

}

}

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.

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"

}

}

modify_item_qty

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"
    }
}

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
    } 
}

Pallet

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

Related Topics

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.

Related Topics

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"
}

Sales Order Header

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

Related Topics

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.

Related Topics

Report

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

Related Topics

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"

}

}

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"

}

}

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

}

}

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

}

}

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"

}

}

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"

}

]

}

]

}

}

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&...