Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Overview

ASN splitting is required when an inbound Transfer Order booking is directly supplying goods to one or more outbound Sales Orders. In other words, certain Sales Orders have been prioritised by the client (ROOM) to be allocated goods directly from an inbound Transfer Order.

...

Please note that any inbound Transfer Order that has no linked Sales Orders, will be treated as one ASN where all goods will be put away.

Processing

When the user clicks the button to ‘Send ASN’ for an inbound Transfer Order, the following processing must be done:

  1. LINKED SALES ORDERS: Determine all the Sales Order Bookings stored in the system (with Booking. Booking Reason = SALES ORDER) that are linked to this Transfer Order (via the “allocate goods from” link in domain model)

  2. GOODS CHECK: Check that the Goods within the Transfer Order can fulfil all the linked Sales Orders. So calculate the total quantity by SKU across all the linked Sales Orders; each of those SKUs must exist within the Transfer Order’s Goods, and the total quantity by SKU across all the linked Sales Orders must be less than or equal to the quantity of the corresponding SKUs in the Transfer Order

  3. IF GOODS CHECK FAILS: Set the following:

    1. Booking. Is WMS Success = FALSE

    2. Booking. WMS Error Message = “Not enough goods in Transfer Order to fulfil linked Sales Orders”

    3. (NB this will need remediation outside the system, and requiring updates from ROOM to either the Transfer Order or the linked Sales Orders, or both, before ‘Send ASN’ can be re-attempted)

  4. IF THE GOODS CHECK PASSES: proceed with below

  5. STORAGE OF SPLIT STATUS (1): For each linked Sales Order, check if an instance of “WMS ASN Split Status” against this Transfer Order booking already exists with ASN Split Ref = the linked Sales Order’s Booking Ref. If it exists, no nothing at this stage. If it does not exist, create a new instance of “WMS ASN Split Status” against this Transfer Order, with Is Success = null, and ASN Split Ref = the linked Sales Order’s Booking Ref. See below and Booking Domain Model page.

  6. STORAGE OF SPLIT STATUS (2): For the main Transfer Order, check if an instance of “WMS ASN Split Status” against this Transfer Order booking already exists with ASN Split Ref = this Transfer Order’s Booking Ref. If it exists, no nothing at this stage. If it does not exist, create a new instance of “WMS ASN Split Status” against this Transfer Order, with Is Success = null, and ASN Split Ref = this Transfer Order’s Booking Ref. See below and Booking Domain Model page.

    Image Added
  7. Construct the WMS Cross-dock ASN API call (see below)

  8. Invoke the API call

  9. Store the results in a separate instance of “WMS ASN Split Status” attached to this booking (see Booking Domain Model page):

Load Receipts API call

The following fields represent the single set of data and Load Receipts Header for the WMS API call to send an ASN. This must be fed from a White Glove Booking where Booking. Reason Code = ASN or GOODS TRANSFER only.

WMS API field

From White Glove Booking Model

Receipt Reason Code

(do not provide)

Update Receipt

“FALSE”

Receipt Type

“Standard”

ASN Number

Booking. Booking Ref

GUID

(do not provide)

HB Reference

(do not provide)

Is Return

“FALSE”

Notes

Booking. Delivery. Additional Info

Warehouse ETA

Booking. Delivery. Earliest By

DC Code

Delivery. Location. Location Code

Load Receipts Line Items

The following fields must be populated per Load Receipts Line Item. These must each correspond to the separate instances of Booking. Goods within the Inbound Booking.

WMS API field

From Model

GUID

(do not provide)

Line No

n, where n is an incrementing integer starting from 1

Supplier Company Code

The code of the client “ROOM” as understood by the WMS

Product Code

Booking. Goods(n). SKU

Quantity

Booking. Goods(n). Quantity. Quantity

Return Reason

(do not provide)

Best Before Date

(do not provide)

Lot Number

(do not provide)

API Response

There is a synchronous success / failure API response as described in API Load Receipts. Examples are:

Example success Response Body

<Response>
<CallStatus>
<Success>true</Success>
<Code>0</Code>
<Message></Message>
</CallStatus>
<GUID>14d78523-3cfb-4460-befb-897e4c196cb7</GUID>
</Response>

Example failure Response Body

<Response>
<CallStatus>
<Success>false</Success>
<Code>100</Code>
<Message>Error. Invalid Mapping - DC</Message>
</CallStatus>
<GUID />
</Response>

The system must process this response as follows:

  • Success returned:

    • Set Booking. Is WMS Success to TRUE

    • Clear the value of Booking. WMS Error Message to null

    • Set Booking. Status to ASN SENT

  • Failure returned:

    • Set Booking. Is WMS Success to FALSE

    • Set the value of Booking. WMS Error Message to the error message returned from the WMS

    • Do not transition the Booking. Status (it remains in status CREATED)

This information must be handed to the front-end API for display on the user’s UI.