Article Abstract

This article contains suggested naming conventions for object dependencies for companies implementing SAP Variant Configuration (VC) using either the internal R/3 VC engine or the Internet Pricing Configurator (IPC) Application Engine (AP). In our experience we have found that there are a number of considerations and potential pitfalls when deciding on a particular naming convention. The aim of this article is to educate VC users about the choices that they make. We will provide common scenarios that modelers face and give examples of various naming conventions.

Meghana Patwardhan is a consultant with Deloitte Consulting's SAP practice. She has 3 years experience with SAP CRM and VC. She currently lives in Chicago on the weekends.

Email address:mpatwardhan@deloitte.com

Dinesh Kanna Prabakar is a consultant with Deloitte Consulting's SAP practice. He has 3 Years of experience with SAP CRM, VC and IPC technologies worked in industries like, Manufacturing and High-tech. He is currently based in Dallas.

Email address:dprabakar@deloitte.com

Why write this article?

While modeling a proof of concept for a client who manufactures extremely configurable products we were struck by how easy it is to name an object dependency and how difficult it is then to find it and easily remember its purpose without having to go through reams of code. This article is our attempt to delineate the possible scenarios in which the object dependencies will be used and then suggest a naming convention that would best suit the scenario. We hope to save fellow modelers a good deal of pain and give valuable suggestions to modelers who will be using object dependencies in VC.

Example Model

We are going to use the business model "ACME Bicycle" introduced by Dr. Barry L Walton in his Paper "Classification Won't Make you Rich, But it could Make you Powerful". We have used the characteristic value domain mentioned in the article "Class Inheritance Won't Make You Rich", By Steve Schneider.

Let's consider the following characteristics for Color, Seat, Frame and Handle bar. having the Domain values:
A_Color (Red, Green, Blue, Black)
A_Seat (Racing, Padded Racing, Mountain, Padded Mountain)
A_Frame (Mens, Womens)
A_HandleBar (Wide, Narrow, Racing)
A_DrinkHolder (Yes, No)

Racing and Mountain type bicycles sold by ACME Bicycle will have the following set of allowed values during configuration. We will suggest naming conventions for these products in this paper.

Racing:
A_Color (Red, Green)
A_Seat (Racing, Padded Racing,)
A_Frame ( Mens, Womens)
A_HandleBar (Narrow, Racing)
A_DrinkHolder (Yes, No)
Note: Narrow Handlebar offered with Racing Seat and not Narrow Seat

Mountain:
A_Color (Green, Blue, Black)
A_Seat (Mountain, Padded Mountain)
A_Frame (Mens, Womens)
A_HandleBar (Wide, Narrow)
A_DrinkHolder (Yes, No)

Naming Conventions: Scenarios and Examples

The number of allowed characters in the name field of an object dependency (Table CUKB, Field KNNAM) is 30. It can be difficult and confusing to incorporate all relevant information (product name, characteristic, characteristic value, logic etc.) in the name of the dependency.

We have defined different scenarios / considerations which can be used to drive the naming convention of an object dependency.

We recommend that you always use the following codes to indicate the type of dependency you will be using. Even though the type of dependency can be selected while creating, it is easier for the modeler/s to search as well as understand the code if the name contains the type of dependency. This way you avoid making the mistake of marking a procedure as a selection condition and wondering why the syntax check gives you errors. If you had "PRO" in the name of the dependency, you would immediately know the reason for the error.

Object Dependency	Code
Precondition	PRE
Selection condition	SEL
Procedure	PRO
Constraint	CON
Dependency Net	DNET

1. Scenario: Procedures and Constraints for Multiple Product Models vs. Single Product Model:

Multiple top level products

There can be many models for multiple top level products that share certain classes and dependencies among them. In this case those dependencies that pertain only to a single model should have a three letter code of the product name in the beginning of their name.

Example: Let's say ACME makes bicycles as well as skates, a procedure that will be used across only all the bike models (if there is more than 1 model for bikes) could be named:

BYC_PRO_XXXXXXX

Those dependencies that will have an effect on all models and will be used across models should have a three letter code of the company to begin with identifying it is global across all models.

Example: For company ACME, a procedure that will be used across all models (skates and bikes) could be named:

ACM_PRO_XXXXXXX

Single top level product

If there is only one model in the system then the dependencies need not have the name of the product in them.

2. Scenario: Selection Conditions on BOM Items

Unique logic for selection of unique components

If each component is selected by a unique dependency then we could include the component number in the name of the selection condition. This makes the model easy to understand. On the flipside, one would have to create a new dependency every time a new component replaces the older component instead of reattaching the older dependency.

Example: Consider this scenario: Characteristic A_HandleBar has Domain of values Narrow, Wide, Racing. Each value drives a unique part number HB_Narrow, HB_Wide, HB_Racing irrespective of which BOM they are part of. One straightforward way is to use the part numbers in the dependency, making it easier for assignment. Another way is to use the characteristic and value as part of the selection condition name.

SC_HB_NARROW
SC_HB_WIDE

Different logic for selection of same components in different Bill of Materials

