Commerce Rules
Overview
Oracle CPQ provides the ability to create Commerce rules that are similar to the Configuration rules. Commerce rules allow you to do things like limit the values in one field based on the selections in another and hide attributes based on other selections.
Rules can be created at the main document and sub-document levels. Rules that are created on the main document or sub-document levels can affect attributes on either level. For example, you can write a constraint rule where the condition attribute is on the main document and the action attribute is on the sub-document.
There are four Commerce rule types:
-
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).
-
Filter Rules exclude irrelevant Line Item Grid items. Filter rules are only available for Commerce sub-documents.
-
Validation Rules verify attribute or field values. Rules are linked to an action and only run when a specific action is clicked by the user.
-
Access Rules (previously known as Hiding Rules) - Hide actions or attributes when a pre-defined condition is met. These rules are triggered based off an attribute change (AJAX).
Main Document Rules
Rules created at the main document level can affect both main and sub-document attributes. When a rule is created main document level but run on a sub-document attribute within the line item grid, the Rule action will be performed on the entire column within the line item grid. For example, you want to hide "Discount" for a particular part number. If the rule condition is met anywhere in the line item grid, the entire column will be hidden for all line items.
- Main document rules using sub-document attributes in the condition will fire if any line item in the transaction meets the condition.
- Main document rules that use line level attributes in the action act on all line items in the transaction.
- Main document access rules can be used to hide a column in the line item grid by hiding the line level attribute mapped to that column. Similarly, main document validation and constraint rules can be used to constrain all values of a column in the line item grid by constraining the attribute mapped to the column.
Rules created at this level have access to all system, main document and line level attributes in the condition. These rules can only hide, constrain or validate line level attributes.
Sub-Document Rules
Rules created at the sub-document level can only affect sub-document attributes. This functionality allows for rules to evaluate each line within the line item grid individually. For example, if you wanted to hide "Discount" for a particular part number, the rule would evaluate each line item and if the condition is met, only that line item is affected. In this case, the input field for Discount would be removed for that particular line item.
- Users can observe line level rules fire on the main document if the action attribute is mapped to the line item grid.
- Line level rules impact individual line items.
- If the condition of a line level rule is based on a line level attribute (or a combination of main document and line level attributes), then only the value of the attribute for the current line item is considered when the rule is evaluated.
- If the condition of a line level rule is Always True or only has main document attributes as input, then all line items will be impacted.
- Line level validation rules can be run with both main document and line level actions.
Order of Operations
The order of operations will be modified and perform as follows:
- Simple validations will be evaluated
- Simple modifications
- Advanced modifications and auto updates will run.
- Commerce rules will run (Hiding, then constraints, then validations).
- Advanced validations will run. Inactive rules will show up in italics in the left panel of the rule editor.
Rule Behavior
Similar to configuration rules, a commerce rule will fire when the condition evaluates to true. The condition of an AJAX enabled commerce rule is re-evaluated when any of its input attributes is changed either by the user or by the auto update function. Input attributes include condition and action attributes and any attributes used as inputs to the condition. Commerce rules also function when the user interacts with Oracle CPQ via SOAP. They even fire when the condition or action attributes are not mapped to the layout, or may not be visible.
Validation rules are evaluated and executed after the action is performed. Validation rules associated with Update Line Item fire when the action is called implicitly or when another Modify action is performed. Simple validations, like required, range check, and so on, will fire automatically for attributes that are associated with hiding or constraint rules. For attributes not associated with rules, these validations fire when an action is performed. For SOAP, rule information is embedded in GetTransaction and CreateTransaction responses and validation message in UpdateTransaction response. Advanced validations are being deprecated for new implementations. Use standard validations instead.
Notes
- NULL and blank Integer values are treated as separate values:
- 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 23B introduces the Standard Process which 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.
- Use validation rules instead of advanced validations in actions. All validations will be written from the Commerce Rule Editor page. However, if you are upgrading from an earlier version of BigMachines or CPQ, your current advanced validations will remain in place, until you migrate to the new commerce validation rules.
- 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!
Related Topics
See Also
