The warranty functionality has been around since the earliest of SAP releases. Even though I’ll use mySAP ERP Central Component (ECC) 6.0 of the mySAP ERP 2005 release as my frame of reference, the concepts hold true for earlier versions. Functionality around warranty claims processing changed in only very minor ways from R/3 Enterprise 4.7 to ECC 5.0 in the mySAP ERP 2004 release to the current one, ECC 6.0 in mySAP ERP 2005. The warranties functionality comes packaged inside the Customer Service (CS) and Plant Maintenance (PM) modules within the overall umbrella of logistics but does not have a separate top-level node in either the main SAP menu or the IMG.

Warranty Master Data

Six categories of master data underlie warranties. Not all of the following categories and objects are required for you to be able to use warranty processing:

• Warranty objects are the actual objects to which warranties are applied, such as functional location, equipment, installed base, and material number with serial number. This master data is a prerequisite for creating warranties. (A vehicle, another category of object that is not part of standard R/3 software, is available only with the IS Discrete Industries Add-On.) Other applications share these warranty objects. You create each category of warranty object via a different transaction code: IL01 (functional location), IE01 (equipment), IB51 (installed base), MM01 (material number), IQ01 (material number with serial number).
  
  
• You need master warranties for an automatic warranty check for a certain warranty object. You create them in the master data record of the relevant warranty object. You enter warranty counters, measurement positions, and measuring points. A master warranty defines the framework of a warranty agreement and defines the services that the manufacturer or vendor will render. Create warranty counters as characteristics in the SAP classification system via transaction code CT04. The counters provide the means to represent the conditions in a warranty. Once you create your warranty counters, you can assign them to a master warranty.
  
  
• Material master data is required only if you want posting to the Financials (FI) and Controlling (CO) modules and pricing to take place automatically. Use the standard material master transactions (MM01, MM02, and MM03) to work with material master records.
  
  
• Business partner is a generic term used to mean both vendors and customers. Both are required for warranty processing. You are not able to post debit and credit memos to the relevant vendor and customer if you haven’t created the business partners. Use the vendor master transactions (XK01, XK02, and XK03) and customer master transactions (XD01, XD02, and XD03) to create, change, and display partner records. If partners need to communicate by electronic data interchange (EDI) (using IDocs), you must maintain partner profiles.
  
  
• Reference or template objects serve as full or partial templates for creating other warranty master objects. Each reference object is a combination of a warranty object type and a valid subtype for that particular object type. Since an item/part can have a different warranty than its parent object, you can link individual reference objects separately at the version level and the item level within this version. Maintain template objects via transaction OWTYMR or OWTY and then Warranty Claim Define Template Objects. Creating reference objects for measurement positions and points is optional.
  
  
• Catalogs are used for defect codes, external services, and labor values. This is an optional activity used more commonly by the IS Discrete Industries Add-On.

Standard Warranty Claims Processing

In an SAP system, a warranty claim is a document that you create using transaction WTY (Figure 1). It contains the reimbursement claim for service, parts, or labor incurred on a defective warranty object.

Figure 1

Initial screen for entering warranty claims information via transaction WTY

A warranty claim document is similar in hierarchical structure to a sales order or purchase order document. Transaction WTY opens up a screen as shown in Figure 1. It requires you to enter the warranty claim type and the warranty claim number. I selected the Postcrediting option (identified as claim types 0005 on the left in Figure 2) and entered the claim number.

Figure 2

Create a warranty claim via transaction WTY

Standard SAP supports several types of warranty claims processing. Your actual business processes relevant to warranties may not exactly match any of these scenarios. For deviations from standard, SAP provides several customer-specific enhancements using Business Add-Ins (BAdIs). The two most important categories are processing with precrediting and processing with postcrediting. The others are claims split, recalls, returned parts, and authorized goodwill.

Warranty Processing with Postcrediting

Postcrediting takes place when the customer/claimant does not receive a credit memo until the party responsible for reimbursing provides the customer/claimant with an acceptance, rejection, or request for resubmission. Here are the steps involved from a process-centric viewpoint:

Step 1. The customer/claimant creates a warranty claim in its system (either an SAP or non-SAP system) or by using some other Web-based interface. If the former mechanism is used, the information is transmitted to the processor’s SAP system by EDI (via IDoc).

Step 2. The processing party (processor) receives this IDoc and creates a warranty claim automatically in the system. If a claim is not automatically created, you have to be create it manually. This claim has a version (from the customer/ claimant) in the warranty claim document.

Step 3. The processor checks the warranty claim for completeness, validity, and all other criteria that you have configured. It may be accepted or rejected if certain criteria are not met. These errors may be automatically corrected or sent for processing manually.

