This chapter covers the following topics:

• Processing Constraints
• Versioning
• Audit Trail
• Open Interface Considerations

Processing Constraints
Processing Constraints enable you to control changes to sales documents in Oracle Order Management.

• Processing constraints are rules that control who can change what and when they can change it.  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.
• 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.
• 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 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.

Examples:

1. 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.
2. No one can add a line to an order after any of the lines on the order have been invoice interfaced.
3. A reason is required to cancel an order line after it has been booked.
4. Only the Customer Service Manager can change the discount percentage on an order line after the line has been shipped.
5. Require all return orders, identified by order type = Return, to be shipped to a central returns processing facility.

Defining Processing Constraints
Navigate to the Processing Constraints window. Order Management > Setup > Rules > Security > Processing Constraints.

Note that the window is divided into several regions. The top region has fields for the Application and the Entity. Any one of the OM entities are the valid values for the entity field. This is used for querying—you cannot create new entities. When you query an entity you will see all the constraints defined against that entity.

1. Constraints
The Constraints region is where most of the details of a processing constraint are defined. The region enables you to view the seeded constraints, view, or update the constraints that were created for your company. You can create new constraints, but you cannot change the seeded constraints with the system check box marked.

1.1. Operation Field
The Operation field can have the values of Create, Update, and Delete for any of the entities, Cancel for Order Header and Order Line entities only, and Split for the Order Line Entity only.

1.2. Attribute Field
The Attribute field can only be used if the operation selected is UPDATE. You may enter a value here, and the constraint will only apply to that field. For instance you may define a constraint that affects only the warehouse field on the order line. If the Attribute field is left blank the constraint will be in effect for all the attributes of the entity. For instance, you may define a constraint which prevents updates to any of the fields of an order line. Please note that only when constrainable attributes are updated, processing constraints execute. All attributes are not constrainable, therefore processing constraints will not execute for such attributes, even though the operation selected is UPDATE.

1.3 Action Field
The Action field allows you to select the action to be taken if the constraining conditions are met.
Note: There is no unique Require Reason action; it must be used in conjunction with Versioning or Audit.
Actions of Require Reason and Require Reasons and Require History for audit history are supported only for the UPDATE operation. Constraints are evaluated in the following order (Only one constraint may take effect for a change):

Actions that Require Reason take precedence over actions that do not.

Example
Assume that both versioning and audit constraints apply to update of price list. Only version is captured as it takes precedence and audit history is not available for this update. However, if audit constraint is on a different attribute like update of payment term and you change the payment term and price list, both version and audit history are captured.

1.4 Applies To Field
The Applies To field is used to define whether the constraint is applicable in the Negotiation or Fulfillment transaction phase. If the field is blank, then it is applicable to both phases.

1.5 System Changes Field
Use the System Changes field to indicate if system changes are allowed even if the constraining conditions are met. The system changes here refer to an attribute initially getting a default value or being re-defaulted when a source attribute changes. This is applicable only for attribute or field level UPDATE operations. The possible values are:
• Never after Insert: System changes are allowed to this field only if the entity has not yet been saved to the database. This is the default value.
• Always: System changes are always allowed on the attribute

1.6 User Changes Field
Use the User Changes field to indicate when the user performing the operation is constrained. This is applicable only for attribute or field level UPDATE operations. The possible values are:
• Never after Insert: You can change this field only if the entity has not yet been saved to the database. This is the default value.
• Always: You can never enter a value for this attribute, even if the entity (for example an order) is being created for the first time.

1.7 System Field
The System Field indicates if a constraint included with the OM system is user updateable. System constraints help prevent data integrity problems and cannot be updated. Any operation, field, action, or list of responsibilities attached to these
constraints cannot be modified. However, additional validation conditions can be included as long as they do not have the same group number.

1.8 Enabled Field
The Enabled field indicates whether the current Condition is active. This allows conditions to be temporarily disabled if necessary. Note that if all conditions are disabled and the constraint itself is not disabled, the constraint always applies for that change. Care must be taken to ensure that the disabling of conditions does not introduce problems in the business flow.