Cancellations & Amendments

Background

Client Orders may be cancelled or amended at any time, but this will mean the system needs to perform certain actions to ‘unwind’ previously-completed actions in respect of that booking.

For example SKUs may already have been picked at the warehouse ready for releasing outbound to the carrier, but the client cancels or reallocates goods to other sales orders, which means goods need to be put back into stock. In some cases the goods may already have been released to the outbound carrier and be en-route to Final Mile Facility but the client cancels the order due to a cancellation by their end-customer.

Ideal Solution (for later phases)

For later phases we should build the system so that if the client e.g. ROOM wants us to change something, it should be done by an UPDATE to a previously-created booking via the API -which may involve the total cancellation of a sales order. Note that the current Booking API has a section for cancellation/ amendments including which scenario is it and the ‘reason’.

Clearly for phase 1 we are not supporting anything regarding this but we will need to use the principles of the fully-electronic signalling and flow to allow manual signals from operators in earlier phases.

Receive & Putaway Task

See https://bigdigit.atlassian.net/wiki/spaces/SMH/pages/3251601441/Standard+Tasks+within+a+Workflow#Receive-%26-Put-Away task status flow. The following table shows the ideal processing that would need to occur depending on the possible statuses of this task when a Client ASN or Inbound Client TRANSFER ORDER is Cancelled or Amended:

Current Task Status

On Client Booking API Cancellation

On Client Booking API Amendment

CREATED

REPLANNING

(task has yet to be confirmed as planned)

Task Status → CLIENT CANCELLED
update display so that the only action the operator can do next is to Cancel the booking.

When Operator Cancels the booking:

Task Status → CANCELLED
update display so that the only action the operator can do next is to ‘close’ (dismiss) the booking.

Task Status → CLIENT AMENDED
update display so that the operator can see what has changed, during the workflow planning process

ASN PENDING

(Transfer Order only)

Task Status → ASN PENDING, CLIENT CANCELLED
update display so that the only action the operator can do next is to Cancel the booking.

When Operator Cancels the booking:

Task Status → CANCELLED
update display so that the only action the operator can do next is to ‘close’ (dismiss) the booking.

Task Status → ASN PENDING, CLIENT AMENDED
update display so that the operator can see what has changed and must select to re-plan whole workflow

When Operator selects to re-plan:

Task Status → REPLANNING
allow operator to make changes to the task & workflow prior to confirming the new plan

ASN SENT

Task Status → ASN SENT, CLIENT CANCELLED
update display so that the only action the operator can do next is to Cancel the booking.

When Operator Cancels the booking:

Send an ASN Cancellation message to the Warehouse
Task Status → CANCELLED
update display so that the only action the operator can do next is to ‘close’ (dismiss) the booking

Task Status → ASN SENT, CLIENT AMENDED
update display so that the operator can see what has changed and must select to re-plan whole workflow

When Operator selects to re-plan:

Task Status → REPLANNING
allow operator to make changes to the task & workflow prior to confirming the new plan

Then when planning has been completed/ confirmed:

regenerate the ASN.
Compare it the previously-sent ASN. If they are the same, do nothing.
If they are different:
- Send an ASN Cancellation message to the Warehouse
- Send the new ASN to the Warehouse

GOODS RECEIVED

GOODS PUTAWAY

(ASN or Transfer Order only)

These scenarios are extremely unlikely and will probably be a client error. It should be flagged with an error message / alert condition, for the SEKO operator to call up the client and ask what is going on.

Transport Task

See https://bigdigit.atlassian.net/wiki/spaces/SMH/pages/3251601441/Standard+Tasks+within+a+Workflow#Transport. The following table shows the ideal processing that would need to occur depending on the possible statuses of this task when any booking is Cancelled or Amended but it has a workflow which includes any Transport task:

Task Status	On Client Booking API Cancellation	On Client Booking API Amendment
CREATED REPLANNING (task has yet to be confirmed as planned)	Task Status → CLIENT CANCELLED update display so that the only action the operator can do next is to Cancel the booking. When Operator Cancels the booking: Task Status → CANCELLED update display so that the only action the operator can do next is to ‘close’ (dismiss) the booking.	Task Status → CLIENT AMENDED update display so that the operator can see what has changed, during the workflow planning process
CARRIER INSTRUCTED	Task Status → CARRIER INSTRUCTED, CLIENT CANCELLED update display so that the only action the operator can do next is to Cancel the booking. When Operator Cancels the booking: Recalculate the Carrier Instruction Consolidation across all bookings, based on the removal of this booking. send an Instruction Amendment to that carrier for each Instruction that has changed send an Instruction Cancellation to that carrier for each Instruction that was previously sent but no longer exists Task Status → CANCELLED update display so that the only action the operator can do next is to ‘close’ (dismiss) the booking	Task Status → CARRIER INSTRUCTED, CLIENT AMENDED update display so that the operator can see what has changed and must select to re-plan whole workflow When Operator selects to re-plan: Task Status = REPLANNING allow operator to make changes to the task & workflow prior to confirming the new plan Then when planning has been completed/ confirmed: Recalculate the Carrier Instruction Consolidation across all bookings, based on the amendment to this task. send an Instruction Amendment to that carrier for each Instruction that has changed send an Instruction Cancellation to that carrier for each Instruction that was previously sent but no longer exists send a new Carrier Instruction for each new consolidated instruction that now exists
CARRIER ACCEPTED	Task Status → CARRIER ACCEPTED, CLIENT CANCELLED update display so that the only action the operator can do next is to Cancel the booking. When Operator Cancels the booking: Recalculate the Carrier Instruction Consolidation across all bookings, based on the removal of this booking. send an Instruction Amendment to that carrier for each Instruction that has changed send an Instruction Cancellation to that carrier for each Instruction that was previously sent but no longer exists Task Status → CANCELLED update display so that the only action the operator can do next is to ‘close’ (dismiss) the booking	Task Status → CARRIER ACCEPTED, CLIENT AMENDED update display so that the operator can see what has changed and must select to re-plan whole workflow When Operator selects to re-plan: Task Status = REPLANNING allow operator to make changes to the task & workflow prior to confirming the new plan Then when planning has been completed/ confirmed: Recalculate the Carrier Instruction Consolidation across all bookings, based on the amendment to this task. send an Instruction Amendment to that carrier for each Instruction that has changed send an Instruction Cancellation to that carrier for each Instruction that was previously sent but no longer exists send a new Carrier Instruction for each new consolidated instruction that now exists
IN TRANSIT DELIVERED	These scenarios are extremely unlikely and will probably be a client error. It should be flagged with an error message / alert condition, for the SEKO operator to call up the client and ask what is going on.

