Year: 2015

Now in my opinion, one of the greatest things that SAP has added into the system is document flow.  this is especially true for SM.  If you’re new to SM or SD, you might not be all that familiar with using document flow.  If you’ve ever visited an SD or SM document, you’ve most certainly seen this weird little icon:  .  If you plan to do anything in either of these areas of SAP, you’ll quickly realize it is your best friend.

Document flow in SAP is simply the connection to all of the preceding/follow-on documents.  In the in house service scenario, a type document flow may look something like this:

You’ll notice that in this picture I was able to see notification, the repair sales order, the inbound delivery, the outbound delivery, the invoice, and any other SD related documents.  What you also may have noticed is the distinct lack of the service order, but there is a service documents button.

Unfortunately, in the design of document flow and the table structure for capturing this, the service documents were neglected in the initial design, so the Service Documents button I believe was an afterthought.  It’s still better than nothing, and I’ll give you some tips for making the best of it.

The first big thing you need to know is, if you’re starting at an SD document (delivery, sales order etc. ) be sure to click once on the sales order (make sure it’s highlighted, and you’re good).  then press the service documents button.  This will bring up a new screen showing the service order and any of it’s related documentation.

One of the other issues I’ve encountered with document flow is the inability to see sub-service orders in the documentation.  The only way to see if there are sub service orders is to drill into the service order, and look for the structure button

You will then need to click this button to see the sub service orders.  You can then drill into the order and see it’s individual document flow.  As a follow-on to this topic, if you have a complicated doc flow, for example…

Notification

Now with a structure like this, you again, won’t be able to see everything depending on where in the structure you are at.  For example, if start at the service order (for quoting), you won’t be able to see the actual service order used for repair.  Instead, you’ll have to navigate to the notification, and then you’ll be able to see the structure below the notification, including the repair sales order.  The way the documents are laid out above, shows kind of how SAP structures them.  Since it is a pseudo parallel path, you have to work your way up to a common document before you can see the next path.  In this example, the notification is that common document.

There is a another big thing to remember when dealing with service.  You have to turn on the document flow for many of the items.  For example, purchase reqs, material transfer, etc. must be turned on before they will generate items in the document flow.  I HIGHLY encourage you to make sure these are turned on.  Not seeing the purchase reqs, or materials issued to a service order makes your job as a troubleshooter FAR more challenging.

Now that’s the basics of document flow, and if you’re not already using it, get familiar.  For me, it’s personally one of the best tools offered in the SD/SM module.

Thanks for reading,

One of the key pieces of the in-house repair scenario is the repair procedure.  The repair procedure simply put is the roadmap of actions that need to happen when you perform a service process.  I’m going to talk about how you can set this up and use it to fit your business process.

First thing is show you where in configuration you define the repair procedure.  The following screen shot shows you where to go in SPRO to configure the repair procedure.

Initially, select the Maintain Repair Actions.  This screen will give you the translation of what each action means.  The actions are the key in the actual repair procedure, so I wanted to show you what they look like.  Normally, this screen doesn’t need to change unless you want to add better text to the action (this will show up in the repair screen).  Some of the important terminology in this screen:

• Send/Pickup Replacement refers to loaned equipment.   Simply put, you send the customer a unit to use while the repair happens, then they send it back after they receive their repaired unit.
• Replacement Part – this is an exchange.  It means the customer will keep this unit (and typically return the unit they currently have to you.  then you can repair it and add it to your refurbished/spares inventory).

Alright, now on to the real work.  Next we will pull up the repair procedures.  I’m going to walk through the example of an in-house repair that allows loaners.  the next screen will show you how to get into the repair procedure.

Select the procedure you want to view (or copy in the event of creating a new one).

Now, you’re looking at the SAP logic of the repair procedure.  What you’ll notice is that everything is broken up by stages.    Remember, for each stage you can only define a single Default.  The stages are as follows:

• 101         Accept repair: this is the actual receiving of the item
• 102         Start repair: this is the repair of the item, or the processing
• 103         Confirm repair: this is what happens after the service order is confirmed.

Now, if you look at the first stage(101) in the procedure below, you’ll see the following steps.  These are the steps you are allowed to do as soon as you enter in the material to repair.

