Select-Option in OO class

06AugJune 27, 2016

Here’s part 2 of my adventure with SELECT-OPTION. Now one of the cool things that SAP did was to move to an OO programming method. However, since I got very used to SAP forms, functions and programs, I keep finding things that aren’t as easy to do with classes. SELECT-OPTION for example.
Now, what I really wanted to do was to send the select option table into a global class, so I could use it select statements and other table functions. Sounds easy, right? Well, actually it is, once you figure out how to do it.
It turns out, all you need to do is create a global structure/table type that woks as a select-option. The new trick that I learned is that there is a special function in SE11 when creating a table type that allows you to create it as a select-option table.
All you need to do is go into SE11, enter in the name of the table type, select TABLE TYPE as the object to create. Once you are in SE11, Enter in the short text, then go to the menu: edit–>Define as Ranges Table Type. This changes the inputs you’re given for creating the table type.
Enter in the data Element (MATNR for example), then enter in the name of the structure you want to create, and press create. It will automatically create the fields for your SELECT-OPTION range.
Save and activate everything. Now all you need to do is enter it into the parameter for your public class and you’re ready to go.
One last point, don’t forget when calling the class, to send it in as a table…

SELECT-OPTION: matnr FOR mara-matnr.

call method XXXX (
exporting
IT_SO_MATNR = matnr )

Anyway, that’s one of my recent discoveries. I’m learning a lot about layouts and trees currently, so there will probably be a post about some of those tricks as well.
Thanks for reading,
Mike

SAP Report: SELECT-OPTIONS in a layout screen.

03AugJune 27, 2016

Well, today I’ll get a little more technical for a change. I’m working on generating a new dashboard for service management, and one of the challenges that I needed to overcome was using Select-options in a layout screen and then feeding those options to a global class. Let’s start with the layout issue:
1. you need to define a subscreen. I usually put this in my _TOP with all my other data declarations. It would look something like this:
SELECTION-SCREEN BEGIN OF SCREEN 1301 AS SUBSCREEN.
SELECTION-SCREEN BEGIN OF BLOCK slssel_1 WITH FRAME TITLE text-f10.
SELECT-OPTIONS:
vkorg FOR vbak-vkorg,
vtweg FOR vbak-vtweg,
spart FOR vbak-spart,
vkgrp FOR vbak-vkgrp,
vkbur FOR vbak-vkbur,
SELECTION-SCREEN END OF BLOCK slssel_1.

SELECTION-SCREEN: END OF SCREEN 1301.

