The Service Management Experts
Menu

service management

Home / Posts tagged "service management" (Page 2)

Serial Numbers – Number Scheme

Since I got a request for more posts about Service management, I thought I’d dig into my bag of tricks.  One of the things I’ve run into a lot of issues is serialization.  For some reason, serial numbers seems to hold a special place of confusion for many customer.  Today I want to talk about the serial number number scheme.  I’ve picked this as my starting point for serialization because many of my recent projects have had a lot of trouble coming to decisions on this topic.
Serial numbers have a great starting point when it comes to numbering.  As of ERP 5.0 or 6.0 (not sure exactly when), SAP added a field called SerializLevel.

This field allows you to make the serial number number scheme unique at a global level or unique at a material level.  This subtle difference has huge implications on the number scheme.  If SerializLevel is blank, then serial number is only unique at a material master level.  To put things simply, the combination of serial number and material number is unique, but the same serial number can show up for any material number.  If SerializLevel is set to 1, then the serial number is unique across the SAP instance.  This means that no serial number will ever show up  for any other material.  SAP accomplishes this by linking the serial number to the equipment record number.  I’ll have a future post that goes into the details of serial numbers vs. equipment records.  Since every business is different, and you can often become locked into a particular numbering scheme.  The number one decision to make is if the serial number is unique across the organization, or if it can be reused for materials.

There are some things to beware of when using this functionality.  The SerializLevel field is plant dependent.  This means that you do have the ability to set this value differently across different plants.  I discourage setting this differently for the same material.  If you were to set the value to be unique across the origanization in one plant, but unique by material in another, you’ll see some very inconsistent results in the history.  I’ll go into the serial number history in a future post, but when it comes to serialization, consistency is key.

The final issue to cover when it comes to serial numbers is what I’ve heard called “intelligent” serial numbers.  When I say intelligent serial numbers, I use the term loosely.  This can be anything from adding a prefix by product to each number, adding in a manufacture date, or it could be a combination of alphanumeric characteristic that have a decoder ring to explain them.  In my humble opinion, this is a very slippery slope and should be avoided at all costs.  When you move down the path of “intelligent” number schemes, you must introduce ABAP code to accomplish this.  I believe the user exit is IEQM0003 (don’t remember for sure if this is the correct exit).  Regardless, if you start creating an “intelligent” number scheme, you must have multiple number ranges available, you need code to possibly shift from one range to the next.  For anyone that’s been doing SAP for a while, you know that every time you introduce code, you introduce risk, and you introduce additional time to implement.

The most important question to ask is “Why do you need an “intelligent” serial number?”  A serial number should be nothing more than a tracking mechanism for a product.  Requiring the serial number to mean something is a not something that add value to a product, but it does increase the cost.  Anyway, I’ll get off my soap box now.  You get the idea that I think intelligent number schemes are costly, risky and unnecessary.

I hope you found this useful.  I hope to hear your comments, thoughts, or let me know things I missed.

Thanks for reading,

Mike

Starting a new Product – SM/WM

Like always, I just hate being bored, so I’m working on my next product that I think will take off. For those of your using SAP Service Management, you probably already know that Service Management and Warehouse Management have ZERO integration. Even though WM is fully integrated with production orders, which are very similar to service order, SAP neglected SM. Sometimes I think I picked the Red-Headed Step Child to specialize in… and as it’s turning out, it could be the best thing ever for me (as soon as my apps start getting into the market).
Well, this new tools is 2 phases. The first phase is create a universal WM helper tool. It will use the functionality of MB1A, MB1B, MB1C and add the ability to automatically create a Transfer Order from it. Simple, but according to my good friend and WM expert, Jeff, something many smaller companies would love. Especially if the same person who does the material movement also creates the TO. I’m nearly complete with this first phase.
Next up, will be integrate the SM orders the same way that production orders are integrated with WM. I don’t know if I’ve fully wrapped my head around how I’m going to accomplish this connection. I have 2 schools of thought and I’ll have to contemplate a little more before I start the coding. One option is to utilize user exits along with a custom configuration table. While this method can work, it is a little more intensive for a customer to implement. In order to avoid any possible overwriting, the customer would have to manually place this include into thier code. Not difficult, but not as easy as my other products. Option 2 entails a batch program that would need to run pretty often to pick up any demands released into the system from service orders and then generate the appropriate WM documents. I also need to spend more time understanding all of the pieces involved for production orders.
All fun stuff, and yet another learning experience. Special Thanks to my good friend Jeff Bass. without him, WM would just be another black box of SAP that I know nothing about. Jeff is an amazing teacher of this stuff. If you need WM help, check him out.
Thanks,
Mike

