Oracle Apps Order Management - Overview of Processing Constraints

In previous releases of Oracle Order Entry, a feature called Security Rules enabled you to control whether changes could be made to certain characteristics of an order after certain cycle steps had been reached. In Release 11i Order Management, Oracle has introduced a new security paradigm called Processing Constraints, which offers somewhat differing functionality. Processing Constraints allow Order Management users the ability to control changes to sales orders, at all stages of its order or line workflows.

Reasons to limit changes to existing orders can be:

Changing data on an entity that would make the data inconsistent and difficult to audit. For example, changing the price list on an order already invoiced. Oracle Applications generally enforces these constraints through seeded processing constraints or within the operation of forms and processes.
Changing data on an entity that has effected downstream activities that are difficult or costly to undo. For example, changing options on an ATO configuration order if the item is already built. You generally determine the business need for these constraints and, to express them, create processing constraints.

Processing Constraints also provide:

The ability to control who can make changes based on Responsibility. A constraint (rule) may apply to all responsibilities, a list of constrained responsibilities, or to all except a list of authorized responsibilities.
The ability to define constraining conditions based on the state of related objects (for example, define a processing constraint for order lines based upon the current status of the order).
The ability to control order changes based on field values
The ability to call custom PL/SQL code to determine whether a processing constraint condition evaluates to true.
The ability to constrain operations at any point in the order or line process flow. In prior releases of Oracle Order Entry, you could only control operations for certain hard-coded cycle actions.

A processing constraint includes these components:

Entity
Operation
Attribute

If an attribute is not assigned to a constraint, the constraint prevents you from updating all attributes on the entity.

Group Number
Conditions

User Action
Validation Entity
Scope
Record Set
Modifier
Validation Template

Applicable To (Optional, user responsibility)

You can define processing constraints for entity or attributes. Entities include regions on the Sales Orders window, such as Order, Line, Order Price Adjustments, Line Price Adjustments, Order Sales Credits, and Line Sales Credits. Attributes include individual fields (of a particular entity), such as Warehouse, Ship To Location, or Agreement.

As you use Order Management, processing constraints are evaluated for any entity you try to cancel, delete, create, split, or update. If you are trying to modify an order line, Order Management evaluates the processing constraints for the Line entity.

You can relate a given role to the highest state of the order that changes can be made. For example, the order entry clerk cannot change an order when it has been acknowledged by customer, but the order entry supervisor can change the order until it has shipped. These constraints may apply to the entire order or individual attributes.

For a complete list of processing constraints that are available in the Order Management application, see the Oracle Order Management Suite Implementation Manual, Release 11i, Appendix G.

Processing Constraint Terminology

Entity

Processing Constraints enable you to define constraints for entities such as order header, order line, order/line price adjustments, and order/line sales credits.

Entities can consist of a group of related attributes that similarly correspond to a database table or Order Management form. Entities that can be managed with Processing Constraints are:

Line Price Adjustment
Line Sales Credit
Order Header
Order Line
Order Price Adjustment
Order Sales Credit

Operation

You can define processing constraints to prevent users from performing the operations of Cancel, Create, Delete, Update, and Split on your orders and returns. You can prevent Update on attributes. You can effectively assign a general Update rule to all attributes associated with a particular entity, as a data entry tool. For example, given a set of conditions you may not allow a user to create a new order line.

Attribute

An attribute is considered a field or column that belongs to an entity. For example, ordered unit of measure is an attribute of the 'Order Line' entity

Select an attribute when the operation is UPDATE or leave the field blank to prevent update of all attributes.

Action

In addition to completely forbidding an action (Not Allowed), you can allow certain actions such as Update or Delete, but maintain an Audit Trail of the changes. To indicate you want to keep an Audit Trail only when a reason is required (Requires Reason with History) or not required (Requires History).

The Requires Reason and History action is applicable for the cancel or update operations to the Order Quantity attribute on the line, only.

System Changes

System changes are used for defaulting and enabling the system to re-default attribute values whenever the defaulting source changes. A changed attribute value would default even if constraint conditions are applicable. This is only applicable for attribute or filed level UPDATE operations.

