1. WMS REST API Guide
  2. Create from IBLPN

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

Track User Activity

If you have purchased WFM (Oracle Workforce Management), you can also send user activity data using the following parameters in the Create From IBLPN API

  • Screen_name: Name of the application or screen in the external system that was used by the user to create OBLPN.
  • Begin_ts: Time at which the user started the create OBLPN operation.
  • End_ts: Time at which the user completed the create OBLPN operation.

If all the three parameters are sent in the API, and if WFM is enabled, user activity is written to the WMS Activity view and subsequently interfaced to WFM, enabling you to analyze user productivity through productivity reports in WFM.

Note:
  • All three parameters must be sent for WMS Activity to be written.
  • If WFM is not enabled, WMS Activity is not written even if the three parameters are sent.
  • Begin_ts and end_ts are parameters at the allocation level and must be sent on all allocations.
  • Activity tracking is currently not supported at the OBLPN level.
  • In order for WMS Activity data to interface successfully to WFM, screen_name that is sent in the API has to be configured as a screen in WMS using an RF module and mapped to a work area activity in WFM.
  • Screen_name sent on the API is also written on the corresponding IHTs that are written with this API.
  • If only screen_name is sent without begin_ts and end_ts, the screen_name is written on the IHT, even if WFM is not enabled.
  • Begin_ts and End_ts cannot be greater than the current timestamp of the facility in the API.

Request Body with User Activity Data

{
"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,
        "begin_ts": "2024-05-21T18:30:00",
        "end_ts": "2024-05-21T18:45:00"
    },
   {
        "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,
        "begin_ts": "2024-05-21T18:50:00",
        "end_ts": "2024-05-21T18:55:00"
    }
    ]
},
"options": {
"pack_flg": true,
"screen_name": "Create OBLPN Screen"
}
}