My 2nd Real Product – Service Dashboard

I’m pretty excited right now. A couple months ago, I completed Broadsword: SM Dashboard, an SAP Dashboard. I took my own advise this time around and designed something that some of my previous clients specifically asked for. It helps because I know the process so well, that I came up with all the scenarios I’ve seen throughout my career.
It’s pretty awesome because I was able to learn several new skills building this product (I’ll post more about those in some future posts) and more importantly, I actually have interested parties in this tool. Like everything else, I need a starting point, and once I have several clients running the tool effectively, that should open the door to future sales. Anyway, things are getting exciting, and between the new products I’m developing and joint venture with DMS I feel like my business is about to take off…

SAP SM Blueprinting Questions – Master Data

One thing I’ve noticed over and over again, is that when it comes to blueprinting for SAP Service Management or Customer service, the same questions and same processes always apply.  And inevitably, the same gotcha’s show up because one of these questions is missed.  So today I wanted to talk about the list of SAP SM blueprinting questions I use.  If you see something I missed, please add it to the comments.  I’ve lumped things together into major categories and I’ve included questions if you’re already on SAP or if you’re about to blueprint from a completely different system.  Together I think we can make a great list for all of us to work.  This first post will focus on all of the master data related to SM/CS.

How many service products do you use?

If your audience is currently on SAP, this finds out what service materials are currently in use.  From here, the follow-up questions would be what service materials do you have, and what are each of them used for.

How many serviceable materials do you have (ballpark)?

This is to get an idea of how many materials are currently being repaired.  One of the big things that often catches customers by surprise is the amount of data that may need to be created if you choose to have different valuations for repaired materials.  Especially in an environment that keeps quick turn around stock in their warehouse (I call that process advanced exchange or service exchange).  There are usually 2 ways to handle this situation.  One is multiple valuation for a single material.  This can often be very messy and transaction intensive for the entire organization.  An alternative method to handle this is a second material material (prefixed or suffixed with something to show it’s a rebuilt/repaired/etc version).  This material can then be stocked under a different number, with different costs, profit centers, etc.  Short story, you need the answer for this to know if you might have to create an additional 10,000 materials to account for all of the serviceable materials.

Do you serialize?