• 101         Returns                – this is flagged at Default, so that means this will automatically be placed into the sales order as soon as the repair procedure is selected.
• 104         Send Replacement – this allows you to send a loaned piece of equipment to the customer
• 106         Replacement Part – allows you to send an exchange to the customer.

Looking at stage 102, you’ll see the addition of Manual and Conf. populated.  Before I move on, the options for confirmation (conf.):

• 01           Repair: fix me
• 02           Do not repair/can be delivered: don’t fix me, but send me back
• 03           Can be scrapped: scrap me
• 04           Repaired/for delivery: I’m repaired, send me back to the customer.

Also note, if something is set as manual, even if 01 -> 04 above are selected, the item will not be automatically added to the sales order.  It will have to be manually entered.

Now looking at the actual data for stage 2 you’ll see that the numbers make a little more sense:

• 102         Repairs                                 01                           : since this is 01, it means repair me, thus generate a service order.
• 103         Outbound Delivery         02           Manual: this is the scenario  where the item cannot be repaired, so just send it back to the customer.  This is a manual step.
• 107         Scrapping                            03           Manual:  Similar to 103, but this time we won’t even send the item back to the customer.
• 108         Credit memo                                                     :  Create a Credit Memo Request for the customer, with reference this line item.
• 109         Debit memo                                                       : Create a Debit Memo Request for the customer, with reference this line item.

I hope this makes sense of how to structure your repair procedure.  If you’d like more detail, please comment below.  Now for the next piece, how do I attach this repair procedure.

In the item category configuration, scroll to the bottom of the item category, and enter the Repair Procedure.  I’m not going into the details of how to select this item category (I’ll save that for another post).

I look forward to your comments.  If you need more in depth assistance on this check out my book,

Thanks for reading,

Why is it that with Big Data every where, GB of information, and limitless data at our fingertips,  many businesses still seem to be so poorly run.  I mean, if you listen to the hype, everything is Big Data, Big Data, Big Data.  So, what’s the deal?  how is it in an age of ERP systems that capture everything you do, we still see so many organizations struggling, or worse yet, barely hanging?  Well, we came up with a couple of things that I believe explain a lot (and I hope you can learn from it).  Most of this will be from my experience of SAP data.

1.  If you don’t know what the data means, how can you interpret it properly.  This sounds so simple, but when you stop to think about it, in a giant system like SAP, there is so much data.  If you don’t know what the data means, how can you possibly use it?  In addition, the bigger the system, the harder it is to mix and match the data into something that makes sense to your team.

2.  If you don’t know where to find the data, it’s gonna be tough to use.  Again, similar to the first point, knowing the data is in there, doesn’t help you find what you NEED to know.  In an ERP system, often there is so much data, that getting the stuff you really need can be challenging.  SAP for example has so many different dates, that knowing which data you really need to be using can be a challenge.  Figuring out the correct date, and then pulling it together to give you the information you need often takes someone with a lot of knowledge about the system.

3. Analysis of the data is key to pinpointing the true issue.  Once you have all the information, and you’ve put it into a readable format, now someone needs to look at it and interpret what it means.  Take my area for example, Service management.  If you have an issue with repairs in-house not happening quickly enough.  There are many areas to review to figure out where the bottleneck really is.  The issue could be the receiving group not processing the delivery soon enough, it could be that the service order doesn’t get released in a timely manner due to missing parts or lack of capacity.  It could even be that the service department doesn’t enter in the data when they need to.  If you don’t know what data to look it, you could be solving the wrong problem.

4.  If you don’t use the information, things can’t get any better.  Now, this is the most difficult of all things to overcome.  When an organization doesn’t act on the data they have extracted, things will not improve.  As a consultant, this is the most frustrating place to be.  Seeing upper management receiving all the data to pinpoint where things are “broken”, but then not taking any actions to improve the the organization.  A couple years back, I was a on a project where inventory was in a terrible predicament.  Things were in the wrong place, employees were not properly transacting things in the system, and every day it got worse.  The entire team kept telling them to perform a full physical inventory, yet the business refused.  Instead, they spent days and weeks counting certain areas they believed were causing the issues.  All this managed to do was shift the problem around and never solve the issue.

