Monday, September 1, 2014

SAP Variant Configuration - Best Practices

The main objective of best practices are

1. To Easy understanding of the system design,

2. For quick problem solving

3. To reduce the time for new product development by reusing the VC Objects

4. For easy data Transfer activities through ALE etc.,

5. To avoid common problems

This document covers the best practices followed during implementation of the SAP Variant Configuration projects in various industries:

1. Easy Naming Convention

In hi-tech manufacturing company, it has always been a challenge to maintain the Variant configuration (VC) Master Data. Use of prefixes in the naming conventions is followed as a best practice While creating the VC master data to overcome this challenge.

For Example:
Characteristics: VCH_XX_CHARNAME
First 3 letters (Prefix) denotes as VC Characteristic, XX denotes the line of business and rest is meaning full name of the characteristic.

First 3 letters (Prefix) denotes as VC Class, XX Denotes the line of business and rest of the name is model name.

Similarly we can maintain the naming convention for all the objects such as dependencies, configuration profiles, user interface designs, variant tables in variant configuration.

Business Benefits of the standard naming convention:

  • Easy Maintenance of the Master Data
  • Easy retrieval of data using reports
  • Easy to check if the right data has been transported to the production client
  • From the name of the dependency, one can easily identify the dependency type

2. Variant Configuration Golden Client Strategy

Business Pain Point:
High Risk is involved in writing the dependencies and maintaining other VC objects directly in Production Client

Use separate client as VC golden client to develop and maintain the VC Model objects i.e.
  • Create / Change Characteristics, classes, configuration profiles, object dependencies, variant tables and user interface designs
  • Test the developments thoroughly before moving the changes to production
  • After successful testing, use SAP standard ALE IDOC's to transfer the VC objects to Production Client

3. Characteristics Definition
The following points need to keep in mind while defining the VC characteristics:
  • Avoid multi-value characteristics unless there is no choice
    • Multi-value characteristics cannot be used in variant tables
    • Multi-value characteristics cannot be used with IN statement
  • Avoid using dashes ( - ) in characteristic names
    • SAP cannot tell the difference between a dash and a subtraction sign in dependency code
    • If you do use dashes, you need to use square brackets around the characteristic name (e.g., $self.[MY-CHAR] = ‘A’)
  • Avoid making characteristics case sensitive
    • Case-sensitive characteristics make it harder to write dependencies
  • Avoid using entry required
    • Use dependencies to dynamically make a characteristic required
  • Avoid using time and currency formats
    • These types do not work in IPC
    • OK to use, if your company will never use IPC
  • Avoid value hierarchies and other value check
    • These do not work in IPC
    • OK to use, if your company will never use IPC
    • Difficult in problem solving

4. Definition of Classes
The following points need to be keep in mind while defining the classes:
  • Do not use local classes
    • Only used for distributed systems (i.e., central and local instances)
    • Can cause confusion in class definition
  • Avoid using characteristic/value overwriting
    • Changes to characteristic through CT04 are not reflected in overwritten characteristic at class level
    • Causes endless confusion in testing and debugging
  • Use organizational areas when required
    • These make it easier to find characteristics of the right type
    • Makes sense in systems where there are a large number of characteristics

5. Dependencies Maintenance
The following points need to remember while creation and maintenance of the object dependencies in VC

  • Use constraints rather than preconditions
    • Preconditions are attached the characteristic values (have to look many places to locate all preconditions)
    • Constraints are placed in the configuration profile (all in one place)
    • For this reason, constraints are easier to locate and debug
  • Assign procedures to configuration profile
    • Possible to assign to characteristics, but not advised
    • Same reasons as for using constraints instead of preconditions
  • Always comment your code
    • Dependencies are commonly short code, but it is easy to forget what they do or the reason they were created
  • Avoid using local dependencies
    • Local dependencies are sequentially numbered (no assigned name)
    • Local dependencies cannot be re-used
  • Use parentheses to group code with similar logic conditions
  • Difference in use of procedure or constraints
    • Constraints have more overhead, but execute only when necessary
    • Procedures are faster to load, but execute every time the user changes a characteristic value

6. Configuration Profiles
The following points need to remember while developing the model
  • Characteristic Grouping
    • Logical Grouping and characteristics sequence make the Order Management peoples life easy to avoid the back and forth movement during the order entry to fill the characteristics.
  • Use interface design
    • Interface design allows tabs to be used to separate characteristics on the configuration interface based on the defined grouping.

