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.