Processing Constraints in OM

Processing constraints are rules that control who can change what and when they can change it. Processing constraints can prevent certain changes, but can also be set up to perform actions based on those changes. They can define actions that can result from these changes, such as requiring a reason for the change, triggering an action in Audit Trail or Versioning, or raising an Integration Event.

Check the blog post: Query to get the list of OM Processing Constraints

SELECT c.constraint_id,

         e.entity_display_name entity,

         c.column_display_name attribute,

         l1.meaning opeartion,

         l2.meaning user_action,

         l4.meaning seeded,

         cc.group_number,

         l3.meaning scope,

         cc.validation_entity_display_name val_entity,

         cc.record_set_display_name record_set,

         DECODE (cc.modifier_flag, 'Y', NULL, '        ') modifier,

         cc.validation_tmplt_display_name val_template,

         l5.meaning seeded_flag

    FROM oe_pc_constraints_v c,

         oe_pc_entities_v e,

         oe_pc_constraint_cnds_v cc,

         oe_lookups l1,

         oe_lookups l2,

         oe_lookups l3,

         oe_lookups l4,

         oe_lookups l5

   WHERE     c.entity_id = e.entity_id(+)

         AND l1.lookup_code(+) = c.constrained_operation

         AND l1.lookup_type(+) = 'PC_OPERATION'

         AND l2.lookup_code(+) = c.on_operation_action

         AND l2.lookup_type(+) = 'PC_ON_OPERATION_ACTION'

         AND l4.lookup_code(+) = c.system_flag

         AND l4.lookup_type(+) = 'YES_NO'

         AND c.constraint_id = cc.constraint_id(+)

         AND l3.lookup_code(+) = cc.scope_op

         AND l3.lookup_type(+) = 'PC_SCOPE_OP'

         AND l5.lookup_code(+) = cc.system_flag

         AND l5.lookup_type(+) = 'YES_NO'

ORDER BY e.entity_display_name,

         NVL (l1.meaning, 'A'),

         NVL (c.column_display_name, 'A'),

         cc.group_number

This post describes how to set up your processing constraints based on validation conditions in validation templates (for example, Booked = Yes) which are evaluated for groups of records (record sets).

Processing constraints are rules that control

·         Who can change?

·         What change is allowed?

·         When the change is permissible?

Setup processing constraints for Create, Delete, Update and Cancel operations for order or line based on user responsibility.

Example:

Cancel sales orders, order lines, returns, and return lines. Order Management automatically adjusts reservations for canceled lines.  The order cancellation feature of Order Management enables you to specify who has the authority to perform a cancellation request.  Cancellations look at constraints.  If you are allowed to cancel sales, the system will perform a cancellation request.  Once a line or order is cancelled, the workflow closes the line.

Processing constraints for orders and returns determine whether you can cancel orders, returns, and lines based on their workflow status.  In addition to your user defined processing constraints, system defined rules exist.  Under these rules you cannot cancel an order if:

·         It has been closed.

·         It has already been cancelled

·         A work order is open for an ATO line.

·         Any part of a line has been shipped or invoiced.

·         Any return line has been received or credited.

Order Management honors processing constraints that you define for the Cancel operation that are stricter than these rules, but if you define any that conflict with these rules, they are ignored.

To prevent a responsibility from cancelling:

Navigate to:        Setup>Rules>Processing Constraints

•        Select the entity to be constrained.

•        Select the operation to be constrained.

•        Enter the constraining conditions.

In the Applicable To Tab:

•        Select the responsibilities authorized to perform this operation.

•        Save the constraint.

To allow a responsibility to cancel when a reason is provided:

•        Select the entity to be constrained.

•        Select the operation to be constrained.

•        Select the action to be taken if this constraint occurs.

•        Enter the constraining conditions.

•        Enter the responsibility constrained from performing this operation.

•        Save the constraint. 

Select an Attribute to constraint, based upon the operation selected.

•    If you select the value UPDATE for the Operation field and you do not select an Attribute value, the constraint allows no update to any field of the entity, by any user.

In User Action, select one of the following:

•        Not Allowed: You cannot perform the constrained operation

•        Require Reason and History: You can perform the operation only if you enter a reason. Use this with Operation CANCEL, Operation UPDATE if the constrained attribute is Ordered Quantity only, and for recording Audit Trail history when requiring a reason for an attribute change

•        Requires History: You can perform the operation and will not be prompted to

·         Enter a Reason. You still have the option to enter both a Reason and Comment, and if you do so, the information is recorded. Use the value for enabling Audit Trail history to be recorded without a reason for an attribute change

Following are the user actions that can be performed:

Check out the blog post for Defining Validation Templates

Processing Constraints Listing Report:

List all processing constraints and the corresponding constrained entities, constrained attributes, constrained operations, validation entities, record sets, validation templates and responsibilities to which constraint is applicable.