As you can see, there are a lot of things preventing businesses from running at their best.  The good news is that of the issues listed above can be solved if you can get someone that knows the data and how to analyze it.  The 4th issue… well that’s beyond anything I can offer any help for =)

Anyway, I’m sure I left a bunch of stuff out…  but I hope you enjoyed it.

If you’re familiar with SAP service management, you realize the challenge of seeing the full picture of the in-house repair process.  If you don’t know what I’m talking about, you’ve never tried to see the end to end service process in a single place.  Because SAP Service Management is a combination of plant maintenance and sales and distribution, this means that you have to try to get your reporting from multiple different places.  If you want to see the time it took from creating the repair sales orders to the time the customer sent you their item for repair, how do you do that?  Worse yet, how do you find out how long it takes between receiving the customer’s item and the time your service order is released?  Because you are often crossing modules, there is nothing out of the box to give you this information.

Now you may have a great SM person, who has spent countless hours working with your BW person to create this cube, so you can get some of these metrics.  In many of the places I’ve been, that never happens.  Often service is the forgotten department, always at the bottom of the development queue.  What if you could get all the information you could ever want or need on your repair sales orders?

What if you could all of this out of the box?  Well, you’re looking at it.  Our Service Management dashboard pulls together all of the information on repairs orders, including associated documents, status’ and when they were set, built in metrics to quickly see at a glance how many orders are open, received, in repair, and so much more.  If you use Service Management, your organization needs this kind of information.

If you’d like to learn more, check out demo of the Service Management Dashboard.

Thanks for reading,

When you deal with third party items, you usually need to control where the dollars are supposed to flow to the purchasing side of things.  Well, with a little digging, I figured out the configuration steps required to do it. This could get long, so I’ll probably break this into a couple of pieces.  This first piece is the Account Assignment Category.  if you are like me, you’ve seen this field in the schedule lines, but never really paid any attention to it.  Well, now I understand the value.

First, here is where you go to in configuration.

From here, you can see the different out of the box account assignment types.  In my example, X was the default.  I was having trouble getting the correct account until I came to look at the next piece of configuration.

Then like magic, I found the field I’d been looking for.

Acct Modification – this field VAX is the missing key I needed to assign the accounts.  It’s also the way to make new keys, so if you want one item category to point to warranty, and one to be billed, this is the start of how to configure that.

in addition, you can determine if you want to perform a goods receipt into inventory, or if the item is purely service related.

One more step for today…  and that’s the next step in configuration.  And this one simply needs an entry for S and your account assignment category. If you don’t make a new category, you don’t even need to perform this step.

I’m not going to go into a super amount of detail here because I’m no MM expert, and I’ll cover this in more depth in my upcoming e-book.  If all goes according to plan, I hope to publish this by mid-November.

Thanks for reading,

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 organization 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,

This is the last part of the SAP Service Management Master Warranty.  So far we’ve gone over all of the configuration to use the master warranty, and we even created a master warranty, but so far, it still means nothing.  Today we’ll go over how to use all the pieces we’ve created so far.

In this screen shot, I’ve shown an equipment record (transaction IE02).  Keep in mind, your equipment may look different, but the important piece is the customer or vendor warranty section.  If you currently do not have these fields shown, you’ll need to configure the equipment record to include those sections.  Once there, you must enter a begin guarantee date (this is your warranty start date).  From here, you either enter in the warranty end date, which is the most straightforward way to enter in the warranty.  The other option, is our master warranty we created (this is shown in the screenshot).  Now, you may be asking me…  why use the master warranty if it’s just date related?  The biggest reason to use the master warranty is that you don’t need to worry about the exact end date.  You just pick the master warranty, and it figures out the end date.  It makes life easier for any sort of automation you might wish to use, in order automatically assign the correct start and end date.  Of course, if you do anything other than time related, you must use the master warranty to handle this…  now back to the show

Now, if your master warranty includes anything not time related, you must use measurement documents.  First, press the measurement/counts button and you will then see the screen shown above.  I’ve shown you the populated version.  Notice that WTY_USAGE_HOURS is the characteristic name.  The rest, I’ll save for another day to go into all the details of the measurement docs.  Be sure to save this and then we can move to the next step.

Now, we move to transaction IK11.  This creates the first counter or measurement.  In the example shown above, you can see that on 5/7/2013, the reading was 5.  As long as it’s less than 1000, it’s still under warranty.  Normally, you collect the measurements on a regular basis, weekly, monthly, etc…

