SAP

Home / Archive by category "SAP" (Page 20)

Service Management – Configurable Service

Not long ago, someone asked me about configurable service.  Well, naturally, this peaked my curiosity.  After all, my two specialties are Variant Configuration and Service Management.  Now, I’ve always known that you could make a DIEN configurable, but as far as I knew, you could use it for pricing and classification, but that was about it.  So I decided as soon as I got some time, I’d do some digging into this.  Well, I finally got around to that digging, and was pleasantly surprised, and as so often happens, it was a mixed success.  So, let’s talk about the good part.

With some digging, and some experimentation, I was able to find 2 methods that gave me a configurable routing (and if I drill into it further, the components seems to be configurable as well).  So, start with your standard VC tasks.  Create the characteristics and the class to hold all your attributes. Next, you need to create yourself a Super General Task List.  Go to transaction IA05.

blog2-02

Just go ahead and copy or create a new task list.

blog2-03

 

Enter in all the possible operations that can be chosen for this service product.

blog2-04

For each operation, enter in an object dependency, a selection condition to be exact.

blog2-05

Here is a sample global dependency (by the way, I always recommend global over local dependencies).

blog2-06

As you can see, the code is simple.  Just a characteristic and a value.  Repeat this for all the operations that are dependent on certain characteristics.  Once you’ve enter in all the dependencies, save and move onto the next step.

Now things change a bit when you move to the configuration profile.  I’m an old school VC guy, so I’ve always used material.  I’ve almost always looked right past the following selection.

blog2-01

So, if you select the General maintenance task list, instead of a material, you will need enter in the task list.  Once inside, the configuration profile is like any other profile.  You must assign a class (type 300).  You can get fancier here by adding procedures or constraints.  But for our example, I’ll keep it simple.

Now, to keep things easier to deal with, go to transaction OISD, to select the general task list.

blog2-07

My example uses the standard Return and Repair process.  So after receiving the equipment, I use the repair sales order to generate the service order.  Now, the drawback to this approach is that you must enter in the configuration during the first visit into the service order.

Up to now, I’ve been unable to make the routing recognize the configuration as a configurable service product.  Only if it is directly linked to the task list.

Now, reading the documentation…  it’s a little vague…

Use Features
PM, maintenance order Assign an object dependency and a configuration profile to the general maintenance task list.
CS, service order with configurable service product A configuration profile is assigned to the configurable service product. From this, assign object dependencies but no separate configuration profile to the general maintenance task list. If, however, you still choose to assign object dependencies, they will be ignored by the system.
CS, service order with “normal” service product Assign an object dependency and a configuration profile to the general maintenance task list.
PM and CS Assign an object dependency and a configuration profile to the general maintenance task list.

If you assign the general maintenance task list in the Customer Service component to a service order with a configurable service product, the configuration of the service product has priority over the configuration of the general maintenance task list.

I’ll continue experimenting, and if I can make it work, I’ll do a future post.

As always, thanks for reading,

Service Management – Creating the RFC to download to Access

One of the recent discoveries I found was that you can download the table structures and populate them in Access on a local machine.  This is kind of a cool concept, as I never realized this functionality was available.  So I decide to dig in a little further.  The baseline configuration is pretty easy (check out my post in SDN if you want more details – Service Management – Basic Settings – Print Control – Download – Download Structures to PC).  Now, what isn’t really explained is that you need some stuff in place in order to be able to use this.  The main piece being a couple of RFC’s.  Now, I’ve been able to piece together a few things, so I thought I’d share them with you.

First and foremost, before you can do anything, you need to get or find several files:

wdpsastr.exe
wdpsatab.exe

Without these 2 files, you won’t be able to create the RFC.  Now, after some digging I’ve found a few things. First, there are some OSS notes that explain a lot of this, so I”m going to include them here.

443027 – MS Access Interface – Access 97, 2000, 2002, 2003
583698 – FAQ note – MS Access Interface
118827 – Interface MS Access, setting the TCP/IP connection

These notes explain what I’ll be going over here, but consider my post a short cut for service 🙂

