Warranty Claims General Information
For any of you that have ever configured the warranty claims for the first time, you’ll probably notice that same thing that I did. There isn’t a whole lot of help out there on the internet. That’s why I’m writing this article. I haven’t implemented everything about warranty claims, but I’ve done several working models and wanted to make it easier for someone out there who might be doing it for the first time. The Warranty Claims module I’ll be talking about is in SAP ERP 6.0. I believe warranty claims may go back as far as 4.6 or 4.7, but I”ll be honest, I’ve only worked on tem in ERP 6.0. Regardless, most everything I discuss in this blog will apply no matter what version of SAP you’re implementing in.
First, the basics about warranty claims. Let’s start simple, what are they, and why would you need to use them. Warranty claims are the SAP provided method of handling any claims from a customer or third party. You will typically use warranty claims in any event where the reimburser (whomever is actually paying for the repair) does not do the warranty/repair work, but rather outsources the work to another party (the claimant) and pays them for the time and materials. Keep in mind that the party that does the work can be a subsidiary of your own company, or even a regional office. The main concept behind the claims model is that you will be paying someone else to perform the repair.
SAP has built in the option to use IDOC’s to load in many of the steps of the claim, or you can process it all manually. The scope of this article will only cover the manual steps, mostly because if you can do it manually, the IDOC method just is a quicker way to load the information.
Terminology
As you may have noticed, SAP has its own terminology around the claims. You’ll notice a couple of key terms that I want to define to make your life easier.
- Customer – this is the end user that is having the warranty/repair work done.
- Claimant – this is the repair shop, 3rd party service center or regional office that does the repair.
- Reimburser – this is whomever is paying the bills.
Steps of the Claim
Depending on how your claims business works, there are four general steps or segments to the warranty claim.
- Step 1: From Claimant
- Step 2: To Reimburser
- Step 3: From Reimburser
- Step 4: To Claimant
I’ll go into more details on each of these steps and what sort of information gets passed a little later. Also, you may not need all of these steps, and SAP does a nice job of letting you control the flow of the claim however you need it to work for you business.
Claim Categories
The next big thing to understand is the general types of claims that you can configure. Like I mentioned earlier, SAP does a great job here of letting you configure what you need, but there are 3 main claim categories.
- Pre-Crediting – the warranty credit memo is created for the claimant before waiting for a reply from the reimburser
- Post Crediting – the warranty credit memo for the claimant is not created until an answer has been issued by the reimburser.
- Recalls – this isn’t so much a claim type, as it a way to group and collect claims. A recall works like a claim “campaign” in that it allows you start one recall with the basic information and then all of the subsequent claims are connected to the recall. A recall will not go through all four steps of the claims.
SAP provides several other out of the box claim types, but these 3 are really main ones you’ll ever need to start with. You will generally pick one of the 3 above and copy it to get started when you do your configuration.
Getting Started
The Customer Warranty Partner Type – AS
Now before you get started really doing your claim, there are a couple of things that need to be in place first. The biggest thing is the partner type AS needs to be configured and assigned to your sold party as a possible option. This partner type is a hard requirement to using warranty claims if you intend to include the “customer” in your claims. The AS partner type simply says that the sold-to party (and it must be a sold-to party to work in the claim) is eligible to be used in a warranty claim. Now depending on your scenario you have a couple of options of how to set this up on your sold-to party’s partner determination.
- When you define the partner type of AS, it is recommended to make it a required partner of your sold-to parties if you could be receiving a warranty claim from any customer. If you only receive claims from a limited number of customers or if you don’t know or don’t care who the end user is, then this step isn’t needed.
- If you do set the required flag on the partner, it is recommended to update all existing sold-to parties in order to automatically add the AS partner type. Gui Script is a great way to handle this if you don’t have the IT resources to do a more formal load. You really just need to visit each customer once your partner determination is set and press save. The new partner will be automatically added.
To give you some ideas, one of my previous clients processed the warranty claim as a sort of intercompany claim. The regional office fixes the part for the customer, the head office then reimburses some percentage of the cost to the regional office, and then the regional office credits the customer, or simply performs the work. In this event, we wanted to capture the customer because the warranty claim was used to move dollars from the head office to the regional office and from the regional office to the customer. Since any customer could have a warranty claim, we set the AS partner type as required and added it to every sold-to party.
Vendors – Claimants
Now for every claimant that you have in your system, it must also be linked to a customer. It seems a little odd, but the way the warranty claim functionality works, you need a customer for every vendor that will be a claimant (service job) and you need to make sure they linked to each other. Also remember, that the customer must have an AS partner type assigned to it, even though it is a vendor.
Processing the Claim
Overview of the Claim Flow
Now that you know about the preliminary pieces you need to have in place, let’s talk a little about the flow of the claim. Below is a sample flow of how a warranty claim can look. Keep in mind, you don’t need all of these steps, but they are available if your process requires it.
You’ll notice this flow shows all 4 versions of the claim. Next, we’ll talk about each of the different claim versions and their purpose. After reviewing each of the steps, you should have a good idea of what versions you need in your process, and what information you wish to collect at each step.
Version Information
The purpose of so many versions in the claim process to capture what each party is asking for, as well as what is agreed to. For example, the service shop may be requesting $500 of labor and $250 of parts, however your agreement only covers parts. In that event, version 2 would show $500 of labor and $250 of parts. Version 3 would show only $250 of parts.
Now the claim can hold a large amount of information in each version, and I’m going to cover some of the high points, but please be aware, there are a lot of fields to capture as much information as you need. You also have the ability to configure the layout and what fields are visible in each tab of the claim.
Header Information includes all the partner information, including the end customer or vendor depending on which version of the claim you are looking at. It also includes the equipment record (or serial number, etc), it will contain a multitude of dates (much like everything in SAP) to say when the failure occurred, when the claim was sent in, etc… It also contains several different text and long text fields.
One of the most useful features of the claim is that you can capture all the parts, labor, subcontracting and break it down in a complete list, so you can see everything that was used in the repair by your service shop. Each item is broken down by category, qty, price requested, etc. You also get complete pricing functionality inside of the claim including a special pricing procedure specifically for the claim type.
You can even create a service or quality notification directly from the claim (and it will be shown in the claim document flow). One of the drawbacks, is that the notification does NOT show the claim as part of the document flow, but nothing is perfect.
Processing the Claim
The biggest thing all the version have in common is the action button. This is how you process the claim and move it from status to status, and can create a new version depending on the action selected. The action button is what you press at each of the claim. When you’ve reviewed it, when you’re ready to send it to the reimburser, when you want to post a credit to the vendor’s account, etc. Using this action button and paying attention to the status of the claim is how you will know what still needs to be done, or who should be processing it next. This is also one of the main pieces of configuration for the warranty claim. You can go anywhere from any status, as long as you configure it as an option. It’ll be important as you begin your configuration to pay attention to your options, and keep in mind what you think you want your claim to look like at each step of the process.
Version 1 – From Claimant
This version is all of the information from the customer, to your service provider. If your process starts at the end user, and you want to track it all the way through, you’ll start at Version 1. You will typically use this claim step if your company is both the service shop and the reimburser. One example of this is the intercompany scenario.
I recommend creating the service notification from this version if you will be performing any sort of repair. This will allow the document flow to capture the notification, repair sales order, etc. so that all of the information can be kept together.
For this version of the claim be sure to set the partner equal to the customer. You must use a Sold-To Party with an AS partner type.
Now, if you are processing the claim manually, be sure to uncheck the Manual Processing box. This was a point I struggled with for a while. If you don’t uncheck this box, you can’t process the claim to get it to version 2. Never did find any documentation that explains this, but it sure gave me headaches for a few days while I played with random pieces of configuration and pushed lots of button before I tried that one.
Version 2 – To Reimburser
This version contains all of the information from the claimant to the reimburser. This version will be used regardless of your scenario. The information is everything from the service center.
For this version of the claim be sure to set the partner equal to the vendor. You must use a Vendor that is connected to Sold-To Party with an AS partner type.
Version 3 – From Reimburser
This version contains all of the information from the reimburser to the claimant. This version will be used regardless of your scenario. The information is everything approved by the reimburser. In short, this version is what the reimburser will pay the service center.
For this version of the claim be sure to set the partner equal to the vendor. You must use a Vendor that is connected to Sold-To Party with an AS partner type.
Version 4 – To Claimant
This version is all of the information to the customer from service provider. This version will include everything that is approved to be sent to the end customer. That may be a credit to their account, it could be spare parts or could simply repairing the part under warranty and sending it back.
For this version of the claim be sure to set the partner equal to the customer. You must use a Sold-To Party with an AS partner type.
Next Steps
Now that you understand the warranty claim process a little better, you should be in position to decide how you want to configure the actual claim. What I recommend doing is play with the SAP standard Pre-crediting or Post-Crediting scenario, whichever is closer to what you think you will need. Run through at least 1 complete claim and pay special attention to all of the statuses and all of the options you get with each status. This should give you some really clean direction of what you need your claim to accomplish, including some of the steps to undo a mistake.