Step 4. If the checks have passed and the claim is accepted by the processor, it sends the claim to the reimburser using an EDI mechanism such as IDoc technology. This creates another version (for the reimburser) in the warranty document. If the claim is rejected, it is automatically returned to the claimant/customer using the same transmission channel for corrections and subsequent submission.

Step 5. The reimburser processes the claim further at its end and returns it to the processor. This creates another version (from the reimburser) in this document.

Step 6. The processor checks the latest version of the claim and applies the configured criteria. The processor accepts the claim and sends this accepted version automatically to the customer/claimant or transfers it for manual processing.

Step 7. The claimant receives the accepted version automatically as a new version. If it is sent for manual processing, the processor can resubmit a new version to the reimburser for further processing.

Step 8. All relevant documents (including credit and debit memos) are posted in accounting. The credits and debits are posted to FI based on revenue account determination criteria and to CO based on CO account determination.

Warranty Processing with Precrediting

For this form of warranty processing, the claims processing party or supplier/manufacturer issues a credit memo upon receiving a warranty claim. The latter sends the warranty claim to the reimbursing party. The following is the sequence of events from the standpoint of account postings:

Step 1. Customer/claimant sends a warranty claim to the processor. This generates a version (from the claimant) of the warranty claim.

Step 2. The processor writes a credit memo for the amount being claimed and a version (to the claimant) of the warranty claim is created. This is the fundamental difference between postcrediting and precrediting. With precrediting, a credit memo is issued immediately.

Step 3. This updates the relevant accounts in FI and CO.

Step 4. The claim goes to the reimburser, which generates another version (to the reimburser) of this claim.

Step 5. The reimburser approves the whole amount or part of it. If a partial amount is approved, various actions can result, such as creation of debit memos and invoices, cancellation, or reversal of postings. Documents are automatically generated in FI and CO. The resulting version is the version from the reimburser.

Warranty Processing with Claims Having Multiple Reimbursers

Sometimes, a warranty claim may consist of items that can be reimbursed by more than one party because of defects that involve parts made by different vendors/ manufacturers. In both postcrediting and precrediting mode, this sort of claim generates multiple versions to the reimbursing parties from the claimant version. The following steps explain this process:

Step 1. The claimant sends a warranty claim indicating that it needs to be split.

Step 2. Group the items. You group two or more items that are to be processed from the same reimburser in the Item Detail tab of transaction WTY, as shown in Figure 3.

Figure 3

Split group in warranty claims processing

Step 3. Release multiple versions. For each unique reimburser in your claim document, you release a version per reimburser for further processing.

Step 4. Reimbursers process claims. The reimbursers process their respective claims versions and return them to the vendor/manufacturer with some type of action (acceptance/rejection/request for more information).

Step 5. Complete the process. If all the reimbursers return their claims version (version from reimburser) as a final version within the stipulated time frame, they are bundled together as one version to the claimant. If one of these versions from the reimburser is not the final version or has not yet arrived, automatic processing is aborted and you complete the process manually.

Warranty Processing with Recalls

With recall processing, the vendor/manufacturer is responsible for fixing or replacing the part even if the warranty on the part has expired. You use transaction code WTYCRL for processing claims with recalls.

Initially, the reimbursing party provides the manufacturer/processor with the relevant data on the part that is being recalled. The manufacturer/processor enters the information in an SAP system using transaction WTYCRL. The system displays an initial screen where you select the recall option and enter the internal recall number. The system automatically triggers this number if you configured the number range object. In the next screen (Figure 4) add these four categories of information: Version Detail, Item Overview, Pricing, and Objects.

Figure 4

Maintain recalls via transaction WTYRCL

Entered information includes (but is not limited to) the items that are affected by the recall, such as the recall number issue by the reimburser, item details, and defect code. The manufacturer/processor informs the customer/claimant of the parts affected by the recall. The customer/claimant sends the manufacturer/processor its warranty claim referencing the external recall number that the reimburser assigned. This claim is then checked for validity and applicability based on the recall information entered by the manufacturer/processor. Suitable action (acceptance, rejection or request for more information) is taken.

Warranty Processing with Returned Parts

Unlike in a recall, the onus for this process is on the customer/claimant to send the malfunctioning part to the manufacturer/ processor. SAP provides transaction code WTYRP for processing returned parts. The process, which begins when the part is returned, is as follows:

Step 1. Claimant submits the claim. The customer/claimant sends a claim to the manufacturer/processor for a part that the system flagged as one to be returned.