Also, if you have trouble finding these files, check out the SDN post.

http://scn.sap.com/thread/292398

I had trouble getting the files from Service.sap.com, but I was able to find them in an old version of my gui installation.  However, it doesn’t appear to have the installation files to put the correct dll files in place.

Once you have this installed, you can go to SM59 to create the 2 new RFC destinations.

blog2-01

Press create to make a new connection.  You will need to do this twice.

blog2-02 blog2-03

Now, you should be able to proceed with the actual configuration to download the service management tables into access.

Thanks for reading,

Variant Configuration – Class Type 200 vs. Phantom KMATs

Recently, I was reminded of one of the biggest downfalls of using class type 200 within a VC BOM.  The is the inability to track the changes using ECM.  This got me to thinking about the differences between the approaches of Class Type 200 vs. Phantom KMATs.  While both methods cwill ultimately get you to the same place, there are very obvious differences between the 2 methods.  In general, both approaches are very valuable, but each has pros and cons.  So let’s talk a little about the differences…

Let me define what I mean by a phantom KMAT.  This is simply another KMAT that sits on the top level BOM.  So this turns into nested KMAT’s, but often there is no configuration that occurs on the phantom level.  It is more of a BOM grouping, with pass through values (if could be configured, but for our purposes today, consider it just a group of parts).  You simply create a KMAT, say Hard Drive, that contains all of the possible hard drives you wish to use.  Then you add the selection condition to each component, set the Material master of the HARD DRIVE KMAT to be a phantom and you’re ready to go.

The first major difference is the change management aspects.  Because of the way the class type 200 works, you can’t add or change materials using Engineering Change Management.  For many organizations, this can be a show stopper.  The convenience of not creating selection conditions for each material, but simply adding characteristic values can be tempting…  but if your organization needs to do a lot of obsolete and supersceding of components, class type 200’s can be a major obstacle.  Now the Phantom KMAT will not have this issue.  But, the price is creating a selection condition for each material on the BOM, and also using a constraint to pass the values from the parent to the child KMAT.  You may also need to create a class for each Phantom KMAT that only holds the characteristics needed for those components, or you could reuse the entire class.  Either way, it can be more overhead.

Reuse of the items.  This is the place that both methods work great at.  Now, one of my favorite things to do is create generic KMAT’s that can be used across multiple product lines.  In my first VC job, we did a lot cables with 35 or more different connectors that can be used.  Well, since the same components were often used across multiple product lines, I could create a single phantom KMAT and use it on multiple top level KMAT’s.  the Obvious value is maintaining changes in one spot.  the hardest part of this method is thinking far enough ahead to make it useful.  Now you can do the same thing with class type 200’s as well.  So both methods are great for this.

A single component vs. as many as you need.  Now another obvious drawback to class type 200’s is the limitation of only being able to select a single part number.  If you had multiple part numbers, you would need multiple classes to select all the components.  Within a phantom KMAT, depending on your selection conditions, you could select as many as you need.

So far, everything seems in favor of the phantom KMAT, but here’s one that is big benefit to the class type 200.  If you work in an environment where parts change often, new options are constantly added, or perhaps you engineer as you need something…  well, the class type 200 can be set to required.  this means that your sales order will show as incomplete if the class doesn’t find a material.  Phantom KMAT’s don’t have an easy way to accomplish the same thing.

Now there are other pro’s and con’s, but in my experience, these are the 4 biggest features to keep in mind.  I’d love to hear your comments.  Thanks for reading,

Warranty Claims – Layout – Define Screen Layouts

Well, I thought I might as well do posts on the Warranty Claims.  I wanted to start talking about the Layout section of configuration.  If you are familiar with the notification or equipment records, you should be very familiar with this concept.  You have a lot of building blocks, and endless possibilities of what to show, what sequence and what tab.  Let me show you just how flexible it can be.  The Define Screen Layouts is ever more flexible, in my opinion, than the equipment record or notification.  You have unlimited items you can load onto a tab, not just the standard 4 or 5 fixed locations.

