Thursday, February 14, 2013

Processing Constraints in Order Management



Overview

Processing Constraints enable you to control changes to sales documents in Oracle Order Management. This chapter describes the Processing Constraints framework in detail.

Introduction

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.


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

    Defining Processing Constraints

    Processing Constraints Window Conditions Tab
    the picture is described in the document text



    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.

    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.

    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.

    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.
    Action Field
    The Action field allows you to select the action to be taken if the constraining conditions are met.

    Processing Constraints Window with User Action Menu Displayed
    the picture is described in the document text
    The combination of Actions that can be selected are:
    • Generate Version, Require Reason and Raise Integration Event
    • Generate Version and Require Reason
    • Generate Version
    • Require Reason, History and Raise Integration Event
    • Require Reason and Require History
    • Require History
    • Raise Integration Event
    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):
    • User Action
      • Not Allowed.
      • Generate Version, Require Reason and Raise Integration Event. This activates automatic versioning.
      • Generate Version and Require Reason. This activates automatic versioning.
      • Generate Version. This activates automatic versioning.
      • Require Reason, History, and Raise Integration Event. This activates Audit Trail to capture changes.
      • Require Reason and Require History. This activates Audit Trail to capture changes.
      • Require History. This activates Audit Trail to capture changes.
      • Raise Integration Event. This can be used with versioning.
    During implementation any action which includes "Raise Integration Event" may be selected. This event is presently used by XML processing and can be used by any other product.

    Once the processing constraint setup is done need to run 1.       Generate Constraints Validation Packages this will be available as a menu function under Rules ->Security menu.

2 comments:

  1. Hi Prasad
    I am unable to add a new column to the orderline record set. I want to base by processing constraint on one of the dff values. can you help me ?
    https://community.oracle.com/message/12808722#12808722
    Jo

    ReplyDelete
  2. Hi All,

    We have created a Constarint to validate the Request date at Order line level.But it is validating the Request date even at Order header level.
    All the setup is fine.
    Please let me know the root cause for this.

    Regardds,
    Sam

    ReplyDelete