Variant Tables

 1. Overview
 2. Example Model
 3. Variant Table Structure (CU61, CU62, CU63)
 4. Maintaining Variant Table Entries
o 4.1 Table Maintenance CU60
o 4.2 Excel-Import (CU60E)
 5. Linking Variant Tables to Database Tables
 6. Variant Tables in Dependencies
o 6.1 Inferring Values
o 6.2 Validating Values

1. Overview
Variant tables are used to store combinations of characteristic values. They can be
referenced in dependencies to infer, check and restrict values. More specifically, they are
used in:

 selection conditions, preconditions, constraints and procedures to check the

consistencyof the values entered,
 procedures and constraints to infer values,
 constraints to restrict values for a characteristic.

One advantage of using them is that you only need to change the variant table, if the
interdependencies between characteristics change, and not the dependencies. This greatly
simplifies the maintenance tasks when a model changes.
The relevant transactions for variant tables are the following:

Transaction Description
CU61 Create variant table
CU62 Change variant table
CU63 Display variant table
CU64 Variant table structure list
CU60 Variant table maintenance
CU59 Transfer variant table contents to database table (Report
RCCUVTDB)
CU60E Excel upload for variant table contents
Remark: In order to delete a variant table, you need to first remove all the lines in the
CU60 and then the table itself is deleted in the CU62. However, once a variant table was
maintained with a change number, the table can no longer be deleted.

2. Example Model
In order to discuss the various features of variant tables is a concrete manner, we will use a
very simple example model, which describes the properties of a Personal Computer (PC). It
consists of 4 single-valued characteristics with the following values:

 CH_PCTYPE (OFFICE, MEDIA, GAMING)

 CH_PROCESSOR (3GHz, 4GHz, 5GHz)
 CH_MEMORY (8GB, 16GB, 32GB)
 CH_HARDDISK (1TB, 2TB, 3TB)

Using a variant table we will build the following combinations of characteristic values:

CH_PCTYPE CH_PROCESSOR CH_MEMORY CH_HARDDISK

OFFICE 3 GHz 8 GB 1 TB
MEDIA 4 GHz 16 GB 2 TB
GAMING 5 GHz 32 GB 3 TB
As you can see, each column in a variant table represents a characteristic and every row
corresponds to an allowed combination of characteristic values. In this particular example,
an Office-PC has a 3 Gigahertz Processor, 8 Gigabytes of Memory and a 1 Terabyte
Harddisk. Similarly, the properties of a Media- and Gaming-PC are displayed in the
corresponding rows of this table.

3. Variant Table Structure (CU61,

CU62, CU63)
In order to create a variant table you start with the transaction CU61, where you first need
to enter a name for the table. We will call our table VT_PC.

In the field Date the current date is entered by default, so you don't need to worry about
that. In the next screen you need to enter a description for the variant table. Note that the
Status is currently 0(In Preparation) - this needs to be changed later on.
As you can see, in this screen there exists also the possibility to link the variant table to a
database table. This functionality will be discussed in section 5.
After pressing on Characteristics you enter the following screen:
Here you can enter the characteristics that you want to use in the variant table. We set the
characteristic CH_PCTYPE as a Key Field. This means that each entry in the column
CH_PCTYPE must be unique. By using dependencies we will use this characteristics later
on to infer values for CH_PROCESSOR, CH_MEMORY and CH_HARDDISK in section 6.
Remark: Marking a characteristic as a Key field is only relevant if you want to infer values
using dependencies.
After pressing Back(F3) you return to the previous screen.
There you need to change the Status to 1(Released). Finally, confirm everything by
pressing Save(Ctrl+S).
In the transaction CU62 the variant table structure can be changed and in the CU63 it can
be displayed.

4. Maintaining Variant Table Entries

4.1 Table Maintenance CU60
So far we have only specified which characteristics are to be used in the variant table. In
our case these are the characteristics CH_PCTYPE, CH_PROCESSOR, CH_MEMORY
and CH_HARDDISK. However, we have not specified any values so far. This is done in the
transaction CU60.
Upon entering this transaction you see the following screen, where you need to enter the
name of the variant table.
After pressing Maintain(F6) you see the following screen:

Here we have already entered the characteristic values for our model according to the table
from section 2.
By using the Check (Shift+F4) functionality, you can make sure that your variant table
complies with the standard (Key Field entries are unique, no empty entries etc.). For the
table maintenance the properties of the used characteristics (single/multi-valued,
restictable, entry required) are irrelevant.
Remark: In order to enter multiple values in a multi-valued characteristic you need to
double-click on a field in the table maintenance CU60. In the pop-up that appears, you can
select the characteristic values using radio-buttons. Note that this representation is not IPC-
compatible. However, there exists the possibility to normalize a variant table with multiple
values by navigating to Table → Untag. As a result, a row of the form

01 AA, BB
is converted to
01 AA
01 BB
In this representation the variant table is IPC-compatible again. Also note that this
normalization should be used cautiously in conjunction with Key Fields, as this might result
in errors during the variant table Check (Shift + F4).
Alternatively to the Standard View of the CU60, there exists the possibility to display the
allowed value combinations in a matrix form. By selecting Table → Decision table →
Presentation: Matrix, the following screens appears:

Each column in this matrix corresponds to an a priori possible value combination. Since our
variant table contains 4 characteristics, with 3 values each, there 3·3·3·3=81 columns. The
variant table restricts this list to 3 combinations - these are the green columns in the table.
In this matrix representation these 3 value combinations are marked with a red X. This way
one can view and maintain allowed value combinations very quickly.
In addition this matrix form, there is the possibility to select Presentation: Number of
combinations under Table as a presentation style. This provides a list view of all possible
combinations - the allowed combinations are marked with a + sign.

4.2 Excel-Import (CU60E)

Apart from the standard transaction CU60 there also exists possibility to fill a variant table
with values using an Excel-spreadsheet. This is done with the transaction CU60E.
In order to do that, it is necessary that there is already a variant table structure in your
system, which contains all the characteristics you want to use. Moreover, the Excel-file that
you use to import the variant table content must of a certain form:

 The columns must have the same order as in the variant table.
 Use no header lines. The Excel table must only contain the characteristic values.
 All characteristic values must have text format. (This also holds for numerical values.)
 For the characteristic values only the language-independent format must be used.
 The Excel-file must have .csv format.
If we were to fill the variant table for our example with the CU60E instead of the CU60 from
section 4.1, the corresponding Excel-file would look as follows:

After you have prepared your Excel-file, you need to enter the name of the variant table
and the location of the file in the transaction CU60E:

After pressing Execute(F8) the content of the Excel-file is transferred to the variant table.
Remark: Note that the CU60E does not support a change-import - when an Excel-file is
uploaded, all entries in the variant table are deleted and replaced by the values from the
Excel-file. In particular, a change-import using change numbers is not supported in the
CU60E.
A more detailed documentation for the CU60E can be found in the attachment of
note 516885 .

5. Linking Variant Tables to

Database Tables
There are certain situation where it is useful to link a variant table to a database (DB) table.
For example, using very large variant tables in dependencies can result in long response
times. In this case, a link to a DB table can significantly improve the performance, since the
DB table is called in dependency knowledge, instead of the variant table.
Remark: More information on performance best practices for variant tables can be found in
note 917987 .
When linking a variant table to a DB table, there are two scenarios which must be
distinguished:

I. An existing DB table is linked to a variant II. An existing variant table is linked to a DB

