Processing
constraints are rules that control
1.who
can change
2.What
Can be Changed
3.when
they can change
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.
Who
can make changes
Based
on responsibility. A constraint (rule) may apply to all
responsibilities, to only a list of constrained responsibilities or
to all except a list of authorized responsibilities.
What
Can be Changed
- Order Header
- Order Line
- Order Sales Credit
- Line Sales Credit
- Order Price Adjustment
- Line Price Adjustment
- Order Payment
- Line Payment
- Sales Agreement Header
- Sales Agreement Line.
When
they can change
The
conditions must be collectively true for the constraint to Allow or
prevent the changes. The conditions may be based on either the state
of a workflow activity (where the entity is in the flow) or a value
in a table.
A condition may also be based on a custom API, which
means that you can call your own PL/SQL code to evaluate the
condition.
Multiple
conditions can be combined using either AND logic (all the conditions
must be true) or OR logic (at least one of the conditions must be
true.)
Usage of Processing Constraint:
Any Action Such as Update , Split , Cancel ,Delete or Create Will be Evaluated by Order Management against the Entity for Constraint