In this case a different dependency is used to select the same component in different bill of materials. We cannot use the component name in the selection condition unless we attach a meaningless prefix (example 1, 2, 3...) to the name. Here it is better to use the characteristic and value in the dependency name so that the modeler can reattach the dependency (instead of creating a new one) in the case that the component is replaced by a newer one.

Example: Lets us consider this scenario: Marketing suggests that they are going to offer headlights free on the selection of Padded Racing Seat for the Racing bike and Padded Mountain Seat in the Mountain bike. But seats have same part number irrespective of where they are used. Hence you need two different dependencies driving the same component in different products. Here it is better to use the characteristic and value rather than the material number as the dependency attached to the component is not unique.

SC_RAC_PAD_SEAT
SC_MOU_PAD_SEAT

NOTE: In the above case, different values of the same characteristic drive the parts in the dependency. Ideally the engineering function should create a dependency that satisfies both the models so that only one dependency needs to be attached which would lead you to name according to the complex logic scenario below e.g. SC_PAD_SEAT_LOGIC. But in the case that the models are maintained by two different groups, it would be hard to change the dependency used by another model to satisfy the requirement of one model. Then we would not be able to use a single dependency and would use the above scenario.

Recurring logic for selection of components

If the logic that is used to select a component will be reused then it is best to NOT include the component name in the selection condition name. Otherwise the same code will have to be changed multiple times if the selection criteria changes. Naming a dependency independent of the component name allows us to reattach it to other components that use the same logic. Also, in case the component is replaced we will not have to create a new dependency. This will reduce the size of the model.

Same dependency is used to select different components in the bill of materials

Example: Let's consider the example where characteristic Frame has the Values Mens and Womens. These values are driving different components in the Bills of Materials. The value "Mens" in Racing drives part numbers Rac_Mens_Frame while in Mountain it selects part number MOU_Mens_Frame. We cannot use the part number as part of the naming convention. Instead we will use the characteristic and values as part of the naming convention.

SC_FRAME_MEN
SC_FRAME_WOMEN

Complex logic

If more than one characteristic drives the logic then its best to come up with a name based on what the logic is trying to achieve. In situations that involve multiple characteristics the modeler should get useful information from the engineer and can use it as part of the name.

Example: Let's say a component will be selected if Padded Racing Seat for the Racing bike or Padded Mountain Seat in the Mountain bike. If the dependency checks for a combination of more than one characteristic we can use the following name:

SC_PAD_SEAT_LOGIC

NOTE: Some company/modelers prefer to use material numbers in the naming of selection condition, irrespective of their reusability. In such scenarios when the same component is selected based on different dependency in different bills of material it would be ideal to include the parent number too. Another approach would be to include suffix, 1, 2, 3 and so on. Even though it is simple to identify the dependency, maintenance and performance impacts should be taken into consideration.

3. Scenario: Preconditions on Characteristics / Characteristic Values

Simple Logic involving single characteristic

Here it would suffice to use the characteristic and value in the dependency name.

Example: Let us consider that the marketing team wants to introduce a new characteristic called Drink Holder with values Yes or No and it is offered only when the Handlebar is narrow. Hence we need to write a dependency to show the Drink Holder only when the characteristic Handlebar has a value Narrow.
Use PRE as the prefix and the characteristic name and the value.

PRE_HANDLEBAR_NARROW

Complex logic involving multiple characteristics

Use PRE as the prefix and the combination of the name and the value. If the number of characteristic value combinations is more than the available length of the characteristic name then a name that identifies the precondition by its purpose is recommended.

Example: Let's say a certain logic which combines many characteristics is needed in a precondition. Then the best way to name it would be:

PRE_LOGIC_NAME

NOTE: Similar techniques can be used for the precondition on the characteristic value.

4. Scenario: Procedures

Procedure which can be used across multiple models

For procedures that are common across different models use "PRO" and purpose of the procedure.

Example: Let us consider the characteristic Drink Holder will be defaulted to YES when the Handlebar is narrow. We can write a procedure to set default the value of Drink Holder to "Yes" when the Handlebar has a value "Narrow". This Scenario is common across both Racing and Mountain. Hence the name need not include an identifier for the model name.
Use PRO as the prefix and the characteristic name and the value.

PRO_DEFAULT_DRINK_HOLDER

Procedures which are specific to a model

For procedures that are specific to a model and cannot be reused, use the 3 letter model as the prefix followed by characteristic and value.

Example: Let us consider that one of the business rules is to drive the component quantity based on the characteristic value for Handlebar. When the Handlebar has a value "Narrow" it sets the component quantity to 2 for Racing bicycle and to 4 for Mountain bicycle. The ideal naming convention would include the model name in such scenarios.

PRO_RAC_HANDLEBAR_QTY
PRO_MOU_HANDLEBAR_QTY

5. Scenario: Dependency Nets and Constraints.

Similar logic can be used for the names of the dependency nets and constraints. Use "DNET" and "CON" as the prefix for the dependency along with the purpose of the constraint and the dependency net.

Conclusion

Each company has its own nomenclature for dependencies. While there are no best practices in naming dependencies we have highlighted the common practices. Adopting a naming convention greatly helps ease the pain of handing off modeling responsibilities. In our experience the above conventions are the most commonly used. We highly recommend discussing the product structure with the engineering team before deciding the naming conventions.

Naming Object Dependencies - Common Practices