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.
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
- 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
- ($SELF.COLOR = ‘RED’, $SELF.SIZE = ‘MEDIUM’) IF $SELF.TYPE = ‘STANDARD’
- 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
