This topic describes the use of expression constraints and table constraints. Constraints control the attribute values that you can select when you configure products for a sales order, sales quotation, purchase order, or production order. You can use expression constraints or table constraints, depending on how you prefer to build the constraints.
Constraints are used to control the attribute values that you can select when you configure products for a sales order, sales quotation, purchase order, or production order. You can use expression constraints or table constraints, depending on how you prefer to build the constraints.
What are expression constraints?
Expression constraints are characterized by an expression that uses arithmetic and Boolean operators and functions. An expression constraint is written for a specific component in a product configuration model. It can't be reused by or shared with another component. However, the expression constraints for a component can reference attributes of the component's subcomponents.
What are table constraints?
Table constraints list the combinations of values that are allowed for attributes when you configure a product. Table constraint definitions can be used generically. When you create a table constraint for a component in a product configuration model, you select a table constraint definition. To create the combinations that are allowed, you add attributes of specific types to the components. Each attribute type has a specific value.
Example of a table constraint
This example shows how you can limit the configuration of a speaker to specific cabinet finishes and fronts. The first table shows the cabinet finishes and fronts that are generally available for configuration. The values are defined for the Cabinet finish and Front grill attribute types.
|Cabinet finish||Black, Oak, Rosewood, White|
|Front grill||Black, Metal, White|
The next table shows the combinations that are defined by the Color and finish table constraint. By using this table constraint, you can configure a speaker that has an oak finish and a black grill, a Rosewood finish and a white grill, and so on.
You can create system-defined and user-defined table constraints. For more information, see System-defined and user-defined table constraints.
What syntax should be used to write constraints?
You must use Optimization Modeling Language (OML) syntax when you write constraints. The system uses Microsoft Solver Foundation constraint solver to solve the constraints.
Should I use table constraints or expression constraints?
You can use either expression constraints or table constraints, depending on how you prefer to build the constraints. You build a table constraint as a matrix, whereas an expression constraint is an individual statement. When you configure a product, it doesn't matter what kind of constraint is used. The following example shows how the two methods differ.
When you configure a product by using the following constraint setups, these combinations are allowed:
- A product in the color Black, and in size 30 or 50
- A product in the color Red and in size 20
Table constraint setup
Expression constraint setup
(Color == "Black" & (size == "30" | size == "50")) | (color == "Red" & size = "20")
Should I use operators or infix notation when I write expression constraints?
You can write an expression constraint by using either the available prefix operators or infix notation. For the Min, Max, and Abs operators, you can't use infix notation. These operators are included as standard operators in most programming languages.
What operators and infix notation can I use when I write expression constraints?
The following tables list the operators and infix notation that you can use when you write an expression constraint for a component in a product configuration model. The examples in the first table show how to write an expression by using either infix notation or operators.
|Implies||This is true if the first condition is false, the second condition is true, or both.||Implies[a, b], infix: a -: b||
|And||This is true only if all conditions are true. If the number of conditions is 0 (zero), it produces True.||And[args], infix: a & b & ... & z||
|Or||This is true if any condition is true. If the number of conditions is 0 (zero), it produces False.||Or[args], infix: a | b | ... | z||
|Plus||This sums its conditions. If the number of conditions is 0 (zero), it produces 0.||Plus[args], infix: a + b + ... + z||
|Minus||This negates its argument. It must have exactly one condition.||Minus[expr], infix: -expr||
|Abs||This takes the absolute value of its condition. It must have exactly one condition.||Abs[expr]||Operator: Abs[x]|
|Times||This takes the product of its conditions. If the number of conditions is 0 (zero), it produces 1.||Times[args], infix: a * b * ... * z||
|Power||This takes an exponential. It applies exponentiation from right to left. (In other words, it's right-associative.) Therefore, Power[a, b, c] is equivalent to Power[a, Power[b, c]]. Power can be used only if the exponent is a positive constant.||Power[args], infix: a ^ b ^ ... ^ z||
|Max||This produces the largest condition. If the number of conditions is 0 (zero), it produces Infinity.||Max[args]||Operator: Max[x, y, 2] == z|
|Min||This produces the smallest condition. If the number of conditions is 0 (zero), it produces Infinity.||Min[args]||Operator: Min[x, y, 2] == z|
|Not||This produces the logical inverse of its condition. It must have exactly one condition.||Not[expr], infix: !expr||
The examples in the next table show how to write infix notation.
|x + y + z||Addition|
|x * y * z||Multiplication|
|x - y||Binary subtraction is translated the same as binary addition where there is a negated second.|
|x ^ y ^ z||Exponentiation that has right associativity|
|x -: y||Boolean implication|
|x & y & z||Boolean and|
|x == y == z||Equality|
|x != y != z||Distinct|
|x < y < z||Less than|
|x > y > z||Greater than|
|x <= y <= z||Less than or equal to|
|x >= y >= z||Greater than or equal to|
|(x)||Parentheses override default precedence.|
Why aren't my expression constraints validated correctly?
You can't use reserved keywords as solver names for attributes, components, or subcomponents in a product configuration model. Here is a list of the reserved keywords that you can't use:
[Create an expression constraint (Task guide)(/dynamics365/unified-operations/supply-chain/pim/tasks/add-expression-constraint-product-configuration-model)