User Changes

Users changes can be used to indicate whether an attribute level constraint applies to the user only for record updates or will the constraint apply even if the attribute value is modified by the user while the record is being created.

Select Never after Insert, (default), to indicate that a user may modify this field only if the entity has not yet been saved to the database. This is for attribute for field level update operations.
Select Never so that an attribute value can never be updated by a user.

For example, setting System Changes to 'Always' and User Changes to 'Never' sets up a constraint where this attribute value can never be edited by the user while constraint conditions are applicable; however the system can always default or re-default a value for this attribute.

Conditions

The condition of your processing constraint is like an If-Then statement. Order Management checks for occurrences of the condition in your constraint while users are cancelling, deleting, creating, splitting lines, and updating orders and returns. When the condition or conditions of a processing constraint are met, Order Management prevents the operation of that constraint.

Group Number

Each processing constraint condition has a number that indicates whether the condition is independent of all other conditions, or whether it should be considered only when another condition is also true. Use this number to create and/or conditions. Create an And condition by using the same group number for each row in the condition, or an Or condition by using a different group number for each row. Conditions with the same number must both be true for the processing constraint to apply.

For conditions with different numbers, at least one must be true for the processing constraint to apply. You can create several And conditions and Or conditions for one object or attribute.

Attention: Order Management does not allow you to enter a number equal to any number already used in the Number field of a system processing constraint condition. This would, in effect, create an And statement with a system processing constraint, and could endanger data integrity.

Scope

Scope indicates whether you want Order Management to evaluate the condition of the constraint against any or all entities in the record sets.

If the Scope is Any the condition holds true if any line within the record set meets the condition.
If the scope is All, all lines in the record set must meet the condition for the entire condition to be evaluated as True.

Validation Entity

The validation entity is the entity on which the constraint condition is based on. This could be same as the entity on the constraint or it could be an entity related to the constrained entity. For example, a constraint might be defined for UPDATE of Ship To on Order Header entity but condition needs to be if Any Order Line has been shipped. Thus validation entity is Order Line while constrained entity is Order Header.

Record Sets

A record set is a set of records that are bound by common attributes such as invoice sets. You can define constraining conditions and specify a record set to be validated for a given condition as defined by its validation template.

Modifier / Not

You can use a modifier in the condition of a processing constraint to define a negative condition. For example, if the condition is Booked and the Modifier/Not check box is checked, then the condition is evaluated as NOT booked.

Validation Template

The validation template defines how the condition is to be evaluated. The template could be based on a workflow state, field value or if it is complex, it could also be based on the output of a validation API.

API based validation templates are not available if the constrained entity is different from the validation entity on the condition. Validation templates are not available even if the record set being used is anything other than the primary key record set.

For example,

API based Validation template Pick Released has been set up for entity Order Line. If you set up a constraint for attribute Ship To on Order Line, the validation template Pick Released is available but for a constraint on attribute Ship To on Order Header, Pick Released will not be available.

For attribute Ship To on Order Line, if the constraint condition uses any record set (ATO Configuration, for example) other than the primary key record set Order Line, the validation template Pick Released will not be available.

Special Considerations

Rules That Cannot Apply

If you define a constraint for Create on an entity where the condition would be applicable on the same existing entity, the constraint will never apply. If the condition only occurs for existing entities, but they are already inserted, the constraint cannot be enforced and will not be applied. For example, a rule for Insert on a Line where the condition is Ship Confirm is unenforceable because a line is already inserted if that condition exists.

Processing Constraints Must Be Cooperative at Various Entity Levels

Order Management evaluates processing constraints for an entity when you are trying to perform an action on that entity. If you have a processing constraint on a lower-level entity (such as Line), and you try to perform an operation on the higher-level entity (such as Order), the Line level constraint is not evaluated. Therefore, when defining processing constraints, make sure that your higher-level entity constraints cooperate with your lower-level entity constraints so that all levels are synchronized. For example, if you have a constraint for the Line entity on the operation of Delete, define a comparable constraint for the Order entity so that you can cover all delete situations.

Defining Processing Constraints

