Resolving Problems after Checkout

Problems described below in this chapter can be resolved after verification by Employee Hub or a client. The problems can be resolved before the checkout is processed or optionally after the checkout is processed.

To be able to resolve problems after checkout, the checkout process must be called with allowToResolveProblemsAfterCheckout = true. If the basket contains critical problems, the basket transaction is directly suspended in the checkout process and the problems must be solved on the Self Checkout. If the basket contains non-critical problems only, the checkoutStatus is set to PENDING_WITH_PROBLEMS in the checkout process. In this case, it is possible to resolve the problems.

It is configurable per clientType which problems are not allowed for the PENDING_WITH_PROBLEMS checkoutStatus. If the basket contains such a disallowed problem, it is suspended directly by the checkout process.

After the last problem is resolved, the checkoutStatus is automatically changed from PENDING_WITH_PROBLEMS to READY_TO_PAY and the basket can be paid by the Payment Service.

Resolve Age Restriction

If an item with an age restriction is registered, the problems SALES_RESTRICTION_ID and SALES_RESTRICTION_VALUE are created on the line item, with the minimum required age. The Basket Service provides the possibility to resolve this age restriction via the RESOLVE_AGE_RESTRICTIONS action. For example: The Employee Hub provides the option to verify the age of the customer.

The customer age is provided to the Basket Service. The Basket Service checks all age-restricted items in the basket and removes the problems if the customer is old enough. The customer age is stored on the basket so that any following items with an age restriction can be checked automatically during the registration.

Resolve Sales Restriction

The item can have another sales restriction besides the age restriction, e.g. restriction of quantity (example - a customer can buy max. 6 packages of toilet paper) or sales info (e.g. theft protection has to be removed). Sales restrictions are maintained in master data. For the sales restrictions, it is defined whether it is allowed to register such an item if the condition is not met or whether the registration is allowed but must be confirmed.

For these sales restrictions, the SALES_RESTRICTION_ID problem is stored on the transaction level or the item level. No SALES_RESTRICTION_VALUE problem is created in this case (in comparison to age restrictions).

Sales restrictions can be resolved by calling the following endpoint on the Checkout Service:

POST /baskets/{basketId}/resolve-sales-restriction

Resolve Problems with External Transactions

If there are problems during the registration of an empties/scale transaction (e.g. transaction is not found), a corresponding problem is created on the basket. The following problems may occur:

  • EMPT_NOT_FOUND
  • EMPT_REDEEMED
  • EMPT_OFFLINE
  • EMPT_DIFF_STORE
  • EMPT_MAX_AMOUNT_EXCEEDED
  • EMPT_LOW_CUSTOMER_CONFIDENCE
  • SCAL_NOT_FOUND
  • SCAL_REDEEMED
  • SCAL_OFFLINE
  • SCAL_LOW_CUSTOMER_CONFIDENCE

See the description of these problems in the Basket Service API.

The Basket Service provides the RESOLVE_EXTERNAL_TX action which can be used to decide if the external transaction should be kept on the transaction or removed.

Resolve Partial Rescan

The checkout process checks under certain conditions if a rescan is needed for the basket transaction. If so, the RESCAN_TYPE problem is created on the basket with the value partialRescan or fullRescan. If the checkout process was called with allowToResolveProblemsAfterCheckout = true, it is possible to resolve the partial rescan problem. An application (typically in Employee Hub) scans the required number of items and sends the result to the Checkout Service via the following endpoint:

POST /baskets/{basketId}/resolve-partial-rescan

The results of the partial rescan are stored in the basket transaction.

If the partial rescan was successful, the problem is resolved. If there is no other problem, the checkoutStatus is changed to READY_TO_PAY and the transaction can be paid.

If the partial rescan was not successful, it means the rescan was processed with a difference, the basket transaction is suspended, and it must be processed on a POS.

Suspend Basket Transaction

If the customer would like to finish the basket transaction on the (SCO) POS (e.g. because of cash payment) or there is a basket problem which cannot be solved (e.g. no employee available or no option to resolve the particular problem), the Checkout Service provides the option to suspend the transaction via the following endpoint:

POST /baskets/{basketId}/suspend

It is possible to call this endpoint either before the checkout is processed or after the checkout when the checkoutStatus is PENDING_WITH_PROBLEMS or READY_TO_PAY.

Resolve Low Confidence

In the GK GO product, items can be registered with a certain confidence level. The confidence level is provided by an external system which uses cameras and sensors to recognize which item was taken by which customer. If the confidence level is too low, the following problems are stored on the basket:

  • LOW_ITEM_CONFIDENCE
  • LOW_CUSTOMER_CONFIDENCE
  • LOW_ITEM_CONFIDENCE_QTY_DECREASED
  • LOW_CUSTOMER_CONFIDENCE_QTY_DECREASED
  • EMPT_LOW_CUSTOMER_CONFIDENCE
  • SCAL_LOW_CUSTOMER_CONFIDENCE

The Checkout Service provides the option to resolve the problems via the following endpoints:

POST /baskets/{basketId}/line-items/{lineItemKey}/resolve-low-confidence
POST /baskets/{basketId}/resolve-low-confidence