Context

Guiding the user through configuration requires dynamic restriction of no longer available choices.

Recommended Practice

Use restrictable characteristics in conjunction with tables.
Minimize use of preconditions.

Benefits of the Practice

Preconditions are always easy to use at first, but with time become increasingly difficult to handle on shared objects. Using restrictable characteristics and table based restrictions (see below) allows for a clean separation restrictable logic from the definition of the characteristic (which can be easily shared driving common data standard).

Exceptions

Calculating the domain of restrictable characteristics in VC is an expensive operation, often more so than running preconditions. If maximizing native VC performance is a must, do not use this practice. If IPC is used for high-level VC configuration, then this exception does not apply (as IPC has much better performance in calculating restricted domains).

Products have a number of characteristics, the allowed combinations of which are considerably constrained (i.e. it’s easier to list allowed combinations than disallowed combinations).

Recommended Practice

Maximize use of variant tables not only for validation and inferences, but also for restrictions by using restrictable characteristics (instead of preconditions).

Benefits of the Practice

Provides for easiest maintenance. Allows to move a large part of modeling effort to the knowledge workers in engineering / marketing. Allows for easy imports of data from external sources.

Exceptions

Do not apply this practice when maximizing VC performance is an absolute must. Variant tables typically all get stored in the same transparent table on R3 and performance suffers if large tables are used. If IPC is used for high-level configuration in R3, this exception does not apply as in IPC variant table data is stored in independent tables.