VC – Moving a product line with ALE

29JunJune 27, 2016

Alright, today I’m switching gears. For those of you that know me, you’ll know that VC is actually my first job in SAP, so I still hold a fondness for everything variant configuration related. I recently helped out a client to move a product line from one system to another, so I thought I’d share it with all of you how we used ALE to accomplish this.

Now let me begin by saying I’m not a basis person, I only know enough to be dangerous. So, in order to initially get ALE up and running, work with your basis team. They need to set the EDI partners, and all of the object types. Some of it may also be trial and error the first time. Simply because SAP provides multiple options for the same object, and some options only work with certain processes. If there’s interest, I can do more homework and go into this on another post. For today, I’m going to assume your ALE connections are properly setup.

Moving all of the VC master data is no small feat. When I first started in 3.0F, there was no ALE, so we actually wrote ABAP to do uploads and downloads to other systems. ALE is much easier and much faster. Like everything in VC, there is a process a certain order to things, so I’m going to run down those right now.

About this guide: All of the fields you need to be concerned with are listed below in the screen shots. Every one of the transactions contains the field Logical system. I will refer to that as the Target system. In addition, most screens contain a field for Engineering Change Number. Below, I define these fields. It is up to you determine if you should be populating the ECM field, and you must work with your basis person if you are not sure the correct value to use for the Logical System.

Target System: The SAP system you wish to populate. Please note, your basis person must creating/maintain the ALE system.

Engineering Change Management (ECM): Your VC modeling may or may not include engineering change numbers. I encourage all clients to use ECM due to the high level of maintenance required. In order to transfer most pieces of a VC model with engineering change management using ALE, you must maintain ECM in all systems, including the development system.

Note: For All screens, you can often use the wild card, if you maintained a standard naming convention. in that event, simply enter XYZ* to capture all product line specific data.

Engineering Change Management:

TXN: CC92

For the ECM number you have 2 options depending on your system setup.

Typically, most companies will create the change number in their production system, then move that ECM to other system. In that event, execute CC92 in the production system, and logical system will be the development or QA system. This, by the way, is my recommended way of doing things.

You can also use a Push system, if you wish to have your ECM driven from the test system. Usually, this would require a unique ECM number range specific to VC, but it can be accomplished.

Characteristics

TXN: BD91

Note, if you use preconditions at a characteristic or characteristic value level, some of your characteristics may fail to load. If this occurs, continue loading the classes and object dependencies. After that is completed, reload the failed characteristics.

Classes

TXN: BD92

The following items must exist first:

Characteristics

Variant Table Structures

TXN: CLD3

Please note, this transaction does not allow for ECM because the table structure is not under ECM control.

The following items must exist first:

Characteristics

Variant Table Contents

TXN: CLD4

The following items must exist first:

Characteristics
Table Structures

KMAT Material Masters

TXN: BD10

Message Type: MATMAS

Classification

TXN: BD93

Please note, this data only needs to be moved if you maintained classification at a material level. This is often used with class type 200 functionality, as well as nested KMATs with restricted characteristic values.

The following items must exist first:

Characteristics
Classes
Materials

Variant Functions

TXN: CUFD

Note, this functionality is not always used. Only in the event of an instance where ABAP coding is required. This is discouraged, if possible, since this functionality cannot be easily converted to the IPC.

The following items must exist first:

Characteristics

Object Dependencies

TXN: CLD2

The following items must exist first:

Characteristics

Dependency Nets

TXN: CUK2

Please note, it is not necessary to move individual constraints, moving the constraint net automatically moves all constraints.

The following items must exist first:

Characteristics
Classes

Configuration Profiles

TXN: CLD1

The following items must exist first:

Characteristics
Classes
Object Dependencies
Constraint Nets
KMAT Materials

Bill of Materials

TXN: BD30

Please note, if you have Sales BOMS and Production BOMS, you will need to call this transaction separately for each.

Also, you may have a list of materials BOM’s to move, be sure to enter the change number in every row of the Target System Chng. NO column.

The following items must exist first:

Characteristics
Classes
Object Dependencies
KMAT Materials
Components in the BOM

Interface Design

TXN: CUID

The following items must exist first:

Characteristics
Classes
Configuration Profile
KMAT Materials
Object Dependencies
Constraint Nets

Pricing Condition Records

TXN: VK12

The following items must exist first:

KMAT Materials

Routing/Reference Operation Sets

Program: RCPDIRO1

Program: RCPTRA02

This the one piece that does not use ALE. It actually uses a more simple technology of downloading a file, and then uploading it. You need to make sure the basis person has defined a directory that is valid in both the original and target systems.

Remember, if you use reference operation sets, you must first transfer those. Use Type S. Then execute again using Type N.

The following items must exist first:

Characteristics
Classes
KMAT Materials
Object Dependencies
Work Centers

How to check for errors:

IDOC Status Monitor

TXN: BD87

To monitor the success or failure, log into the target system and execute this transaction.

After executing the transaction you’ll be able to see what failed and what succeeded. If anything failed, you’ll be able see the IDOC log to see exactly what failed and why. (See the next section).