This simple question is often one of the most important questions you’ll ask during blueprinting.  I’ve worked at multiple companies that did not serialize their products, but wanted to start serializing in SAP.  While this sounds like a simple request, there are a lot of follow questions you must find out during your blueprinting phase of the project.  Here’s where to start:

  •      Do you use equipment records or serial number records?
    • There isn’t a huge difference between the pieces of functionality, and won’t have a large impact on how you configure the system.  However, be prepared to explain the difference between a serial number & an equipment record.
  • Do you use an installed base or serial number hierarchy?
    • The use of an installed base or serial number hierarchy won’t impact your configuration that much, but it will have a big impact on your processes.  Both of these pieces in SAP require a lot manual maintenance, or perhaps some heavy programming work to accomplish.  It’s something you want to know as soon as possible, if you ask me.
  • Do you use an equipment BOM or Plant Maintenance BOM for any serial numbers?
    • This is important to understand because in SAP you have the option to maintain individual bills of materials for each equipment/serial number.  Again, this won’t impact your configuration, but will impact your processes.  If they answer yes to this question, you then need to understand how do they use this bill of material?  is it purely to maintain the as-built/as-maintained history record, or do they use it for creating materials using the same bill of material.
  • How much information do you capture in your serial number?
    • With SAP serial numbers/equipment records you have the ability to capture an immense amount of data.  While this often sounds like a great thing, the new user will quickly learn that SAP doesn’t really maintain most of this data without a lot of custom development.  Often, I encourage my clients to only use what they NEED.  Now need is of course subjective, but it’s important to stress that it will be easy for this data to get out synch unless you have a good master data process.  These are the most common pieces that are maintained, but remember, there are a lot of options for more data, just be cognizant of the manual nature of most of the fields.
      • Partner Information
      • Warranty information
      • Serial Number Hierarchy
      • Location information
      • Classification information
      • Etc
  • Do your customers register their serial numbers with you to begin warranty or receive additional support?
    • This question is another important piece of serial number maintenance.  If they do have customer registration, you will need to follow up and find out how they receive the registration from their customers.  Is it online, mailed in, phoned in?  How should the warranty be handled?  does it differ by product, or does everything get a 90 day warranty.  This and much more is all part of the registration portion.

Do you use master warranties?

The master warranty is another piece of data that you want to capture early on.  The entire warranty conversation will inevitably take up a lot of your blueprinting time.  We’ll go into more details in some of the following posts.  For now, find out if the customer uses master warranties, or if they have a set of warranty rules for a defined period of time/products/services/coverages etc…

  • How do you currently determine what master warranty to assign to each product? or does everything get the same master warranty?
  • When does the warranty period begin?  When the product ships?  when it’s registered?  or some other method?
  • How many characteristics are you tracking in the warranty?
    • Are you tracking things by time, mileage, working hours, or all of the above?

Do you use measuring points?

Measuring points are another major piece of master data associated with SAP Service Processing.  You first need to determine if they have materials that need measuring points.  Then you need to find out if you are measuring time, distance, operating hours, etc to make sure you can properly handle the setup.  Finally, you need to understand how those measurement points get loaded into the system.  Are they currently automated?  does someone manually enter them on a weekly/monthly basis?  What are the measurement points used for.  Are they used for warranty information?  to provide automated service notices to the customer for their next oil change? or are they simply tracked on internal equipment?

These are the big things I always try to cover when I start talking master data.  Obviously, every one of these pieces leads into other questions and business processes, but I wanted to start with one piece at a time.

Thanks,

Mike

www.paperstreetenterprises.com

SAP SM: Quoting In-House Repairs

One issue I’ve found in SAP Service Management (Customer Service) is that most companies want to quote the repairs they perform in house.  The problem is that the standard repair process doesn’t give a good alternative to handle this.  You can only use the DP80 functionality if you use a service order that is non-revenue bearing, but you must use a revenue bearing service order to perform in-house repairs.

Up until now, I’ve always handled it manually.  Simply creating a quotation with reference to the repair sales order.  The problem is that the connection to the process is loose at best, and you cannot use the information from planned service order to automatically update the quote.

Recently I found the following OSS notes.

Note 153869 – Creation of quotation after goods receipt for repair

Note 204874 – Settled costs in resource-related billing

This OSS note maps out a process that uses the original repair sales order as both the quote and the order.  Through the use of different item categories, we can use DP90 to perform quoting functions, as well as the actual billing.  Now, several things needs to be taken into account for this process to work.  The first is that you will need to add some addition item categories and item category usages.

I recommend you create Item category Usage, ZEIN & ZENI so you can control the quotation item categories.  Then you can leave SEIN & SENI for use in the billing items.  Be sure to add these new usages to the item category determination for your repair sales orders.

The next step is to properly setup the DIP profile in order to accommodate the new changes. What you need to do is change the billing portion of the profile to include the planned costs.  This will allow DP90 to pull in all of the planned costs, which can be used for quoting. DIP 1.jpg