7. Super BOMs
The following points need to remember while creating the Super BOM
  • Group like items together
    • Use the same item number to make it easy to see which items are/may be missing
    • Use item test column to identify the item grouping the variant components
  • Control changes using ECM
    • Avoid problems with determining validity and controlling changes
  • Quantity calculations or multiple BOM items?
    • Using procedures to calculate quantities makes BOM more compact
    • Using quantity calculations can make selection conditions easier to write, but could also make them more complex to write
    • Quantity calculations could become very complex

8. Engineering Change Management
Changes to a product occur frequently in hi-tech engineering environments, where initial product designs are often continuously evolving prototypes. This rapid and efficient change process can be achieved through ECM.

We can use ECM for Characteristics, classes, Super Bill of Materials, SuperRouting, Configuration Profile, dependencies and Variant tables

The following business benefits can be achieved by using the ECM in Variant Configuration.
  • The effective date of the ECM helps to manage future changes
  • Easy tracking of VC Data changes
  • Easy reporting of VC Data changes
  • Saving cost, time & effort

9. Data Transfer using ALE
Transfer Characteristics, Class, Configuration profile and Dependencies from VC client to PRD client using IDOC’s after testing

Saturday, August 17, 2013

SAP VC Master Data Distribution Using ALE


SAP Variant Configuration (VC) Master Data can be distributed across the different Clients /Systems in the organizations using ALE functionality of SAP.

Master Data Includes the following objects:
  1. Characteristics and Values
  2. Classes
  3. Variant Table Structures
  4. Variant Table Contents
  5. User Defined Functions
  6. Object Dependencies (Selection Conditions, Pre Conditions and Procedures)
  7. Dependency Nets
  8. Configurable Materials
  9. Configuration Profiles
  10. Bill of Materials
  11. User Interface

Message Types Used for VC Master Data:

Characteristics and Values: Most objects for variant configuration are dependent on characteristics. For this reason, characteristics must be   transferred first.
Message Type used for Characteristic and value transfer is CHRMAS. 
SAP Transaction: BD91

Classes: During the ALE distribution of the classes, the characteristic assignment also transferred.
Message Type used for Class transfer is CLSMAS
SAP Transaction: BD92 

Variant Table Structure: Variant table structures created to support the maintenance of the data relevant for variant configuration.
Message Type used for Variant Table Structure transfer is VTAMAS
SAP Transaction: CLD3

Variant Table Contents: After distribution of the variant table, table contents can be transferred.
Message Type used for Variant Table Contents transfer is VTMMAS
SAP Transaction: CLD4

User Defined Functions: User defined variant functions are used to check and infer the characteristic values. In side these function, ABAP function modules are used.

Note:The distribution of functions only transfers the framework (Characteristics, texts, etc.,) the function modules used in functions must be transported first using the standard SAP transport management system.
Message Type used for User Defined Functions transfer is VTMMAS
SAP Transaction: CUFD

Object Dependencies: The dependencies transferred here are global object dependencies. Local object dependencies are transferred with the objects to which they are assigned.
Message Type used for Object Dependencies transfer is KNOMAS
SAP Transaction: CLD2

Constraint Net (Dependency Net): These also can be distributed as of release 4.5
Message Type used for Dependency Net transfer is DEPNET
SAP Transaction: CUK2

Configurable Materials: Depending on how many configurable materials you have, you can use ALE to distribute them or create them in the target system. The other materials in BOMs for configurable materials are transferred to the target client by the usual data transfer.
Message Type used for Material transfer is MATMAS
SAP Transaction: BD10

Configuration profiles: These must be distributed after the configurable materials, because the key of the material identifies the profile. During the ALE process, the dependencies for the configuration profile are also transferred, and are reassigned to the profile in the target client. At the same time, the class assignments belonging to the configurable material (in the variant class) are transported.

Message Type used for Configuration Profile transfer is CNPMAS
SAP Transaction: CLD1

Super BOM: Material BOMs for configurable materials can be distributed using ALE. The transfer also assigns the dependencies for BOM items to the items. Make sure that the dependencies and all the materials required already exist in the target system.
Message Type used for Material BOM transfer is BOMMAT
SAP Transaction: BD30

User Interface: You can use ALE to transfer interface designs for variant configuration.The distribution of interface designs uses BAPI technology
Message Type used for User Interface transfer is VCUI_SAVEM
SAP Transaction:CUID

System Setup:

The following steps need to follow to setup to use the ALE functionality for master data distribution.