Handover

This article focuses on the handover process for developers. For information on the handovers in the store operations process, see the Handoverarticle in the Operations appsection.

A handover job represents the handover of an order to the end consumer or shipping provider.

Despite general information like the order date, tenant order ID or a reference to the corresponding facility, a handover job carries handover relevant information. This covers:

• Handover channel:

  • Delivery: will be handed over to a shipping service provider

  • Pick up: will it be handed over to the end customer

• Handover job cancel reason: Can be defined if the parcel(s) weren't handed over

A handover job is automatically created when:

• A parcel has changed to status FINISHED while the related pick job was in status CLOSED

• A pick job has changed to status CLOSED and there is at least one parcel of the related shipment that is in status FINISHED

Automatic versus manual handover job completion

A handover job is completed (set to status HANDED_OVER) automatically when a track-and-trace event is received from a carrier with track-and-trace enabled (if a carrier integration is in place).

It's possible to manually set a handover job to status HANDED_OVER, which triggers the handover event even before the carrier has physically scanned or picked up the parcel. In this case, the information from the handover job, such as items and quantities, is used to mark all associated line items as handed over. This ensures that line item quantities are passed correctly.

Currently, it's not possible to restrict the manual action based on user roles or permissions. As a result, users can manually trigger a handover event even before the carrier picked up the parcel.

Handover configuration

Handover refuse reasons

Reasons why customers have rejected the order on handover can be stored in the handover configuration. They are called "refused reasons".

When handing over the products to the customer or delivery service there is a chance that the customer refuses the products. In that case, the refused products can be marked with a reason why the products were not accepted. The list of available reasons can be set up in different languages.

Localization for reasons

The response has a refusedReason field that contains one of the locales provided by refusedReasonLocalized object. Which exact translation was chosen depends on the locale set in the authorization token when sending the request to the GET endpoint.

If no locale was provided by the client or the locale is not available in the refusedReasonLocalized object, the answer will default to the tenant locale. If the tenant locale is also not available in the refusedReasonLocalized object, then the first key-value pair will be selected.