Scribd
Upload
10 views4 pages

Variant Configuration BP

This document outlines best practices for implementing SAP Variant Configuration (VC) projects, focusing on system design clarity, problem-solving efficiency, and reduced product development time. Key practices include establishing a clear naming convention, utilizing a 'golden client' for development, and adhering to specific guidelines for defining characteristics, classes, and dependencies. Additionally, it emphasizes the importance of Engineering Change Management and data transfer processes to enhance overall project effectiveness.

Uploaded by

Naveen Mittal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
10 views4 pages

Variant Configuration BP

This document outlines best practices for implementing SAP Variant Configuration (VC) projects, focusing on system design clarity, problem-solving efficiency, and reduced product development time. Key practices include establishing a clear naming convention, utilizing a 'golden client' for development, and adhering to specific guidelines for defining characteristics, classes, and dependencies. Additionally, it emphasizes the importance of Engineering Change Management and data transfer processes to enhance overall project effectiveness.

Uploaded by

Naveen Mittal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 4

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 thischallenge.

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.

Class: VCL_XX_MODEL
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

Solution:
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
o Multi-value characteristics cannot be used in variant tables
o Multi-value characteristics cannot be used with IN statement
 Avoid using dashes ( - ) in characteristic names
o SAP cannot tell the difference between a dash and a subtraction
sign in dependency code
o 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
o Case-sensitive characteristics make it harder to write
dependencies
 Avoid using entry required
o Use dependencies to dynamically make a characteristic required
 Avoid using time and currency formats
o These types do not work in IPC
o OK to use, if your company will never use IPC
 Avoid value hierarchies and other value check
o These do not work in IPC
o OK to use, if your company will never use IPC
o 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
o Only used for distributed systems (i.e., central and local
instances)
o Can cause confusion in class definition
 Avoid using characteristic/value overwriting
o Changes to characteristic through CT04 are not reflected in
overwritten characteristic at class level
o Causes endless confusion in testing and debugging
 Use organizational areas when required
o These make it easier to find characteristics of the right type
o 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


o Preconditions are attached the characteristic values (have to
look many places to locate all preconditions)
o Constraints are placed in the configuration profile (all in one
place)
o For this reason, constraints are easier to locate and debug
 Assign procedures to configuration profile
o Possible to assign to characteristics, but not advised
o Same reasons as for using constraints instead of preconditions
 Always comment your code
o Dependencies are commonly short code, but it is easy to forget
what they do or the reason they were created
 Avoid using local dependencies
o Local dependencies are sequentially numbered (no assigned
name)
o Local dependencies cannot be re-used
 Use parentheses to group code with similar logic conditions
o ($SELF.COLOR = ‘RED’, $SELF.SIZE = ‘MEDIUM’) IF $SELF.TYPE =
‘STANDARD’
 Difference in use of procedure or constraints
o Constraints have more overhead, but execute only when
necessary
o 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
o 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
o 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
o Use the same item number to make it easy to see which items
are/may be missing
o Use item test column to identify the item grouping the variant
components
 Control changes using ECM
o Avoid problems with determining validity and controlling changes
 Quantity calculations or multiple BOM items?
o Using procedures to calculate quantities makes BOM more
compact
o Using quantity calculations can make selection conditions easier
to write, but could also make them more complex to write
o 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

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy