Commerce Constraint Rules

Overview

Constraint Rules determine attribute values to constrain or allow, or fields that can't be populated in Commerce. These rules are triggered based off an attribute change (AJAX).

For example, if the Bill To Company Name = "Acme", constrain all non-zero values in the Discount column on the Line Item Grid. Include message "No discounts allowed for Acme'.

Similar to constraint rules in configuration, constraint rules in commerce are set up to warn the buyer when certain attribute values are not allowed. While a constraint is active, the system doesn’t allow the user to advance within the Commerce Process (for example, saving a quote). Once the user has alleviated the constraint, he is allowed to use any displayed commerce actions to proceed through the quoting process. A constraint rule has a condition and an action. When the condition and action are both true, then a constraint is fired, which shows up as a message to the user. Constraints can be written and/or run on attributes in the main document or sub-document. For example, an attribute value on the main document could constrain a value in the line item grid and vice-versa.

Buyside Constraint Rule example

Administration

Create a Constraint Rule

Perform the following steps to create a constraint rule for a Commerce attribute.

Navigate to the Rule Editor page.
Admin > Commerce and Documents > Process Definition > Documents > Rules
Select Constraint from the Add drop-down menu.
Enter the rule Properties.
- Name - Enter the name of the rule in this section. This is a required field.
- Variable Name - The Variable Name field populates automatically. Variable names can only contain alpha-numeric characters and underscores. The entry can be changed before saving, but after saving the value is read-only.This is a required field.
- Description - Enter a description, if desired. Only viewable by FullAccess users, use this field to describe how the rule functions so that other FullAccess users can easily understand the purpose of the rule.
- Status - Determine the status of the rule:
  - Active - The rule is fired when the condition is met.
  - Inactive - The rule is not fired even if the condition is met. Inactive rules are displayed in italics in the rules list in the left panel.
Define rule Condition.

Select the Condition Type

Always True - The rule will fire automatically, every time, because a specific condition does not need to be met.

Simple - Use the rule editor to define condition attribute values.
- Select an attribute from the drop-down menu.
- Select an Operator and enter the Value.
Advanced - Define advanced conditions using BML.
- Click Define Function to open the BML Editor.
- Select the applicable variables and functions, then click Next.
- Enter the BML function, then click Save and Close.
Select the Action Type.
- Simple: Select this option to constrain listed components when conditions are met.
- Advanced: Select this option to use BML to define dynamic constraint rule actions.
  - Click Define Function.
  - Select the applicable variables and functions, then click Next.
  - Enter the BML function, then click Save and Close.
Select the applicable attribute from the Components drop-down.
- For main document constraint rules, you can add main and sub-document attributes.
- For sub-document constraint rules, you can only add sub-document attributes.
- Click Add to select additional components.
Enter the following items for each attribute:
- Operator - select an option from the drop-down menu.
- Value - if applicable, enter a value that is used with the operator.
- Message- the constraint message to display to the user.
- Message Location - select Attribute or Top.
Click Save.

Behavior: The time component of date attributes are not supported in commerce rules. Currency attributes with a default of 0.0 are not constrained in a new transaction even if the value is constrained by a rule. You can set up a validation rule to ensure that the transaction cannot be saved with this value. For an integer attribute constraining 0 will not constrain the blank value. If you constrain a currency attribute using a simple constraint rule, then the exchange rate will be taken into account when the attribute is constrained.

Example: in a USD base currency site if the constrained value of a currency attribute is 1 and the exchange rate for Euro is 2, then for the Euro user the constrained value will be 2 while for the dollar user, the constrained value will be 1. However, if you use an advanced constraint rule, the exchange rate will not be taken into account. In this case, if the function returns 1 as the constrained value, then the value 1 will be constrained for both the dollar and the Euro user.

You can control whether or not a dialog loading box appears for the constraint and access rules by making a settings change within Commerce Settings. For the option ‘Number of Milliseconds to Wait Before Showing the Loading Dialog for AJAX Rules’, enter:

Positive number: Determines how many milliseconds the dialog will appear.
Negative number: Disables the processing dialog for AJAX rules.
Zero (0): This will happen instantaneously.

Use a constraint rule if you’d like the user to correct a constrained value prior to clicking any Commerce action.

Actions that are "Save Without Validating" or "Modify Without Saving or Validating" type can be performed even if there is a constraint on the page.

Constraint rules are performed with AJAX functionality, while validation rules are tied to actions, meaning a user must click an action button for validation rules to run. AJAX allows the rule to run without requiring the user to refresh the page.

Reverse constraints are allowed for Menu attributes when you can specify the allowed values instead of the constrained values.

Notes

NULL and blank Integer values are treated as separate values:
- NULL= 0
- Blank = ""
Using NULL as an attribute value is strongly discouraged.
If you use logic that tests for NULL values in rule conditions or BML, confirm that the logic takes this difference into account.

Custom Variable Name Conventions

In Oracle CPQ 23D, CPQ adopted Oracle CX Sales variable naming conventions for custom items. When an administrator creates a new custom Commerce item, the "_c" suffix is appended to the variable name. The new naming convention for custom variable names provides more consistency for integrations with Oracle Sales.

Beginning in Oracle CPQ 24C, customers can submit a service request to disable the "_c" suffix on variable names for custom Commerce entities (Actions, Analytics, Attributes, Data Columns, Integrations, Library Functions, Rules, Steps, etc.). The "_c" suffix is enabled by default for standard and legacy Commerce processes.

Customers can submit a Service Request (SR) on My Oracle Support to disable the "_c" suffix on variable names for custom Commerce entities
When the "_c" is disabled, the "_c" variable name suffix will not be required for newly created custom Commerce entities.
Disabling the "_c" variable name suffix for custom Commerce entities will not change existing variable names.
The "_c" suffix setting will not impact existing variable names when cloning a Commerce process or migrating Commerce items. Target variable names will be the same as the variable names from the source Commerce process.

Notes:

Oracle CPQ Standard Process provide a converged set of generic rules sourced from existing Oracle CPQ reference applications. The Standard Process rules cannot be deleted or modified, but they can be inactivated. For Validation type rules Linked Actions can be updated. Refer to Standard Process Rules to rules that are provided in the Standard Process.
Test performance early and often – AJAX enabled constraint and access rules might make the Transaction page slow depending on the number of attributes, rules, use of advanced function, and so on. Performance tests are a must!

Commerce Constraint Rules

Overview

Administration

Notes

Related Topics