Returns Management¶
The modular design of Jumpmind Commerce allows the Returns Management Engine to run stand-alone or together with the full pos product. Our returns solution provides an out-of-the-box fraud prevention measure that gives you the control to determine how often and how many identified or unidentified returns your customers can make. Additionally, the returns engine has the ability to look up a customer’s purchase history, payment token, loyalty account, etc. so that their returns can be completed without a physical receipt in hand.
An integration with Appriss is also fully supported. This would allow your returns management to be controlled via Appriss.
Concepts¶
Return Types¶
Identified (Receipted) returns are ones driven off a historical transaction. Commerce allows a simple scan of a receipt, or search of customer history, to pinpoint and select what is being returned. Within this, the user can then scan the item, which will then allow for the return to be completed.
Unidentified (or Non-Receipted) returns are ones without a physical receipt or any successful search to tie to an original sales transaction. These returns typically result in a store credit refund as opposed to cash.
Reason Codes¶
Reason codes allow a user to classify a return which will help dictate that item's Disposition code
Disposition Codes¶
Disposition codes are what allows a store to know how to handle an item (re-stock, dispose, etc.), after a return is complete.
Taxes¶
With all return transactions, the system would properly process the taxes returned be based on the location of the original transaction and apply any new tax, at the proper rate, if any additional items are sold as part of the transaction.
The Returns Screen¶
| Item | Description |
|---|---|
| 1 | Customer making return. |
| 2 | Receipt from the original transaction where item(s) can be selected for return. |
| 3 | Item selected for return with details of original purchase date and reason for return. |
| 4 | The amount of sales tax for the returned item calculated from the location of the original transaction. |
| 5 | The total amount of the transaction being returned. |
Return Process¶
Configuration¶
Configuration for returns starts with setting up one or more return policies. A return policy is a set of parameters and rules a retailer establishes to govern how customers return merchandise and what tenders they can receive for that returned merchandise. Multiple return policies can be configured to handle different scenarios. For example, the retailer might have the following return policies:
- Identified (Receipted) returns for non-loyalty members
- Identified (Receipted) returns for loyalty members
- Identified (Receipted) returns for employees
- Unidentified (Non-Receipted) returns for non-loyalty members
- Unidentified (Non-Receipted) returns for loyalty members
- Unidentified (Non-Receipted) returns for employees
Each of the above return policies may have different parameters that can be set differently for each policy, such as return tender types allowed (original sale tender, merchandise credit, gift card, etc.), purchase timeframe (i.e. if purchased within the last 30 days or 60 days, etc.). Configuration by return policy is completed via the ReturnPolicyModel / sls_rtn_policy table. The following configurations are available:
ReturnPolicyModel (sls_rtn_policy)¶
| Attribute | Description |
|---|---|
| returnPolicyId | A unique identifier for the return policy |
| returnPolicyName | The name for the return policy |
| description | The description for the return policy |
| requiresAdditionalInfo | A flag (1 or 0) denoting whether the policy requires capturing additional customer information |
| exchangeAllowed | A flag (1 or 0) denoting whether the policy allows even exchanges |
| sameTenderTypeAllowed | A flag (1 or 0) denoting whether the policy allows for the original tender type to be used for tendering the return |
| differentTenderTypeAllowed | A flag (1 or 0) denoting whether the policy allows for different tender types thatn the original for tendering the return |
| merchCreditAllowed | A flag (1 or 0) denoting whether the policy allows for merch credit for tendering the return |
| permissionId | The required permission that the cashier must have in order to fullfil the return of an item. From USR_PERMISSION.PERMISSION_ID |
| rcptRtnTransCountLimit | The number of receipted return transactions allowed for a given customer during the transHistRefInDays period |
| nonRcptRtnTransCountLimit | The number of non-receipted return transactions allowed for a given customer during the transHistRefInDays period |
| rcptRtnItemCountLimit | The number of receipted return items allowed for a given customer during the transHistRefInDays period |
| nonRcptRtnItemCountLimit | The number of non-receipted return items allowed for a given customer during the transHistRefInDays period |
| RcptRtnRatioLimit | A ratio applied to receipted returns calculations that will override receipted returns limits. I.E. If .50, then if the customer sales history during transHistRefInDays has greater than 50% of items not returned, then the customer will continue to be allowed to return, regardless of the number of transactions or items returned |
| nonRcptRtnRatioLimit | A ratio applied to non-receipted returns calculations that will override receipted returns limits. I.E. If .50, then if the customer sales history during transHistRefInDays has greater than 50% of items not returned, then the customer will continue to be allowed to return, regardless of the number of transactions or items returned |
| transHistRefInDays | The number of days to look at customer history in order to determine returns rules and limits |
| overrideAllowed | A flag (1 or 0) that denotes whether this return policy is overridable by a manger level |
Example return policies might look as follows:
Once the return policy(s) have been configured, matching rules need to be configured that determine how an individual return transaction maps or matches to the return policy(s) configured above. These mapping / matching rules are configured in the ReturnPolicyMatchModel / sls_rtn_policy_match table. The following configurations for mapping / matching are available:
ReturnPolicyMatchModel (sls_rtn_policy_match)¶
| Attribute | Description |
|---|---|
| policyMatchId | A unique identifier for the returns policy match rule |
| policyMatchName | A name for the return policy match rule |
| description | A description for the return policy match rule |
| priority | A numerical order (sorted lowest to highest) in which the match rules should be applied to the return policy |
| returnPolicyId | The return policy to use if a match is made |
| receiptPresent | Whether this is an identified return. I.E. the original sale has been identified |
| numberOfDays | If the return is in the number of days window, consider the policy a match |
| purchaseStartTime | If a return should be applied based on purchase time, this field should be populated with the time the purchase was made |
| purchaseEndTime | If a return should be applied based on purchase time, this field should be populated with the time the purchase can no longer be returned |
| itemGroupId | Match on an item group. If the value is * then the policy applies to all item groups |
| customerGroupId | Match on a specific customer group. If the value is * then the policy applies to all customer groups |
For the example return policies described above, the following return policy match models would match a transaction to those return policies:
| Return Policy | Return Policy Match |
|---|---|
| Identified returns for non-loyalty members | receiptPresent=1,priority=20 |
| Identified returns for loyalty members | receiptPresent=1,customerGroupId='loyalty',priority=10 |
| Identified returns for employees | receiptPresent=1,customerGroupId='employee',priority=10 |
| Unidentified returns for non-loyalty members | receiptPresent=0,priority=20 |
| Unidentified returns for loyalty members | receiptPresent=0,customerGroupId='loyalty',priority=10 |
| Unidentified returns for employees | receiptPresent=1,customerGroupId='employee',priority=10 |
Once return policy(s) and matching rules have been configured, general tender type rules need to be set up to govern which tenders are available for returns as a whole. Note, this is NOT restricting return tenders by return policy, which is configured in the return policy itself, but instead, a list of available tenders types for return transactions as a whole including the minimum and maximum amounts permitted for each of those return tender types. This configuration is done in the TenderPolicyModel / sls_tender_policy_table
TenderPolicyModel (sls_tender_policy)¶
| Attribute | Description |
|---|---|
| tenderPolicyId | A unique string identifier for the tender policy |
| tenderTypeCode | The tender type code for the tender policy |
| tenderCode | Unique code to identify this tender |
| tenderOperation | The operation for the tender policy (e.g. SALE, RETURN, ZERO_BALANCE, or CHANGE_DUE) |
| minTenderAmount | The minimum amount that can be accepted for this tender and operation |
| maxTenderAmount | The maximum amount that can be accepted for this tender and operation |
| overTenderAllowed | Whether or not this tender require supports overpayment from the customer |
| defaultToAmountDue | Whether or not to default the tender amount to the amount due |
| paymentServiceRequired | Whether or not the payment service is required to process this tender |
| autoFocusEnabled | Whether or not the tender amount is auto focused for editing |
| buttonGroupId | The button group id associated with this tender type |
| buttonId | The button id associated with this tender type |
Example TenderPolicyModel configuration might look as follows:
Configuration that applies to all policies (yml, ConfigModel)¶
openpos.sell
| Parameter | Description | Default |
|---|---|---|
| displayReasonAndDispositionForReturns | Setting that indicates if the reason an item is returned and the disposition of the returned product should be shown | true |
| reasonAndDispositionForReturnsMaxLength | Setting that defines max length to truncate display values for reason and disposition of the returned product | 20 |
| confirmNonReceiptedWithCustomerLinked | Setting that determines if the 'Link Customer or Scan Receipt' dialog will still prompt on starting a non-receipted return even if a customer is already linked | false |
openpos.pay
| Parameter | Description | Default |
|---|---|---|
| preferReferencedReturns | If true, then during refunds supported payment providers will attempt to automatically process returns to the original card | true |
| referencedReturns.excludeCardType | An array of card types that don't support referenced returns | |
openpos.tender
| Parameter | Description | Default |
|---|---|---|
| hideReturnOptionBelowMinAmount | Determines whether return options below minimum tender amount is hidden vs disabled | false (disabled) |
| returnLessThanMinFallback | Tender type used to absorb the amount from other tenders where their suggested refund is below the minimum allowed | CASH |
| preferredNonReceiptedRefundTender | Tender type of the preferred method to refund non-receipted return value | STORE_CREDIT |
openpos.returns
| Parameter | Description | Default |
|---|---|---|
| crossBorder.allowed | ||
| useReturnsCustomer | ||
| useCaptureId | ||
| promptForAddCustomerOnCheckout | ||
| ... |