Month: May 2013

Home / 2013 / May

Service Management – Master Warranty pt 4

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.  Watch for another series in the future on some more advanced topics related to warranties, measure documents, etc…  and just as a teaser…  Rapier now includes the ability for your customer to see their customer or vendor warranty and the full status for each piece of equipment they have registered.  Thanks for reading and if you want more great tips like these, check out my Service Management E-Course.


Service Management – Master Warranty pt 3

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.


Service Management – Master Warranty Pt 2

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.



Service Management – Master Warranty pt 1

I know much of my blog has been consumed with the new Solution Sales Configuration, but happily I started to add some new functionality to Rapier, so it gave me the chance to get back into Service Management again =)  For those of you that don’t care about VC or ABAP, thanks for your patience.

Today will be part one of my series on Master Warranties, or even Warranties in general.  The Master Warranty is SAP’s solution for an easy, reusable way to attach a rule based warranty to your equipment records.

So to start this off, you first need to make sure the master warranty functionality is setup.  So, moving down the list, we first look at Check Warranty Categories.

You’ll see by default there are 2 standard versions.  Customer & Vendor.  I can’t think of another option for warranty, but SAP does give you the option to add new entries 🙂  Just make sure the master warranties you want available are checked.  By default, both are checked and normally, you want change this, unless you want to turn off Vendor Warranties for example.

Next up, we’ll look at Define Warranty Types

This is the biggest piece of configuration in the whole master warranty area.  Again, you have the 2 options Customer & Vendor.  Now there are a bunch of fields you can setup (but you don’t need to)…

D.Box.Not – If the indicator is set, a dialog box is displayed when you create a service notification that gives you the warranty status.
D.Box.Ord – If the indicator is set, a dialog box is displayed when you create a service order that gives you the warranty status.
D.Box.Inv – If the indicator is set, a dialog box is displayed when you create a service invoice that gives you the warranty status.
Status Profile – allows you set status profile (a group of status’ that apply) to a particular warranty type.
Partner Determination Procedure – just like everywhere else in SAP.  Figures out your partners.
Usage of the Condition Table & Application & Procedure – You can set this to work according to the condition tables like Pricing, listing/exclusion, etc…  This is actually new to me.  I didn’t realize this could be done, and after a little more digging, it does nothing…  these are fields for future use…  so they do nothing.  So much for my excitement.

Well, this seems like a good place to stop for today.  I’ll pick this up again in the next post and talk further about configuring the master warranty.


Variant Configuration – PLM_PMEVC_1 the new PMEVC in EHP5

Well, for my latest engagement, one of my homework assignments was to find out if the ERP 6.0 enhancement packs did anything for SAP Variant Configuration (VC).  After digging through the documentation, I was able to find one new piece that is worthwhile, if you have EHP5 in your SAP system.  There is now a new version of the PMEVC called PLM_PMEVC_1 that includes some additional functions, including the following:

New functions with respect to Bill of Materials:
o Display of BOM header data on detail screen
o Display of BOM items on detail screen
o Assign and create global and local dependencies to BOM items in the Product Modeling Environment
o Create selection conditions for BOM items with Drag&Drop functionality for characteristic values

New functions with respect to Characteristics:
o Add new values for characteristics
o Change the descriptions and long texts for characteristics and values
o Assign document info records to characteristics and values

New functions with respect to overwritten characteristics
You can copy changes from the global characteristics to the overwritten characteristic by the function Adapt to global characteristic which you access by a right mouse click on a characteristic in the model tree.

New functions with respect to Simulation:
o Assign values to reference characteristics
When starting the simulation, you can assign values to reference characteristics according to the selected scenario. This improves the quality of simulating configuration models because reference characteristics can have the same values as in sales order or material variants.
o Assignment of a Configurator
You have a new option, IPC in Production/VC Optional in Simulation, for selecting the configurator in the basic data for the header material.
With this setting, you can use variant configuration for the simulation although you use IPC in your productive system.
In the Product Modeling Environment, under Extras -> Settings, depending on the settings on the header material you can define if you want to use IPC or VC for the simulation or if you want to select the configurator when starting the simulation.

