Returns

You use the Returns settings to configure criteria for return transactions. A return is a retail transaction in which a customer returns purchased merchandise to the store in exchange for another item or to receive a refund.

Types of Return Transactions

There are two transaction types for a return:

Return With Receipt
Return Without Receipt

Returns With Receipt

In a Return With Receipt transaction, the original transaction information such as the store number, register number, transaction number, and date is readily available on the receipt and can be quickly entered at the POS. An authorization request is issued simply to ensure that the items had not already been returned, and that correct prices have been entered for the items. If the information is deemed to be valid, the return is approved and the customer can be reimbursed or their merchandise exchanged.

Returns Without Receipt

Because sometimes customers do not have their original receipts, a Return Without Receipt requires additional information before the authorization request is approved. This information includes the prices of the return items to ensure that they are processed at the lowest price in effect during a specified time period. Customer identification information is also captured to allow a store to track how often customers return merchandise without a receipt. For more information about this, see “Velocity Checking Feature for Returns Without a Receipt.”

To configure a return policy for the POS, you will need to create a unique definition profile for each return transaction type.

How Returns Are Authorized

Return transactions require authorization to ensure that items being returned were not already returned, or to confirm the item price for the return transaction. Return transactions can be authorized through a local database, or through a centralized returns authorization component such as Returns Authorization.

In the local database scenario, original transaction information is retrieved from the store’s back office database. Only returns for the same store can be verified this way. In a centralized authorization component scenario, transaction information for all stores is available so a return for a purchase from another store can also be verified.

Note Note

This access to data from all stores is accomplished through a data feed process such as the Common Data Loading (CDL) which can load daily transaction data into the Returns Authorization component database, or through a real time trickle feed. For more information on the real time trickle process, see Setting Up Real Time Trickle for Transaction Records.

In the CDL data feed process, same day returns are processed differently than returns from previous days. For same day returns, the system first checks the transaction number to see if it belongs to the current day. Then, if the return transaction is determined to be valid, it is authorized. In the real time trickle process, the return is verified against the original transaction.

End of the note.

Procedure

Configuring a Return Transaction

To configure a return transaction, you must complete the following steps:

Create a return transaction definition profile according to the following specifications:
- For both Returns With Receipt and Returns Without Receipt, in Returns configuration, configure required options in each of the following screens in :
  - General section of the General tab page
  - Return Allowances tab page
  - Return Authorization tab page
- Configure tender details for the return transactions as required.
  - For Returns With Receipt do this on the Return Tender tab page in Tender configuration.
  - For Returns Without a Receipt, do this on the Return Authorization tab page in Returns configuration.
Create a user defined transaction (UDT) for each return type and link each UDT to its respective return transaction profile (as created in Step 1.) The definition for the Return Without Receipt will require an additional link to a prompt for customer information. To see how to define a prompt for customer information, see the example below.

Example

To process a Return Without Receipt transaction, you need to capture customer identification information. The following steps show how to configure a profile prompt to do this.

Note Note

These steps assume that a user defined transaction (UDT) definition which launches the Return Without Receipt function has already been created. For information about user defined transactions, see User Defined Transaction.

End of the note.

Create a profile prompt to capture an identification number such as a driver’s licence number. The following prefixes have been defined for the Returns Authorization component and are required in the profile prompt definition:
- IT— Identifies the type of ID such as driver’s licence or military ID
- ID — Identifies the number of the ID presented
- IS — Indicates the state when a driver’s licence is presented as the ID format.
  
  Note
  This prefix is optional for the Returns Authorization component.
  
  End of the note.
You may create additional prompts to capture other identification, as required.
In Choices configuration, create an option list with the acceptable types of identification for return transactions. Each option must be linked to a specific customer information profile prompt definition.

Note
For the Returns Authorization component, the values in the Data field must be numeric and must correspond to the ID types configured in the Returns Authorization application.

End of the note.
Create an overall profile prompt to capture customer ID when the Return Without Receipt transaction is launched. This prompt is linked to the UDT manager code that launches the Return Without Receipt function, and to the Choice List definition.

No prompt is required for a Return With Receipt.

Note
The Returns Authorization component requires the prefix IT in the prompt line input field.

End of the note.
Create a return transaction definition for each return transaction type with the following settings:
- On the General tab page, set the following options as required:
  - Allow Sale to Switch Back to Return
  - Allow Review of Authorized Prices
  - Customer Identification Profile
    
    Note
    This parameter is not required for a Return With Receipt transaction because that transaction can be easily located through the original receipt information. It is required for a Return Without Receipt.
    
    End of the note.
  - Customer Information Profile — This parameter may optionally be used to retain a customer's returns history for velocity threshold checks at a future time, or for other transaction information for both the Return With Receipt and the Return Without Receipt transactions.
- On the Return Allowances tab page, set the following options as required for Returns Without Receipt:
  
  Note
  Note these parameters will configure tender details for a Return Without Receipt only. For a Return With Receipt, tender options are configured in Tender configuration.
  
  End of the note.
  - Authorize Refund
  - Refund Service
  - Policy For Declined Receipts
  - Allow Override Decline
  - Refund to Original Tender
  - Auth Level to Override Orig Tender
- On the Other tab page, set the following options for Returns With Receipt, as required:
  
  Note
  These settings are not required for Returns Without Receipt.
  
  End of the note.
  - Maximum Number Of Transaction Receipts
  - Allow Receipts From Other Stores
  - Allow Receipts Not In Database
Set the following parameters in the POS.INI file:
- USEAUTOTENDERMENU
- AUTHREFUNDS
For more information on the POS.INI file , see the Technical Reference Guide.

Velocity Checking Feature for Returns Without a Receipt

If you want to track how many or how often customers return merchandise without a receipt, you can use the velocity checking feature in the Returns Authorization component. You do this by setting a limit for the maximum number of return transactions or for a maximum dollar value of returned merchandise. Then you define a prompt to capture a customer's identification when they request to return merchandise. The prompt launches a search for previous transactions made by this customer. Depending on your store's defined return policy, a request for further returns can be denied if a customer is found to have reached the maximum Returns Without Receipt threshold.