Processing Constraints –Processing constraints is a common security framework in Order Management where you can define and build security rules around sales entities (Line, header , line payments etc).
Using processing constraints in Order Management you can define the conditions and status at which an update can be made to an entity. For example a line cannot be cancelled after it has been shipped. This can be seeded as a system constraint to prevent data corruptions. Similarly you can define constraints that suit your business practices and prevent changes. These constraints can be defined at the entity level and for each attribute.
When you attempt to make changes to an order, Order Management validates the changes against processing constraints enabled. In addition, Order Management validates the order changes based on your user responsibility.
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.
With processing constraints, you can control:
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.
More than just what can be updated. The following operations can be controlled: Create, update, delete, cancel, and split all at the entity level. For example, given a set of conditions you may not want to allow a user to create a new order line. You can also control the update operation down to the attribute level. For example, given a set of conditions, you could choose to allow update to the warehouse field of an order line but not to the price list field.
Changes to entities. An entity roughly corresponds to a table or window. The entities you can control in Order Management are:
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
Changes based on a group of conditions. The conditions must be collectively true for the constraint to fire 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.)
A custom message can display when an attempt is made to violate a constraint.
This chapter details the differences between Processing Constraints and the functionality in Order Entry that it replaced - Security Rules. It describes in detail the implications of selected values in the following forms: Processing Constraints, Validation Templates and Record Sets. Finally, set up for processing constraints is demonstrated using the following business examples:
No one can change the customer purchase order at the line level; your company requires that one sales order can relate to only one customer purchase order.
No one can add a line to an order after any of the lines on the order have been invoice interfaced.
A reason is required to cancel an order line after it has been booked.
Only the Customer Service Manager can change the discount percentage on an order line after the line has been shipped.
Require all return orders, identified by order type = Return, to be shipped to a central returns processing facility.
Constraints for drop ship functionality enable you to control changes within the drop ship flow between Oracle Order Management and Oracle Purchasing. See Processing Constraints for details on these constraints.
Versioning in Order Management uses constraints to enable automatic versioning. You can use validation templates for example to drive versioning by transaction type as a condition. By using the processing constraints and workflow activity, you can increment the version and determine the statuses available to version, which give you complete flexibility setting up versioning.
Background
Security Rules provide functionality to control changes to orders. However, they have certain limitations both in the philosophy and in implementation. In Order Management there is a processing constraints framework usable by other products.
This framework provides to you the ability to:
Control changes based on who is trying to make them (by responsibility)
Define constraining conditions based on the state of related objects (for example, define a constraint on a line based on the state of the order)
Control changes based on the value of a field - see Validation Templates section below
Call custom PL/SQL code to determine whether a condition is true
Constrain operations at any point in the process flow. In prior releases you could only control operations for certain hardcoded cycle actions.
You can check these constraints from Setup->Rules->Processing Constraints
Using processing constraints in Order Management you can define the conditions and status at which an update can be made to an entity. For example a line cannot be cancelled after it has been shipped. This can be seeded as a system constraint to prevent data corruptions. Similarly you can define constraints that suit your business practices and prevent changes. These constraints can be defined at the entity level and for each attribute.
When you attempt to make changes to an order, Order Management validates the changes against processing constraints enabled. In addition, Order Management validates the order changes based on your user responsibility.
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.
With processing constraints, you can control:
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.
More than just what can be updated. The following operations can be controlled: Create, update, delete, cancel, and split all at the entity level. For example, given a set of conditions you may not want to allow a user to create a new order line. You can also control the update operation down to the attribute level. For example, given a set of conditions, you could choose to allow update to the warehouse field of an order line but not to the price list field.
Changes to entities. An entity roughly corresponds to a table or window. The entities you can control in Order Management are:
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
Changes based on a group of conditions. The conditions must be collectively true for the constraint to fire 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.)
A custom message can display when an attempt is made to violate a constraint.
This chapter details the differences between Processing Constraints and the functionality in Order Entry that it replaced - Security Rules. It describes in detail the implications of selected values in the following forms: Processing Constraints, Validation Templates and Record Sets. Finally, set up for processing constraints is demonstrated using the following business examples:
No one can change the customer purchase order at the line level; your company requires that one sales order can relate to only one customer purchase order.
No one can add a line to an order after any of the lines on the order have been invoice interfaced.
A reason is required to cancel an order line after it has been booked.
Only the Customer Service Manager can change the discount percentage on an order line after the line has been shipped.
Require all return orders, identified by order type = Return, to be shipped to a central returns processing facility.
Constraints for drop ship functionality enable you to control changes within the drop ship flow between Oracle Order Management and Oracle Purchasing. See Processing Constraints for details on these constraints.
Versioning in Order Management uses constraints to enable automatic versioning. You can use validation templates for example to drive versioning by transaction type as a condition. By using the processing constraints and workflow activity, you can increment the version and determine the statuses available to version, which give you complete flexibility setting up versioning.
Background
Security Rules provide functionality to control changes to orders. However, they have certain limitations both in the philosophy and in implementation. In Order Management there is a processing constraints framework usable by other products.
This framework provides to you the ability to:
Control changes based on who is trying to make them (by responsibility)
Define constraining conditions based on the state of related objects (for example, define a constraint on a line based on the state of the order)
Control changes based on the value of a field - see Validation Templates section below
Call custom PL/SQL code to determine whether a condition is true
Constrain operations at any point in the process flow. In prior releases you could only control operations for certain hardcoded cycle actions.
You can check these constraints from Setup->Rules->Processing Constraints
