第 22 页 / 共 52 页
2 Creating a Product Model for SAP Variant Configuration
2. Mode of Action
The second step queries you about the mode of action. Here, you’re supposed
to restrict the value lists for characteristics. This is the first selection option in
this step. The difference from other selection options is described in the follow-
ing.
It is possible that the wizard won’t provide the Value Restriction option. In
this case, the required prerequisite—that the characteristics whose value lists
are supposed to be restricted are indicated as restrictable in the characteristic
definition—is not met.
3. Configuration Object
Next, the wizard queries you for the configuration object. In addition to char-
acteristics from classes, you can also use and evaluate other reference objects in
constraints. Because this example is supposed to restrict characteristics of a vari-
ant class, the corresponding variant class is also the configuration or reference
object.
4. Variant table
After the configuration object step, the variant table selection is implemented.
Because this example contains only one variant table in the PMEVC environ-
ment, no comprehensive selection can be made.
5. Explanation
In the Explanation step, you can assign a language-dependent long text to the
object dependencies, that is, to the table constraint. It also lists the characteris-
tics of the variant table to exclude characteristics for object dependencies if
required.
6. Constraint Name
For constraints, the name must be assigned externally, that is, by the user. This
request, including a short text, is made in the Constraint Name step.
7. Complete
All steps are completed. A description of these steps is provided once again in
detail before the user can complete the table constraint.
The system then displays the completed table constraint (see Figure 2.33). After
saving, you can directly test it by calling the configuration simulation from PMEVC
via the Test button.
150
6060.indb 150 10/4/11 11:56 AM
第 23 页 / 共 52 页
Object Dependencies for the Value Assignment Interface or the Sales View 2.6
Figure 2.33 Result of the Table Constraint Wizard
The value assignment interface displays the three characteristics: “Special wish,”
“Casing,” and “CPU.” Initially, the corresponding input help ([F4] key) provides all
values from the variant table for each characteristic. However, if you start assigning
values to any of the three characteristics, the system provides the values only for
the other two characteristics that lead to an allowed value assignment according
to the variant table. The same applies to two characteristics to which values have
been assigned.
A special feature of the traditional configurator is that if the allowed value range
for a characteristic is restricted to a value, the system automatically sets this value.
This is done only for required characteristics in the IPC. Note that the characteristics
need to be restrictable according to the characteristic definition. As a result, the
151
6060.indb 151 10/4/11 11:56 AM
第 24 页 / 共 52 页
2 Creating a Product Model for SAP Variant Configuration
lists of the allowed values for characteristics to which values have been assigned
are restricted to the value assignment, as already described.
2.6.3 Variant Tables in Detail
The first usage of variant tables was introduced in the example above. You can
address variant tables in all types of object dependencies. The columns of variant
tables are always characteristics. The rows represent value assignment combina-
tions. You can use variant tables for different purposes:
EE Value restrictions in constraints (in this context, values can already have been
assigned—as described in the example)
EE Inferences of values in constraints or procedures
EE Conditions as preconditions, selection conditions, if conditions in procedures
or constraints, and as a condition part in constraints
EE Consistency checks via constraints
These purposes are discussed in more detail in the introduction to the correspond-
ing types of object dependencies in Sections 2.6.4 through 2.6.7.
At this point, the structure and maintenance of variant tables will be introduced
(see Figure 2.31 and Figure 2.34). You can maintain the variant table’s structure
and content via PMEVC. There are also specific transactions for the following tasks:
EE Content maintenance (Transaction CU60)
EE Creating, changing, and displaying the table structure (Transactions CU61 through
63)
The Basic Data tab of variant tables (see Figure 2.31) contains names, the descrip-
tion (language-dependent short text), the status, and the group. The status can be
adapted via Customizing and also includes the content maintenance and usage in
object dependencies as well as distribution locks for the content and structure.
The same aspects apply to groups as to characteristic and class groups; it is also a
separate list in Customizing. Furthermore, you can couple the variant table with
a database table in the basic data. This is described in detail later in this section.
The basic data is complemented by the authorization groups for the content and
structure maintenance.
152
6060.indb 152 10/4/11 11:56 AM
第 25 页 / 共 52 页
Object Dependencies for the Value Assignment Interface or the Sales View 2.6
Figure 2.34 Structure and Maintenance of the Variant Table (PMEVC)
The Characteristics tab, which is assigned to a variant table, provides the col-
umns of the variant table. For the maintenance of the table content and for the
usage in object dependencies, the settings in the characteristic definition—such
as single-level/multilevel, restrictable, required characteristic, default values, or
object dependencies—are irrelevant. In the characteristic view, you can define a
first key. This key is merely a prerequisite and is significant only if you want to
infer values from the variant table. This can be done via constraints or procedures.
For value restrictions, conditions, or mere consistency checks, the system ignores
the key information.
For inference of values, constraints with an inference part can evaluate more than
the Value Assignment Alternative (key in the Characteristics tab) that is specified
in the tab. You can create these additional alternatives in the corresponding view.
In PMEVC, you can also maintain the elements of the Content directly in the
variant table.
153
6060.indb 153 10/4/11 11:56 AM
第 26 页 / 共 52 页
2 Creating a Product Model for SAP Variant Configuration
Besides maintaining content from PMEVC, you can implement the content via a
common transaction, namely, Transaction CU60. In addition to the standard display
(1 in Figure 2.35), this transaction also allows for displays as a matrix (2) and as
a list (3). These last two displays enable you to easily decide which combination
is supposed to be used (decision table).
Figure 2.35 Variant Tables—Content Maintenance with the Common Transaction
IPC-Compatible Table Content
You can also select multiple values for each field in the standard display. This display
isn’t IPC-compatible, but you can transfer it to such a display using the respective menu
entry (Add up, Untag).
Besides the already introduced options of maintaining variant table content using
PMEVC or a common transaction, namely, Transaction CL60, you can also import
content from Excel tables. For this purpose, you can use Transaction CU60E.
154
6060.indb 154 10/4/11 11:56 AM
| IPC-Compatible Table Content |
|---|
| You can also select multiple values for each field in the standard display. This display isn’t IPC-compatible, but you can transfer it to such a display using the respective menu entry (Add up, Untag). |
第 27 页 / 共 52 页
Object Dependencies for the Value Assignment Interface or the Sales View 2.6
Figure 2.36 Transaction CU60E—Data Import from Excel Tables into Variant Table
To import data using Transaction CU60E, the SAP ERP system requires an existing
variant table. This means that you first have to create the required characteristics
and then use these characteristics to create the variant table structure.
The example in Figure 2.36 assumes that the result of the data import is a variant
table (as illustrated at the top of Figure 2.36). The specified preparations in the
ERP system include the creation of the three characteristics that are used in this
example (multimedia package, CD drive, and speakers) as well as the creation of
the variant table structure (T_TAB_VPC00).
When creating and filling the Excel table, the following needs to be considered:
The columns of the Excel table and their sequence must correspond to those of the
variant table, and all values in the Excel table must be in the text format. This also
applies to numerical characteristics in the variant table. The Excel table mustn’t
contain headers or descriptions—only language-independent characteristic values.
The system checks the format of the values during the data import and cancels the
transaction if necessary. The Excel file needs to be saved as a csv file (see Figure
2.36). This means that semicolons are used as separators for this Excel file format.
155
6060.indb 155 10/4/11 11:56 AM
第 28 页 / 共 52 页
2 Creating a Product Model for SAP Variant Configuration
Transaction CU60E requires solely the name of the variant table as well as the name
and address of the Excel file as specifications. You start the data import using the
Execute button ([F8]). Only complete data imports are possible; an option for
change uploads does not exist. The system deletes possibly existing variant table
content and fills the variant table with the new entries.
Transaction CU60E
With regard to Transaction CU60E, please refer to SAP Note 516885. It also contains a
documentation for this transaction.
As already mentioned, you can use variant tables in all types of object dependen-
cies. Basically, the syntax always looks the same (see Listing 2.8).
table <table name>
(<column characteristic>=<interface characteristic>,...)
Listing 2.8 Syntax Concept for Calling Variant Tables
You can break down this visual similarity as follows:
EE The call starts with the keyword table.
EE Then the name of the table is specified.
EE Next, all columns of the variant table that are to be evaluated are listed in brack-
ets. You don’t always have to evaluate the entire table. Because the characteris-
tics of the table don’t have to correspond to the characteristics of the user
interface, the system assigns the corresponding characteristic to the value assign-
ment interface after each column characteristic.
Figure 2.33 shows an example of such a table call in constraints. Note that X. pre-
cedes the characteristics from the value assignment interface. This refers to material
T-VPC, as you can see in the constraint directly above the table call. As mentioned in
Chapter 1, you cannot address objects (the material master in this case) as flexibly
as in constraints. In this case, you can only use the $self., $root., or $parent.
levels. The table access from Figure 2.33 would then be as shown in Listing 2.9.
table TAB_VPC ( T_PC6R = $self.T_PC6R,
T_PC6R = $self.T_PC6R,
T_PC6R = $self.T_PC6R)
Listing 2.9 Table Access in Preconditions, Selection Conditions, and Procedures
156
6060.indb 156 10/4/11 11:56 AM
| Transaction CU60E |
|---|
| With regard to Transaction CU60E, please refer to SAP Note 516885. It also contains a documentation for this transaction. |
第 29 页 / 共 52 页
Object Dependencies for the Value Assignment Interface or the Sales View 2.6
Characteristics of the value assignment interface for which the values are supposed
to be inferred must be linked with $self.; $parent. and $root. are also allowed.
Figure 2.37 Coupling of Variant and Database Tables
Coupling with database tables also needs to be discussed (see Figure 2.37) in the
context of the maintenance of the variant tables. The background for this function
is the requirement to also address database tables in object dependencies. How-
ever, this is not directly possible in object dependencies. There are two options for
addressing database tables in object dependencies.
EE Directly addressing a database table (variant function)
You create a variant function and address the database table in the function
module that corresponds to the variant function. The variant function is used
in object dependencies.
EE Indirectly addressing a database table (coupled variant table)
You create an appropriate variant table and couple it with the database table. If
the coupling is active, you can directly include the variant table in any type of
object dependencies. Then the database table is also addressed.
The second option uses an assignment of the database table in the maintenance of
the basic data of the variant table structure. You can also distinguish between the
following two scenarios.
1. Scenario 2—Starting Point Database Table
An existing database table is to be addressed using this approach. You must create
the appropriate characteristics, that is, characteristics with the appropriate format,
in this scenario. You have to create characteristics only for the fields (that is, the
columns of the database table) that are to be addressed in the object dependen-
cies. Then you create a variant table that contains exactly these characteristics as
columns. You must include the name of the database table in the basic data of the
variant table. This allows for a field assignment. All characteristics of the variant
table are linked to the columns of the database table. Finally, you must activate
the coupling. Afterward, you can evaluate the database table in all types of object
dependencies by addressing the coupled variant table in the syntax.
157
6060.indb 157 10/4/11 11:56 AM
第 30 页 / 共 52 页
2 Creating a Product Model for SAP Variant Configuration
2. Scenario 2—Starting Point Variant Table
An existing variant table that may already be used in object dependencies is to be
converted into a database table. This scenario is used, for example, when variant
tables reach a size that may lead to performance problems. However, there may
also be other reasons.
In this case, you need to create an appropriate database table. With regard to the
format, the fields of the table must be created in such a way that they can include
at least the values of the corresponding characteristics. The key fields of the data-
base table are not relevant for Variant Configuration. Only the key combination
of the variant table is critical for the evaluation of object dependencies. Of course,
you must select the database table key in such a way that uniqueness is ensured
for later content.
Analogous to the first scenario, you must now couple the variant table with the still
empty database table, activate it, and assign the corresponding fields. Finally, the
content of the variant table is transferred to the database table using Transaction
CU59. In this second scenario, you don’t have to adapt all object dependencies that
use this variant table. They have exactly the same function as before. Bear in mind
that the content of the variant table is inactive when the coupling has been activated.
In the standard version, you maintain the content directly in the database table.
You can lock the content maintenance of the variant table via the status. You can
also delete the content of the variant table to prevent misunderstandings.
Additional maintenance in the variant table with a delta transfer of this data to the
database table is also possible. However, this isn’t very useful because you cannot
delete rows when implementing a delta transfer, and problems may occur due to
the key of the database table.
2.6.4 Constraints in Detail
As already mentioned, you can use all types of object dependencies for the configu-
ration in the value assignment interface. Constraints are the most important and
default type of object dependencies, because they can be used for nearly all tasks.
You can therefore perform the following tasks using constraints:
EE Setting values
EE Checking values (in consistency checks)
158
6060.indb 158 10/4/11 11:56 AM
第 31 页 / 共 52 页
Object Dependencies for the Value Assignment Interface or the Sales View 2.6
EE Addressing any objects that are also in the multilevel configuration (not only
$self, $parent, or $root)
EE Working with a high performance level
EE Working in a declarative way (this means you don’t have to consider a process-
ing sequence or similar factor in the modeling process)
Constraints are collected in dependency nets (also referred to as constraint nets).
Dependency nets are generally assigned to the configuration profile. It doesn’t
matter whether a large number of constraints are assigned to a dependency net.
However, the number of dependency nets in a configuration model should be kept
to a minimum, even though you cannot always ensure that only one dependency
net is assigned to the configuration profile of the header material of the configura-
tion profile.
Need for Multiple Constraint Nets
If, for example, individual configurable assemblies of the overall model are sold separately,
all constraints that are related to this assembly must also be assigned to the configuration
profile of this assembly via a dependency net.
Within the dependency net, the constraints are local object dependencies; the
dependency net itself is global. Note that both have a status. Constraints are con-
sequently active only if the following conditions are met:
EE The constraint is released.
EE The dependency net is released.
EE The dependency net is assigned to a configuration profile that is considered dur-
ing configuration.
A constraint consists of at least two and at the most four sections. Objects and
restriction are the mandatory sections here. The following explains the four sec-
tions according to their sequence:
1. Objects
In this section, you enter all used classes and objects and define variables.
2. Condition
This section is only used to (optionally) specify a central condition under which
the constraint is supposed to be evaluated.
159
6060.indb 159 10/4/11 11:56 AM
| Need for Multiple Constraint Nets |
|---|
| If, for example, individual configurable assemblies of the overall model are sold separately, all constraints that are related to this assembly must also be assigned to the configuration profile of this assembly via a dependency net. |
第 32 页 / 共 52 页
2 Creating a Product Model for SAP Variant Configuration
3. Restriction
In this section, you define equations, tables, and functions for inferences of
values and/or value checks.
4. Inferences
This section enables you to (optionally) enhance the inference and restrict char-
acteristic values.
The objects section is mandatory and must contain the objects that are addressed
in the constraint. Objects can be classes, material masters, and documents. The
declaration has the following syntax:
EE Class
(<class type>)class name, for example, (300)T_VPC
EE Material master
(Material)(<class type>)(Nr = ’<material number>’),
for example, (Material)(300)(Nr = ’T-VPC’)
EE Document
(Document)(<class type>)(Type = ’<document type>’, Version = ’<document
version>’, Part = ’<document part>’, Nr = ’<document number>’),
for example, (Document)(017)(Type=’DRM’,Ver-sion=’01’,Part=’000’,Nr=’T-
VPC’)
In the objects section, you can also locally define variables for the constraint; the
constraint in Figure 2.33 uses such an object variable. Object variables for classes are
declared by is_a, and for all other objects by is_object, as shown in Figure 2.33.
The constraint in Figure 2.33 would be as shown is Listing 2.10 without variables.
objects: (300)t_vpc
restrictions: table tab_vpc ( t_pc6r = (300)t_vpc.t_pc6r,
t_pc8r = (300)t_vpc.t_pc8r,
t_pc3r = (300)t_vpc.t_pc3r).
Listing 2.10 Sample Constraint: Table Call without Using Variables
Note that in this context you can also declare the variant class instead of the mate-
rial master in the objects sections, as done here. After the equals sign, the syntax
is as follows: <object>.<characteristic>.
In the objects section, you can also define characteristic variables, which are class-
specific. You therefore don’t have to use object variables here. In the syntax, this
160
6060.indb 160 10/4/11 11:56 AM
第 33 页 / 共 52 页
Object Dependencies for the Value Assignment Interface or the Sales View 2.6
is implemented with where and a list of the variables separated by a semicolon.
The constraint in Figure 2.33 would be as follows with characteristic variables
(Listing 2.11):
objects: (300)t_vpc where ?spe = t_pc6r ;
?cas = t_pc8r ;
?cpu = t_pc3r.
restrictions: table tab_vpc ( t_pc6r = ?spe,
t_pc8r = ?cas,
t_pc3r = ?cpu).
Listing 2.11 Sample Constraint—Table Call Using Characteristic Variables
Specific Variable Names
As shown here, question marks are often used as variables so that they can be easily
identified. You cannot use variables for characteristics from tables, that is, for columns.
If the objects section lists multiple objects, use a comma to separate them.
The restriction section is the second section that is mandatory in constraints. Here,
you can carry out consistency checks. The constraint reports an inconsistency when
the restriction section is not met. You can also use constraints to infer values. For this
purpose, the equations must be solved for the value that is supposed to be inferred,
or you must use the inference section. This is further detailed in the context of the
inferences section below. The restriction section enables you to restrict values (see
Figure 2.33). You can use variant tables and variant functions.
You can also work with conditions in the restriction section. The if syntax element
is provided for this purpose. Additional syntax elements, such as then or else, are
not available. As shown in Listing 2.12, first the statement and then the if condi-
tion is provided.
restrictions:
(300)t_vpc.m1 = ’a’ if (300)t_vpc.m2 = ’x1’,
false if (300)t_vpc.m2 = (300)t_vpc.m3.
Listing 2.12 Restrictions with if Conditions
This restriction section contains two statements that are listed with a comma. The
first statement consists of the assignment of the a value for the m1 characteristic.
The second statement only leads to an inconsistency message if the if condition
161
6060.indb 161 10/4/11 11:56 AM
| Specific Variable Names |
|---|
| As shown here, question marks are often used as variables so that they can be easily identified. You cannot use variables for characteristics from tables, that is, for columns. |
第 34 页 / 共 52 页
2 Creating a Product Model for SAP Variant Configuration
after false is met. The processing of the false syntax element basically generates
inconsistency messages and can only be used in constraints.
In constraints, you can use a condition section. The condition section must always
be inserted between the objects and the restriction section. It contains exactly
one logical expression. The constraint is not processed until the condition of the
condition section is met, which is very good regarding the performance. You can
also work with variables and variant tables in the condition section, as Listings
2.13 and 2.14 show.
objects: (300)t_vpc where ?os = t_pc01;
?hd = t_pc04,
(300)t_vpr where ?tr = t_pr02.
condition : specified ?hd.
restrictions : ?tr = ?os
Listing 2.13 Sample Constraint with Condition Section
objects: (300)t_vpc where ?spe = t_pc6r;
?cas = t_pc8r;
?cpu = t_pc3r.
condition: table tab_vpc ( t_pc6r = ?spe,
t_pc8r = ?cas,
t_pc3r = ?cpu).
restrictions: false.
Listing 2.14 Sample Constraint with Table Call in the Condition Section
In Listing 2.13, the restriction section is evaluated under the condition that a value
has been assigned to the t_pc04 characteristic. In this case, the system checks whether
the same values have been assigned to the t_pc01 and t_pr02 characteristics. If
no values have been assigned to t_pc01, the system copies the value assignment
of t_pr02 to this characteristic.
In Listing 2.14, an inconsistency message is output if the (300)t_vpc variant class
in the value assignment interface corresponds to a row of the tab_vpc variant
table in the configuration. This is used if inconsistent value assignment combina-
tions are collected in variant tables. You can also create such constraints with the
table constraint wizard. In this case, you must select the Checking Inconsistent
Combinations entry as the mode of action. In this context, have a look at Figure
2.32 in Section 2.6.2.
162
6060.indb 162 10/4/11 11:56 AM
第 35 页 / 共 52 页
Object Dependencies for the Value Assignment Interface or the Sales View 2.6
The inferences section, which is optional just like the condition section, is the fourth
section of a constraint. This section is always the last section of the constraint and
enhances the evaluation of the restriction section. This “enhanced evaluation” can
refer to equations, variant tables, variant functions, and restrictable characteristics.
The syntax of the inferences section is merely a list of characteristics.
Consequently, an equation, V = L * W * H, for example, in a restriction section with-
out a subsequent inferences section is only evaluated for calculation in such a way
that V is the product of L, W, and H. However, if the constraint has the following
structure, the fourth value is inferred from any three values (see Listing 2.15).
objects: (300)t_vpc where
v = t_pc91 ; l = t_pc92;
b = t_pc93 ; h = t_pc94.
restrictions: v = l * b * h.
inferences: v, l, b, h.
Listing 2.15 Sample Constraint with Equation and Inferences Section
Variant tables and functions for which more than one value assignment alternative
is defined are additional examples (see Figure 2.34 in Section 2.6.3). If you don’t
use the inferences section here, the system can only evaluate the first key, that is,
the first value assignment alternative. However, if the constraint has the following
structure and if two additional value assignment alternatives exist for the first and
third characteristics and for the second and third characteristics, the system can
infer the remaining third characteristic from the table from any two characteristics
to which values have been assigned (see Listing 2.16).
objects: (300)t_vpc where ?spe = t_pc6r ;
?cas = t_pc8r ;
?cpu = t_pc3r.
restrictions: table tab_vpc ( t_pc6r = ?spe,
t_pc8r = ?cas,
t_pc3r = ?cpu).
inferences: ?spe, ?cas, ?cpu.
Listing 2.16 Sample Constraint with Variant Table and Inferences Section
For usage with restrictable characteristics, have a look at the constraint in Figure
2.33 in Section 2.6.2.
Now that we’ve discussed constraints in detail, the following sections deal with
the other types of object dependencies. As already mentioned, you can use all
163
6060.indb 163 10/4/11 11:56 AM
第 36 页 / 共 52 页
2 Creating a Product Model for SAP Variant Configuration
types of object dependencies to design the value assignment interface in sales and
distribution.
2.6.5 Preconditions
You can use preconditions to disallow individual characteristic values or entire
characteristics for the value assignment interface. If you don’t use preconditions,
values can be assigned to any characteristic of the value assignment interface in any
sequence. You can select any value from the list of the allowed values—irrespective
of the value assignment of other characteristics. In this context, you have to find
answers to two questions:
1. What is supposed to be disallowed? That is, which characteristic or which char-
acteristic value is supposed to be dynamically disallowed?
2. When is it supposed to be allowed? That is, when is the corresponding charac-
teristic or characteristic value supposed to be allowed within the scope of the
value assignment?
The storage location of the respective precondition answers the first question.
The syntax answers the second question. For example, if the XYZ engine is only
supposed to be offered for the sport version of a car configuration, a precondition
must be assigned to the XYZ characteristic value of the characteristic for the engine
selection (What is supposed to be disallowed?). The syntax contains the prerequisite
that the sport version was selected for which the XYZ+ engine is allowed (When
is it supposed to be allowed?).
What effect does it have when the $self.version = ’sport’ precondition is assigned
to the XYZ characteristic value?
EE Assigning the “Sport” value to the “Version” characteristic
If the “Sport” value is assigned to the “Version” characteristic, the list of allowed
values in the characteristic for the engine will provide all values as if no precon-
dition exists.
EE Assigning a different value than “Sport” to the “Version” characteristic
If a different value than “Sport” is assigned to the “Version” characteristic, the
“XYZ” value will be missing in the list of allowed values in the characteristic for
the engine.
EE No value assigned to the “Version” characteristic
Note that the precondition is considered to be met if no value is assigned to the
164
6060.indb 164 10/4/11 11:56 AM
第 37 页 / 共 52 页
Object Dependencies for the Value Assignment Interface or the Sales View 2.6
“Version” characteristic. In this case, the list of allowed values of the engine
characteristic would include all engine values. In the standard version all allowed
values are initially available. During the value assignment, the system hides the
values that are no longer allowed. If you don’t want to use this standard logic,
you must implement this by adding $self.version = ’sport’ and $self.ver-
sion specified. The system then first provides all values that can be generally
selected, and the list of allowed values is gradually extended.
EE Sequence of the value assignment
The precondition mentioned in the previous item is elegant in one direction
only: if values are assigned first to the version and then to the engine. If you
start by assigning values to the engine, you can select any engine and any ver-
sion. Only then is the precondition evaluated. It retroactively disallows the XYZ
engine. This leads to an inconsistency message if the XYZ engine and a version
other than sport are selected. You can avoid this by assigning a precondition to
the sport version. Another option is to force a processing sequence. A value is
not supposed to be assigned to the “Engine” characteristic until the version is
known. In this case, you use a precondition for the characteristics. You assign a
precondition of the $self.version specified (When is it supposed to be
allowed?) to the engine characteristic (What is supposed to be disallowed?).
EE Multiple preconditions
You can also assign multiple preconditions to characteristic values or character-
istics. In this case, the value assignment is only allowed if all preconditions are
met. It can be considered an And link. You can only implement an Or link between
preconditions when you include the conditions in a precondition. A precondi-
tion can be any complex condition using any brackets, negations, and concat-
enation with and and or.
Values or characteristics that are excluded via preconditions are not displayed in
the value assignment interface by default. However, you can use the settings in
the configuration profile (see Figure 2.38), for example, to define that disallowed
characteristic values or characteristics are displayed but not used for the value
assignment.
In Figure 2.38, the settings were called via the menu during the configuration.
The With excluded characteristics checkbox was selected here. As a result, the
disallowed value, XYZ, is displayed but cannot be selected. Similarly, disallowed
characteristics would be displayed, but you couldn’t assign values to them.
165
6060.indb 165 10/4/11 11:56 AM
第 38 页 / 共 52 页
2 Creating a Product Model for SAP Variant Configuration
Figure 2.38 Displaying Excluded Characteristic Values (Preconditions)
You can use variant tables in all types of object dependencies, that is, also in pre-
conditions. The syntax of a precondition that uses the table from Figures 2.31 and
2.34 could be, as shown in Listing 2.17:
table TAB_VPC ( T_PC6R = $self.T_PC6R,
T_PC8R = $self.T_PC8R,
T_PC3R = $self.T_PC3R)
Listing 2.17 Sample Variant Table in a Precondition
This example has the same syntax as a procedure. Instead of $self, you can also use
$parent or $root everywhere—provided that this is correct with regard to content.
You could assign such a precondition with exactly this syntax to one of the three
mentioned characteristics; however, this wouldn’t be a clean solution.
Considering the increasing elegance of the solution, the following three options
can be used to disallow values.
EE Precondition for the characteristic (as described)
EE Precondition for the characteristic value (as described later)
EE A constraint with this variant table and restrictable characteristics (as the most
elegant solution; see Figure 2.33)
If you selected the variant with the precondition for the characteristic, the pre-
condition wouldn’t affect the value assignment of the three characteristics. Not
166
6060.indb 166 10/4/11 11:56 AM
第 39 页 / 共 52 页
Object Dependencies for the Value Assignment Interface or the Sales View 2.6
until values have been assigned to all three characteristics addressed in the variant
table does the precondition become active and output an inconsistency if the table
doesn’t contain this value assignment combination.
However, preconditions for characteristic values are more elegant than this variant
with a precondition for the characteristic but still not as elegant as the variant with a
constraint. For example, if you assume that values are assigned to the characteristics
in a fixed sequence and the T_PC3R characteristic is the last characteristic to which
a value is assigned, you can provide preconditions for the characteristic values of
this characteristic. The precondition for the value ’03’ would have the following
syntax (see Listing 2.18):
table TAB_VPC ( T_PC6R = $self.T_PC6R,
T_PC8R = $self.T_PC8R,
T_PC3R = ’03’)
Listing 2.18 Sample Variant Table in a Precondition for Characteristic Value ’03’
Analogous preconditions also apply to the other values of this characteristic. Com-
pared to the first variant—that is, the precondition for the characteristic—this has
the advantage that only the values that lead to a consistent value assignment are
provided for the third characteristic. Preconditions for characteristics or character-
istic values don’t require restrictable characteristics.
2.6.6 Selection Conditions
Selection conditions can dynamically convert optional characteristics into required
characteristics.
Optional Characteristics
This technology requires that the Entry Required checkbox in the characteristic is not
set, that is, the characteristic is actually a so-called optional characteristic.
If you assign a selection condition to such a characteristic, the characteristic dynami-
cally becomes a required characteristic if the condition is met. Let’s illustrate this
with an example.
167
6060.indb 167 10/4/11 11:56 AM
| Optional Characteristics |
|---|
| This technology requires that the Entry Required checkbox in the characteristic is not set, that is, the characteristic is actually a so-called optional characteristic. |
第 40 页 / 共 52 页
2 Creating a Product Model for SAP Variant Configuration
Sport Version Requires a GPS
For the car configuration, the selection of a GPS needs to become a prerequisite for the
sport version. In this context, the rules and the syntax must be analogous to the pre-
conditions. The selection conditions must be assigned to the GPS characteristic (What
is required?); the content of the syntax is the condition of the sport version (When is
it required?). The syntax is analogous to the precondition specified previously: $self.
version = ’sport’. The selection condition with this syntax is assigned to the GPS
characteristic. This way, the selection of a GPS is required for the sport version.
Compared to the rules of preconditions, there are two differences, which must be
considered:
EE Multiple selection conditions for a characteristic
If multiple selection conditions are assigned to a characteristic, it is sufficient
for the characteristic to become a required characteristic when one selection
condition is met.
EE No value assigned to a characteristic in a selection condition
If a selection condition addresses characteristics to which no value has been
assigned, the selection condition is not met. In contrast to a precondition with
the same syntax, the selection condition above outputs “false,” that is, not met
if no version is selected.
2.6.7 Procedures
Procedures are object dependencies that set values. In contrast to other types of
object dependencies, they can affect processing sequences. For this purpose, the
configuration profile is assigned with procedures, and a sorting is transferred.
There is also the option of assigning procedures to characteristics and characteristic
values. However, this method is not supported for the configurator of the IPC and
is consequently not discussed here. Instead, we’ll discuss in detail the assignment
to the configuration profile. Procedures allow for fixed or dynamic assignments of
values. The following list describes in detail what this means:
EE Fixed assignment of values
A fixed assignment of values refers to an assignment of values that cannot be
overwritten by users or constraints. Attempts to do so would result in inconsis-
tencies. Procedures can also not overwrite external assignments of values, that
is, values set by users or constraints. The same applies to users and constraints.
168
6060.indb 168 10/4/11 11:56 AM
| Sport Version Requires a GPS |
|---|
| For the car configuration, the selection of a GPS needs to become a prerequisite for the sport version. In this context, the rules and the syntax must be analogous to the pre- conditions. The selection conditions must be assigned to the GPS characteristic (What is required?); the content of the syntax is the condition of the sport version (When is it required?). The syntax is analogous to the precondition specified previously: $self. version = ’sport’. The selection condition with this syntax is assigned to the GPS characteristic. This way, the selection of a GPS is required for the sport version. |
第 41 页 / 共 52 页
Index
? R Assignment of default values, 136 Arithmetic operator, 134
|| R Character string link, 135 ASAP Implementation Roadmap, 567
Assemble-to-order (ATO), 41
Assembly processing, 275, 393
A Assignment of default values, 136
Assignment of production resources and tools,
A2A R Application to application, 658 97
ABAP and object dependencies, 131 Assignment of values
ABAP function module, 57, 591 Dynamic, 123, 169
ABAP programming language, 55, 564 Fixed, 123, 168
Abstracter data type (ADT), 407 ASUG R Americas‘ SAP Users‘ Group, 637
Access node, 230 Asynchronous, 618
Action, 61, 124 ATO R Assemble-to-order, 41
Actual characteristics, 451 Authorization group, 77
Actual configuration, 450 Authorization object
Actual value assignment, 451 C_LOVC_DEP, 312
ACWG R American Configuration C_TCLS_BER, 323
Workgroup, 640 Automated product configuration, 35
Adaptable Custom Solution (ACS), 224, 229 Avenue from VC, 532
Advanced mode, 61 Avenue Migration, 533
Advanced Planning & Optimization (APO), Avenue Orchestrator, 527
304, 451 Avenue Remodel, 533
Aggregation, 408 Avenue to VC, 533
Aggregation characteristic, 410 Avenue XML, 532
ALE R Application Link Enabling, 314
Alternative Dates, 383
American Configuration Workgroup (ACWG), B
640
Americas‘ SAP Users‘ Group (ASUG), 637 B2B R Business-to-Business, 48
Analysis tool, 141 B2C R Business-to-Consumer, 48
AP Application Platform, 62 Backward chaining, 47
AP Configuration Engine, 62, 337, 338, 370 BAdI, 229
Application group, 455 Balancing, 408
Application Link Enabling (ALE) Baldor Electric, 626
ALE distribution, 411 Baseline, 428, 430
ALE distribution model, 413, 418 Explosion, 432
ALE partner profile, 417, 418 Batch classification, 451
ALE partner profiles, 413 Batch job, 431
Application log, 439 Batch selection criteria, 451
Application Programming Interface (API), 669 Bill of material explosion, 101
Application-to-application (A2A), 658 Bill of materials, 37, 214, 219, 371, 377
AP Pricing Engine, 338 Application, 101, 222, 420
683
6060.indb 683 10/4/11 11:59 AM
第 42 页 / 共 52 页
Index
Configurable bill of materials, 38 Management, 75
Enhancements, 38 Name, 76
Explosion, 101 Planning, 292, 330
Filter, 101 Status, 77
Has part, 406 Value, 36
Maintenance, 183 Characteristics-dependent planning, 451, 461
Manual enhancement, 38 Character string link, 135
Maximum BOM, 38 Character string operator, 135
Minimum BOM, 406 Checkbox
Part of, 400, 406 Configurable Material, 89
Relationship Class hierarchy, 55
Structures, 582 Classification, 84
Super BOM, 38 System, 55, 75
Synchronization, 232 Classified materials, 187
Usage, 221 Class management, 82
Business Object, 648 Class network, 55
Building block, 406 Class node, 57, 82, 183, 217, 322, 371, 591
Business Application Programming Interface Cloth, 449
(BAPI), 534 Coaching project, 582
BO R Business object, 648 Coil, 449
Business-to-Business (B2B), 48 Company philosophy, 552
Business-to-Consumer (B2C), 48 Comparison function, 226
Business Transaction Event (BTE), 417 Component condition, 348
Component formula, 348, 354
Component list in planned and production
C order, 260
Component structure, 37
Cable, 449 Component decomposition, 37
CCE R Core Constraint Engine, 657 Composition problem, 39, 395, 403
Change Decomposition problem, 403
ECR, 378 Dynamic modification of the BOM
Mass data, 559 structure, 395
Master, 378 Interlinked component structure, 395, 400
Master record, 378 Top-down approach, 403
Number, 376, 378, 390 Condition, 159, 162, 348
Number type, 378 Condition technique, 59
Type, 380 Condition type, 193
Changeable material variants, 450 VA00, 193
Change management for master data, 73 VA01, 193
Characteristic, 36, 37, 71, 371, 377 Configit A/S, 535
Characteristic value, 371 ConfigScan Validation Suite, 515, 528
Create, 51 Configurable
Dependency, 37 Assembly, 102
Disallow a characteristic value, 164 General maintenance task list, 280
Display, 455 Material, 49
Fast data entry, 454 Model service specification, 274
Group, 77, 177 Purchased material, 591
684
6060.indb 684 10/4/11 11:59 AM