The Service Management Experts
Menu

sap

Home / Posts tagged "sap" (Page 2)

Variant Configuration – CU60E – Uploading to a Variant Table

Hey everyone, I figured it was about time I drifted back to VC for a while.  I’ve been posting about business and service a lot lately, so here’s a little tidbit that has come in very handy for me.  Often time when you’re loading in a variant table, there can quite a few entries.  So SAP built in a pretty little cool utility.  It’s CU60E.  The only problem with it is that isn’t intuitive exactly how it works, so here’s how you can make use of it.

1.    The characteristics in your file must be listed in the same order as they appear in the variant table.

2.    The file must be saved in a ‘;’ delimited file (Use CSV, and then do a find a replace).

3.    Validate the CSV file to make sure there are no quote marks included.  If there are, they need to be deleted.

4.    The upload should only be done for the initial load of the table.   When it runs, it wipes out the existing contents, and uploads the file.  You cannot append to an existing table using this transaction.

If you follow those 4 simple steps, you’ll be able to upload to any variant table using CU60E.

happy configuring!

Remember, if you need any help with variant configuration, service management or production planning, please use the contact us button above, and let us know how we can help,

thanks,

Mike

1.    the variant table.

2.    The file must be saved in a ‘;’ delimited file (Use CSV, and then do a find a replace).

3.    Validate the CSV file to make sure there are no quote marks included.  If there are, they need to be deleted.

4.    The upload should only be done for the initial load of the table.   When it runs, it wipes out the existing contents, and uploads the file.  You cannot append to an existing table using this transaction.

Inspection Characteristics – How to Add to a Material

While testing my software applications I often run into new pieces of master data that I’m not familar with.  Not that long ago, I had to learn how to assign Inspecting Characteristics to a material (so they would show up in a production order).  Since my blog is also my searchable notebook, I thought I’d share it with the world =)  Please note, this approach isn’t the only way to do this…  but for my testing, it works.  Feel free to experiment further.

Step 1.  Make sure that the material master has a quality view and you select Inspection Setup:  Select inspection type 03

Step 2.  Create a Master Inspection Characteristic (MIC)

Go to transaction QS21.  You will need to probably create a few MIC’s.  First we will create a Quantitative one.

Enter in the plant and press enter

Enter in the info shown above (you can enter more, but consider this the base amount of data).  Hit enter or press control indicators

Hit enter after filling in the above data

Enter in the above data and press enter.

Now press the Quantitative button and enter in the above data.

Enter in a catalog and press enter.

Save it and you’re first MIC is done.

To do a Qualatative Characteristic

go to QS21 again and enter in the plant

Fill in the above data and press Control Indicators

Fill in the data and press enter

Fill this in.  Press Enter and Save.

You now have 2 MIC’s.  Feel free to create as many as you want/need.

Step 3.  Add the MICs to the routing

TXN CA02 to pull up a routing.  enter in the material and plant.

Go to the Operations you want to add it to.

Highlight the operation to add the characteristics to and press Inspection Characteristics

And badda bing, badda bang, badda boom, you have inspection characteristics loaded into your routing.

Next time you make a production order, you’ll see these.

If you need more help from us, just press contact us above, and we’ll be happy to help you,

Thanks for reading,

Mike

Service Management – Service Order Number Range

Here’s a simple little post that I often forget, so why not add it to my notebook (or to everyone else, my blog).  Whenever you create a new service order type, you must remember to set the service order number range.  Relatively easy, but it does work a little different than setting the number ranges in SD, so I thought I’d run you through it quick.  Here’s where you go in configuration.  (the shortcut is txn: OION)

Select configure number ranges

Then press Edit Groups

Now once you are here, scroll all the way to the bottom until you find the section called Not assigned.

if you see any order types in this section it means they have not been assigned to a number range (I know, rocket science, right?)  So, press click on the order type and press the select button.  Then scroll up to the number range you want to assign this order to.  Click the check box in front of it, then press the Element/Group button.  Viola…  (if you don’t see the number range, you’ll have to back up to the previous screen and check the intervals.

Now, the biggest thing to remember with all of this is that if you transfer the new order type, you most likely haven’t (and shouldn’t) transport the number range assignment.  Number ranges are one of those all or nothing type transports.  So, in the new client, remember to repeat these steps to avoid shortdumps =)

thanks for reading, and as always, if you need Service management or Variant configuration help, click the contact us button above and let us know how we can be of service,

Mike

Service Management – Service Order Release Strategy

One of the decisions I often see customers struggle with is when to release the service order.  So I thought I’d give you my opinion on the service order release strategy that I’ve seen and give you some good information to consider before you make your final judgement.

