Returns, reversals, return material authorization, and return delivery are different terms used for goods returned to you by a customer, each based on different processes. Every forward movement has a potential return or reversal.

Setting up a complete return-order process (in other words, setting up reverse-logistics) involves a lot of configuration steps in SAP R/3. The documentation is spread out, and setting up these end-to-end processes calls for experience, as matching the setup to your business model might be challenging.

I will show you how to set up returns from customers through sales transactions. I will also cover the follow-on processes (or interfaces) for addressing customer complaints in an SAP R/3 system. The R/3 modules involved in the setup of a return-order process are SD, MM, LES, and Financial Accounting (FI). It is not practical for me to cover the entire returns process in one article. For example, I have not discussed the inspection of returned goods. However, I have provided enough details for you to tailor the process to your needs.

Let's review the business case. The goods sold could be returned for different reasons:

• The customer is not happy with the product.
• The goods were damaged in transit.
• The incorrect material or part was shipped.
• More than the requested quantity was shipped.

Each reason might require a different process to execute the return. For example, if an incorrect part was shipped, the customer wants to return it and get credit for it. You can call this a pure reversal. In the case of damaged goods, the customer wants a replacement part. You might have to generate return material authorization (RMA) to receive the broken part and generate a new replacement order.

In any case, the customer wants a replacement part without charge or a credit. The vendor wants to accept the return and get the part back into inventory or reject the return.

The above processes affect the following logistics and accounting areas:

• Customer service/sales at the front end — those who accept the return and acknowledge it in the system.
• Materials management/inventory management — receiving and processing the part into inventory.
• Financial accounting — posting the inventory and the sales transactions.

Enabling return-order processing in R/3 requires some or all of the following steps, depending on the business scenario or requirements. These steps are mapped against your business process or requirements. If you want to receive the part into your inventory, you must work with the MM and LES setup. Otherwise, you might deal with only the SD and FI configurations.

Create a Sales Document

To create a return sales order in SD and subsequent delivery, you may use the SAP standard order type RE or define your own using transaction VOV8 (menu path Sales and Distribution>Sales> Sales Document>Sales Document Header>Define sales document types). You may also create the return-order type with reference to the standard return-order type. Figures 1 and 2 show the key parameters to set up for return orders. The SD document category for a return is H. You can configure it to automatically create credit for the return by selecting RE as the Order-related billing type in the Billing section. A credit memo is triggered once the return delivery is processed (post goods are issued and material is logistically received into the inventory). Using the default setting code of 08 Check credit memo in the Billing block parameter in the Billing section could block issue of the credit memo. Billing block is copied into the sales document, and manually removing it releases the document for credit memo.

Figure 1

Parameters in transaction VOV8 to maintain for returned sales orders — note that the SD document category for returns is H

Figure 2

R/3 can automatically create credit for a return

Figure 3

Sales document change mode (VA02) for applying a rejection code

To send a replacement with free delivery, use the SAP standard document type FD, which creates a return order without reference. For a subsequent free delivery, use the document type SD, which is created with reference to a sales order. The SD document category is I (order without charge). The screen sequence group for these documents is RE.

You may also initiate a credit through invoice correction (document type RK) or a credit memo request (document type CR). The SD document category is K, the screen group sequence is GA, and the order-related billing type is G2. To capture the reason for creating the return order, use the Order reason code in the return order, free-of-charge deliveries, or credit memo request. Figure 3 shows the Order reason field in the sales order documents.

The Order reason code is also used for retro-billing. Retro-billing takes the pricing date for billing from the original order, as the price might have changed between the time the customer was billed for the item he ordered and when it was returned for a refund. The credit/debit memo must be retro-billed if the price has changed. Maintain Order reason codes through transaction OVAU (menu path Sales and Distribution>Sales>Sales Document> Sales Document Header>Define order reasons).

The usage indicator in the sales order indicates how the material is being used — for example, if the material is a regular part or a replacement part. If you update the usage indicator at the header level, it is copied to the item level. You can use the usage indicator to update selectively by applying it to a few line items.

Configure usage indicators via transaction SPRO (menu path Sales and Distribution>Sales>Sales Document>Sales Document Header>Define usage indicators). Figure 4 (on the next page) shows the Usage indicator field update in a sales document.

Figure 4

Usage indicator field update in a sales document

Return the Part to Inventory

To return the part to inventory, you need to configure the associated delivery document for returns along with the sales order. Select LR (return delivery) for Delivery type in Figure 2. The configuration for the delivery document type is accessible through transaction 0VLK (menu path Logistics Execution>Shipping>Define delivery types).

Define Item Categories

The associated Item category, which drives how the system processes the item, is assigned to the header document. The menu path to access the configuration for sales document item categories is Sales and Distribution>Sales Documents>Sales Document Item>Define Item categories, and for delivery document item categories is Logistics Execution>Shipping> Deliveries>Define item categories for deliveries. Figure 5 shows the Maintain Item Categories screen where you set the following key parameters in the Business data section:

Item type: Leave this blank, indicating a standard item if it is a return or free of charge.

Special stock: This indicates if this stock needs to be managed differently. For example, the regular and consignment items are transacted differently in the system.

Relev. for billing: Select D (relevant for pro forma) to generate a pro-forma invoice for a return or free-of-charge item. Otherwise, leave the box blank.

Billing block: If you want to default any billing block at item level, select 1.

Pricing: Leave this blank for a return or free-of-charge item. For a free-of-charge item, you could also use B (pricing for free goods 100 percent discount).

