Overview: Use the Returns/Refunds page to review information related to the returns, exchanges, and refunds associated with an order. In addition, this page displays whether an overpayment or balance due exists on the order.
How to display: Select the Returns/Refunds option on the Order Summary, Order Activity, Order Messages, Customer Messages, or Invoices page.
When you first advance to this page, return and refund activity displays in chronological order, with the most recent activity at the top of the page.
In this topic:
• Refunds
• Functions that Produce Refunds
• Create the Return Authorization
• Receive the Returned Merchandise into the Warehouse
• Credit the Customer for the Return
• Credit Card Net Exchange Billing
For more information:
• Returns/Refunds Options for step-by-step instructions on the actions you can perform on the Returns/Refunds page.
• Fields on Returns/Refunds for a description of the fields on the Returns/Refunds page.
Purpose: The system creates a refund any time there is a difference between the order total and the payment.
Refunds occur when:
• The customer returns an item.
• You cancel all or part of a prepaid order at the customer's request.
• You cancel all or part of a prepaid order because the merchandise is sold out.
• The system cancels all or part of a prepaid order through the Automatic Backorder Cancellation program.
• You cancel part of an order when the customer has already paid the entire freight amount.
• The customer's initial payment exceeds the total cost of the order (overpayment).
• The customer pays less than the order total (underpayment).
Note: The system will never generate a refund for an order if you cancel an item on the order with a cancel reason whose Generate Refund? field is set to 3 Do Not Generate a Refund.
There are several types of refunds:
• Checks (K) = A refund check can be cut for the exact amount of the refund.
• Credit Card Credits (C) = In addition to crediting the customer's credit card account, you can issue a credit card credit acknowledgment using the Process Refunds (MREF) menu option.
• Stored Value Card Credits (V) = The system generates a new gift card for the refund amount; the customer can use this gift card credit towards a new order.
The system generates a refund type that corresponds to the way the customer paid for the merchandise. For example, if the customer paid using a Visa card, the system generates a credit card credit. However, you can control how the money is refunded by defining an alternative refund type in the Pay Type table. You can also change the refund type by defining an alternate refund category.
How Pay Type Determines Refund Type
The pay type that a customer uses on an order determines the type of refund received, depending on how you have defined the pay type.
When you create a pay type, you must assign it to one of five payment categories. Each payment category automatically produces a certain refund type, as follows.
• Payment Category Cash/Check (1) produces Refund Type Check
• Payment Category Credit Card (2) produces Refund Type Credit Card Credit
Alternate Refund Type
When you define an alternate refund type for a pay type, the system automatically generates refunds of the alternate refund type.
The system accepts only gift card or cash/check alternate refund types.
Alternate Refund Category
When you define an alternate refund category for a pay type, you give yourself the option of changing the refund to the type that corresponds to this category.
The system accepts only cash/check alternate refund categories. However, you can change any type of refund to a gift card credit at the Change Refund Screen in the Work with Refunds (WREF) menu option.
Functions that Produce Refunds
Refunds are created from:
• Order entry (or order async): overpayment due to a sold out item or an initial amount more than what is owed (overpayment) or less than what is owed (underpayment)
• Order maintenance (returns or billing cancellations)
• Return authorization process (credit returns)
• Billing (automatic backorder cancellation)
• Auto Soldouts (auto soldouts program)
The system assigns each refund a reason code. These codes are:
• A Auto Cancel Backorders = This reason applies when a backorder item exists on an order and you process automatic backorder cancellations.
• B Balance Due = This reason applies when an order has an unpaid balance.
• O Overpayment = This reason applies when a customer pays more than the order total, when the customer cancels a prepaid item or order, or when an item on a prepaid order is sold out.
• R Return = This reason applies when a customer returns one or more items using a return authorization.
• S Soldout = This reason applies when a soldout item exists on an order and you process automatic soldout cancellations.
The system can hold a refund automatically or you can place them on hold.
Automatic holds occur when:
• The refund check amount is less than the minimum or more than the maximum amount specified in the Pay Type table; you can define these amounts in the Work with Pay Types (WPAY) menu option.
• The refund release days have not elapsed (this is used to hold refunds for an order paid by check until the check has cleared).
• The order that includes the refund is on hold.
• The cancel reason you used to cancel any item on the order had the Generate refund? field set to 2.
• The refund is associated with Credit Card Net Exchange Billing.
You can also place a refund on hold manually through the Work with Refunds (WREF) menu option; for example, if you suspect a fraudulent customer.
You can release refunds that are on hold. Releasing refunds from hold, however, does not mean that they will be processed if the order is on hold.
The system releases the refund automatically when the order hold is released or the refund release days pass. However, if the refund is on hold because it is more than the maximum for the pay type or because you put it on hold manually, you must release it through the Work with Refunds (WREF) menu option.
When the amount of a refund is less than the minimum defined for the pay type, the system marks the refund to be written off. The refund will be written off the next time you process refunds unless you change the status (for example, to generate a refund check because the customer requests it).
You can also change the status of a refund to “writeoff pending” through the Work with Refunds (WREF) menu option regardless of the refund amount (for example, if you have tried and failed to collect a balance due).
Writeoff Updates
When you write off a refund amount the system updates the customer record with the writeoff amount. The writeoff balance accumulates for the customer. You can apply the balance to a new order as a payment if it is a positive amount or as an additional charge if it is a negative amount.
You can cancel a refund through the Work with Refunds (WREF) menu option if the refund was created by mistake or the customer is a fraud.
Follow the guidelines below when you are working with refunds.
1. Print the Refund Due List.
2. Review the refunds that are ready for processing.
3. Check the order status and determine which held orders you want to release.
4. Determine which refunds you want to release from hold.
5. Use the Work with Refunds screen in the Work with Refunds (WREF) menu option to research refunds, to release, hold, cancel or writeoff a refund, or to change the type of refund to issue.
6. Reprint the Refund Due List so that you have a record of the changes you make to the refunds and to verify that you changed the refunds correctly.
7. Process refunds and writeoffs using the Process Refunds (MREF) menu option.
8. Reconcile checks you receive from the bank or void them as needed, and purge refund checks once reconciliation is complete using the Reconciling Checks (MREC) menu option.
If you have a problem printing the refund checks, you can reprint them with the Reprint Refunds Screen (MREP).
Whenever the system creates a refund record, it associates the refund with a bank code. The system determines the bank code as follows:
• When you created the source code used on the order header, you specified a division.
• When you created the division associated with the source code, you specified a bank. The system uses this bank code.
The system uses the bank code in one or more ways, depending on whether you process orders in multiple currencies.
• Even if you process orders in only one currency, you might use more than one bank for deposits and refunds. When you process refund checks, the system determines the next sequential check number to use by checking the Bank table.
• If you process an order in a foreign currency, you generate the refund in this currency as well. The system requires additional setup and validation when the Multi Currency by Offer (E03) system control value is selected; among other things, each currency is associated in Order Management System with a unique bank. The bank code that appears on the Work with Refunds Screen (WREF) indicates the currency that the customer used to pay for the order. Because the system requires a bank code when you process refunds, you can generate refunds in only one currency at a time. If you specify a dollar limit to generate for one of your refund types, the system interprets this limit in your local currency, but generates the refund in the customer's currency.
You can suppress refund processing:
• For orders you receive through the Generic Order Interface (Order API). You can use the suppress_deposit_flag and the suppress_refund_flag to suppress processing of deposits and refunds for orders you receive through the generic order interface. For example, it might not be appropriate to process a deposit or generate a refund for a retail outlet order if the transactions have already taken place at the store.
• For returns you receive through the Inbound Return API. You can use the suppress_refund in the Return Request Message (CWReturnIn) to indicate if you do not want to create a refund for the return. For example, it might not be appropriate to generate a refund for a POS order, when the transactions have already taken place at the store.
In this situation, the refund is generated in a cancel pending status.
An overpayment occurs when:
• A customer's initial payment on a prepaid (cash/check) order exceeds the total cost of an order.
• A customer cancels a prepaid item or order.
• An item on a prepaid order is sold out.
The system considers a refund an overpayment if the Refund Reason field for the refund is set to O Overpayment.
The Method for Processing Overpayments in Order Entry (D70) system control value defines how you would like to handle overpayments on prepaid orders.
• AUTO/REFND = you want to create a refund automatically when a customer overpays on a prepaid order (payment category 1).
• AUTO/CONTR = you want to apply all overpayments on prepaid orders automatically as contributions.
• OE PROMPT = you want the Contribution (Overpayment Exists) window to open in order entry when a customer overpays on a prepaid order.
The total overpayment amount on an order does not include the price of any sold out items; the system automatically creates a refund record for sold out merchandise.
You have the option of converting a contribution to a refund, either through standard Order Inquiry or the Work with Contributions function. To do so, however, you must have authority to the Convert Contribution Authority (A41) secured feature.
Once you apply an overpayment as a contribution, you cannot reapply it to the order (for example, in the case of an exchange). Also, if the customer subsequently cancels the order, the contribution is not automatically included in any refund.
A balance due occurs when a customer pays less than the order total on a prepaid (cash/check) order.
The system considers a refund a balance due if the Refund Reason field for the refund is set to B Balance Due.
If a customer short pays an order by an amount equal to or greater than this amount, the system places the order automatically on BD (Balance Due) hold.
Orders are evaluated for the Balance Due Dollar Limit and Balance Due Percentage Limit defined in the Pay Type table. Balance due percentage limit takes precedence over balance due dollar limit, so the system puts the order on hold when it is underpaid by the percentage even if it not underpaid by the dollar amount. When you apply a cash/check payment method:
• If there is a balance due percent limit specified, and the order is underpaid by this percentage, put the order on hold; otherwise,
• If there is a balance due dollar limit specified, and the order is underpaid by this amount, put the order on hold; otherwise,
• Do not put the order on hold for an underpayment.
Example: A customer underpays a $1,250.00 order by $25.00. The balance due dollar limit is $5.00; however, the balance due percent limit is 5%. Five percent of this order is $62.50. This order will not go on hold. The customer has underpaid by more than the balance due dollar limit but less than the balance due percent limit.
Note: If the underpaid amount is less than the amount specified in the Balance Due Dollar Limit, and there is no Balance Due Percent Limit specified, the order does not go on hold. The system creates a balance due record (negative refund record) and puts this record into a write-off pending status. These refund write-off amounts accumulate for the sold-to customer, and can be applied to a subsequent order as an additional charge. The Default Additional Charge Code (C45) to be used in these instances is specified in the System Control table.
Flagging a Balance Due as a Write Off
If a refund is flagged as both a balance due and a write off, the write off setting will take precedence over the balance due setting. In this situation, the system does not display the Balance Due transaction on the Returns/Refunds page.
Purpose: Returns are processed in three stages:
1. Create the Return Authorization.
2. Receive the Returned Merchandise into the Warehouse.
3. Credit the Customer for the Return.
A separate secured feature controls the ability to perform each step of the return process. For example, an operator might have authority to create and receive a return, but not to perform the credit.
• Enter Return Authorization (A28) secured feature
• Receive Return Authorization (A29) secured feature
• Credit Return Authorization (A34) secured feature
The Use Streamlined Return Authorizations (F44) system control value controls whether you must perform the create, receipt, and credit as separate steps, or whether the return is automatically processed as far as your authority extends.
You can perform a return using the following methods.
• Posting a Return using Work with Return Authorizations (WRTA)
• Posting a Return in Order Entry
• Posting a Return using the Order API
• Posting a Return in Order Maintenance
• Posting a Return using the Inbound Return API
Posting a Return using Work with Return Authorizations (WRTA)
When posting returns using the Work with Return Authorization (WRTA) menu option, the system looks at the setting of the Use Streamlined Return Authorizations (F44) system control value.
If the Use Streamlined Return Authorizations (F44) system control value is unselected, the return authorization process after you select an order consists of:
1. Creating one or more return authorizations.
2. Receiving the return(s) as a separate step.
3. Crediting the return(s) as a separate step.
You can perform all three steps through the Work with Return Authorization (WRTA) menu option. You can also perform the receipt and credit separately, using the Receiving Returns (WRAR) and Crediting Returns (WRAC) menu options respectively.
If the Use Streamlined Return Authorizations (F44) system control value is selected, the return authorization process after you select an order consists of selecting one or more items to return or exchange. At this time, the return is processed as far as your authority extends. For example, if you have create and receive but not credit authority, the return is automatically created and received at this time.
Once a return authorization has been created, or created and received, by one operator, another operator with greater authority must complete the return authorization processing.
Posting a Return in Order Entry
You can post a return in order entry by entering an order line with a negative quantity for the number of units of the item being returned.
When you post a return in order entry, the system performs the following updates:
• RA Header table: Creates a record in the RA Header table unless the Use Streamlined Return Authorizations (F44) system control value is selected and the Create Return Download Triggers (K28) system control value is unselected.
• RA Detail table: Creates a record for each negative order line on the order in the RA Detail table if the Create Return Download Triggers (K28) system control value is selected.
• WRTA and Returns/Refunds page: Displays the posted return in the Work with Return Authorizations (WRTA) menu option and the Returns/Refunds page only if the Use Streamlined Return Authorizations (F44) system control value is unselected and the Create Return Download Triggers (K28) system control value is selected. The return is entered, received, and credited.
Note:
• In order to post a return in order entry, you must have authority to the Enter Return Authorization (A28), Receive Return Authorization (A29), and Credit Return Authorization (A34) secured features.
• The system displays returns posted in Order Entry on the Returns/Refunds page only if the Use Streamlined Return Authorizations (F44) system control value is unselected and the Create Return Download Triggers (K28) system control value is selected.
Posting a Return using the Order API
You can post a return through the Order API by entering an order line with a negative quantity for the number of units of the item being returned.
When you post a return through the Order API, the system performs the following updates:
• RA Header table: Creates a record in the RA Header table unless the Use Streamlined Return Authorizations (F44) system control value is selected and the Create Return Download Triggers (K28) system control value is unselected.
• RA Detail table: Creates a record for each negative order line on the order in the RA Detail table if the Create Return Download Triggers (K28) system control value is selected.
• WRTA and Returns/Refunds page: Displays the posted return in the Work with Return Authorizations (WRTA) menu option and the Returns/Refunds page only if the Use Streamlined Return Authorizations (F44) system control value is unselected and the Create Return Download Triggers (K28) system control value is selected. The return is entered, received, and credited.
Note:
• In order to post a return using the Order API, you must have authority to the Enter Return Authorization (A28), Receive Return Authorization (A29), and Credit Return Authorization (A34) secured features.
• The system displays returns posted using the Order API on the Returns/Refunds page only if the Use Streamlined Return Authorizations (F44) system control value is unselected and the Create Return Download Triggers (K28) system control value is selected.
Posting a Return in Order Maintenance
You can post a return in order maintenance by selecting Return for an order line (to return an individual item) or by selecting Return Order for the order (to return the entire order).
When you post a return in order maintenance, the system performs the following updates:
• RA Header table: Creates a record in the RA Header table for the posted return. The RA is entered, received, and credited.
• RA Detail table: Creates a record for each order line returned in the RA Detail table. The RA detail is returned and credited.
• WRTA and Returns/Refunds page: Displays the return in the Work with Return Authorizations (WRTA) menu option and on the Returns/Refunds page. The RA is entered, received, and credited. If the Use Streamlined Return Authorizations (F44) system control value is selected, the RA displays in WRTA only if there are remaining lines on the order that are eligible for return. In addition, you cannot view the RA lines. Regardless of the setting of the Use Streamlined Return Authorizations (F44) system control value, the RA displays on the Returns/Refunds page.
In addition, you can also post a return in order maintenance by entering an order line for a negative quantity for the number of units being returned. In this situation, the system performs the same updates that occur when you post a return in order entry.
Note: In order to post a return in Order Maintenance, you must have authority to the Enter Return Authorization (A28), Receive Return Authorization (A29), and Credit Return Authorization (A34) secured features.
Posting a Return using the Inbound Return API
You can use the Inbound Return API to create and process a return against an order detail line, based on a Return Request Message (CWReturnIn) received from an external system.
When you post a return through the inbound Return API, the system performs the following updates:
• RA Header table: Creates a record in the RA Header table for the posted return.
• RA Detail table: Creates a record for each order line returned in the RA Detail table.
• WRTA: Displays the posted return in the Work with Return Authorizations (WRTA) menu option. The return is entered, received, and credited.
Note: The system does not require authority to the Enter Return Authorization (A28), Receive Return Authorization (A29), and Credit Return Authorization (A34) secured features in order to create, receive, and credit a return processed through the RETURN_IN job. The system creates the return without errors; however, if you do not have authority to these secured features, you cannot review the return in WRTA.
Create the Return Authorization
This occurs whenever you process a return through either Work with Return Authorizations (WRTA) or order maintenance; however, in order maintenance, it occurs automatically “behind the scenes.” At this point, the system also writes a message to order history.
• The return authorization can be either a straight return (specify a return reason code), or an exchange (specify an exchange reason code).
• When you process an exchange you need to supply information about the exchange item. The Require Exchange Item at Time of Receipt (F42) system control value controls the point when you must supply this information (that is, at the time of creating or receiving the return).
• You can process multiple returns or exchanges against the same order line. For example, if a customer returns one unit because it is defective and wishes to exchange another unit for a different color, you can create two separate return authorizations for the item using a return reason code and an exchange reason code. Similarly, if the customer is returning two units for two different reasons, you can create two separate return authorizations for the item using the different return reason codes.
• You can also create a return authorization against all shipped, unreturned items on the order at once.
Receive the Returned Merchandise into the Warehouse
When you receive the returned merchandise, the receipt is processed through the ORDR_ASYNC job, which updates:
• Inventory for the item, including increasing on-hand in the item location and item warehouse, and adding an inventory transaction history record.
• The order, including the order detail and order line history.
• In the case of an exchange, adds the exchange item to the order.
• In the case of a misshipped item, adds the returned item to the order.
• The return authorization header and detail.
Note: When you process an exchange, adding the exchange item reopens the order if it was closed. Adding a new line causes the order to move through the normal processing routines, which may cause the order to go on hold if, for example, the exchange item has a higher price and the customer paid by check.
Credit the Customer for the Return
The credit is processed through the ORDR_ASYNC and BILL_ASYNC jobs, which update:
• The order, including order history, and creating the credit invoice and refund, if appropriate.
• The return reason or exchange reason history for the offer.
• The return authorization header and detail record.
Note: Refunds can be either positive (you owe the customer money) or negative (the customer owes you money).
Credit Card Net Exchange Billing
If the Use CC Net Exchange Billing (M23) system control value is selected and the order contains a credit card pay type, the system may hold the credit invoice for the return to net it against the debit invoice for the associated exchange in order to reduce the number of transactions that occur for an exchange.
________________________________
Copyright © 2020, Oracle and/or its affiliates. All rights reserved.
Legal Notices