blog5-01

Using OWTY, you can see the layout folder.  Define Screen Layouts is our destination today.

blog5-02

So, you will now notice the familiar tree structure on the left.  If you are designing your own layout, I highly encourage you to copy one of the existing layouts and change it to fit your needs.  For demonstration purposes, I’ll walk you through the SAP layout.  Highligh SAP, then double click on the Tab Page Title on the left.

blog5-03

Now on this portion, you can see each tab that is configured for the layout.  Again, you can define as few or as many tabs to be displayed for your layout.  You can also adjust the titles of each tab.  For demonstration, I’ll select the Header Details tab, to show you the next drill down.

blog5-04

Now, for those of you familiar with the equipment configuration, this will be somewhat familiar.  The nice thing to notice is that you are not confined to the 4 or 5 fields.  You can add as few or as many boxes as you want.  The Group Box contains sets of fields that you can add.  Unfortunately, you cannot alter the fields within a group box, but at least you can limit what you show.  As an example, check out some of the many group boxes available for the warranty claim layout.

blog5-05

This is the part that typically requires a lot of experimenting.  Many of the options look similar, but will have quite a different look and feel.  So I encourage you test each one to make sure the optimal selection is made.

You’ll just continue this process for each tab, until you have your claim layout.  Remember, if you create a new layout, you will need to go back to your claim configuration and enter this new layout.

thanks for reading,

 

Warranty Claims – Control Data – Warranty Check

Well, I recently talked with some old colleagues about an upcoming new avenue of business for them.  One of the options was Warranty claims, so that got me thinking that I should get back to this configuration piece of warranty claims 🙂  Today I’ll discuss the Warranty Check.  The configuration itself is pretty straightforward.  The idea behind this single piece of configuration is how the action (A200 Warranty Check) should behave.

blog4-01

Using OWTY you can see where to configure this step.

blog4-02

Now the configuration portion only has 2 pieces.  One is the LinkItemResults which can be either AND or OR.

This field comes into play if you have a complex master warranty that contains more than 1 item.  So if you have a simple time based, this won’t impact you at all.  But if your master warranty has multiple items within it, and you select AND, then all items must be true for it to be considered under warranty.  If you select OR, any one item will suffice to be considered under warranty.

The FactoryCalender is exactly what it sounds likes.  Just another calender, that will be used to calculate time based warranties.

I’ll try to post more warranty claims config in the coming days, as I don’t have anything else interesting to post at the moment.  I’m currently trying to catch up on my sleep after 3 incredibly long weeks.

Thanks for reading, and as always, if you want to hear about something in particular, let me know.

Variant Configuration – Balancing Options vs. Maintenance

Today, I’m going to talk a little bit about the “theory” of variant configuration.  I use the term loosely, because, well, everyone has their own theory.  I guess that’s why it isn’t a law 🙂  One of the struggles I encounter over and over again is clients that want to use the variant configurator to handle 100% of the options for a product.  Without a doubt, the first place I learned VC was still one of the most solid implementations I’ve ever seen.  But ever there, the line would occasionally get blurred.

Let me walk you through what I mean.  Whenever I walk into a VC project, I go in with the expectation of being able to handle 80% of the product options.  Some places more, some less, but it all depends on the complexity.  For example, let’s just say you have an option that is order twice a year, but it works like everything else.  It’s just a simple option, no complex logic, so in my mind, it’s a no brainer, add it and probably never sell it, but life isn’t any harder from a maintenance perspective.

Now, we take the flip side.  We have an option that gets order let’s just say 12 times a year.  But this option has a lot of extra rules built around when it can be picked, what it can be used with, complicated BOM components dependent on multiple things.  Well, now what do you say?  if it’s me, I try to push back saying it should be a special.  What’s a special Mike???  Well, very simple.  It’s a standard part number in the system, you can even copy the BOM rules from VC to get everything else right.  But you keep that stuff out of the VC.  “But why?  VC can handle it?”