Now, the biggest dilemma I hear is do I release it automatically, or do I wait.  My answer, like any good consultant, is it depends.  The biggest factor that anyone needs to consider in this choice is, do you care when the requirements move to MRP.  What happens is when a service order is released, any planned components will show as a demand in MRP.  Well, if you’re not ready to work on this order for another 2 months, in my opinion, you don’t want the demand going out for the parts as soon as it’s created.  Now, if you’re using all of your dates correctly, and have outstanding capacity planning figured out, you can probably avoid this.  Most places I’ve worked at are not that sophisticated, and don’t have the resources to maintain that level of planning for service.  In those instances, I encourage you NOT to release the service order automatically.  You can control that setting in the service order type configuration:

simply make sure this box is unchecked.  The other cool thing is that you can decide on an order type basis.  So perhaps for your field service or plant maintenance orders you do want them released automatically, but perhaps for your service exchange or even in-house repair orders, you want to manually control this.

As a rule of thumb, I generally set it to be NOT released immediately, unless it is for a Field Service Order Type.  This allows the service planner to review the order, set the dates properly, make sure the correct components have been called out, and decide if it should be added into the queue…  or this one should wait because there is already a backlog of more important service orders to attend to.

Using the system status, it is easy to see what is not released.  Simply look for CRTD to see the unreleased orders.  If it is REL, it has been released.

I hope you found this interesting.

As always, if you need more help in service management or variant configuration please use the contact us button above and let us know how we can help.

I’m also on the lookout for new topics to blog about.  if you have suggestions, please comment on any of my post,

Thanks for reading,

Mike

Challenges of the First Sale

Hi again,

For those of you that follow me, you know that I’m trying to launch my SAP Add-on Applications business.  Well, if you remember, several months ago I announced that my first sale was pending.  Well, it is still pending, and I just wanted to relay some of the challenges I’ve encountered, and some lessons I’ve learned based on my experiences over the past few months (I know, crazy the amount of time it can take for customers to truly decide to buy).

Everything started a couple years ago when I worked at a client, and the need for a service dashboard first popped into my head.  As it turns out, one my clients that consulted for was interested in my dashboard.  Imagine my excitement.  Someone wants to buy what I’ve put nearly 6 months of work into (at that time, since it’s been even more.  lol).  Sweet…  so I scheduled a demo, everyone liked it…  then I waited…  I emailed to check in to see if there were questions I could answer.  I always tried to not pressure my prospect, so I’d just drop an email every 2 weeks or so to see if there were questions i could answer, or anything that would help them decide if my dashboard would be a fit.

Eventually, I get an email that says my prospect is interested…  Now I’m really excited.  So next begins the negotiations on price.  Well, my first piece of advise, set your bottom price you will accept, AND STICK TO IT.  I failed this first test.  When the prospect came back and gave me the price they thought was fair, it was $5000 less than my bottom line.  What did I say?  “OK”.  What should I have said…  “I’m sorry, but for we can’t possibly sell something for less than X”.  Ok…  so I dropped the first ball, but whatever, I got my first sale, and I just need them to sign my paperwork.  Oops.  I don’t have any paperwork.

So, next mission is come up with all of the terms and conditions.  Luckily for me, I at least had the legal portions of this that I got done a while ago.  But, I still needed the specific purchase agreement document.  Lucky for me, I’ve been a consultant for a while, so I know all about contracts.  I also had my SAP paperwork that had the agreement for my partnership.  This made a perfect starting point, so I quickly put it together, ran it past my partner.  We hashed out the details we could live with and quickly sent it over to my customer.  I’m giddy as a school girl.  I can see my first payday for all the effort that I’ve put into this venture.  I’m already planning my next product that I’m going to sell to this prospect…  it’s awesome.

Well, more waiting…  roughly ever other week, I’d finally get some feedback from the prospect.  The first round was a lot of changes, to both the legal document and purchase document.  So, first order of business is getting my lawyer to look at it and make sure I’m still protected, and won’t lose my software based on the wording from the prospect.  Within a week, I hear back and have my answers.  So I do my markups.  Now the purchase agreement is where the trouble came in…

Now, keep in mind, I’m still excited, this is my first sale, and I can’t wait to make it happen.  But, I start reading the markups and I get a bad feeling in the pit of my stomach.  I vent for a few minutes to my partner, and then calm down.  The prospect is now requiring free training.  Well, it’s a report…  who needs to be trained on a report???  anyway, we decide that training isn’t being given for free.  We’re already selling this at a 60% discount (a  lot lower than I wanted).  Then, the payment terms are suddenly 1/2 now, 1/2 after implementation.  the problem is that implementation from our side is a 1 day event.  But, suddenly 1/2 of the money would be withheld until the prospect decided to implement and receive their free training…  Ugh… Then to top it all off, our business model (and everyone that I’ve talked to who does similar software) charges a yearly software maintenance agreement or licensing for a number of users.  Either way, it’s residual income year after year.  The prospect said no… we don’t want that.

