Purpose: This is my experience implementing a customer warranty for a discrete manufacturing company. Please watch out for new offerings from SAP services for best practices for warranty management.
Business Process:
After the equipment sales, it could be the case that customer pays an additional fee to have an extended warranty. If there is a claim from a customer who has an extended warranty, the system should give the service.
When equipment is bought, a standard warranty comes bundled with it; if the extended warranty is purchased, the warranty period gets extended. For example, if the standard warranty for labor is for 2 months, if you buy 12 months extended warranty for labor, then the complete warranty for the labor would be 12 months from the installed date (Some companies effect extended warranty from the date when standard warranty expires).
The extended warranty can cover whole equipment or its parts or only accessories.
An extended warranty contract could be purchased at different events. During the sales order process, itself customer may opt for the extended warranty; in such a case, we can trigger an email to the distributor with extended contract creation in the backend and let the distributor review and approve them. Once approved, we can change the warranty data on the equipment (Like the end date of labor warranty, the end date of parts warranty, etc., along with the contract number for reference). Extended warranties are created as contracts separately to enable revenue recognition periodically.
SAP solution Back end :
A sales contract is a standard SAP functionality. Contract billing and revenue recognition are also standard functionalities in SAP. We can use the same object (we May have to enhance it to accommodate warranty requirements ). We can use standard pricing objects for pricing the contract (Procedure /condition type and condition record)
You may have to create service materials to indicate extended warranties (Like Material -ABCD - Extended warranty for 10 years)
You may require custom tables for warranty requirements like
- Table to store what warranty coverage is covered in the contract (If the Car is the finished product, you may offer Parts only or Labor only, parts + labor, Battery + labor, the engine only, engine+labor, etc.)
- Table to store equipment/parts that can be covered under extended warranty (Say Battery, battery, engine, wheels, etc.)
- Table to store coverage period ( 1,2,5,10 etc. with a code)
- Table to link all warranty data like which type of equipment can be covered for maximum which period and what kind of warranty coverages can be extended etc
Sap Configuration requirement :
Number range, contract type, item category, incompletion procedure and determination, pricing procedure and decision, text procedure, Billing type, and copy control.
Sales org structure definition to create a contract in the right sales org element.
SAP solution front end :
Standard Fiori app for sales contracts does exist; however, you may have to create a custom Fiori app with the following features
- Contract create/change/search/cancellation/renewal
- Contract price
- Contract status (Created /approved/denied /void etc)
- Contract validity
- Contract coverage
Most of the data for contracts gets copied from a sales order. However, the user may manually enter equipment/serial number / Functional location, billing plan, validity dates, etc., manually. Equipment data would be entered under the technical objects section of the contract.
Data migration design :
Extraction of current open contracts in the legacy system, transforming to S4 HANA system structure and uploading the contracts in S4
Replication of contract to any interfaced systems as needed
Historical contracts migration for reporting and legal requirements.
Persona Design :
Distributor /Branch /warranty admin /Warranty manager/ Contract admins can use contracts.
Unique Controls/Requirements :
- Replicating contracts to a different system
- Creating contracts from different events (From sales order, from any other system, manual, from the claim, etc.)
- Reports to show expiring /expired contracts- SDV3 tcode may also be used.
- Dealers based on performance may be allowed for special warranty contracts where they may get a higher commission. You may have to have a process to accommodate such contracts
Special Notes :
- Do not allow people to create contracts directly in sap if validations are written in the Fiori app. Control it through persona controls.
- You may allow people to edit contract through VA42 to change the address of partners, contract object status, pricing conditions, etc
- Use message output functionality of contract to update warranty counters in equipment
Do watch out for SAP products on warranty. This blog post is based on my implementation experience using standard SAP functionalities and a custom Fiori app.
Your feedback would help me post more of my experience in warranty implementation.