| Oracle® Retail Returns Management User Guide Release 14.1 E54473-01 |
|
 Previous |
 Next |
Oracle Retail Returns Management is a proactive, centralized, multi-channel solution that provides the retailer with the ability to reduce overall return rates, prevent and catch return fraud, and improve customer service.
For specific information, see the following sections:
|
Caution: The screens that are used for configuring policies and selecting customer and cashier exceptions to track are not designed for concurrent use by multiple users. Oracle Retail Returns Management does not provide any locking to prevent multiple users from making updates on the screens at the same time.For example, if two users are editing the same return policy, the changes that will be saved to the return policy are the changes that were saved last. |
The application is comprised of the following components:
Default return policies and multiple exception policies allow the retailer to centrally manage returns, using configurable rules that can be evaluated at the merchandise, customer, or location level to determine authorization. This provides quick adaptation to changes in business and seasonal conditions.
Defined XML messages sent from the point-of-return or other channel trigger action in Oracle Retail Returns Management and an appropriate response message. This enables Oracle Retail Returns Management to be rapidly integrated to work with existing store and channel systems.
An analytic engine checks return policies to evaluate the returnability of an item. Item returnability is calculated by examining the item, customer, associate, and store in question and then advising the point-of-return on the most appropriate path to take.
The exception file is a constantly evolving knowledge base for preventing fraudulent returns by tracking which shoppers and cashiers have made exceptions to the defined return policy and therefore are at a higher risk of fraud.
Return tickets act as a Customer Service Record (CSR) that enables inquiry and audit of the trail of return activity for a given customer, associate, item, or store. This enables the retailer to handle customer service inquiries into which steps may have been taken to prevent return fraud.
The Oracle Retail Returns Management client provides a web-based interface for Loss Prevention, IT, Store Operations, Call Center, and field personnel to configure and manage the returns process.
The point-of-return communicates with the centralized Oracle Retail Returns Management system through a series of XML messages:
Depending on the return steps that the point-of-return follows, the following actions may be performed by the cashier:
Select a matching transaction from multiple potential transactions or confirm a single matching transaction.
If receipted, enter or select the items for return from the transaction.
If the retailer uses a validation number on receipts as an additional proof of purchase in case the original transaction cannot be retrieved, the point-of-return may prompt for this validation number.
If nonreceipted, enter nonreceipted items for return.
Enter or select information such as the reason for the return.
Ask the customer for identification, if required.
The point-of-return sends the Authorize Items for Return request message to Oracle Retail Returns Management. The message contains details about whether each item attempted for return is from a particular original transaction or is nonreceipted, information about the original transaction if provided, the reason for return, customer positive ID, and other details.
Oracle Retail Returns Management creates a return ticket to track the activity of this return attempt.
The Oracle Retail Returns Management analytic engine evaluates the contents of the Authorize Items for Return request message to determine the returnability of the items to the customer, using the following information:
The return policies defined by the retailer, including the configured response codes, receipt messages, tenders, and customer positive ID capture settings.
The return pattern watch file that looks for periodic purchase and return patterns for high risk items.
The customer exception file that accumulates return history for the customer, based on their positive ID.
The cashier exception file that accumulates return history for the cashier, based on the cashier ID.
The record of whether a customer service override is available for this particular customer positive ID.
The record of the customer type assigned to this customer.
Customer type is used to group customers by loyalty status, return history, or other types. It is sent from the point-of-sale, parameterized by Oracle Retail Returns Management, and used with the What is the Customer Type rule.
Oracle Retail Returns Management forms and sends the Authorize Items for Return response message back to the point-of-return. The message includes an approval, contingent authorization, manager overrideable denial, or denial response, a response code, a response description, receipt messages, and tender designations, each by line item and overall for the return:
If Oracle Retail Returns Management encountered a policy rule that required a check of the customer's return history via the positive ID, and a positive ID was not provided, the point-of-return may prompt to collect the positive ID information and send another Authorize Items for Return request message to Oracle Retail Returns Management once the information is collected, so that customer history may be checked.
The point-of-return consumes the contents of the response message and presents appropriate screens or tender options. If any manager overrides are required, the point-of-return is responsible for gathering the appropriate manager authorizations to proceed.
After the transaction is tendered, if necessary, and completed, the point-of-return sends a Return Final Result message to Oracle Retail Returns Management, to log the ultimate resolution of the return attempt and the tenders that were used.
When a customer tries to return an item, the retailer might want to consider these and other questions:
Does the customer have a receipt?
What is the condition of the item?
How many days have passed since the item was purchased?
What is the customer's cumulative exception count?
Does the customer have a gift receipt?
Was the transaction a split tender?
In Oracle Retail Returns Management, these questions are called rules. The retailer determines what action to take based on the answers to the questions:
Continue processing the return, stop and require a manager override, or deny the return.
Send particular response codes or receipt messages that inform the cashier, manager, or customer of the returnability of the return.
Limit the refund to certain types of tenders depending on the answer to the question.
Require that a positive ID is obtained from the customer so that the customer's previous return history can be checked for similar situations and so that this and subsequent return activity can be tracked.
All of these settings are configured on the response to the rule.
A collection of rules used to determine the returnability of a line item to a customer is called a policy. The two types of policies that exist are default and exception.
Default policies cover all return situations that are not specifically defined by an exception policy. Default policies are always in effect. If Oracle Retail Returns Management does not find a specific exception policy that covers a situation, the analytic engine falls back to the appropriate default policy.
Two default policies must be defined, one for receipted situations and one for nonreceipted situations.
The retailer must decide what constitutes a receipted situation versus a nonreceipted situation, so that the receipted/nonreceipted flag can be sent in the Authorize Items for Return request message.
For instance, if the customer does not have a paper receipt for a transaction, but the transaction can be retrieved by search, the retailer may choose to treat this as a receipted return attempt.
Retailers usually treat returns using gift receipts as receipted return attempts.
If the retailer accepts item returns without a paper receipt or other proof of purchase, this is most often processed as a nonreceipted situation.
Each line item attempted for return is considered separately as receipted or nonreceipted, so that the retailer can mix different return situations within one return attempt, if the point-of-return allows this.
Exception policies can be defined to cover either items that must be processed differently than normal, or stores for which special policies are in effect. Exception policies are assigned to a combination of the following:
A location, by node of the store reporting hierarchy, store group, or store number
An item, by item number or merchandise hierarchy group
Exception policies might be defined for articles of clothing that cannot be returned under any condition. They might also be assigned to certain stores that need a more stringent return policy because of previous abuses, such as stores in areas that encounter significant problems with short-term returns when the original tender was a check, prior to the check clearing the bank.
Exception policies can have effective and expiration dates, unlike default policies that are always in effect. Therefore, exception policies may be defined to be used instead of the default policies on certain dates such as holiday seasons.
If the system does not find an exception policy that applies to the attempted return of a line item, the system falls back to the appropriate default receipted or nonreceipted policy to evaluate returnability.
Each exception policy is also designated as covering receipted or nonreceipted situations.
When the return of a line item is attempted at a point-of-return, the system determines the appropriate policy to apply, based on the item attempted for return, its receipted/nonreceipted flag, the store where the return is being performed, and the date on which the return attempt is occurring.
The item designation supersedes the store designation in the case where two policies might tie.
If no exception policy is in effect that applies to that item, store, and return date, Oracle Retail Returns Management falls back to the appropriate default policy (receipted or nonreceipted).
When the returnability has been determined, based on the appropriate policy, the system checks for any other items that the customer is attempting to return at that time. When the responses have been determined for all items in the attempted return, the system sends the Authorize Items for Return response message with the results of the evaluation of the attempted return.
For the following examples, these store and item assignments are used.
Sample store hierarchy definition:
Texas contains the store reporting hierarchy nodes of Austin and Dallas (cities).
Each node has specific stores, including store 01291 for Dallas.
Sample merchandise hierarchy definition:
Kitchen Appliances >> Stoves and Ranges >> Gas Ranges
Gas Ranges includes item 123456: Gas Cooking Range
Example 1
Exception policy 1 applies to:
Store hierarchy node or store: Texas node of the store hierarchy and
Merchandise hierarchy or item: Item 123456 (Gas Cooking Range)
Exception policy 2 applies to:
Store hierarchy node or store: Store 01291 and
Merchandise hierarchy or item: Kitchen Appliances
Customer returns item 123456 in store 01291.
Exception policy 1 would be used to evaluate the return of this line item because exception policy 1 is more specifically defined on the item, as opposed to exception policy 2, which is defined on the merchandise hierarchy node in which that item is included.
Example 2
Exception policy 1 applies to:
Store hierarchy node or store: Dallas node of the store hierarchy and
Merchandise hierarchy or item: Kitchen Appliances (Gas Cooking Range)
Exception policy 2 applies to:
Store hierarchy node or store: All Stores (top level of the store hierarchy) and
Merchandise hierarchy or item: Kitchen Appliances
Customer returns item 123456 in store 01291.
Exception policy 1 would be used to evaluate the return of this line item, because the items tie but the Dallas node of the hierarchy is more specific than the All Stores top level of the store hierarchy.
The return pattern watch file enables the retailer to define patterns of purchase and return dates for items in order to look for instances where customers are consistently returning items after short-term use. For example, a retailer who sells televisions may wish to define television items that are purchased shortly before sporting event weekends and returned immediately after the weekend as a suspicious return pattern for watch. A retailer who sells formal dresses may wish to define junior formals that are purchased shortly before prom season and returned immediately after prom season as a suspicious return pattern for watch. This type of behavior is often known as renting or wardrobing.
When a customer positive ID is collected with a return transaction and an item is returned that falls within the return pattern watch file items and dates, the system can track the behavior. Rules can be included in return policies to watch for this behavior and render a desired response such as denial or require a manager override.
Since this type of behavior is a pattern over a long period of time, even as long as a number of years worth of time, it is recommended that the retailer retain this exception data so that Oracle Retail Returns Management can effectively evaluate customer exception history.
The customer exception file is a collection of tables that hold the history of customer return activities, such as the occurrence of nonreceipted returns, the occurrence of return pattern watch returns, and the cumulative number of return activities.
The retailer selects the customer exceptions that they wish to track. Selection of a customer exception to track causes that type of return activity to be stored for research in Oracle Retail Returns Management.
Rules can be included in return policies that look for a particular type of return activity. These rules can be included in return policies whether or not the exception has been selected for tracking; however, the retailer loses the ability to see the historical occurrences of the return activity if the exception is not selected for tracking, although the return ticket is still available for view.
The customer's return activity is tracked based on the customer's positive ID.
Positive ID, also known as personal ID, is used as the unique identifier for a customer, for purposes of evaluating the customer's prior return activity. Since positive IDs are issued by state or government agencies, the positive ID is generally reliable as a unique identifier of a retailer's customer.
The positive ID may be of any type that the retailer accepts as definitive proof of identity, such as a driver's license, military ID, passport, or state ID. Some retailers may also choose to accept student IDs, green cards, picture IDs such as credit cards that have a picture image, or other forms of identification as a positive ID.
The positive ID must consist of a type, an issuer such as the state or country, and a unique number. Effective and expiration dates are optionally captured with the positive ID information.
Returns may be processed without collection of a positive ID; however, the customer's prior return activity cannot be verified without provision of a positive ID. An indicator can be set on a policy rule response that indicates whether a positive ID is required in order to check the rule, and the rule cannot be evaluated unless the positive ID is obtained. In this case, an additional roundtrip to Oracle Retail Returns Management may be made, for another evaluation once the customer positive ID is obtained.
If the rule What is the customer's cumulative count? is included in the retailer's policies to evaluate a customer's cumulative exceptions, and the customer feels they have earned an unjust cumulative count, an authorized Oracle Retail Returns Management user can freeze or reset the cumulative count. The cumulative count stays at the count until the entered date, or resets to the entered cumulative count.
If a customer feels unjustly denied an attempted return, such as in the case where a customer's positive ID has been stolen from them, an Oracle Retail Returns Management user can grant the customer a customer service override.
Retailers can choose to print receipt messages on returns describing why line items are approved or denied for return. In the event that a return is denied, the retailer may wish to include the phone number for the customer service department, so that the customer can call for more information on why the return was denied.
Customer service users can be given access to research a customer's return activity based on the customer's positive ID, and also to issue a customer service override on the customer's behalf. A customer service override grants the next denied return attempt, by that customer's positive ID, an automatic approval of all line items on that return. Once the return is completed, the customer service override is no longer available for use.
Customer service overrides have an expiration date that is configured by a parameter to be a number of days from the date the override was entered. The number of customer service overrides issued to each customer can be controlled by a parameter as well.
Like the customer exception file that tracks prior customer return activity, the cashier exception file tracks cashier return activity using the cashier's unique ID. The cashier exception file is a collection of tables that hold the history of cashiers' activities on return transactions, such as the occurrence of nonreceipted returns and the cumulative number of return activities.
The retailer selects the cashier exceptions to be tracked. Selection of a cashier exception to track causes that type of return activity to be stored for research in Oracle Retail Returns Management.
Depending on the retailer's published policies, point-of-return capabilities, and customer service considerations, the retailer may wish to allow a mix of line item approvals and denials within a particular return attempt, or may wish to approve or deny the complete return. The rules engine and messages accommodate both scenarios by providing a response at each line item level and a worst response at the whole transaction level. The worst response is selected based on the worst response code at the line item levels. The retailer can choose to use either level of response at their point-of-return when implementing Oracle Retail Returns Management.
Multiple points of offline processing could occur in the communication between a point-of-return and Oracle Retail Returns Management. Table 2-1 describes possible solutions to handle offline situations. Your solutions architects can also provide specifics on how offline situations are handled in your implementation.
Table 2-1 Possible Offline Processing Situations
| Offline Situations | Return Handling |
|---|---|
|
These situations involve the Authorize Items for Return request and Authorize Items for Return request response messages:
|
The point-of-return could have the ability to use any current checks for returnability, or accept the return as is. When Oracle Retail Returns Management receives an Authorize Items for Return request message, the system creates a return ticket, no matter the send success of further messages, so that the information is available for online research. Exceptions are not recorded unless a final result is received to tell Oracle Retail Returns Management of the ultimate resolution of the return attempt. Even if no Authorize Items for Return request is received in Oracle Retail Returns Management, if a final result message is received then a return ticket is created and the information is available for online research and exception tracking. |
|
These situations involve the final result:
|
Exceptions are only recorded when a final result is received to tell Oracle Retail Returns Management of the ultimate resolution of the return attempt. If an Authorize Items for Return request is received, but a final result is not, then a return ticket exists for online research but no exceptions are recorded for the customer or cashier. |
If a return ticket needs to be voided because the return transaction at the point-of-return was voided, the system receives notice of the void through the final result message. Any exceptions recorded for that customer and cashier are reversed, and the return ticket shows as voided on the return ticket screen.