So, I start with my first round of compromises (all of which benefit the prospect).  I did hold firm on no free training.  But I gave in, and say 1/2 up front, 1/2 after 2 weeks…  I made the SMA optional, and I even discounted it… something we originally agreed we wouldn’t do.  And we gave in on most of the legal points…

Two more weeks go by, and we get the next revision…  pretty much asking for more.  Training is required.  and the payment schedule of 1/2 up front, 1/2 after 2 weeks wasn’t acceptable.  We compromised again.  We gave in the training, and said 1/2 up front, 1/2 after a month.  It’s a report, takes 5 minutes to install.  No configuration is required…  so anything more than a week…

Still not good enough…  at this point, I have stopped compromising.  I’ve already agreed to more than I should have, and the possibility of getting the 2nd half at some arbitrary date in the future, was more than I could accept.  So I sent the paperwork back one last time, nothing additional offered.

So, after all this… what did I learn above all else?  Be willing to walk away.  If you keep giving in, the customer is going to keep asking for more.  It’s no one’s fault but my own.  I don’t know if my prospect will sign or not.  And I’m ok with it.    Don’t get me wrong.  I really want the sale, but I’ve already got to a point where making this sale is no longer a financial win for me.  I know this was long winded… but I wanted to let you know that the sale isn’t everything.  Even if it isn’t a physical product, there is still a point where the sale isn’t worth what you’ve given up.  So, stay firm, and don’t get too attached to that sale.

As always, learning things the hard way so you don’t have to =)

thanks for reading,

Mike

 

Service Management – Bringing in a General Task List

One of the really nice features in service orders is the ability to default in a General Task List (routing).

If you are familiar with transaction OISD, you already know that you can assign a general task list by plant/service material.  However, one of the things I often run into with clients is that the task lists aren’t specific to a service material (DIEN), rather they are specific to a material or group of materials. For that reason, SAP is so kind to provide a user exit:

IWO10020 (I believe)

this exit lets you impose your own logic on the general task list selected for the service order.  In our case, we a looked at the material in the task list header.  If the servicable materials = material in the header of the task list, bingo, add it to the service order.

You may have other rules that are more generic, product hierarchy, material group, or whatever you use to make a general group.  This way you have the ability to create the task list one time, and have it automatically pulled into every service order that matches your criteria.  This will help your planning and save your service technicians the time of entering in this data every time.

Hope you found this useful,

As always, if you’d like more help in SM, please contact us.  We will be happy to do anything we can for you.

Mike

IWO10020

Finding a New Audience

Well, since I like to be diverse, I’m jumping back to some of my marketing efforts.  Once again, some of my best ideas come from talking to my good friend Justin.  We were recently chatting, and he put the idea in my head of the “guest” blog post.  this is a concept out of the Remarkable marketing Blueprint.  We both signed up for this, and it has been so helpful to have another perspective.  Well, the idea of the guest post I pretty much wrote off.  Who would I guest post on?  I’ve looked, and I can’t even find any other blogs talking about SAP Service Management.

Justin, in his great way of playing devil’s advocate with me brought up the idea that posting on SDN is just like a guest blog post.  it is a new audience, new readers and another place for me to try to jump start my readership.  So…  for that reason, you’ll notice that I’m only going to be posting 4 times a week.  I’m going to start moving one of those posts over to SDN.  If you’re one of my readers, I’d love it if you could follow me out there as well.

Michael Piehl on SDN

Anyway, thanks for reading, and please feel free to forward me onto your friends or colleagues that you think might benefits from some good SAP knowledge =)

Mike

Variant Configuration – $Root, $Parent and $Self

If you didn’t know better, you’d think this was some strange post about psychotherapy.  Well, it’s just one of the underlying concepts you need to understand for variant configuration.  this is one of the concepts that is easier to describe with a picture.  So let’s start with one.  $ROOT, $PARENT and $SELF are the different ways to refer to the characteristics in your model.  Each of them works a little differently.

Now, what you’ll notice is that we have several nested KMATS at multiple different levels.  Now to start this conversation, we’re talking procedures.  Using the picture, let’s do a simple table to show you

Configuration $SELF $PARENT $ROOT
Level 4 Level4 Level 3 Level 1
Level 3 Level 3 Level 2 Level 1
Level 2 Level 2 Level 1 Level 1

Now, if you look at the picture, we only call out the BOM level at the bottom.  In reality, there is a BOM level for each configurable material, but it would be redundant to go through that.  The important things to realize is that $ROOT and $SELF always points to the same place.   Only $PARENT changes.