While that statement is technically true, VC can handle most anything.  What becomes the defining factor is the increased logic that all the simple things now have to work around, along with the time to “decipher” what is happening every time a new option gets added, or something simple changes.  That costs time, money, and even processing speed.  For a “possible” 12 orders, that just as easily could have become standard part numbers.

Now everyone will take their own stance on this, and everyone is probably right…  for their scenario.  I’m just telling you from my standpoint, specials should be special…  standards should be VC 🙂

Thanks for reading,

Variant Configuration – Using the SCE Debug

Well, a while back, I did some posts about different ways to debug in the IPC.  THere was one more way that I never talked about, mostly because I hadn’t been able to get it working on my machine.  Using the SCE Debug as a tool is a great way to test your models on a local machine.  While it won’t contain all the same information as doing it online, it does give you the opportunity to play with your model without being connected to SAP or even the internet.

The modeling happens in R/3 as usual. If something is to be tested in IPC, a runtime version has to be created. This is of course the same pre-requisite for the IPC running in VMC of ECC. However instead of calling the report to publish the runtime version to VMC’s DB, you download it, using transaction CU36. It will download the whole KB into flat files. The flatfiles will then be imported into a (local) database. This process is executed by a simple batch file. After the flatfiles are imported, the RTV is available to SCE.  For more information on this, see my previous posts.

Select from the menu Trace–>Trace Settings.

blog01-01

In the dialog you can select an appropriate input level for filtering out some details (if wanted). 9 will show everything, which makes sense for a trace.

Select from the list of modules, for what you want to receive log entries. They are as follows:

Module Description
DDB Dynamic Database. This is the memory of the inferencing engine, storing all facts about the current configuration state.
PMS Pattern Matching System. Constraints are considered declarative. This means in opposite to procedural coding where everything is executed line by line, constraints describe a status and will be executed in any undefined order if their pattern is fulfilled. The pattern usually exists of an object declaration as well as a condition. The pattern matching system is responsible to find those constraints, which patterns are fulfilled.
CSTR Constraint. This is useful for figuring out for example in combination with DDB, how a constraint influences facts.
RULE Rules. (If used) Mainly used in Advanced mode as monitoring rules
CFG Configuration
SCND Selection condition (good for troubleshooting existence or missing items on a bom explosion). See super bom.
PCND Precondition. If used. It is strongly recommended not to use any preconditions.
PROC Procedures. This option makes most sense in combination with DDB, seeing which modifications happen.
FUNC Functions
TABL Variant Table access

Table 1 “traceable engine modules”

Very typical and useful settings are DDB,CSTR,PROC. Eventually SCND if the bom explosion is to be verified.

After selecting the options, you can do any modification directly in the SCE UI. With each selection / modification, you see traces being updated in the lower part of the window:

blog01-02

The trace area is not very powerful regarding functionality like search etc. The right click menu allows to clear or to save it to a file. It is however possible to select all entries with ctrl + A, copy the traces (ctrl + C) and paste them into an external editor, such as notepad++.

One of the biggest benefits of using the SCE over using IPC is if you want to see the initial logic being executed, you activate the trace and create a new configuration session (with the white paper icon in sce).  The IPC will automatically execute the initial logging before you can begin the simple trace, so often this will help you find problems within the initial execution of your dependencies.

As always, Thanks for reading,

Service Management – Using the Installed Base

I recently decided I wanted to understand a little better how the installed base works within in ERP 6.0.  I certainly found some things I liked, and some things that were disappointing.  For any of you experts out there, perhaps you can tell me if I’m missing something in configuration (I looked, and found nothing).  So, let me tell you about my finding…

Transaction: IB51 allows you to create a standard installed base.  you select your type of IB and simply press enter.  Here is a sample screen shot of a quick IB that I put together.blog01-01

What I like is the ability to add most any type of object into the installed base.  I can add straight materials, equipment, functional locations, Documents, Text or even other Installed Bases.  Very cool, because it can truly be a repository of most anything you might have at a location.

Now, it got even a little more cool, when I looked at transaction IB61, this allows me to copy from a sales order or a production order and bring in the items automatically into the installed based.  A very handy tool.