Sales Order Cancellation

Out

If a Sales Order Cancellation is received:If our internal status of the SO is such that we know it hasn't yet been picked (Question: does the Warehouse have an electronic API signal that tells an external system that stuff has been Picked?) then we just send a cancellation of the sales order to the warehouse API.If our internal status of the SO is such that we know it HAS BEEN PICKED (same question as above) then we would need to send a Hold request to the warehouse API and then a Cancellation of the sales order to the warehouse APIIf our internal status of the SO is such that we know it HAS BEEN RELEASED TO THE CARRIER (Question: does the Warehouse have an electronic API signal that tells an external system that stuff has been Released?) then we would do nothing with the warehouse; instead we would send an instruction update to the White Glove partner effectively removing this SO job from their instruction. The carrier would send the goods to the FMF but then the WGP would no longer take action on the job in respect of that SO. (ROOM may then need to send a Transfer Order booking to request movement of those goods back from that FMF to our WH.)If a Sales Order AMENDMENT is received, and that SO now says that these goods are NO LONGER to be fed from a given inbound TO, AND/OR that SO now says that the estimated ship date needs to be later than before; this could also be a signal to hold. (I think we'd also need to analyse the other fields in the SO to identify which other value changes would also constitute such a signal.)If this situation arises:If our internal status of the SO is such that we know it hasn't yet been picked (see question above) then we just send an AMENDMENT of that sales order to the warehouse API.If our internal status of the SO is such that we know it HAS BEEN PICKED (see question as above) then we would need to send a Hold request to the warehouse API and then an Amendment to the warehouse APIIf our internal status of the SO is such that we know it HAS BEEN RELEASED TO THE CARRIER (see question above) then we would do nothing with regard to the warehouse; we'd probably need to speak to ROOM to ask them what they want to do. In most situations these goods would have to still arrive at the FMF and then get moved somewhere else via another TO from ROOM, unless there's another SO that ROOM has prioritised higher which happens to also require the same FMF, in which case it would need an amended White Glove Partner instruction.For earlier phases:If ROOM calls up to cancel a Sales Order:* If the booking is not yet in SALES ORDER SENT; the operator needs a button to "Cancel" it which puts it into a CANCELLED state, at which point it can then be flagged as 'closed' without any further actions* If the booking is already in SALES ORDER SENT; operator will need to speak to the warehouse to see if it's been Picked/ Packed already (if not obvious) - or indeed already released to the carrier! * If not already picked/packed, then we use the "Cancel" button as above. But because this is in SALES ORDER SENT status, the back end would additionally need to send a Sales Order Cancel WMS API call to the warehouse * If already picked/packed, then we'd need something in the front end to allow this fact to be confirmed by the SEKO Operator. Maybe a button to transition it from SALES ORDER SENT to PICKED/PACKED status. We probably might want to put this state transition in anyway, regardless of potential cancellations or amendments. (We are starting to get into Workflow Tasks manual management now anyway!) Then if cancellation occurs, the operator would click the "Cancel" button as above. But because this is now in PICKED/PACKED status, the back end would need to send a Hold stock API message to the WMS and then a Cancellation message * If already released to the carrier, then we'd need something in the front end to allow this fact to be confirmed by the SEKO Operator. Maybe a button to transition it from PICKED/PACKED to RELEASED status. We probably might want to put this state transition in anyway, regardless of potential cancellations or amendments. (We are starting to get into Workflow Tasks manual management now anyway!) Then if cancellation occurs, the operator would click the "Cancel" button as above. But because this is now in RELEASED status, there would be no messages sent to the WMS at all. It would now merely be in CANCELLED state and the SEKO operators would have to manually untangle stuff outside the system.If ROOM calls up to amend a Sales Order, then we may need to introduce the concept of making bookings editable in the front end. Alternatively we support API amendments early on, and detect when amendments occur, and process things differently as above depending what status the booking is currently in.