Rules and Rule Sets

Rules define integrity constraints on the attributes of items and structures. You can define integrity constraints on operational as well as on user-defined attributes.

Integrity constraints can implement business rules and are created through use of the rules framework. For example, a rule might be that the minimum speed must be less than maximum speed.

Rule sets gather multiple rules together and are associated with a source of attributes, such as attribute groups, item classes, change types, or structure types. The specific source (such as an attribute group name) is defined as part of the rule set. Rule sets also list valid business entities, such as items, item suppliers, or item revisions. The association of a rule set with a specific source of attributes enables the rule expressions entered in rules in the rule set to be validated by checking for allowable entities.

Each attribute is referenced by its business entity and attribute group name followed by the attribute name. For example, [Item].[Physical Attributes].[Unit Volume]. In this example, [Item] indicates that it's an item attribute; [Physical Attributes] is the display name of the attribute group, and [Unit Volume] is the display name of the attribute.

Keep in mind that:

• If the rule set is associated with an attribute group, then only the attributes in that group can be used in its rules.

• If the rule set is associated with an item class, then only the attribute groups valid for that item class can be used in its rules.

You can set the status of a rule set draft. You can keep a rule set in draft status until the drafting of its rules is complete. If a rule set is in draft status, the rule set isn't triggered as regular transactions are completed. During this time, you can run rule impact analysis to simulate and study the impact of the rule sets on a selected set of existing items, enabling you to make necessary changes. While performing the simulation, the draft rule sets along with other active rule sets are applied on the selected set of items, and the impact is captured by an asynchronous scheduled process.

The rule sets associated with new item requests and change order types are used to generate identifying numbers for new item requests and change orders.

The types of rule sets and rules are as follows:

• Assignment

• Validation

• Blending

• Composite

Assignment

An assignment rule set determines the value of an item attribute based on the specified condition.

Here’s an example of an assignment expressed in ordinary English: Lead Percent is Total Lead Mass divided by Unit Weight.

After you create a rule, you validate and save it. Then, if necessary, enter subsequent rules. Rules are executed in the order of their sequence in the rule set. Therefore, if an attribute's expression depends on a previously calculated value, you must ensure that the previous value appears ahead of the attribute, in the rule, and is therefore computed first. Generally, rule sets for assignments should be executed before rule sets for validations, so that you can write validation conditions against assignment results that you're confident are valid.

Note:

• You can include change header attributes and extensible flexfields in assignment rules to assign values to change header attributes and flexfields.
• The following attributes aren’t supported in number assignment rules created on changes: Approval Date, Assigned To, Change ID, Created By, Creation Date, Need by Date, Reason, and Requested by.

• Multirow extensible flexfields aren’t supported in number generation rules on changes.

• Groovy scripts aren’t supported for creating validations and assignment rules on changes using extensible flexfields. So it’s recommended to use item rules.

Validation

A validation rule set validates conditions based on attribute values defined for items. Validation rule sets are typically used to model predefined business rules on items.

Validation rules restrict items that can be added as related items to an item, and restrict the relationship types that can be allowed for items. This restriction could be based on item or item revision-level attributes which could be operational attributes or extensible flexfields.

Test the validations by going to the Item Update page and editing the appropriate attribute groups. Updated values are validated against the rules, and error messages appear on the screen.

The severity of a validation rule determines what action is taken if the validation fails. The severity levels, and their resulting actions, are as follows:

Severity	Description
Warning	The business entity can still be saved. An explanatory message, which you define, is displayed to the end user. The user must acknowledge the warning message to save the item.
Needs Approval	The attribute data requires that a change order be created for the business entity.
Reject	The business entity can't be saved until the attribute validation passes.

The following behavior for validation rules occurs during a runtime end user session:

• Rules are only run for attributes that have changed, except in the following circumstances.

  • The item's item class has been changed

  • The rule is a valid-component-type rule

  • The rule uses Context attributes, such as Context.ExecutionDateTime

  • The rule uses one of the following functions:

    • exists()

    • loopSum()

    • conditionalLoopSum()

    • assignedToCatalog()

    • assignedToOrg()

• If a validation with a severity of Reject fails, then the entire business entity containing the attribute is rejected.

• If a validation with a severity of Needs Approval fails, then a change order must be submitted and approved.

  • All related attributes also require a change order. In this context, related attributes are those that are used in any validation that uses an attribute that requires a change order. In other words, if any attribute requires a change order, then all the updated attributes in that validation rule (those specified in the IF Expression and Validation Condition fields of the rule) must also be part of the same change order.

  • If the attributes computed in assignment rules are used in subsequent rules, then they can form a chain of dependencies. In order to ensure that the data remains consistent, the change order requirement is propagated along this dependency chain.

  • The change order requirement propagates only along updated attributes. If an attribute isn't updated, then it should not affect other attributes.

Blending

When there are multiple spoke systems providing item data, blending rules are applied during import, to control which item attribute values are imported into production from the multiple spoke systems, based on the blending priority for each spoke system that you define in the blending rules.

Composite

Composite rule sets can contain both assignment and validation rule sets. Composite rule sets can be used to aggregate rule sets that operate on different attribute groups and item classes.

You create a composite rule set on the Manage Rule Sets page. To define a composite rule set of mixed type, ensure it contains both assignment and validation rule sets. Set the type to Mixed, enabling the creation of a rule set that contains both assignment and validation rule sets. Then add assignment and validation rule sets to the composite rule set.

Note: You can include assignment, validation, and composite rule sets in the entry and exit criteria for a change type.