table table
In this scenario you start with a DB table (e.g. the table In this scenario you start with an existing variant table,
MARA from the material master). By linking it to a whose content will be transferred to a DB table. For
variant table, the content the DB table can be used in performance and maintenance reasons, this can be
dependencies via the variant table without making use useful for very large variant tables (>100.000 cells).
of variant functions.
In order to do that, you need to create a DB table,
In order to do that, you need to first create the whose column fields have a format which is "suitable"
characteristics which are supposed to be the columns of for the characteristics of the variant table - for
the variant table later on. Note that you don't need to example, if the characteristic is a five-digit numerical
rebuild all of the columns of the DB table using value, then the DB field must be NUM(5) - but
characteristics. Creating the characteristics that you NUM(6) or larger would also be fine. You just have to
eventually use is sufficient. Next you create the variant make sure that the DB field is large enough, so that
table structure in the CU61 with the characteristics that parts of the characteristic values are not cut off. Once
you have created. After entering the DB table name in the DB table was created in the SE11, you switch to
the field Database Tableof the CU61, the link between the CU62 were you enter the DB table name in the
the DB table and the variant table is active. Basis Data of the variant table. After saving, these two
objects are linked. In order to actually transfer the data
from the variant table to the DB table, you need to
execute to the transaction CU59, where you just enter
the name of the variant table.
Now, whenever the variant table is called in
dependency knowledge, the DB table is called instead
- you don't need to make any adjustments in the
dependencies for this to work. Note that all the
maintenance tasks must now be done in the DB table -
changes to the variant table content in the CU60 do not
have any effect.

6. Variant Tables in Dependencies

Variant tables can be used in all types of dependencies (selection conditions,
preconditions, procedures and constraints). The structure of a table call is always the
same:
Copy Code

1. table <TABLENAME> (<column> = <characteristic>,...)

It is initialized with the keyword table, followed by the name of the variant table. In
parenthesis you start with a column-name of table and set it equal to some characteristic in
your variant class. The various column-characteristic pairs are separated by commas. Note
that you don't have to use all the columns from the variant table.

6.1 Inferring Values

You can use the following variant table call in a procedure to infer the values of
CH_PROCESSOR, CH_MEMORY and CH_HARDDISK, based on the value of
CH_PCTYPE.
Copy Code

1. table VT_PC (
2. CH_PCTYPE = $self.CH_PCTYPE,
3. CH_PROCESSOR = $self.CH_PROCESSOR,
4. CH_MEMORY = $self.CH_MEMORY,
5. CH_HARDDISK = $self.CH_HARDDISK )

Once the characteristic CH_PCTYPE is entered in the configurator, the other

characteristics CH_PROCESSOR, CH_MEMORY and CH_HARDDISK are inferred,
according to the table from section 2. This works because CH_PCTYPE is a Key-Field in
the variant table.
Note that in procedures, the characteristics in the dependency must have
the $self, $root or $parent prefix. Characteristics which are inferred must have
the $self prefix.
Alternatively you can also use constraints to infer characteristic values. Here is an example
for a constraint that has the same functionality as the procedure from before:
Copy Code

1. OBJECTS:
2. PC is_a (300) EMM_CLASS_PC
3.
4. CONDITION:
5. PC.CH_PCTYPE specified
6.
7. RESTRICTION:
8. table VT_PC (
9. CH_PCTYPE = PC.CH_PCTYPE,
10. CH_PROCESSOR = PC.CH_PROCESSOR,
11. CH_MEMORY = PC.CH_MEMORY,
12. CH_HARDDISK = PC.CH_HARDDISK )
13.
14. INFERENCES:
15. PC.CH_PROCESSOR, PC.CH_MEMORY, PC.CH_HARDDISK

Here the variant class, that contains the characteristics of our model, is called
EMM_CLASS_PC.

6.2 Validating Values

With constraints we can also validate characteristic values, i.e. we can check whether a
given combination of values matches a combination from a variant table. If they don't
match, we want to get an inconsistency in the configurator.
The basic idea is the following: Constraints whose RESTRICTION-part only contains
FALSE always raises an inconsistency in the configurator and a variant table call, where
the provided values don't correspond to a valid combination in the table, evaluates to
FALSE. Putting these two things together we get the following constraint:
Copy Code

1. OBJECTS:
2. PC is_a (300) EMM_CLASS_PC
3.
4. RESTRICTION:
5. table VT_PC (
6. CH_PCTYPE = PC.CH_PCTYPE,
7. CH_PROCESSOR = PC.CH_PROCESSOR,
8. CH_MEMORY = PC.CH_MEMORY,
9. CH_HARDDISK = PC.CH_HARDDISK )
So if we enter, for example, CH_PCTYPE = OFFICE, CH_PROCESSOR = 3 GHZ,
CH_MEMORY = 8 GB and CH_HARDDISK = 3 TB, then I get an inconsistency, because
this value combination doesn't exist in the variant table.