SAP Warranty - Claim creation business process-5

[Narasimha]

This blog post shares my implementation experience for a  claim entry application for a discrete industry. Always watch out for the latest SAP offerings on warranty solutions. This solution is based on standard SAP warranty transactions in the backend and a Custom Fiori application in the front end.

 

Business Requirement:  SAP Warranty claim processing module takes care of warranty claims of customers (To be settled by the OEM-manufacturer ) and vendor warranty (Manufacturer gets reimbursed by the supplier/vendor). This blog post focuses only on customer warranty. Here the end customer (retail or direct) buys a product from the manufacturer directly or through a sales network consisting of dealers, Distributors, and branches. If any defect arises in the product end, the customer raises a complaint directly with the manufacturer or the dealer /distributor/branch. These role holders will raise a necessary claim. This claim will then be validated based on warranty validation rules before the claimant (Dealer/Distributor/Branch) submits the claim. If the claim data is as per the set rules, the claim could get auto-approved, and necessary credits would be passed to the claimant. If the auto-approval doesn't go through, the claim gets processed through the required team (Could be Branch/distributor/ Warranty manager/Warranty admins), where manual validations are carried out, and the claim could get into new status (Denied/sent back for proof / approved, etc.) . If the claim gets approved, necessary credit entries are passed on to the Branch/Distributor/Dealer.

In SAP, a standard warranty covers the following processes (Please see SAP online help to understand these topics in-depth)

Processing with Postcrediting/Precrediting (Standard warranty claim. This blog post discusses post crediting only (Claimant gets credit only after reimburses approves the claim). SAP supports immediate claim settlement to the claimant through pre crediting process, and the claim then goes to the reimburser. )

Processing with Authorized Goodwill ( Claims that  need to be approved despite warranty conditions are no longer fulfilled)

Processing with Parts to be Returned  (Process of returning the part to the service center or to the plant . Not detailed in this blog post)

Processing with Claim Split  (When multiple reimbursers are involved in a claim. This process is also out of scope in this blog post)

Processing with Recalls/Technical Campaigns  (Manufacturer is at fault. This process is not discussed in detail in this blog post)

Common processes

Warranty Check to check whether the warranty conditions have been fulfilled.

Accounting postings - Credit/Debit memo/Grouping credit memo

 

The business process for claim entry at a high level in this blog post is as below.

 

Claim creation by claimant  (Dealer/Distributor/Branch/Repair Shop/Warranty team) --> Claim processing (Auto approval/ Manual approval/Validation rules) --> Claim payment (credit /debit financial postings)

 

Claim creation requirements

Channels : Claims can be generated from web(different browsers) / mobile /internal portal /mail/mass claim creation.

Claimants: Role holders who can create claims  -Dealer/Distributor/Branch/Repair Shop/Warranty team (Warranty processor /warranty manager etc.)

Claims on: Serialized machines/equipment, Serialized parts, non-serialized parts,  non-serialized accessories.

The claim could have the following features as part of the claim entry process.