Now, once you enter in the measurement/counter, you can go back to IE02/IE03, and see the status of of warranty.  Notice, the little check mark which means it’s still under warranty.  You can even see the complete details by pressing the puzzle piece next to the status.

The last 2 shots show the the full details of the warranty.  You can see the difference between line 1 which is date dependent, and line 2 which is counter related.  All of this same information can be seen if you enter this piece of equipment on a service notification.  I hope these lessons have enlightened you on using the master warranty.

Thanks for reading,

In the last post, I finished the configuration portion of the SAP Service Management – master warranty series.  Now, that leaves us with the “important” part.  Setting up the master data and using it.  That’s what the next 2 lessons will cover. Today I’m going to talk about creating a master warranty.

TXN: BGM1 (like always, 2 is change, 3 is display)

Unless you choose to use the external number range, you can leave this field blank and simply hit enter.  The system will come up with the next available number for you.

Now you’re looking at the initial screen (after I filled in the basics).  Let me just touch on these fields.  If we look at the header section, you’ll notice there are several fields filled in.  Like everything, a description is needed.  Next you choose if this will be a customer or a vendor warranty (if you have any concerns or other options, see my previous posts on the configuration).  I also checked the pass on warranty box.  This simply says that I want to pass this warranty onto any sub-equipment records below this one.  It goes back to the inheritance of the warranty.  The remaining fields are sort and text type fields.  They aren’t required, and may never be needed.

Now we get to the heart of things.  When you look at the Services tab, you must enter at least one service.  Think of an entry in this section as a warranty “grouping”.  Each enter you post here is a service material, so you will need a DIEN or similar material master to exist.  In a master warranty, you can add as many materials as you like here, and can assign characteristics for each material.  This comes in handy for example if all service “time” is covered under warranty, but only certain materials are covered under warranty, you could list those out individually.  Once you enter you material(s), you will need to highlight each one, and select the count tab.

The count tab is truly where the magic happens.  In my example above, the warranty1 material will be true if it is inside of 24 months (characteristic 1) or the Usage Hours is less than or equal to 1000 hours.  The first line is purely time dependent (remember the flag we set in config for time).  The 2nd characteristic will be based on measurement documents since this is the only way we can know this value.

At this point, we can save or repeat the count tab for each remaining material we entered in the first tab.  Next time, we’ll show you how to add the master warranty to an equipment record.  Thanks for reading.

Today I want to continue with the Master Warranty configuration I started yesterday.  This time around we will get into more details…  more of the nitty gritty.  If you missed part one of this post, check it out here.

The important piece is to make sure the customer and vendor warranty are assigned to a number range.

Next we move onto the Initial Transactions: Default Values.  This is rarely anything you need to change, but I like to be thorough   It simply sets the defaults for the transactions.  By default, it’s set for the customer warranty, which is the most common master warranty, so unless you do more with Vendor warranties, you can leave this alone.

Now we get to the fun part.  In order to complete the configuration for the master warranty you need to create some master data.  Now, I’ll be honest, I hate the way this works, because you must create master data in your configuration client…  but it is what it is…  Now, is where you need to do a little planning.  You must create some characteristics (I’ll get that shortly).  Now the characteristics need to be the same in all clients (at least the name).  How many characteristics you need to create is based on what you need to track in the warranty.  In my coming example, I needed to track 2 things.  Straight time (in months) and the number of hours the widget was used…  so I created 2 characteristics.  I’m going to cover the creation of those now…

TXN: CT04 – this to create the time based characteristics.  Be careful with your naming convention, because you may go down the road and need one for years, one for weeks, who knows…  so be specific in your naming.

Nothing fancy in the setup…  but it is a good idea to include a Unit of Measure.

Once your characteristics exist, you head to the last step of configuration.  Define Warranty Counters.

You’ll notice that I added 2 characteristics.  Keep building this list for all the things you want to track.  Now for things that are purely time dependent, make sure you set that flag.  That tells the warranty that it is based on time not on measurement documents (we’ll cover those in the upcoming posts).

Ok…  the configuration is done.  Next up, we’ll talk about the master data to use that configuration.

As always, thanks for reading.