This has a subscreen of 1301 (and it also has a box around this data to make it look nicer.

2. Once you have this subscreen declared, you need to go to SE51 and update your layout. You will need to go into the layout screen and place the subscreen in your desired location.
in my example, I’d call it SUB_1301. Be sure to make it large enough to hold all the fields (it’ll encompass your full width of the screen to hold all the fields).

3. Finally, you need to make a declaration for the new subscreen in your flow logic. Here’s a very simple example:

PROCESS BEFORE OUTPUT.
CALL SUBSCREEN SUB_1301 INCLUDING SY-REPID ‘1301’.

MODULE STATUS_0110.

PROCESS AFTER INPUT.
CALL SUBSCREEN SUB_1301.

Be sure to include a line for each PBO and PAI.
One of the big gotcha moments for me is that I can’t define my select-options as large as I’d like. I had to pare down my list so that i would fit int he screen. If you need everything, you would have to break it up into multiple screens. This may have to do with the fact that I’m using a tabbed layout.
Anyway, if you know of better ways to handle this, please let me know. I’m always interested in better ways code.
Happy coding,
Mike

VC – Moving a product line with ALE

29JunJune 27, 2016

Alright, today I’m switching gears. For those of you that know me, you’ll know that VC is actually my first job in SAP, so I still hold a fondness for everything variant configuration related. I recently helped out a client to move a product line from one system to another, so I thought I’d share it with all of you how we used ALE to accomplish this.

Now let me begin by saying I’m not a basis person, I only know enough to be dangerous. So, in order to initially get ALE up and running, work with your basis team. They need to set the EDI partners, and all of the object types. Some of it may also be trial and error the first time. Simply because SAP provides multiple options for the same object, and some options only work with certain processes. If there’s interest, I can do more homework and go into this on another post. For today, I’m going to assume your ALE connections are properly setup.

Moving all of the VC master data is no small feat. When I first started in 3.0F, there was no ALE, so we actually wrote ABAP to do uploads and downloads to other systems. ALE is much easier and much faster. Like everything in VC, there is a process a certain order to things, so I’m going to run down those right now.

About this guide: All of the fields you need to be concerned with are listed below in the screen shots. Every one of the transactions contains the field Logical system. I will refer to that as the Target system. In addition, most screens contain a field for Engineering Change Number. Below, I define these fields. It is up to you determine if you should be populating the ECM field, and you must work with your basis person if you are not sure the correct value to use for the Logical System.

Target System: The SAP system you wish to populate. Please note, your basis person must creating/maintain the ALE system.

Engineering Change Management (ECM): Your VC modeling may or may not include engineering change numbers. I encourage all clients to use ECM due to the high level of maintenance required. In order to transfer most pieces of a VC model with engineering change management using ALE, you must maintain ECM in all systems, including the development system.

Note: For All screens, you can often use the wild card, if you maintained a standard naming convention. in that event, simply enter XYZ* to capture all product line specific data.

Engineering Change Management:

TXN: CC92

For the ECM number you have 2 options depending on your system setup.

Typically, most companies will create the change number in their production system, then move that ECM to other system. In that event, execute CC92 in the production system, and logical system will be the development or QA system. This, by the way, is my recommended way of doing things.

You can also use a Push system, if you wish to have your ECM driven from the test system. Usually, this would require a unique ECM number range specific to VC, but it can be accomplished.

Characteristics

TXN: BD91

Note, if you use preconditions at a characteristic or characteristic value level, some of your characteristics may fail to load. If this occurs, continue loading the classes and object dependencies. After that is completed, reload the failed characteristics.

Classes

TXN: BD92

The following items must exist first:

Characteristics

Variant Table Structures

TXN: CLD3

Please note, this transaction does not allow for ECM because the table structure is not under ECM control.

The following items must exist first:

Characteristics

Variant Table Contents

TXN: CLD4

The following items must exist first:

Characteristics
Table Structures

KMAT Material Masters

TXN: BD10

Message Type: MATMAS

Classification

TXN: BD93

Please note, this data only needs to be moved if you maintained classification at a material level. This is often used with class type 200 functionality, as well as nested KMATs with restricted characteristic values.

The following items must exist first:

Characteristics
Classes
Materials

Variant Functions

TXN: CUFD

Note, this functionality is not always used. Only in the event of an instance where ABAP coding is required. This is discouraged, if possible, since this functionality cannot be easily converted to the IPC.

The following items must exist first:

Characteristics

Object Dependencies

TXN: CLD2

The following items must exist first:

Characteristics

Dependency Nets

TXN: CUK2

Please note, it is not necessary to move individual constraints, moving the constraint net automatically moves all constraints.

The following items must exist first:

Characteristics
Classes

Configuration Profiles

TXN: CLD1

The following items must exist first:

Characteristics
Classes
Object Dependencies
Constraint Nets
KMAT Materials

Bill of Materials

TXN: BD30

Please note, if you have Sales BOMS and Production BOMS, you will need to call this transaction separately for each.

Also, you may have a list of materials BOM’s to move, be sure to enter the change number in every row of the Target System Chng. NO column.

The following items must exist first:

Characteristics
Classes
Object Dependencies
KMAT Materials
Components in the BOM

Interface Design

TXN: CUID

The following items must exist first:

Characteristics
Classes
Configuration Profile
KMAT Materials
Object Dependencies
Constraint Nets

Pricing Condition Records

TXN: VK12

The following items must exist first:

KMAT Materials

Routing/Reference Operation Sets

Program: RCPDIRO1

Program: RCPTRA02

This the one piece that does not use ALE. It actually uses a more simple technology of downloading a file, and then uploading it. You need to make sure the basis person has defined a directory that is valid in both the original and target systems.

Remember, if you use reference operation sets, you must first transfer those. Use Type S. Then execute again using Type N.

The following items must exist first:

Characteristics
Classes
KMAT Materials
Object Dependencies
Work Centers

How to check for errors:

IDOC Status Monitor

TXN: BD87

To monitor the success or failure, log into the target system and execute this transaction.

After executing the transaction you’ll be able to see what failed and what succeeded. If anything failed, you’ll be able see the IDOC log to see exactly what failed and why. (See the next section).

Analyze Application Log

TXN: SLG1

Use this log to understand the errors. Certain errors may require manual changes in the target system. Other errors simply need a piece of data that has not yet been moved. As soon as the missing data is created in the target system, you can re-execute the IDOC in BD87, or you can send it again using the transaction in the original system.

SAP SM Blueprinting Questions – Service Processing

04JunJune 27, 2016

Now, onto more of the nitty gritty, what do you need to find out about the actual processing of the service orders. In this part of the SAP SM blueprinting series we cover what do you need to find out when it comes actually performing the repairs. So let’s get into it.

How many service orders do you process in a day/week/month?

It’s old fashioned, and I think everyone knows this, but I’d hate to skip over the obvious. This question helps you gauge how to structure your processes. Just having an idea that the service department processes 1 order every 2 weeks, or they process 25 in a day. You’ll need to start thinking about how the service group will see their open orders, how they will notify other groups when they start or complete the orders, etc. Simply put, the answer to this question will set the stage of what you need to do for all realization about the actual repair process that occurs.

How many different service order types do you utilize, and what is the purpose of each?

You may need to phrase this question differently depending on your audience. The gist of the question is determine how different “types” of orders you process. A type of order is anything that it is either tracked separately for financial or processing issues. For example, if the accounting department needs to separate the costs of an Field service type order from an in-house order. Sometimes, it’s purely fro reporting to know which orders need to processed ahead of others (for example, an in-house repair would need to be processed before the exchange orders that will just go back into your “spares” inventory. Keep in mind, the more order types you create, the more maintenance you will be responsible, so like everything, drive to the minimum number of order types you can.

Do you break a single repair up into multiple smaller pieces?

SAP uses sub-service orders to accomplish the breaking of main service order up in multiple pieces. This is especially useful when you deal with equipment that is broken into multiple pieces for repair. This often happens with larger pieces of equipment that get broken down into more management sub-assemblies, each that need their own repair. Sub service orders in SAP work great for this, because you are not allowed to complete the “main” service order until it’s sub-service orders have been completed. So you can build an entire structure of orders if your process is complex. However, remember that using these orders now doubles or triples the amount of master data to maintain for each order. So if your shop is small, be aware they will have to do a lot more system work. Short story, only implement if needed, and make sure that the people that will be dealing with day to day

Do you perform subcontracting for any service repair (in-house or external)?

Another thing to determine is if you have to worry about any subcontract or 3rd party to do work on a part. There are several different ways that you subcontracting impacts the service order.

The first way is that you need a component that is purchased. In SAP, if you don’t have the material in stock, it will generate a purchase requisition for the component. It may also be for a part that is not maintained as a material master in your system (this could be something like ordering hammers for the field service tool belts).
The next way is that you may send the part being repaired (or a portion of it) to an outside vendor to perform a specialized service or process that you do not offer. It could be special diagnostics or tooling on the part. This again requires a purchase requisition.
- do you need to see that the inventory has left your facility? In SAP, you can implement the A&D solution to actually perform the material movements and SAP deliveries to show that the part has left/come back into the facility. This is very nice functionality, but keep in mind that it has limitations, and it adds multiple additional steps to the process. Find out how necessary the requirement is perform you promise it. It requires certain enhancement packs to be installed and activated, so if you go down this path, you’ll need to work with the basis/development team to accomplish this.
The next thing to consider is, do you use a 3rd party service center to do the entire repair. In this event, please check out my post on Warranty Claims: SAP Warranty Claims: A Guide for Beginners

How should the costs be broken up?

The cost breakdown is simply the broad categories that display on the service order as you do planning or actual hours & components. Some of the common breakdowns include:

Labor
Travel Costs
Components
External Components
etc…

Remember, these categories have no impact on anything financially. It is simple “buckets” that the particular cost elements are grouped into to.

Do you perform repetitive service tasks for certain products?

This question is related more to master data than service processing, however it fits much better into this portion of the blueprint. It’s important to find out if your client does repetitive steps for a particular repair. This could by service material (service process) or by serviceable material (material that is being repaired). If the same steps are performed every time, you need to set up General Task Lists, and teach the business how to use General Task Lists. If you are not familiar with these tasks list, it’s simple a routing and component list that can be automatically copied into the service order upon creation.

How do you need to track your time entries to the service order?

This question helps you drive to the answer of if you need to pursue CATS (computer aided time sheets). CATS is a useful tool if you use SAP to handle your payroll and your service orders. Keep in mind that the standard time entry tools for service orders (IW41, IW42 for example) can handle entering in personnel numbers, multiple confirmations, etc. CATS certainly provides better reporting, and looks more like a time sheet for your employees entering their time. CATS will certainly require a lot more configuration, including setting up an organization structure (often a difficult and controversial topic for any organization). As a general guideline, I will steer clients away from CATS unless they have solid reasons for using it (often if the client does Project Systems and Service, both will want to use CATS, then it makes sense to use CATS).

If you perform service at the customer’s location, who enters in the time and material for the job?

This question is typically more business process related, but it is certainly information you need to know. The reason it’s important is because you need to know if field personnel will be entering in their own time and materials, or will they be emailing, faxing or mailing in their time sheets to someone in an office who will enter it for them. If they intend to enter it in the field, you need to know if they have internet connection in the area. In our day and age, most places have internet coverage, however there are still locations on our globe that do not have easy connectivity or have very weak or slow connections. In that event, you need to be very sensitive to making someone log into SAP, if they are using just a 3g network. You may need to look into a web interface that provides a small amount of bandwidth to get the confirmations entered.

If you perform service at the customer’s location, do you ever send components for a service job?

This is one of the famous loaded questions you ask. It’s pretty rare to do service and never send components. The reason for this is to determine HOW you need to handle the components. There are several common ways to handle this.

The service technician is located at the office or a plant with parts and takes parts with them to the customer. In this event, the technician simply issues the parts to the order and removes them from stock. Packs them up, and takes them to the client. If there are extra parts, they are returned to the warehouse after the completion of the job.
The service technician maintains “trunk” stock. This simply means they have a list of stocked components with them at all times. These “trunk” locations are typically a storage location in SAP. Then the stock is issued from their SLOC to the order.
The parts are shipped ahead of the tech by way of a sales order/delivery process. They are shipped directly to the customer, perhaps as a no charge order, but this again needs to be determined by the business.

If you perform service at the customer’s location, do you perform scheduling of your technicians?

Now this question will often get a quick “Yes” from the customer. However, you need to dig into the how. Many clients simply track their techs on MS Outlook, Excel, or the big calender hung in the boss’ office. Now some clients have a far more sophisticated method to track their people, and when they are available, but you need to know what level of complexity you need to implement. In addition, you need to find out if they track the travel time, how are the tech’s schedule maintained? Is there an automated connection to the call center? Do they schedule “real-time” with the customer? Who has access to view this? Do they track skills of each tech to determine who can do what? Keep in mind, to implement this in SAP is usually a very custom solution requiring quite a bit of development. SAP does offer a solution, but it is an add-on, and last I looked into it, it is only for CRM.

Do you perform any service parts planning?

Service parts planning can often mean a lot of different things depending on the client. Some of the things you need to determine are:

Are the parts being planned independent of the production demands?
If it is a shared stock, who wins? By that it’s important to understand in the event of limited stock, does a sales order get the stock, does service get the stock or does production get the stock?
How do you forecast service demands? How much history is currently used to determine the service forecasting?

Alright, here’s the stuff I can think of related to service processing. As always, I welcome your comments on anything I missed, or even anything else you would like me to cover… Next time we’ll talk about a few of the remaining “oddball” items, such as forms, technical stuff, and financial stuff.

Thanks for reading,

Mike

SAP SM Blueprinting Questions – Shipping and Receiving

16MayJune 27, 2016

This next installment of SAP SM Blueprinting is a short and sweet one, but be sure not to over look these details. If you perform in-house repairs or returns, you need to understand what processes need to be accounted for. Here’s a good starting point.

Do you currently have any special processes or requirements after receiving the material into stock?

Often when you receive materials into your plant, there are special requirements, special areas, or people to notify. Be sure to check if any of the following might apply:

Does the inspection or service department need to be notified?
Does the customer receive any notification when their part has been received?
Does Customer service need to be notified upon receipt? This could be to issue a credit, or an email to the customer.
Do any movements need to occur from the dock to the service department?

Where do the returns get received?

While this is a simple question, it can have a lot of configuration implications.

Do you need a specific storage location for all repairs and/or returns?
Will the repairs be processed in an inventory managed or warehouse managed storage location?
Is a unique shipping point needed for repairs? This is often very helpful in the storage location determination.

The ever present of question of serialization

It seems question never goes away. Shipping and receiving is often the forgotten when dealing with returns and repairs. If your shipping and receiving areas are familiar with serial numbers, this should go pretty quickly. However, if serialization is new to the group, be sure they are prepared for the following

Repairs may require a serial number, what if the serial number isn’t readily available or visible?
What if the serial number returned doesn’t match what is expected?
Will shipping ever be required to create a serial number for a repair? If so, is the labeling hardware available in an accessible location?

Shipping the Product back to the customer

Do you need to be concerned with returnable packaging?
What paperwork needs to be provided to the customer upon return of the product?
How are special shipping instructions provided to the shipping department?

Hope you found this helpful, and as always, please post anything else I may have missed or if you have any questions.

Thanks,

Mike

SAP SM Blueprinting Questions – Sales / Customer Service

08MayJune 27, 2016

Well, I’m back again to continue my blog on blueprinting for SAP Service Management / Customer Service. This next portion tends to be one of the biggest areas for me in dealing with SAP SM blueprinting. I’ll do my best to keep it straight forward to give you the best details I can on SAP SM Blueprinting. Please also refer to my other posts about Master Data and the Call Center blueprinting.

What processes does your business currently utilize?

This one simple question usually has the most impact on the service blueprint, at least in my experience. You need to understand what processes your customer currently uses. Once you understand what those processes are, you should be able to map them to SAP relatively easily. Inevitably, some of the processes won’t be mentioned, so do your best to ask about each of these in detail.

Repair and Return Processing (in-house)
- This is the standard SAP repair processing. This will involve sales orders, deliveries, service orders and often notifications. There are a lot of variations that can be built into this standard process, and you’ll want to understand if any of them apply. Some of the variants include:
  - Are Loaned Items offered to customers? are they offered to all customers or only customers who have purchased a “premium” service of some time.
  - How does scrapping need to handled for customer own equipment?
  - Is it fixed price billing? or Time and Material billing?
- How many in a day/week/month?
Advanced Exchange Processing
- This process is a variation of the standard repair process. The exchange is simply sending a new unit to the customer before receiving the customer’s unit. This is often offered as a premium service to customers. Some questions that need to be addressed for this process include:
  - How does billing occur? is the customer billed as soon as the exchange is sent, and credited upon receipt of the customer’s equipment? Or is the customer billed after the unit is received and repaired?
  - Are brand new units sent as an exchange? or are refurbished units sent as as exchange?
  - What happens to the repaired inventory? Is it stocked as a new number or different valuation type? is it put back into stock as new? Does it need to go to a special inventory location?
  - Does the repair of exchange need to be tracked separately? does it require it’s own service order type? does it need special scheduling, for example all standard repairs must be done first before working on any exchange units? It is first come, first serviced?
  - Is it fixed price billing or Time and Material billing?
- How many in a day/week/month?
On-site/Field Service Processing
- On-site or Field Service is usually the easier process. Typically this consists of a service order that gets charged time and expenses. However, like everything else, there are a lot of processes that can be combined with on-site service.
  - How do you deal with components needed for the On-Site work? Are the parts sent to customer directly? do you use “trunk” stock where your technicians carry their own stock? Do you charge the customers for the shipping of parts? Do you ever use customer’s parts in the order and if so, do you need to account for those in any of the processes?
  - Do you use sub-contractors or 3rd parties to perform any on-site work? Do you need to track items like per-deim? hotel? airfare?
  - Do you track or charge for travel time?
  - Do you schedule your technicians? need a calender of events to know who is where?
  - How are costs currently tracked/entered? do the technicians enter the information? is the information sent to someone on-site?
- How many in a day/week/month?
Returns for Credit
- The easiest of the service processes, the simple return for credit. No repairs, no replacements, just a credit. Some additional pieces to consider include:
  - How does the stock need to handled when it is returned? does it need to be sent to quality, repairs or production before issuing the credit?
  - How is the process handled if the material is damaged upon return? is credit still issued? is it partially credited? Is it repaired, and if so, where does the cost go?
  - When is it returned to stock? can it go back to unrestricted inventory as is, or does it need to be a different valuation type or a different material?
- How many in a day/week/month?
Returns for replacement
- This is a gray area as far as I’m concerned in the service world. This could actually fall under the repair process and be executed like a service exchange, or it could just be a return order, with another sales order (free or paid) order to follow up.
- The biggest think that drives this one way or the other is finance. If it should count for or against your service revenue, this by all means, add it to the service process. However, if it’s just a cost of sales, you’ll want to be careful trying to make it fit into service. Someone’s budget might take a hit that they weren’t expecting. In general, try to steer this away from repair orders.
- How many in a day/week/month?

Do you perform quoting of repairs?

Such a simple question… right? nothing ever is in SAP. When you talk about quoting in the service order, there are always little considerations you have to take into account. So make sure you know what you need in advance.

Do you quote in house repairs? if so, do you quote them before or after the product arrives in-house?
- If you quote them after, please check out my blog post: SAP SM: Quoting In-House Repairs. It will explain how to quote using the repair sales order you received the repair on.
Do you quote time and materials? or do you quote as a fixed price?
Do you need to begin processing before the quote is approved? for example, do you need to make or buy materials that have a long lead time?
How do you track your quote approval/rejections?

How do you price/bill your repairs?

The pricing and billing of the repair order is actually a much easier question (at least initially).

Do you offer fixed price repairs?
Do you offer time and material billing? If so, what do you bill for?
- Labor?
  - do you break it out by straight time, over-time, travel time? If so, do you have pricing and costing rates for each of them?
- Materials
  - do you break it out by material types? Finished goods? raw materials? etc?
  - Do you display each material used? or just lump them all together into a single total?
- Subcontract
  - do you need to break this into labor and materials as well?
- On-Site expenses? do you incur these? If so, how do these need to be broken down to the customer?

Do you deal with warranty of products?

Warranty tends to be one of the most challenging pieces to deal with when it comes to the repair process. There are a lot of variables, and it seems that everyone handles it differently. So make sure you collect a lot of information. I’ll do my best to arm with as many questions as I can think of.

How do you Track warranty? is it through serialization? equipment records? time of shipment?
When does the warranty start? shipment? registration? receipt? time of creation?
- if it’s registration, how do you track that? is there an interface?
How your warranty measured? straight time? operating hours? mileage? or a combination of multiple things?
- If it isn’t straight time, how do you track the other metrics? is there any automation to capture the numbers or is it a manual process?
What is covered by the warranty? Time? Materials? customer service? on-site service? everything?
When do you know that something is warranty? do you know at the time of the customer contact? or not until you actually evaluate the material and see if it falls under warranty (this is a big one in determining how to handle warranty).
Do you accrue for warranty costs? if so, how? is money taking out of each sale of particular parts to go into an accrued warranty account? is there no accrual? What accounts should be credited/debited when doing a warranty service of any time?
Are there special considerations for profitability or COPA? (I’m no expert here, so if you’re like me, make sure you have your FICO person available to translate. ha ha)
what happens if someone doesn’t state it’s warranty? what is the process going to be? (this one is always more for me, because without fail, setting something as warranty is often forgotten and need to be corrected after the fact. Have a plan for this)
Do you perform your own service work for the warranty, or do you allow 3rd parties to repair the product and then bill you? (if so, see my post SAP Warranty Claims: A Guide for Beginners).

Do you use service contracts/extended warranty/etc?

Since we’re talking about warranty, the conversation wouldn’t be complete without talking about contracts. Unless you offer a lifetime warranty, often you will give your customers an option to purchase an extended warranty or perhaps some sort of maintenance plan. Like warranty, contracts require a lot of information to set the process up correctly.

What do you sell under a service contract? is a yearly maintenance visit? X hours of support? full repair/replacement? Exchange processing for quick turn around? extended warranty, for some or all facets of your product?
Do you use deferred revenue for the contract?
Do you use a billing plan? or do you bill everything up front?
What accounts need to be credit/debit for the contract revenue?
How is service recognized? what accounts needs to be credited/debited when something is under contract?
Will you track specific serial numbers under the contract? or any products the customer owns? (serial number tracking is encouraged)
DO you have a cancellation policy? do you have a method for extending the contract?
Do you track the costs vs. revenue associated with the contract?

This was a big topic, so inevitably, I missed something. Please add things I have overlooked to help all of us get better at blueprinting,

Thanks,

Mike

SAP SM Blueprinting Questions – Call Center

03MayJune 27, 2016

My last post started talking about the questions to ask when you blueprinting the SAP Service Management / Customer Service modules. This next installment is the SAP SM Blueprinting questions I ask regarding the call center. If you want more details, check out my post about Blueprinting Questions – Master Data.

Are you currently using call center tickets/notifications?

This question is how you can initially determine exactly what your client needs to run the call center. Some clients don’t currently use notifications or any sort of help desk tickets, and other clients can’t live without them. If they are currently using notifications, you follow up with some of these additional questions.

Do you use multiple notification types?
- Some clients want the distinction between return merchandise authorizations, simple call center calls.
- It’s important to understand what is different between each type of notification. It might be possible to consolidate notification types, and report in different method.

How many calls are you tracking in the course of a day/week/month? How many people are taking these calls?

This question will help you to gauge exactly how much time a call center representative can devote to entering a help desk ticket. If you receive a 10,000 calls in a month, and it’s spread between 4 people, the call center won’t have the time to capture every detail of every call in a ticket. However, if it’s a well manned call center, it might be feasible to turn every call into a notification that may be closed when the call is ended, or may required follow on actions.

What information do you capture during a call?

This is the biggest piece of your work for the call center. Based on this information, you can design your first pass of the notification. Including what screens and what fields should be on the first tab, and at the top of the page. Remember, you can capture as much information in the notification as you want, but there is a trade off between time to enter the data and how you use that data. Be sure to stress that you should only capture what you will use, or your just throwing away hours on data entry.

Do you use tasks/objects/etc. in your notifications?

This is question that determines just how functionality you will incorporate into the notification. Implementing tasks/objects/activities etc. gives you the option to incorporate workflow, and assign tasks to individuals. You want to be careful with this, since this functionality can add a lot of overhead to maintaining your notifications.

Do you generate repair sales orders directly from the notification?

If you do repair processing, or even straight returns, you need to generate repair sales orders or return sales orders. This is standard functionality in SAP, but remember to be aware that only limited data from the notification is passed to the sales order (unless you enhance SAP). For example, there isn’t an out of the box action button to generate a return order.

What follow on activities are needed from the call center?

Notifications in SAP can spawn other activities that need to happen, or simple things that need to be logged, like a phone call to the customer, or add an entry to the solution database. It’s important to understand what your customer really needs. Most customer initially think they want a lot of these things. Remember, to keep expectations in check. While all of this and more come standard in SAP, it’s important not to overload your call center team just because something sounds cool.

Log Phone Calls
Create Internal Note
Quality Notifications
Send Confirmation of Receipt
Solution Database
Send Final Notice
Other Actions?

Do you generate service orders directly from the notification?

Remember, when you start this discussion that there is a difference between the repair process and simply generating a service order directly from the notification. Typically, when a service order is generated directly from the notification it is either for quoting or perhaps for on-site/field service. For in house repairs, best practice is to use the repair sales order/process, which is often generated from the notification by the action box. Often this question is either a part of or leads to a process discussion. How do you want to generate your work orders that are not in-house repairs. This will vary from client to client, but I’ll always recommend that you keep your processes similar whenever possible (so make your field service orders work similar to your in-house repairs).

Do you have any workflow or customer programs designed around the notification?

This question often ties into the use of tasks/objects etc. This question covers you in case you need to worry about interfaces that create/change notifications in the system, or any emails/workflow that are required during the processing of the notifications.

Do you currently track any metrics around the notifications?

This is always a tough question to tackle during blueprinting, but it’s better to gather the requirements now. In short, what are the company metrics your call center is measured on. Sometimes these are corporation wide, other times they vary from division to division. Either way, you’ll want to find out how the call center is measured, and be sure to include a method in your notification to capture that data. Most likely, you will need a custom report to deliver this information, but nevertheless, find out early. Here’s some common metrics I’ve encountered.

number completed
Amount of time open
Number of open tasks
Etc

Do you have any on-line/web based notification entry systems for your customers or suppliers?

Finally, does your customer have any web interfaces or tools that allow your customers to by-pass the call center by registering their own products or creating their own RMA’s. This is a great cost savings, but requires significant programming to accomplish.

Alright, that’s what I have for this round. I’ll be back soon to continue this blueprinting discussion. Again, please chime in with anything else in this area that I may have missed.

Thanks,

Mike

www.paperstreetenterprises.com

SAP SM Blueprinting Questions – Master Data

30AprJune 27, 2016

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

20AprJune 27, 2016

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.

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.

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

20FebJune 27, 2016

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.