SAP

Home / Archive by category "SAP"

Variant Configuration – My 6th E-Book

It’s hard to imagine that I’ve written 6 books now.  While the formatting portion is getting manageable, I certainly won’t say it comes easy to me.  However, it is very satisfying when I finally finish it and see that people are buying it.

My latest book has gone away from Service Management, and instead goes into my other SAP passion of Variant Configuration.  Yes, SAP Press has a book out about Variant Configuration, and I’m sure it is good.  But what I really wanted to do was put together a book that helps you model.  So this book, like my others, goes into all the nuts and bolts of each different screen and transaction.  But the real value, I think, is that I focus a lot on HOW to build up that model.  In my years of SAP, it’s easy enough to look at google, or do some trial and error.  But there was never a reference that would help me pick the best method…  there is also nothing out there that I’ve found that tells you to expect to model the same product multiple times.  ha ha ha.  If any of you have modeled in VC, you know this is often true.

Anyway, I hope you check it out.  If you do, please let me know what you think.

SAP Variant Configuration: Your Successful Guide to Modeling

Thanks for reading,

Service Management – Using the Install Base in ECC

In my travels, one of the things that companies are often looking for is an install base of their products.  It seems that the natural solution to this is using the SAP install base transactions.  After all, it is the perfect place to group things together.  You can group equipment, materials, even documents, functional location or other install bases.  So, why not use it?

Here are a couple of the major issues associated with using the Install Base within ECC.

  1. You can assign partners and partner functions.  This is standard in functional locations, but not in the install base.  A simple work around is using the external ID to become the partner number.  You would have to explicitly define your approach to say that there is an install base for each ship-to party, for example.  Not the end of the world, and this work around has been proven to work at multiple clients.
  2. There are no BAPI’s to install or dismantle components from the install base.  For this reason, I built that functionality into my Renovation product.
  3. There are no BAPI’s to create or change an install base header.  For this reason, I built that functionality into my Renovation product.
  4. There is no standard way to automatically update the install base when you ship out a new product, or receive a return of a product.  For this reason, I built that functionality into my Renovation product.  It usese a background job to collect all the specific material movements that should be tracked.
  5. There is no way to know if your end user has moved or got rid of products.  There is no fix for this.  Short of adding an IoT sensor to everything you sell, you will most likely never know what a customer does with your products.  It’s just something that will always be incomplete.
  6. Poor standard reporting.  Like many other areas of service, the reporting just doesn’t meet expectations.  This why I’ve  built a few additional reports into Renovation to make it easier to search install bases and quickly see all the products, along with warranty dates and other key information.

If you use the ECC install base today, I’d love to hear how you tackled some of these challenges.  If you would like to use the install base, but just see too many technical hurdles, let me know.  I’d love to show you what Renovation can do to help.

Thanks for reading,

ABAP – S/4 – If Line_exists

Here’s another new one I discovered.  How often you do write a few lines of code to check if something exists?  For example, a common thing I do is look for an entry in a table?  If it’s there, I need to do something, if not, I move on. For example:

read table Lt_test transporting no lines with key key1 = val1 key2 = val2.

if sy-subrc = 0.

else.

endif.

Well, in S/4, that has been condensed.

if line_exists( lt_test[key1 = val1 key2 = val2]).

else.

endif.

you get to skip the read statement.  Now, if you need the contents, this might not help as much, since you would need to extract that line anyway, but if you are purely looking for the existence, then it’s a lot cleaner.

Thanks for reading,

ABAP – S/4 Concatenate

Here’s another fun little tidbit for the new coding in S/4.  If you want to concatenate a string together you used need to do:

CONCATENATE ‘X’ ‘Y’ into lv_var.

now you can do:

lv_var = ‘X’ && ‘Y’.

Even better, you don’t run into type mismatches either.  For example, if you have a time stamp, the value is in a packed format.  This means that you must first concatenate things into a string, then copy them to the final value.  with the &&, you can skip all that and do it in a simple one line statement.

ABAP really is getting better 🙂

Thanks for reading,

SAP – Coding in S/4 – Data Statements

I recently had the opportunity to see some code in S/4.  While the old code works, there are certainly some new things that simplify coding life.  One of the fun ones I learned is how you do a smarter data statement.  Here is my first example.  You take in a customer number in the internal format, but you want to convert it to the external format.  Here’s how I do it today:

DATA: lv_kunnr_out TYPE char10.
CALL FUNCTION ‘CONVERSION_EXIT_ALPHA_OUTPUT’
EXPORTING
input = i_kunnr
IMPORTING
output = lv_kunnr_out.

Here’s how you can do it in S/4.

* DATA(lv_kunnr_out) = |{ i_kunnr ALPHA = OUT }|.

Pretty slick.  it’s not gonna change the world, but it nice to make things more readable 🙂

Thanks for reading,

Service Management – Equipment History and how to find it

I thought I’d do a post on serial number / Equipment history.  The serial number history is an amazing resource, but only if you use the serial number properly.  If you are using standard SAP, in your equipment record there is a tab called serdata.  This magical tab is by far my favorite on the equipment record.  it gives you the material, serial number, if it’s currently in stock and of course the history button:

Now this is a sample history of a single serial number.  This becomes invaluable because if you look at the legend that included in this screenshot, you’ll see a huge list of documents that will be shown in the history, but only if you add the serial number to them.

