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
Check the blog post: Query to get the list of OM Processing Constraints
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.
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:
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.
