Return policies and validations

Clear and concise return policies improve customer satisfaction and makes the return process more convenient. Return policies are defined by enterprise.

If a customer returns an item to the store, the item is validated against the return policies. The return validations prevent fraud and enable a smooth return transaction. On completing the return validations, the customer is refunded through the appropriate payment method.

Returns validations

Validations for returns processing belong to the Returns domain. Returns validations contain a detection mechanism to determine whether to run the override rules for the validation. If an override rules configured for the validation fails, it might result in a violation that requires manager approval.

Note:

Following are the validations for return processing:

  • Is Returnable: Identifies an item as returnable/non-returnable.
  • Return Window: Specifies the duration or time period within which an item can be returned.
  • Return Reason: Specifies reason codes for returning an item.
  • Unit Price Limit: States the unit refund value for an item in an order line.
  • Blind Line: Specifies whether a blind line in a return order is accepted or rejected.

Validate returnable item

This validation is used to check whether the item that is being returned by the customer is returnable.

If the item is configured as non-returnable and if the validation fails, checkOverrideRule API is called to run override rules and to detect violations.

Validate return window

This validation checks if the sales orders to be associated with the return lines are within the return window range.

All sales orders that match the search criteria specified on the return order are fetched. These sales orders are filtered based on the return window range present on the Item details.

For this validation, the item entity is enhanced to add the following attributes:

MinReturnWindow: Defines the minimum duration within which an item can be returned.

MaxReturnWindow: Defines the maximum duration within which an item can be returned.

The detection rules for this validation are based on the Customer Level and a corresponding Return Window that is defined by the enterprise.

For example, the detection rules can be defined as follows:
  • For CustomerLevel “GOLD," the ReturnWindow is 20 Days.
  • For CustomerLevel “PLATINUM,” the ReturnWindow is 30 Days.
  • For CustomerLevel “DIAMOND,” the ReturnWindow is 40 Days.
  • For CustomerLevel “XYZ,” the ReturnWindow is 15 Days.

The detection mechanism that is supplied for this validation has a predefined Greex rule that is based on the CustomerLevel and ReturnWindow attributes. If the detection mechanism determines that override rules need to be run, checkOverridenRule API is called to run the configured override rules and to detect violations.

Validate return reason code

This validation is used to check the return reason of the item that is being returned.

If the return reason code matches the return reason on the return order, the detection mechanism determines whether override rules need to be run. If override rules are configured for the item, checkOverridenRule API is called to run override rules and to detect violations.

For example, the detection mechanism can be as follows:
  • ReturnReason is “OPENBOX”
  • ReturnReason is “DAMAGED”

Validate unit price

This validation is used to check whether the value of the item that is being returned is lesser or higher than the base refund amount. The base refund amount is the minimum refund amount that is defined for an item and can be refunded to the customer without any approval.

In this validation, the base refund amount is the detection mechanism. If the base refund amount is higher than the defined refund amount, checkOverridenRuleAPI is called to run override rules and to detect violations.

This validation is used for a scenario where high value items are returned only by manager override.

Example of the detection mechanism is as follows:
  • LineTotal is greater than $100.

Validate blind line

Based on the order search criteria, return orders are associated with sales orders. In some cases, there might be return lines that remain unassociated to any sales order. These return lines are called blind lines. Blind lines are created in many scenarios, such as:
  • Over return of quantity by the customer
  • Receipt not included with the return
  • Fraud

Blind line validation is used to accept or reject blind return lines. The detection mechanism for this validation is internal.

If blind lines exist for an order and if override rules are configured for this validation, checkOverridenRule API is called to run the override rules and to detect violations.

Other validations are based on whether the return line is blind or not. For example, the Return Reason validation has the following override rules:
  • IsBlindLine is “Y” and CustomerLevel is “DIAMOND ” then accept ReturnReason “DAMAGED."
  • IsBlindLine is “Y” and CustomerLevel is “” then don’t accept ReturnReason “OPENBOX."