Some of the biggest culprits are the SD delivery, especially if you do in-house repairs.  if you don’t add the serial number to the inbound delivery, it won’t show up anywhere in the document chain.  You can manually add it to the SD repair sales order (using the menu extras->technical objects), then even the sales order will show it.  Now, keep in mind, your serial number profile will define where the serial number is allowed and where it is required.  I’ll be doing a post soon talking about the serial number profile to give you more details.  the important detail to take away from today’s post is that everywhere you can put a serial number you should.  If you include it in a document, it will show up in the history and give you a complete picture of everywhere the number has been used.

Thanks for reading,

 

Service Management – Resetting Equipment Status

In a previous post I talked about the equipment status.  This field can be very powerful, but at times, it’s very painful.  I have run into issues the status doesn’t get set or reset properly after certain transactions.  Today I want to talk about how to reset equipment status.

blog2-01

Once inside of the equipment record, edit–>special serial number functions –>manual transaction.  The manual transaction is the equivalent of the equipment status reset.  It allows you to force the status (remember, this won’t impact the stock)

blog2-02

that will bring up this nice pop-up window that presents you with the following options:

To stock: ESTO
From Stock: add AVLBTo Customer: ECUS
From Customer: ESTO
Delete Assign to HU: Clears the handling unit
Delete Inv. Assign: clears inventory connection

Save, and should be able to continue with your transactions.
Good luck and thanks for reading.

 

Service Management – Equipment Hierarchy

I wanted to talk about something that is relatively simple, yet immensely cumbersome in practice.  That’s right, the equipment hierarchy.  When I say the equipment hierarchy, it may also be known as the equipment structure.  It is the process of linking serial numbers/equipment records into a structure or hierarchy.  The principal is very simple, and I’m going to walk through the process.  After the process, I’ll explain what makes it all so cumbersome (if you haven’t already experienced the pain).

If you go into any equipment record and go to the structure tab.

blog-01

in the bottom portion, you’ll find the button:  blog-02 to structure the hierarchy.

blog-03

On this screen, you simply enter in each equipment record that belongs at this “level”.

blog-04

Now you can see that a structure exists.  If any of the equipment records in this list had their own equipment hierarchy, you’d see the Sb-Eq box checked.

Now at the top of the page, you’ll see the button:  blog-05  and it will bring up the entire structure report.

blog-06

My example was pretty simple, but it would also show functional locations, and would show the entire explosion.  So, pretty easy, right?

now, the problem comes into maintaining this.  Up to this point, I’m not aware of any automated way to capture the hierarchy.  Say for example, have a production order with the top level material being serialized, and you use several other serialized components to assemble it.  You must now manually create that structure (now make it worse, and say it’s a production order for 50, you have to repeat the process 50 times).  The issue becomes complicated because you may issue 50 serialized components to make 10 finished goods.  Which 5 items went into which finished product???  Without a high amount of diligence, it becomes highly manual and extremely difficult to maintain automatically.  I’ll be talking more in the future about some methods to begin capturing this information.

Thanks for reading,

Service Management – Populating Equipment Record Data

If you have dealt with service management, it’s likely this topic may be near and dear to your heart.  It is certainly a piece of functionality I have always looked for within SAP ECC.  What am I talking about?  The ability to set data within the equipment master.  Out of the box, the equipment master has limitless pieces of information that could be maintained within it.  The problem is that most of the information can only be maintained manually.  In the world of service, this becomes especially important because if the equipment record exists at the time of manufacturing, when you ship it to the customer, there is no integration to populate the partners, warranty data, and more.

After seeing too many projects that have needed this functionality and chosen to custom build it, I decided to add this functionality to Renovation.  I’ve nearly completed the first version of this tool.  I wanted to post this out there to get any feedback of functionality that might be the most useful to add for version 1.1.  And of course, to let you know that this exists, if you or your client could make use of it.

We have designed a program, that can be run in the background (most likely on a nightly basis).  Initially, the input is the Post Goods Issue date range.  This will allow you to look at all deliveries, PGI’d within a date range and update key data within the equipment record.

The data that will be updated is configurable (you choose what you want to update), but the list include:

  • Partner & Partner types from the sales order
  • Warranty start dates
  • Warranty End Dates or Master Warranties
  • Sales Area Data
  • Model Number
  • Planning Plant
  • Maintenance Plant
  • and more

In addition, I’ve included the option to set a user status for equipment that start upon installation.  This allows you to update everything except the warranty start date, and make it easy to locate the equipment records awaiting an installation date.

The configuration tables allow you to use the sales area, material number, product hierarchy and material group to set different values for each different scenario.  This means that even if different products or product families have different warranty rules, you can define those in a table using any or all of the criteria, and they will be automatically applied to the correct equipment records.

Some of the future idea I have to expand upon this:

  • Adding selection criteria to allow this to work as a mass change tool for equipment as well.
  • Additional fields for updating (extend to everything in the equipment BAPI).
  • Include Classification
  • Include Long Text

I’d love to hear your thoughts.  Thanks for reading,

Service Management – Using the Install Base

When it comes to using the install base within ECC, I certainly found some things I liked, and some things that were disappointing. 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.

Thanks for reading,