Attribute	Requirement	Remarks
Serial number	Serial number to be validated in the backend for the correctness and to bring associated warranty data. Serial numbers are usually associated with the final product purchased by the customer, but sometimes even parts/accessories may have serial numbers. Help section for the user showing different types of claims	Persona-based checks to control the proper serial selection.
Extended contracts	There could be claims based on Extended warranty contracts.
Parts/accessories claim	Claim on specific part/accessory of the equipment. Many times, some of the parts may belong to 3rd party manufacturer. There would be a feature to select the parts as returnable.
Warranty information	Based on the input - warranty information like installation date, the end date of different warranties (Like Car engine warranty end date, Car Battery warranty end date, etc.). So it should be showing extended Warranty end dates also if purchased.
Claim information data	You may capture claim information like when the equipment failed(Failure date) and defect reason (You may map defect codes to equipment or part, etc.). Recall the reference number if the part is eligible for recall..(Auto population through recall master data), comments for capturing Details	There could be additional requirements to capture  -like if the technician has visited before and his visit reference number.
Persona information	If Distributor is raising a claim on behalf of Dealer, features to support Searching dealers and other related controls. If the Dealer is raising, you may want to hide information which Distributor can see. Usually, dealers will have more minor control /authorizations compared to distributors, and similarly, Branches, the internal warranty processing team of reimbursement, will have more authorizations.
Owner information	Show owner details and allow to edit address and other information. However, address verification information and duplicate address validations must be built into the app.
Claim part /accessory replacement information	Dealer/Distributor can add which parts/accessories or equipment were changed. Here requirements may come to capture failed parts details, failure code, where to return the part, etc., so that system can calculate how much part cost is to be reimbursed to the claimant.
Claim Labor charges	Here any labor-related expenses have to be captured, like what type of labor was used, how many hours, travel hours, tools (like crane hiring ), etc., so that the correct labor cost to reimburse can be calculated by the system. Only the warranty processor/admins could see the standard labor hours allowed and the labor rate for the dealer/distributor.
Claim overview	Before submitting the claim, an overview of how the system calculated the eligible warranty cost-reimbursable to the dealer/distributor/branch(claimant)
Document upload	Based on the input done by the claimant, the system should insist mandatory documents be uploaded for claim verification by the next in line (Like in the case of a dealer raising a claim, the Distributor may validate if the Distributor raises, warranty team will process claim.
Final view	Once all the information is entered, and data validation is successful, a claim should get generated in the system with the status as created. The claim could go through a background job for validations per the warranty rule engine (Use BRF +) settings, and the status can change as designed.

 

SAP solution Back end :

SAP has provided one standard T-code WTY for raising warranty claims in S4, without any Fiori app. This transaction will allow users to create different claims and claim versions. Each version can have a set of warranty claim data (explained above). However, the standard WTY screen has an only a limited set of attributes. So you have to enhance the screen and back end table and also ensure validation rules built-in front end Fiori app is also built in the backend so that user doesn't directly go and change data in WTY transaction.

SAP solution front end:  Suggesting custom Fiori app integrated with WTY transaction in the back end.

Sap Configuration requirement :  SAP Warranty solution is an integrated solution. At high level, you would need MM(Vendors/Material/Serial number), SD(Customer, Pricing), CS (Installed base, Master warranty), PM(Equipment /Functional location/Counters /Measurement document/Catalogs-Defect codes), FI/CO (Credit/debit/revenue recognition/VSR check) .

• OWTY- Warranty general settings: Has default settings for pricing condition types for parts, amounts, default days for part return, etc


• Warranty claim number range for each warranty type and for recall claims


• Partner functions:  For identifying your sales business partners like Dealer, Distributor, service technicians under Dealer, etc


• Partner determination procedure: For warranty claims


• Warranty Claim type:  You can create different claim types based on business processes. (It could be serialized equipment claim, parts claim, accessory claim, recall, direct customer claim, etc.) . You can control pricing procedure, action matrix, partner determination, accounting document type, start status, and many more controls for each claim type.


• Decision code : You can codify claim decisions like Approved / In-Process/ Denied /settled / Document to verify /Pending settlement etc


• Recall object ID type: You can put object types that could be called in recall transactions. Ex Equipment, Serial number, production date, etc. (We can set data for recall with these settings. Ex for all equipment(*) for production date 1/1/2022, recall is applicable


• Warranty claim Item type:  SAP comes with a standard Item type(Like MAT(material), FR(Flat rate) ). You can create your own item type to make them more meaningful. Group these item types and assign these item type groups to warranty types. One custom item type example could be CRNE- Crane, and we can set it to be pricing relevant.


• Item reference type: In the WTY transaction, there is a ref type field. The values configured here show up there. You use this as per your requirement. For example, you can use it to split the high-level claim type to sub-level claim types based on the line item in the claim. For example, say your overall claim is for serialized equipment, your one of the line items in a claim (say labor) could be from the extended contract. This ref type -if you configure EX (Like extended contract), you will be able to differentiate the claim types within a header claim type.


• Define status for parts to be returned: SAP delivers standard statuses like "Parts do not have to be returned," "partial deliver," etc., along with controls for each status like deadline control, etc. Use this configuration correctly if you have strict deadline controls for part return.


• Control data: For controlling  Process control, copying control, VSR checks, Warranty checks
  
  
  
  • Process controls (Actions are configured here for warranty processing like Z123- Claim submitted, Z788-submitted, Z788-Claim Reopened
  
  
  
  


• Claim statuses Like Z111-claim created, Z112 -claim submitted by Distributor, etc., then assign action function codes to claim status)


• Copy control - Copying the procedure to claim type


• VSR Checks - BRF + to be used as rule engine.


• Define message type: Create your own message type (Like if you want to print, send the output to EDI, etc.)

Data migration design :

• Open claim migration: Extraction of claims from a legacy system, mapping them to equivalent claim types, and mapping historical claim items to new claim items.


• Historical claim migration and reporting

 

Persona Design:  Dealer / Distributor / Branch / Warranty admin /Service center / Service technician etc, based on your requirement.

 

Unique Controls/Requirements :

• European legal requirement of extending the warranty by 2 years for specific industry sectors.


• Linking vendor details for reimbursement from vendors.


• Including startup details (Technicians visit the premise before the product is commissioned and carry out detailed checks in some industries. This data is also captured in the system while processing the claim.


• RMA- (Return material authorization) SAP has an in-depth solution.


• Some industries want to show MTBF (Mean time between failure) and MTTF (Mean time to failure) data for the equipment to be shown to the warranty processor to do quality analysis and to see if the equipment/part replacement decision by the Distributor was justified or not.


• The requirement to register the product (If not done initially) when the first claim is raised by the Dealer or Distributor.


• Creation of notification within claim (This is standard sap functionality . Numbers should be assigned in advance for the notification type configured)

 

Special Notes :

• Have a detailed discussion on open claim migration due to following reasons.
  
  
  
  • Many times manual decision on open claims is based on old claims.
  
  
  • Historical claims also serve as the basis for MTTF/MTBF
  
  
  • Historical warranty master data would be needed for recall decisions.
  
  
  • You may use your BW database to host historical data and expose the required data to S4HANA for use in warranty applications.
  
  
  
  


• Warranty claim entry application user interface would depend on types of claims and persona. Hence detailed requirement study should be made before finalizing UI screens.

This blog post shares my implementation experience for a  claim entry application for a discrete industry. Always watch out for the latest SAP offerings on warranty solutions.

Your feedback would be very much appreciated.