there is an exception to this rule, and because of that, I suggest avoiding $ROOT.  The exception is when you take a KMAT that was not part of another configuration, and suddenly add it to the BOM.  As soon as you do this, $ROOT suddenly points to a new level.  Personally, it’s not a method I like to use.  Prefer to use $PARENT, and then I make sure to pass the values from level to level if needed.

This pic comes straight out of SAP help.  It’s a little bonus for this blog post to help explain how constraints can deal with the separate levels.  In a constraint, the concept of $SELF, $ROOT and $PARENT don’t exist.  Everything is about classes and if they are part of each other.

I hope this make sense,

If you need more help, click the contact button above, and let us know how we can help you,

Mike

Variant Configuration – Passing Values between Nested KMATS

In this age, having a model without nested KMATs (multi-level configuration) is a thing of the past.  Because of that, I wanted to do a quick post about transferring values between the different levels of the bill of material structure.  There are 2 methods to accomplish this (at least using the standard ERP functionality).

1.  Procedure:  $SELF.X = $PARENT.X  or $SELF.X = $ROOT.X

2.  Constraint:
Object:
mod1 is_a(300)  mod,
mod2 is_a(300) mod,
Assy is_a(300) mod_component

Condition:
part_of (Assy, mod1, ‘0100’) or
part_of (Assy, mod2, ‘0100’)

Restricitons:
Assy.X = mod1.X,
Assy.X = mod2.X

Inferences:
mod1.X,
mod2.X

This rule is a very generic way to show you how to pass values down to a lower level cstic.  This variation goes one step further and actually checks to make sure that the nested KMAT is a at certain position in the bill of material.  This is not required, but can be very handy if is the same class exists in multiple positions in the BOM.  Notice, we copied down, but you could just as easily copy back up by reversing the restriction.  While not a common practice, the option is still there.

You’ll notice that the first method is far more simple, and will do the trick.  the constraint is more complicated to write, but has more power.  Personally, I’m a constraint kinda guy, so I tend to use that method.  But you need to use what fits your situation best.

Now, whenever you need to transfer characteristics between levels, you NEED to test early on in the process how it behaves in a sales order, planned order, production order and sales order costing.  Many times the behavior that works great in CU50, doesn’t translate the same way in a production order.  You may have assign the constraint/procedure at a different configurable material in order to get the rules to fire in all scenarios.

Happy configuring.

Remember, if there is anything we can do to help, please click the contact us button at the top of this page.

Mike

Service Management – Adding Multiple repairs on the same repair sales order

Now, if you’ve been doing this for a while, I’m sure you’ve encountered this issue.  The customer sends back multiple repairs for the same order, however, service notifications can only contain a single material/serial number.  Now, I’ve heard rumors that in EHP4 or EHP5 there is something that can be activated to allow for multiple serial numbers, but I haven’t seen this yet, and for most of us, it isn’t an option anyway.  Because of that, we resort to alternate processes 🙂

Adding another repair to the same sales order is pretty easy.  You must need to make sure you fill out 4 key fields.  Material (this is the service material/DIEN), qty, Servicable Material (this is the material you are fixing), Srv Qty (this is the qty of units you are repairing in a single service order).  That’s it.  As long as all your master data is properly setup, you’ll be good to go.

Now a couple of words of warning.  First, your notification will not track to any additional line items you enter on the repair sales order.  By that, I mean that if you do a lot of work/information gathering at the notification level, the document flow may not be reflected accurately.  This is because in SAP, the notification number is at the header level, even though the actual repairs are at a line item level.  Certainly not the end of the world, but it can be confusing, especially if you rely heavily on document flow (like I usually do).  Another point on this is if you are dealing with warranty/service contracts.  Only the material/serial number entered will be checked.  So if there are 5 items, only 1 of them will be checked automatically by the system if you do it all in a single notification.

Second, I always encourage using a quantity of 1 for every repair.  There are exceptions, but often the clients I deal with want their units back as quickly as possible.  If they send you 5, and 1 of them takes 2 weeks extra, they want the 4 that are done.  Well, if you load the qty of 5 in the sales order, that means you only get 1 service order, 1 inbound delivery, etc…  You could get fancy and split things up after the fact, but it will get messy and much harder to trace.  If you were to set up 5 repair line items, you could should them each as they are completed (or you could even do complete delivery).   The important thing is you have the option.  If the group of materials sent back are only useful as the qty 5, then by all means, do a single line.

Those are the quick ins and outs.  We are have an SAP app that does have one approach of connecting multiple notifications to a single repair sales order line item.  The drawback is that the document flow still only works from the notification.  If you are interested in learning more about it, please contact us.

Hope this was useful and as always, if you need additional help, please let us know.

Mike