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
No comments:
Post a Comment