Versions Compared

Key

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

...

  • One ASN for each Sales Order that has been allocated to this Transfer Order, each containing the goods required by the individual Sales Order, and containing the linked Sales Order inbound ASN booking reference to indicate the cross-dock instruction

  • One ASN for the remaining goods (i.e. all SKUs / quantities left over after all the linked Sales Orders have been processed) - these are the goods not needed for cross-dock and so will be put away.

...

  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 PREP OF SPLIT SALES ORDER 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 do 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 /wiki/spaces/SMH/pages/3274768397 page.

  6. STORAGE PREP OF SPLIT TRANSFER ORDER 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 do 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 /wiki/spaces/SMH/pages/3274768397 page.

  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

...

  1. SEND CROSS DOCK ASNS: For each linked Sales Order:

    • if the corresponding instance of WMS ASN Split Status has Is Success = null or FALSE, invoke WMS 'Load Receipts’ API call below for scenario NEW / CROSS DOCK

    • If the corresponding instance of WMS ASN Split Status has Is Success = TRUE, invoke WMS 'Load Receipts’ API call below for scenario UPDATE / CROSS DOCK

  2. SEND RESIDUAL ASN: For the main Transfer Order:

    • if the corresponding instance of WMS ASN Split Status has Is Success = null or FALSE, invoke WMS 'Load Receipts’ API call below for scenario NEW / ASN

    • If the corresponding instance of WMS ASN Split Status has Is Success = TRUE, invoke WMS 'Load Receipts’ API call below for scenario UPDATE / ASN

  3. STORE ASN STATUS: Store the result of each WMS ‘Load Receipts’ API call above into the corresponding instance of WMS ASN Split Status:

    • If API call returns success, set WMS ASN Split Status. Is Success = TRUE and set WMS ASN Split Status. WMS Error Message to null

    • If API call returns failure, set WMS ASN Split Status. Is Success = FALSE and set WMS ASN Split Status. WMS Error Message to the returned error message from the API call

  4. STORE OVERALL STATUS: Process the overall Transfer Order Booking as follows:

    1. If ALL WMS ASN Split Status instances were successful:

      • Set Booking. Is WMS Success to TRUE

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

      • Set Booking. Status to ASN SENT

    2. If one or more WMS ASN Split Status instances were unsuccessful:

      • Set Booking. Is WMS Success to FALSE

      • Set the value of Booking. WMS Error Message to “one or more ASNs could not be transmitted to the warehouse”

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

    3. All this information, including the individual WMS ASN Split Status. WMS Error Message values, must be handed to the front-end API for display on the user’s UI.

Load Receipts API call (Scenario parameters)

The following fields represent the WMS ‘Load Receipts’ API call to send either or a NEW or UPDATE for either a CROSS DOCK or a normal ASN, as described above:

WMS API field

From White Glove Booking Model

Receipt Reason Code

(do not provide)

Update Receipt

NEW scenario: “FALSE”

UPDATE scenario: “TRUE”

Receipt Type

“Standard”

ASN Number

Booking. Booking WMS ASN Split Status. ASN Split Ref

GUID

(do not provide)

HB Reference

ASN scenario: (do not provide)

CROSS DOCK scenario: Booking. Booking Ref

Is Return

“FALSE”

Notes

Booking. Delivery. Additional Info

Warehouse ETA

Booking. Delivery. Earliest By

DC Code

Delivery. Location. Location Code

...

The following fields must be populated per Load Receipts Line Item. These must each correspond to the separate instances of Booking. Goods goods within the Inbound Booking.either the linked Sales Order (CROSS DOCK scenario) or the residual goods in the ASN after all linked sales order goods have been taken out (ASN scenario):

WMS API field

From Model

GUID

(do not provide)

Line No

n, where n is an incrementing integer starting from 1, as the SKUs are being processed

Supplier Company Code

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

Product CodeBooking. Goods(n). SKU

CROSS DOCK scenario: the current SKU being processed in the linked Sales Order booking

ASN scenario: the current SKU being processed in the main Transfer Order booking

Quantity

Booking. Goods(n). Quantity. Quantity

CROSS DOCK scenario: the Quantity of the current SKU being processed in the linked Sales Order booking

ASN scenario: the Quantity of the current SKU being processed in the main Transfer Order booking, minus the sum of all the Quantities for this same SKU across its linked Sales Order bookings

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

...

)

...