Step 2. The manufacturer/processor sends a notification to the customer/ claimant that contains the time within which the part needs to be returned. The notification message enables the customer/claimant to print a bar code with the claim number and item number (for reference purposes).

Step 3. Claimant ships item. The customer/claimant affixes the bar code to the part and ships it off to the manufacturer/ processor.

Step 4. The system checks automatically (based on configuration) whether the part has been delivered within the specified time interval. If it hasn’t, automatic processing is aborted and this claim needs to be processed manually.

Step 5. If it arrives on time, the bar code information is scanned and entered via transaction WTYRP. The system checks if this part is really defective based on the information the manufacturer/processor initially entered. The claim is processed for acceptance or rejection or request for more information.

Warranty Processing with Authorized Goodwill

This special case does not occur frequently. If you would like a customer/claimant to send a warranty claim despite the expiration of the warranty, you could set up the system to accept it as an act of authorized goodwill.

From an SAP processing standpoint, the manufacturer/processor informs the customer/claimant about the former’s approval of the latter’s claim for a part that has been previously discussed by the two parties. The manufacturer/processor then creates and authorizes this claim via transaction WTYAUT. This generates an authorization number in the system that is sent to the customer/claimant. The customer/claimant creates a warranty claim referencing the authorization number and the authorizer’s name. When the manufacturer/processor receives the claim, it is checked for the authorization details and if it matches, the claim is processed for acceptance or rejection.

SAP Objects for Warranty Claims Processing

In any SAP application, it is always very helpful to know the names of technical objects that act as the building blocks as you may be able to gather information about the application from them.

• Packages/Development Classes: The package ISAUTO_WTY contains all the SAP objects that underlie warranty claims processing. A couple of other packages contain functionality relevant to warranties and warranty processing. ISAUTO_WTY_MP contains all objects that facilitate the mass change feature. ISAUTO_WTY_MTY contains all objects that facilitate warranty checks and creating and maintaining master warranties.
  
  
• Tables: Master and transaction data pertaining to warranty claims processing resides in several tables. Names of most of these tables contain the characters WTY so it is easy to do a wildcard search. Some of the most important tables that you can use to browse contents via transaction SE16 are:
  
  

  - CWTY001: Master data for warranty claim types
  - CWTY011: Master data for item types
  - PNWTYH: Header (transaction) data for warranty claims header
  - PNWTYV: Version (transaction) data for warranty claims versions
  - PVWTY: Item (transaction) data for warranty claims items

• Enhancements: The warranty claims processing application is highly customizable. SAP provides several BAdIs that provide customers a lot of flexibility. All of these BAdIs have names starting with WTY, which facilitates a wildcard search.
  
  
  Note
  If you want a list of all the BAdIs SAP provides for carrying out customer enhancements to warranty claims processing functionality, run transaction SE18 and do a wildcard search for “*WTY*”.
  
  
  
• Transactions: You have no reason to memorize all the transaction codes in this application. However, here are a few that you may want to memorize because of their importance and frequency of usage:
  
  

  - OWTY: Main Customizing transaction in the IMG (Figure 5). You can find all the customizing options steps in warranty processing in one
     place when you run this transaction.
  - WTY: Creation and maintenance of warranty claims
  - WTYSE: Search of warranty claims based on various criteria
  - WTYNK: Number range creation for warranty claims documents
  - WTYCRL: Maintain recalls

• Authorization objects: Several authorization objects are checked automatically when you process warranty claims in transaction WTY. You may not be able to process warranty claims if you do not have authorization for all of these authorization objects. The objects you must have in your profile to be able to post claims documents are:
  
  

  - C_WTY_ACT: Controls the ability to maintain warranty action codes
  - C_WTY_OBJ: Determines the ability to maintain warranty claims
  - C_WTY_STAT: Controls the ability to maintain the status of a warranty claim

Figure 5

All customization activities for warranty claims (transaction OWTY) click here to view a larger version of this image

Anurag Barua

Anurag Barua is an independent SAP advisor. He has 23 years of experience in conceiving, designing, managing, and implementing complex software solutions, including more than 17 years of experience with SAP applications. He has been associated with several SAP implementations in various capacities. His core SAP competencies include FI and Controlling FI/CO, logistics, SAP BW, SAP BusinessObjects, Enterprise Performance Management, SAP Solution Manager, Governance, Risk, and Compliance (GRC), and project management. He is a frequent speaker at SAPinsider conferences and contributes to several publications. He holds a BS in computer science and an MBA in finance. He is a PMI-certified PMP, a Certified Scrum Master (CSM), and is ITIL V3F certified.

You may contact the author at Anurag.barua@gmail.com.

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