Now, for the con of the Installed Base.  The number one thing I was missing was the ability to assign partners to the Installed Base.  I have become a big fan of attaching partners to equipment records, functional locations, notification etc…  suddenly not having that option left me feeling a bit naked.  You can assign a single address, and probably work some hokey methods to tie text to a partner number.  But why not just integrate the option.  Oh well.  It could be worse.  In addition, installed base does not fix the issue of having to manually maintain everything when something changes.  So, just like the serial number hierarchy within the equipment record or functional location, if you make any changes, you have to manually do the adjustment in the installed base.  The most common example I run into is that a customer sends back a piece of equipment and for one reason or another, a new unit is sent to the customer and the old number remains at the plant (or gets scrapped).  You must manually go into the installed base and make the swap if you want to keep things accurate.

Overall, it’s not bad functionality, if only I could assign partners to it.  If you know what I’m missing, please comment on this post.  I’d love to know 🙂

Thanks for reading,

Variant Configuration – SCE UI Load KB

Well, since I’m on a roll, figured I might as well show you how to load the KB into the SCE UI within your local database.

The first step is to make sure that you extracted the latest files from CU36 (see my previous post for details on this).

Now, here is where you need to do a little work.  In your IPC installation directory (and I use the word installation loosely, since it was just a zip file with a bunch of files).  So, what needs to happen is to copy all the flat files into the ..\db directory (for me, there was an intermediate folder, so for me it ..\db\temp\ to hold all my flat files.

Now, one additional step that I needed to do was copy the file sce_import_meta_data.sql from the ..\lib\scripts\ directory and place it in the ..\db\ directory (notice that even for me, it was not in the temp directory).  Now, I also needed to rename this file to be: import_meta_data.sql

Once this prep work has been completed, go the ..\bin\KBAdmin.bat

blog03-01

Verify your DB settings (see my previous post on the SCE if you need more details on how to set this).

blog03-02

Use the menu:  knowledgebase–>upload

blog03-03

enter in the location you used for the flatfiles (see above for more details).

Press Start Upload.

When it’s done, you will now have the DB populated with the knowledge base you loaded.

When you know what to do, it’s pretty easy…  but this took me a few hours of experimenting to figure out what to do… =)

Thanks for reading,

Variant Configuration – Creating the Knowledgebase

Well, now that you know how to get the database setup for the SCE UI, you need to work on creating the knowledgebase.  This is pretty straightforward exercise, but it does require a few transactions to perform the whole process.  Let’s walk through what you need to do.

blog04-01

We start with Transaction: CU31 to create the KB object.

blog04-02

Much of the information is just descriptive, so set the status and give it a description.  THen press the profiles button.

blog04-03

Again, these are just names, so name the Profile and give it a description.  Then press enter.

blog04-04

Now, we finally get to some real data.  I typically enter in the KMAT material, but you could do it by class and class type.  Add a description and then save.

blog04-05

Now that you have a knowledge base, you can create the runtime version (RTV).  Go to transaction CU34.

blog04-06

IN this screen, we set up all the vital stuff, including what plant the BOM should be looking at, if it’s a production BOM or Sales BOM, etc… Also, a very important field is the valid from date.  Remember, that KB’s and RTV’s have no concept of engineering change.  This means that the valid from date is VERY important for your process going forward.

After you enter in the info, I encourage you to check.  Press the syntax check button, and you will receive a report of your model.

blog04-07

My model is very simple, so everything is green.  If anything is yellow, be sure to pay close attention.  This could cause you issues within the SCE/IPC.  The question mark to the right often has good information.

Finally, green arrow back, press generate, and you have your RTV.

The last step is just to download the flat files.

Use transaction CU36

Enter in your KB and version, then press the export button.

blog04-09

The only field you need to be concerned with here is the Path.  the rest only applies if you are using R/3 or CRM as the your SCE installation.  For my purposes, I’m focusing on the offline database only.

Hit the green check and you’re ready,  Next post I’ll talk about uploading the flat files into the SCE.

Thanks for reading,