Analyze Application Log

TXN: SLG1

Use this log to understand the errors. Certain errors may require manual changes in the target system. Other errors simply need a piece of data that has not yet been moved. As soon as the missing data is created in the target system, you can re-execute the IDOC in BD87, or you can send it again using the transaction in the original system.

SAP SM Blueprinting Questions – Technical

18JunJune 27, 2016

Welcome back. This is the last piece in my series on talking about SAP SM blueprinting. This last edition will focus on the Technical aspects of service management. So let’s get right into it.

Forms

This is the biggest piece of the technical aspect of Service Management. When it comes to service there are a lot of documents, but it all depends on what the business plans to use. First off, for every document, be sure to get sample documents for EVERYTHING that the client says is required. During realization, you’ll need to analyze every one of these and determine the mapping of old to new data. Here’s the forms you need to consider:

Service Quotation: Does this look just like a standard sales quotation? Are you use RRB to determine the detailed cost of the quote?
RMA/RGA paperwork: Does this come from the notification or repair sales order. I will recommend using the repair sales order, but I’ll leave that for another post :). Does this look like an order confirmation or is completely different?
Service Order Paperwork: There’s a bunch of options here that come standard in SAP.
- Time Ticket – do you need this print out? should this look like the production order shop floor papers?
- Pick List – is this something that should be printed? who does this work, does the repair group pick their own components, or does the warehouse?
- Shop Floor Papers – do you need this print out? should this look like the production order shop floor papers?
- etc.
Invoice – Do you need a special invoice for service? Again, I always suggest to avoid this if at all possible.

Technical

This is the piece is the easiest part of blueprinting because you should completely skip it. Don’t start talking user exits, BAPI’s or anything custom at this point. This doesn’t mean to ignore the stuff, but initially, save this until realization. Remember, you don’t need to solve every problem, for now, just collect them all.

Interfaces
Interfaces are anything that needs to link into SAP, but is not part of SAP. The most common example of this is Taxware/Vertex. Now there may also be existing websites that link into the existing system, there may be some external part planning, an outside application to handle scheduling, etc. I personally always dislike this part because it tends to be the biggest headache. Your biggest goal is to figure out everything that needs to come into SAP, and more importantly, determine if SAP can handle this with standard functionality so the interface can be replaced with SAP. Be sure to get as many details as possible, including functionality and what information is exchanged between systems. This is likely to be a time consuming piece of realization to get all the details and possibly design a technical interface to replicate the old behavior.

Alright, this wraps up everything I have for the blueprinting. If you have anything I’ve missed, please let me know. I always hope to learn something as well.

I’ll be back soon,

thanks,

Mike

SAP SM Blueprinting Questions – Service Processing

04JunJune 27, 2016

Now, onto more of the nitty gritty, what do you need to find out about the actual processing of the service orders. In this part of the SAP SM blueprinting series we cover what do you need to find out when it comes actually performing the repairs. So let’s get into it.

How many service orders do you process in a day/week/month?

It’s old fashioned, and I think everyone knows this, but I’d hate to skip over the obvious. This question helps you gauge how to structure your processes. Just having an idea that the service department processes 1 order every 2 weeks, or they process 25 in a day. You’ll need to start thinking about how the service group will see their open orders, how they will notify other groups when they start or complete the orders, etc. Simply put, the answer to this question will set the stage of what you need to do for all realization about the actual repair process that occurs.

How many different service order types do you utilize, and what is the purpose of each?

