P. 1
Order Management by ORACLEUG

Order Management by ORACLEUG

|Views: 988|Likes:
Published by PraveenReddyB

More info:

Published by: PraveenReddyB on Aug 18, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

03/12/2013

pdf

text

original

Submitted by Anonymous on Wed, 12/16/2009 - 16:36

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.

•Audit Trail

•Versioning

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->