Returns: Select this if you want to indicate the item is a return. You might want to select other appropriate data based on your requirement for item category. If you choose the standard return delivery item (RLLN), as shown in Figure 5, the Bus. data item, Sched. line allowed, Wght/vol. relevant, and Determine cost fields are preset as selected. The Item category group defined in the material master determines the item category in the document. Figure 6 shows the item category fields in the material master.

Figure 5

The Maintain Item Categories screen

Figure 6

Item category fields in the material master

Inventory Movement

To this point, you have acknowledged the return from the ordering point of view. To bring the part into inventory, you must do one or all of these steps:

1. The returned material/goods are received into inventory by post goods issuing (PGI) the return delivery. PGI reflects the returned goods in the inventory movement or allocates it to a movement type in the system. Movement types are configured through the menu path Materials Management>Inventory Management and Physical Inventory> Movement Types. Start by defining a new movement type. A goods movement can be a goods receipt, goods issue, or a transfer posting of materials. Transaction OMJJ brings up the Debit/credit indicator (Figure 7). Based on the material moving out of or into inventory, the movement type is configured as Credit (H) or Debit (S), respectively. In the same configuration step, map the transaction codes that are allowed, as Figure 8 shows.

2. Configure the Control reason for the movement of the returned goods through transaction OMBS (Figure 9). You might also want to configure the Reason for movement for the return delivery.

3. Set up the movement type for the Dynamic Availability check through transaction OMCP, although this is not necessary for returns. The movement type enables the system to find predefined posting rules that determine how R/3 posts the accounts of the financial accounting system (stock and consumption accounts) and how it updates the stock fields in the material master record. You can set the subscreen for the account assignment (coding) block through transaction OXK1.

Figure 7

Debit/credit indicator on the Definition of New Movement Types screen

Figure 8

Allowed transactions mapping for Movement type

Figure 9

Control reason settings

Accounting/Financials

The return or reversal of the transactions has two effects:

• The reverse document increases the transaction credit figures by the same amount, as it was debited early with the forward movement or sale.
• After posting the document, R/3 reverses the previous forward movement documents generated.

These transactions have both sales and the inventory postings.

Inventory postings. The accounting postings for any material/inventory movement are determined as follows: The Valuation class defined in the material master drives the account assignment for the inventory movement (Figure 10 on the next page). The Valuation class is mapped to a particular general ledger account through the R/3 Financials (FI) transaction OBYC (Automatic Posting — Procedures). A transaction is assigned for every procedure.

For inventory posting, the transaction is BSX. (This transaction refers to the FI posting. Do not confuse it with the term used for SAP R/3 transactions for accessing menu paths.) If you double-click on the transaction for Inventory posting and enter the Chart of accounts in the pop-up, you get the mapping screen for Valuation modif., Valuation class, and the Account value (Figure 11). You might have to set up another account from which you set the inventory amount. This captures the dollar amounts as part of the material moving in and out of the company's inventory. To do so, use transaction GBB (Offsetting Entry for Inventory Posting).

The typical account postings during the PGI on a return document are debited to inventory and credit cost of goods sold. You can define the inventory movement as Credit or Debit in the movement type configuration explained earlier. (Refer to Figure 7). Figure 12 shows the material movement document created for a return post goods issue or when the part is received into the inventory.

The amount to post is determined by the Standard price or the Mov. avg. price maintained in the material master. Figure 10 shows the field details. This value is populated in the condition type (for example, VPRS) and carried along with the pricing procedure for the document.

Return sale and financial postings. From the sales point of view, when you issue a credit memo request or create a credit for return, the accounting needs to be set up to capture the dollar value transacted in the revenue account and customer account. The typical financial postings during invoice creation for returns are credit customer account and debit revenue.

The revenue account is determined automatically through the account key mapped for each condition type in the pricing procedure. Follow the menu path Sales and Distribution>Basic Function>Pricing> Pricing Control sub-menus to configure the pricing for returns. Figure 13 shows a typical pricing procedure (transaction V/08). The Account Key is part of the revenue account determination. Figure 14 shows the configuration for the Account Key along with other conditions for determining the general ledger account.

The reconciliation account for the customer is defined in the customer master record, as shown in Figure 15. To update this field, go to Logistics>Sales and Distribution>Master Data>Business Partner. Select the appropriate partner (Sold to or Payer) and select Change. Select Accounting information from the Company code data and hit enter or execute. This takes you to the accounting information for updating the reconciliation account (general ledger) for the customer.

Figure 10

Valuation class in the material master drives the account assignment for the inventory movement

Figure 11

Mapping screen for Valuation modif., Valuation class, and the Account value

Figure 12

Material movement document for a return post goods issue

Figure 13

Typical pricing procedure

Figure 14

Account Key configuration

Figure 15

Define the reconciliation account for customer in the customer master record

Flow of the Return Document

Figure 16 walks you through a typical return document and the associated document flow. The creation of the return acknowledges (accepts or rejects) the customer return. The document number is 60000047. The delivery is created, referencing the return order, to initiate the shipment of the part. The number of this document is 84000016. Once the delivery is post goods issued, the goods movement document is created as the display material document 4900000011 as shown in Figure 12. Once the inventory is posted, the credit is issued to the customer. The credit number created in Figure 16 is 90012836.

Figure 16

A typical return document and document flow

Rajen Iyer

Rajen Iyer is the cofounder and CTO at Krypt, Inc. Rajen has written several in-depth, best practice articles, white papers, patents, and best-selling books on SAP Logistics and SAP Global Trade Services, including Effective SAP SD and Implementing SAP BusinessObjects Global Trade Services. He is also an invited speaker at industry conferences.

You may contact the author at Rajen@kryptinc.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.