You may need to phrase this question differently depending on your audience. The gist of the question is determine how different “types” of orders you process. A type of order is anything that it is either tracked separately for financial or processing issues. For example, if the accounting department needs to separate the costs of an Field service type order from an in-house order. Sometimes, it’s purely fro reporting to know which orders need to processed ahead of others (for example, an in-house repair would need to be processed before the exchange orders that will just go back into your “spares” inventory. Keep in mind, the more order types you create, the more maintenance you will be responsible, so like everything, drive to the minimum number of order types you can.

Do you break a single repair up into multiple smaller pieces?

SAP uses sub-service orders to accomplish the breaking of main service order up in multiple pieces. This is especially useful when you deal with equipment that is broken into multiple pieces for repair. This often happens with larger pieces of equipment that get broken down into more management sub-assemblies, each that need their own repair. Sub service orders in SAP work great for this, because you are not allowed to complete the “main” service order until it’s sub-service orders have been completed. So you can build an entire structure of orders if your process is complex. However, remember that using these orders now doubles or triples the amount of master data to maintain for each order. So if your shop is small, be aware they will have to do a lot more system work. Short story, only implement if needed, and make sure that the people that will be dealing with day to day

Do you perform subcontracting for any service repair (in-house or external)?

Another thing to determine is if you have to worry about any subcontract or 3rd party to do work on a part. There are several different ways that you subcontracting impacts the service order.

The first way is that you need a component that is purchased. In SAP, if you don’t have the material in stock, it will generate a purchase requisition for the component. It may also be for a part that is not maintained as a material master in your system (this could be something like ordering hammers for the field service tool belts).
The next way is that you may send the part being repaired (or a portion of it) to an outside vendor to perform a specialized service or process that you do not offer. It could be special diagnostics or tooling on the part. This again requires a purchase requisition.
- do you need to see that the inventory has left your facility? In SAP, you can implement the A&D solution to actually perform the material movements and SAP deliveries to show that the part has left/come back into the facility. This is very nice functionality, but keep in mind that it has limitations, and it adds multiple additional steps to the process. Find out how necessary the requirement is perform you promise it. It requires certain enhancement packs to be installed and activated, so if you go down this path, you’ll need to work with the basis/development team to accomplish this.
The next thing to consider is, do you use a 3rd party service center to do the entire repair. In this event, please check out my post on Warranty Claims: SAP Warranty Claims: A Guide for Beginners

How should the costs be broken up?

The cost breakdown is simply the broad categories that display on the service order as you do planning or actual hours & components. Some of the common breakdowns include:

Labor
Travel Costs
Components
External Components
etc…

Remember, these categories have no impact on anything financially. It is simple “buckets” that the particular cost elements are grouped into to.

Do you perform repetitive service tasks for certain products?

This question is related more to master data than service processing, however it fits much better into this portion of the blueprint. It’s important to find out if your client does repetitive steps for a particular repair. This could by service material (service process) or by serviceable material (material that is being repaired). If the same steps are performed every time, you need to set up General Task Lists, and teach the business how to use General Task Lists. If you are not familiar with these tasks list, it’s simple a routing and component list that can be automatically copied into the service order upon creation.

How do you need to track your time entries to the service order?

This question helps you drive to the answer of if you need to pursue CATS (computer aided time sheets). CATS is a useful tool if you use SAP to handle your payroll and your service orders. Keep in mind that the standard time entry tools for service orders (IW41, IW42 for example) can handle entering in personnel numbers, multiple confirmations, etc. CATS certainly provides better reporting, and looks more like a time sheet for your employees entering their time. CATS will certainly require a lot more configuration, including setting up an organization structure (often a difficult and controversial topic for any organization). As a general guideline, I will steer clients away from CATS unless they have solid reasons for using it (often if the client does Project Systems and Service, both will want to use CATS, then it makes sense to use CATS).

If you perform service at the customer’s location, who enters in the time and material for the job?

This question is typically more business process related, but it is certainly information you need to know. The reason it’s important is because you need to know if field personnel will be entering in their own time and materials, or will they be emailing, faxing or mailing in their time sheets to someone in an office who will enter it for them. If they intend to enter it in the field, you need to know if they have internet connection in the area. In our day and age, most places have internet coverage, however there are still locations on our globe that do not have easy connectivity or have very weak or slow connections. In that event, you need to be very sensitive to making someone log into SAP, if they are using just a 3g network. You may need to look into a web interface that provides a small amount of bandwidth to get the confirmations entered.

If you perform service at the customer’s location, do you ever send components for a service job?

This is one of the famous loaded questions you ask. It’s pretty rare to do service and never send components. The reason for this is to determine HOW you need to handle the components. There are several common ways to handle this.

The service technician is located at the office or a plant with parts and takes parts with them to the customer. In this event, the technician simply issues the parts to the order and removes them from stock. Packs them up, and takes them to the client. If there are extra parts, they are returned to the warehouse after the completion of the job.
The service technician maintains “trunk” stock. This simply means they have a list of stocked components with them at all times. These “trunk” locations are typically a storage location in SAP. Then the stock is issued from their SLOC to the order.
The parts are shipped ahead of the tech by way of a sales order/delivery process. They are shipped directly to the customer, perhaps as a no charge order, but this again needs to be determined by the business.

If you perform service at the customer’s location, do you perform scheduling of your technicians?

Now this question will often get a quick “Yes” from the customer. However, you need to dig into the how. Many clients simply track their techs on MS Outlook, Excel, or the big calender hung in the boss’ office. Now some clients have a far more sophisticated method to track their people, and when they are available, but you need to know what level of complexity you need to implement. In addition, you need to find out if they track the travel time, how are the tech’s schedule maintained? Is there an automated connection to the call center? Do they schedule “real-time” with the customer? Who has access to view this? Do they track skills of each tech to determine who can do what? Keep in mind, to implement this in SAP is usually a very custom solution requiring quite a bit of development. SAP does offer a solution, but it is an add-on, and last I looked into it, it is only for CRM.

Do you perform any service parts planning?

Service parts planning can often mean a lot of different things depending on the client. Some of the things you need to determine are:

Are the parts being planned independent of the production demands?
If it is a shared stock, who wins? By that it’s important to understand in the event of limited stock, does a sales order get the stock, does service get the stock or does production get the stock?
How do you forecast service demands? How much history is currently used to determine the service forecasting?

Alright, here’s the stuff I can think of related to service processing. As always, I welcome your comments on anything I missed, or even anything else you would like me to cover… Next time we’ll talk about a few of the remaining “oddball” items, such as forms, technical stuff, and financial stuff.

Thanks for reading,

Mike