...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
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)
...
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:
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
Current Task Status | On Client Booking API Cancellation | On Client Booking API Amendment |
|---|---|---|
CREATED REPLANNING (task has yet to be confirmed as planned) |
When Operator Cancels the booking:
|
When Operator selects to re-plan:
|
ASN PENDING (Transfer Order only) |
When Operator Cancels the booking:
|
When Operator selects to re-plan:
Then when planning has been completed/ confirmed:
|
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:
ASN SENT |
When Operator Cancels the booking:
|
When Operator selects to re-plan:
Then when planning has been completed/ confirmed:
|
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) |
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 the booking:
|
When Operator selects to re-plan:
|
CARRIER INSTRUCTED |
When Operator Cancels the booking:
|
When Operator selects to re-plan:
Then when planning has been completed/ confirmed:
|
CARRIER ACCEPTED |
When Operator selects to re-plan:
When Operator Cancels the booking:
| |
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
...
|
When Operator selects to re-plan:
Then when planning has been completed/ confirmed:
| |
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. | |
Pick Pack & Release
See https://bigdigit.atlassian.net/wiki/spaces/SMH/pages/3251601441/Standard+Tasks+within+a+Workflow#Pick%2C-Pack-%26-Release. The following table shows the ideal processing that would need to occur depending on the possible statuses of this task when any Sales Order booking is Cancelled or Amended but it has a workflow which includes any Pick Pack & Release task:
Task Status | On Client Booking API Cancellation | On Client Booking API Amendment |
|---|---|---|
CREATED REPLANNING (task has yet to be confirmed as planned) |
When Operator Cancels the booking:
|
|
WAREHOUSE INSTRUCTED |
When Operator Cancels the booking:
|
When Operator selects to re-plan:
Then when planning has been completed/ confirmed:
|
PICKED & PACKED |
When Operator Cancels the booking:
|
When Operator selects to re-plan:
Then when planning has been completed/ confirmed:
|
PICK PACK NOTIFICATION SENT (to Carrier) | We need to re-think Pick/Pack Notifications in the context of Carrier Instructions which contain multiple consolidated goods from multiple Sales Orders | |
GOODS RELEASED | 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. 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. | |
White Glove Partner Instruction
See https://bigdigit.atlassian.net/wiki/spaces/SMH/pages/3251601441/Standard+Tasks+within+a+Workflow#White-Glove-Partner-Instruction state diagram. A similar analysis to the Transit Task above, in respect of White Glove Partner consolidations, will need to be carried out, in order determine what the system needs to do when Sales Order Cancellations / Amendments are received via the Booking API.
There may also need to be changes to https://bigdigit.atlassian.net/wiki/spaces/SMH/pages/3251601441/Standard+Tasks+within+a+Workflow#End-Customer-Schedule task when Sales Orders are cancelled or amended.