This 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).

Prerequisites

Become familiar with the Processing Constraints that are delivered with the Order Management Application. See: Oracle Order Management Suite Implementation Manual, Release 11i, Order Management Processing Constraints Appendix.

You must define your validation templates and record sets:

Defining Validation Templates

Defining Record Sets.

Defining Validation Templates

Order Management provides you the ability to define your own validation conditions by the use of validation templates. A validation template names a condition and defines the semantics of how to validate that condition. Validation templates can be used in the processing constraints framework to specify the constraining conditions for a given constraint. These conditions are based on:

where the entity is in its workflow
the state of attributes on an entity
any other validation condition that cannot be modeled using the above methods

API based validation templates are not available if constrained entity is different from the entity for which the validation template has been defined (or the Validation templates are not available even if the record set being used is anything other than the primary key record set).

For example,

To define a validation template:

Navigate to Validation Templates window.

The Validation Templates window displays.

Select the Entity for which the condition is to be defined.

Enter a Template Name for the condition.

Enter a name in the Short Name field for the condition.

Optionally, enter a Description for the constraint condition.

Select the Validation Type to be performed by the condition. Select from:

Wf: (validation is based on the workflow status of this entity):

Select the Activity for the condition.
Select the Activity Status for the condition. Select from: Active, Complete, Error, Notified, and Suspended.
Select the activity Result for the condition.
Save your work.

API (validation is completed through an Application Program Interface):

Select the PL/SQL Package you wish to interface with the constraint condition.
Enter the Procedure name of the API.
Save your work.

Col (validation is based on the values of database columns on this entity):

Select the Attribute Column name on the entity for the constraint condition.
Select the Validation Operation for the constraint condition. Select from: = (Equal To), <> (Not Equal To), Is NULL, Is Not NULL.
Select the Value String you want to validate against the value of the column.

Note: You can add more than one attribute, value pair, otherwise all pairs will be added together in the validation.

Save your work.

When you have created new validation templates or record sets, you will need to submit the Create Validation Packages concurrent program from the Tools menu to submit a concurrent request to create a validation package for all new or modified validation templates and record sets that may constitute a permitted validation combination. After the request completes, all validation templates that processed successfully will be visible in the list of values in the Processing Constraints window.

Defining Record Sets

The Records Sets feature in Order Management is used to define and maintain record set definitions for processing constraints. A record set is a set of records that are bound by common attributes such as ship sets. You can define constraining conditions and specify a record set to be validated for a given condition as defined by its validation template.

To define a record set:

Navigate to the Record Sets window.

The Record Sets window displays.

Select the Entity for which you are defining a record set.

The Seeded check box is enabled if the system automatically defines the name of the record set. This check box is non updateable.

Enter the name of the Record Set.

Enter the Short Name for the record set.

Note: You cannot modify the Short Name once it has been entered.

Optionally, enter a Description for the record set.

The Based On Primary Key check box is used to indicate the record set that is based on the primary key columns for the entity. There can only be one primary record set per entity. These records are seeded and cannot be updated.

Select the name of the columns that should be matched from the validated record in the Matched Columns For Record Selection region.

For example, if you define a Ship Set record set, the matching columns will be the Header ID and the Ship Set number.

Save your work.

Select the Create Validation Packages concurrent program from the Tools menu to submit a concurrent request to create a validation package for all modified validation templates and record sets that may constitute a permitted validation combination.

Only after the request completes, the created validation template is visible in the list of values in the Processing Constraints window.

Save your work.

To set up processing constraints

Navigate to the Define Processing Constraints form.

The Define Processing Constraints window appears.

Query Application for Oracle Order Management and Entity for the entity for which you want the processing constraint, for example, Order Header or Order Line.

Move to the Constraints region. In the top area of the region, enter each constraint in a line.

In Operation, select the operation that you want to constrain.

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.

Select a value for the System Changes field. The value selected in this field determines if system changes are allowed, despite the constraint. Choose from:

Always: System changes allowed
Never after Insert: System changes allowed if the entry has not been saved to the database.

Select a value for the User Changes Field. Choose from:

Never: The user is always constrained
Never after Insert: The user is constrained after the entry is saved to the database

Seeded Check Box - If a Constraint has the seeded check box selected, you cannot update the constraint definition.

Move to the Conditions tabbed region. Enter a constraining condition for the selected constraint. The selected constraint is determined by the previous cursor position prior to moving to the Conditions tabbed region.

In Group Number field, enter a numeric value according to the following principles:

For conditions that should together evaluate to TRUE (AND conditions), enter the same group number. The constraint applies if the entity in question meets all of the conditions defined.
For conditions that should together evaluate to OR (OR conditions), enter a different number for each record. The constraint applies if the entity in question meets any one of the conditions defined.

In Scope, if the record set applies to multiple records, indicate the scope of evaluation of the record set for this condition. An example of a record set that applies to multiple records is the record set of all of the lines of a sales order. Select one of the following:

Any: The condition is satisfied if one of the records meets it, for example, the condition is satisfied if one of the sales order lines is booked.
All: The condition is satisfied if all of the records meet it, for example, the condition is satisfied if all of the sales order lines are booked

In Validation Entity, enter the entity for which the condition is validated. You can enter the same entity as the constraint (at the top of the Constraints region) or you can enter an entity related to the constraint. For example, if the constraint is against Order Header, Validation Entity can be Order Line.

In Record Set, select the record set that corresponds to the entities to which the constraints process should apply the condition. For example, if you enter the order line record set Line, the condition is evaluated against the order line in question. If you enter the order line record set Order, the condition is evaluated against any or all (depending on the scope) lines of the order in question.

If Validation Entity is different from Entity (at the top of the form), you can only select record sets based on the primary key of the validation entity.

Select the Not check box (the negative condition modifier) to direct the constraints processing to evaluate the NOT condition of Validation Template. For example, if you expect to select Validation Template Booked, selecting NOT creates the condition of not booked for the constraint.

In Validation Template, select a validation template. This item specifies the condition being evaluated.

Constraint Condition Seeded check box:

If a Constraint has the seeded check box selected, and the constraint condition check box is also selected, you cannot update the constraint condition.
If a Constraint has the seeded check box selected, and the constraint condition check box is not selected, you can update the constraint condition.

In User Message, enter the trailing portion of the error message that the constraint processing should display when the user violates the constraint.

For example, if the constraint was to not allow an update of the item field on the order line if the line has been previously booked, constraints processing displays the error message You are not allowed to update the item; the item is booked.

Move to the Applicable To tabbed region. In this region, specify to whom the constraint applies.

Select one of the following:

All responsibilities: The constraint applies to all responsibilities.
Authorized responsibilities: The constraint applies to all responsibilities except ones that you specify. Specify the excepted responsibilities in the untitled lines below your selection.
Constrained responsibilities: The constraint applies to the responsibilities that you specify. Specify the excepted responsibilities in the untitled lines below your selection.

Save your work.

Processing Constraints Example

To set up a processing constraint that forbids update of the sales order header order type when there are order lines created or when the order is booked, do the following after navigating to the Define Processing Constraints form:

Query in the top of the form:

Application: Oracle Order Management
Entity: Order Header

Enter on a new line at top of the Constraints region:

Operation: Update
Attribute: Order Type
User Action: Not allowed
Leave System Changes, User Changes blank
Clear Seeded check box

Enter in the first line of the Conditions tabbed region:

Group Number: 1
Scope: Any
Validation Entity: Order Header
Record Set: Order
Clear NOT check box
Validation Template: Booked
Clear Seeded checkbox
User Message: the order is booked

Enter in the second line of the Conditions tabbed region:

Group Number 2
Scope: Any
Validation Entity: Order Header
Record Set: Order
Clear NOT checkbox
Validation Template: Lines Exist
Clear Seeded checkbox
User Message: the order has lines

Processing Constraints Usage

As you use Order Management, processing constraints are evaluated for any entity you try to cancel, delete, insert, split, or update. If you are trying to modify an order line, Order Management evaluates the processing constraints for the Line entity.

Oracle Apps

PAGES

Pages