The other thing you need to decide is if the quotation items will be statistical or not.  This depends on if you want all of the items to be displayed to the customer on the quotation, or if you plan to simply roll the items up for easy calculation of your quotation price.    The basic code provided by SAP assumes that quoting will be actual pricing, and billing will be statistical.  In order to provide some additional flexibility in the solution provided by SAP, I included a check in the code to look at the materials of the quotation usage to determine if each was statistical or not.

DIP 2.jpg

In my code below, if the Material Determination for an item was set to C: Transfer qty only, then it was statistical.  In all other options, it was normal pricing.  This does require you to maintain the items in both the quotation and the invoicing portion of the DIP profile, but the flexibility was worth the one time maintenance.

Be sure to setup ODP4 to show the cost in the sales order.  Be sure the condition you use (EK01 is recommended) is also a part of the pricing procedure for the repair.

Finally, the biggest thing to consider is the output changes that will be required for this process to work. I encourage you to create a new quotation Smartform.  It can be similar to your current quote or order confirmation, but you will want to handle the item categories appropriately for your customers.  For example, you may want to show the itemized quotation costs, but not show any of the repair process items like the inbound delivery.  You will also need to setup the form to show your pricing at the appropriate level.

Here’s the code I used in the exit: V46H0001 ->EXIT_SAPLV46H_001

data: da_vbak like vbak.
data: da_vbkd like vbkd.
data: lv_quant type AD01INVQUA.

CHECK NOT I_VBAKKOM–VBELN IS INITIAL.

CALL FUNCTION ‘SD_VBAK_SELECT’
EXPORTING
I_DOCUMENT_NUMBER  = I_VBAKKOM–VBELN
IMPORTING
E_VBAK             = DA_VBAK
EXCEPTIONS
DOCUMENT_NOT_FOUND = 1.

CHECK SY–SUBRC = 0.

* only in repair environment
check da_vbak–vbklt ca ‘FG’.

* read billing form of repair main item
CALL FUNCTION ‘SD_VBKD_SELECT’
EXPORTING
I_DOCUMENT_NUMBER = I_VBAKKOM–VBELN
I_ITEM_NUMBER     = C_VBAPKOM–UEPOS
IMPORTING
E_VBKD            = da_VBKD.

CASE I_SDSM_DLI–WRTTP.
WHEN ’01’ or ”.                      “resource related quotation
CASE da_vbkd–FAKTF.                 “billing form
WHEN ’01’.                        “fixed rate
select SINGLE INV_QUANT from AD01C_MAT into lv_quant
where PROFNR = I_SDSM_DLI–FFPRF and
DPUS   = ’11’ and       ” quotation
INV_MAT = I_SDSM_DLI–SD_MATNR.
if sy–subrc  <> 0.
select SINGLE INV_QUANT from AD01C_MAT into lv_quant
where PROFNR  = I_SDSM_DLI–FFPRF and
DPUS    = ’11’ and       ” quotation
MAT_DIR = ‘X’.
endif.
case lv_quant.
when ‘C’.
C_VBAPKOM–VWPOS = ‘ZENI’.       “statistical
when others.
C_VBAPKOM–VWPOS = ‘ZEIN’.       “not statistical
endcase.
*         C_VBAPKOM-VWPOS = ‘SEIN’.       “not statistical
WHEN ’02’.                        “costs
*         C_VBAPKOM-VWPOS = ‘SENI’.       “statistical
C_VBAPKOM–VWPOS = ‘ZENI’.       “statistical
ENDCASE.

WHEN ’04’.                            “resource related invoice
CASE da_vbkd–faktf.
WHEN ’01’.                        “fixes rate
C_VBAPKOM–VWPOS = ‘SENI’.       “statistical
*       when ’02’.                        “costs
*         no change at the moment, because no change necessary
*         – item with service product   => SENI statistical
*         – items from costs            => SEIN non statistical
*         c_vbapkom-vwpos = ‘SEIN’.       “non statistical
ENDCASE.
ENDCASE.

SAP Warranty Claims: A Guide for Beginners

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.

Warranty Claim Process Flow

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.