These are some cool new additions…  so give it a shot if your system has this package (if you don’t have the txn yet, talk to your IT/Basis person and ask them to activate it for you).  Happy configuring.


Variant Configuration SSC Syntax of KnowledgeBase

Finally, we have enough pieces that we can start playing with Variant Configuration SSC model.  But in order to play with the model, we need to have a knowledge base, so today we will go over the SSC syntax required to create one.  If you haven’t checked out the previous posts, they will help you catch up:

Variant Configuration – SSC Stand Alone Installation
Variant Configuration SSC – tricks to installing the local database

Variant Configuration SSC – using the Modeling Environment
Variant Configuration SSC – Syntax for Classification
Variant Configuration SSC – Syntax for Materials
Variant Configuration SSC – Syntax of Contraints and Constraint Nets

First off, if you follow a standard approach, go to the knowledgebase.ssc file (or whatever you named it).  The syntax will look something like this:

knowledgeBase AM_TUTORIAL_KB {
version “01.00” logsys “PSECLNT001” status released /*validFrom 2013-05-01*/
validFrom 2013-05-01
name ‘AM_BOOK_PRF’ material AM_MAT_BOOK,
name ‘AM_SHELF_PRF’ material AM_MAT_SHELF,

Step one, is to create the KB.  There are all the standard pieces, and since we’re in a playground, most of these don’t mean much.  the version & logsys can be whatever you like.  set the status to be released and give it a validFrom date…  Then enter in the profiles you want to attach to this KB.  You’ll notice that I have 5 materials assigned as part of this KB.  Finally, you need to define a Task.  Which we’ll define in a second.  If you remember CU31/32/33, CU35 & CU36, this is how you do it in the SSC.


Now in the task, we just need to list all the constraintNets & ruleNets that should be pulled into the KB.  It’s that easy.

Now, we just need to use Eclipse to Export Knowledgebase (this puts it into your db and allows you to execute it).

Now open the Knowledgebase (right click on the KB in the model view) and you can start playing.  I talked about this a few post ago.  Check out my post on using Eclipse for more details.  Thanks for reading.


Variant Configuration – SSC Syntax of Contraints and Constraint Nets

Alright, so if you look at my previous posts, you’ll see that we defined the initial building blocks of the SSC, we today we can start talking about some of the fun stuff.  Today I’ll tell you how to write the SSC syntax of constraint net with some constraints.  Don’t worry, soon we’ll actually have something you can play with, but like everything, gotta get the initial data in place first.  For more details on that, check out the previous posts, they will help you catch up:

Variant Configuration – SSC Stand Alone Installation
Variant Configuration SSC – tricks to installing the local database

Variant Configuration SSC – using the Modeling Environment
Variant Configuration SSC – Syntax for Classification
Variant Configuration SSC – Syntax for Materials

Constraint Nets:

constraintNet SHELF_CNET {
name “Shelf Constraints”

You’ll notice, these are very simple.  All they need is a name, a description and the list of constraints that it will include.  Please note, we’ll talk about Rules at a later date, and the syntax is similar, but the key words are different.

Now for the real fun…  Constraints.

First, here’s a nice easy one that just restricts the value set of a characteristic.

name “Restrict Cstic Values”
?SH is_a (300)AM_SHELF
?SH.domain AM_THICKNESS in
(1.75, 2.50, 3.50)

Now for me, the biggest change is the new keyword domain.  I’m still used to the old school world of VC, it used to be just enter in the cstic and tell it what values are acceptable.  In the SSC, you have to use the word domain to restrict the values (and you cstics still need to be restrictable).  Notice though that all the other pieces are the same.  Objects, restrictions & inferences (conditions are still available too).

Now, let’s step it up a level.  This next example will use some ADT’s and give you a peak at how those look.

name “Shelf Holds Books”
?SH is_a (300)AM_SHELF,
?BK is_a (300)AM_BOOK
In this example, we are relating the Shelf to the Book.  Notice that here we can start talking about the ?SH or ?BK as a whole, and even assign it to a characteristics.  In the VC world, you would have to assign characteristics, but now we are talking about “instances”.  In the SSC there is going to be a lot of talk about instances and instantiation.  Back to the code…  this rule says that if the book (?BK) is held by a shelf (AM_IS_HELD_BY is a characteristic with an ADT or Abstract Data Type).  Then we want to set the shelf ?SH to show that it holds the book.  The important thing to realize is that it’s not just any book, but it’s one specific book.  Using the ADT characteristics hold the instance number of a particular book.

How about one more example?

name “Restrict Shelf dims by books”
?SH is_a (300)AM_SHELF
?SH.domain AM_DEPTH,
?SH.domain AM_HEIGHT,
?SH.domain AM_WIDTH

This constraint restricts the shelf dimensions based on the books that have been assigned.  One other thing I didn’t mention before, AM_HOLDS_BOOKS is multiple value since a shelf can hold many books.  The restrictions in this constraint show a new syntax (at least it’s new to me in the VC world).  This is the ?SH.AM_HOLDS_BOOKS.AM_WIDTH.  What this syntax say is that the shelf (?SH) has an ADT (AM_HOLDS_BOOKS) and we are looking at the specific characteristic of the Book.  Now, since AM_HOLDS_BOOKS is multiple value, it is smart enough to look at all the books assigned to the shelf and check those values…  pretty cool, huh?

There is a lot more stuff that can go into a constraint, and I’m sure I’ll talk more about it in the future…  but this should give you a good place to start playing.  I’m still excited about this SSC stuff…  once you get past the hurdle of getting it installed, it really is pretty slick.  Thanks for reading.


Variant Configuration – SSC Syntax for Materials

Last time I talked about Classification in the SSC, so today I’m going to continue on the same theme and take a look at SSC syntax of material related pieces into the SSC (Solution Sales Configurator) modeling environment, also known as Eclipse 🙂  If you haven’t checked out the previous posts, they will help you catch up:

Variant Configuration – SSC Stand Alone Installation
Variant Configuration SSC – tricks to installing the local database

Variant Configuration SSC – using the Modeling Environment
Variant Configuration SSC – Syntax for Classification

Defining a material is pretty straightforward.  You don’t need to worry about plants or screen views, just a name, description and a class.

material AM_MAT_SHELF {
name “Shelf Material”

The other piece, that you may actually determine is optional, is the bill of material.  I’ve been learning that having a BOM isn’t a requirement when you move into the advanced mode IPC or SSC.  Being a classical guy, that takes a little getting used to.  This example actually does have a simple BOM, so it’s still good to know the syntax:

10 material AM_MAT_BOOKCASE min 1 max 999,
20 material AM_MAT_BOOK min 0 max 9999

Again, pretty simple.  You don’t need to worry about plants, or BOM types.  Just the material and what the BOM consists of.  You also need to define the min and max qty, rather than a set qty.  This is to set the limits of instantiation.

The other thing that is new for me is that configuration profiles are no longer needed (at least not for the front end).  All of the constraint nets and rule nets are assigned to the knowledge base (we’ll get to that in a future post).  Now also keep in mind…  many of these items I’m talking about will still be required for integration with manufacturing, but if you are talking purely about the front end (and this example is) then you don’t need to worry about these pieces.

more to come soon.  Thanks for reading.


Variant Configuration – SSC Syntax for Classification

Alright, now I’m starting to get the hang of this, and I have to confess, I like it.  If you’ve ever worked with me, you probably recognize that I was kinda old school when it came to the VC, and model creation.  I tended to always the old transactions rather than the cool new tools like PMEVC.  However, the SSC (Solution Sales Configurator if you forgot) has given me a cool new way to do things that really speeds things up.  Now, I’ll have to see if there’s anyway to import back into ECC easily, but for now, I’m just playing in the Eclipse tool.  Today I’m going to talk about the SSC syntax of classification.

If you haven’t checked out the previous posts, they will help you catch up:

Variant Configuration – SSC Stand Alone Installation
Variant Configuration SSC – tricks to installing the local database

Variant Configuration SSC – using the Modeling Environment

Now, here’s what I did to give myself a baseline.  I took an old presentation about advanced mode modeling from the CWG:  Advanced_Mode_Tutorial.pdf.  Hank Meeter wrote this nearly 10 years ago, but when it comes to what you can do with the SSC, it all still applies.  And since I really hadn’t done anything with advanced mode in well, I think I might have played around in a sandbox 9 years ago…  I figured I needed a refresher.  So I pulled up my own system, and I went through did all the exercises.  Now the part that sucks is that I can’t get the IPC on my systems (apparently all the money I pay SAP, and the fact that I’d use it to help them sell the stuff when I consult doesn’t warrant me getting the install files, but I”m not bitter 🙂 ).  So I could write all the rules in ECC, but I couldn’t test any of it.

Next, I did all the same exercises in Eclipse, and what’s really cool is that I could execute it there and see the instantiation, the rules firing, and even a bit of the debug functionality.  So, I’m going to break this into a few posts, and talk about the syntax in Eclipse and how to make it all work.

Now, the first thing you need is a project, so I made myself a new SSC project (see my previous posts if you need help installing).  And since this was a simple one, I got rid of a bunch of folders and just kept:

I created a file under each of these.  Under Classes, I created the file Library.ssc (because the example is about a library and books and bookcases).  Then I created a file under Knowledge-Bases called…  knowledgebases.ssc (original, I know)…

so great.  I have 2 empty files…  what the heck do I do with them.  One of the nice things about the Eclipse is that it has the helper functionality built into it.  so if you press <cntrl>-<space>, you’ll get the list of options.  Still, it’s daunting, so I cheated and used some of the starter projects I got to get me started.  So that’s what I’ll do for you 🙂

Now the building blocks of everything Variant Configuration related is Classification, so it’s the obvious place to start.


/* here’s a few examples that should get you started */
/*Here’s  numeric cstic with a defined value range */

characteristic AM_THICKNESS {
name “Thickness” numericLength 4 decimalPlaces 2 restrictable unit “cm”
0.25, 0.50, 0.75, 1.00, 1.25, 1.50, 1.75, 2.00,
2.25, 2.50, 2.75, 3.00, 3.25, 3.50, 3.75, 4.00,
4.25, 4.50, 4.75, 5.00, 5.25, 5.50, 5.75, 6.00,
6.25, 6.50, 6.75, 7.00, 7.25, 7.50, 7.75, 8.00,
8.50, 9.00, 9.50, 10.00
/* here’s your char based */
characteristic AM_MATERIAL {
name “Material” textLength 6 restrictable
“CHIP” name “Chipboard”,
“PLY”  name “Plywood”,
“WOOD” name “Solid wood”,
“STEEL” name “Steel”
/* a numeric interval */
characteristic AM_WEIGHT {
name “Weight” numericLength 4 restrictable unit “g”
intervals 1-9999
/* my first Abstract Data type */
characteristic AM_HOLDS_BOOKS {
name “Holds Books” classType AM_BOOK multiValue
/* an aggregating characteristic */
characteristic AM_WIDTH_TOTAL {
name “Total Width” numericLength 6 decimalPlaces 2 unit “cm”
specialFunction aggregating

Next up, gotta do something with those characteristics.

class AM_SHELF {
name “Shelf”
AM_HEIGHT required,
AM_WIDTH required,
AM_DEPTH required,
AM_THICKNESS required,
AM_MATERIAL required,
AM_HOLDS_BOOKS required noinput,

One of the big things to notice is that you don’t set the characteristic attributes like invisible or required at the cstic level.  You have to define it at the class.

Gotta keep you reading…  and I like to keep some ideas of what to write about next, so I’ll start the next round like materials and bills of materials tomorrow.  Hope you find this interesting.


My Apologies…

I just wanted to put this out there.  My wife is due this week with second little munchkin, so don’t be surprised if there are some days without posts.  I’m trying to write some posts in advance to try to keep giving you the information you’ve grown used to…  but even the best of us fall behind eventually =)

so in short, accept my apology in advance and I promise to be back…  of course, I might be in a bit of a fog for the next few weeks, but I’ll be here =)

as always, if you have any ideas or want to know more about something…  let me know.  I can always use new ideas for blogging =)