• GoodsOut
  • Cancellation requests
    • By goods-out staff (GOS)
    • From higher-level business process (HLP)
    • Cancellation workflow/logic:
    • Life-cycle / Active

GoodsOut

Cancellation requests

The cancellation of a goods-out can be desired by different actors for various reasons.

By goods-out staff (GOS)

There are various reasons why the person asked to process the goods-out may want it to get canceled. For example, there may not be enough stock to pick or packaging material. There may not be enough space or time to perform the picking and packing. There may be some power outage. Some machine needed (e.g., a label printer, a pallet jack) may be broken or otherwise not available.

As long as the GoodsOut is still unconfirmed, the goods-out staff could simply reject it. But once it has been confirmed, that is no longer possible. And simply canceling the GoodsOut from the "processing side" is not allowed as goods-out are "depending business processes" and thus their cancellation must be controlled via their "parent process".

From higher-level business process (HLP)

A high-level business process that is parent of one or more goods-out may want those to get canceled because it may be canceled itself or because the existing goods-out are not needed/wanted anymore. For example when a different location shall perform the goods-out or when a delivery is to be split.

As long as the GoodsOut is not yet "in process", it could simply be canceled as the parent process has the right to do so. But when picking has already started, this would cause a problem with the picked stock. The goods-out staff has picked things and they are not "in stock" anymore. Automatically booking them back to "in stock" would not cause them to actually move "in the real world". The goods-out staff would also not really get any notification, "his" GoodsOut would simply not be shown in the UI anymore.

Cancellation workflow/logic:

Thus, the following workflow/logic should be used when requesting and performing cancellations:

• GOS wants to cancel

  • GOS issues request describing the wish to cancel
  • HLP accepts or rejects the request
  • If rejected
    • Workflow is finished
  • If accepted and GoodsOut is still UNCONFIRMED or CONFIRMED
    • GoodsOut can directly get canceled, "accept" can be sent as secondary+before to "cancel"
  • If accepted and GoodsOut is already IN_PROCESS
    • GOS must trigger cancellation by executing "performFullCancellation"

• HLP wants to cancel

  • HLP issues request describing the need/wish to cancel
  • GOS accepts the request
    • We may want to allow GOS to reject, but that would need some kind of setting or user right that allows this.
  • If rejected (once we allow this)
    • Workflow is finished
  • If accepted and GoodsOut is still UNCONFIRMED or CONFIRMED
    • GoodsOut can directly get canceled, "accept" can be sent as secondary+before to "cancel"
  • If accepted and GoodsOut is already IN_PROCESS
    • GoodsOut can get canceled, "accept" can be set as part of "performFullCancellation"

Life-cycle / Active

A cancellation request has a simple life cycle consisting of the states REQUESTED, ACCEPTED, REJECTED and WITHDRAWN.

Additionally, it has a cancellation_performed flag. This flag is not a state as it does not represent a property of the request but of the goods-out.

Requests are considered to be "active" when they are in state PENDING or ACCEPTED and their cancellation_performed flag is false.