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.