Академический Документы
Профессиональный Документы
Культура Документы
An Oracle WhitePaper
November 2010
Oracle Order Management enables you to audit the changes in order attributes from
the Sales Orders, Quick Sales Order, Order Organizer, Quick Order Organizer forms
or Process Order API. This is achieved by utilizing the Processing Constraints
framework, OM Lookups, an OM system parameter and the Audit Trail Consolidator
concurrent program.
Order Management application gives the flexibility to audit only the required
attributes based on the business requirements.
Each business can decide what order attributes are critical and an audit needs to be
maintained. Queries can be run or reports produced to show what actual changes have
been made to auditable attributes, who made the changes and when.
The attributes of the following entities can be audited: Order Header, Order Line,
Order Sales Credit, Order Line Credit, Order Price Adjustment, Line Price
Adjustment.
When OM system parameter: Audit Trial is enabled and proper processing constraints
are defined for the auditable attributes, the relevant history tables are populated with
the history data.
OE_AUDIT_ATTR_HISTORY - Table which holds the consolidated history
data in a format needed for viewing and reporting history. This table is populated with
the history data by Audit History Consolidator concurrent program.
All the Audit History related calls are within OE_AUDIT_HISTORY_PVT package
(OEXPPCHB.pls). This is a private API.
Define new processing constraints that specify when, and for what attributes of an
order, audit trail updates are recorded, having the appropriate action:
a) Required Reason and History
b) Require History
c) Require Reason, History and Raise Integration Events*
a) If the option Requires Reason and History is selected: when the field is changed,
a reason window will always appear and a reason code must be entered.
History will be captured.
b) If the option Requires History is selected, a reason window will not appear when
making a change and history will be captured.
There is always the flexibility of entering a reason code by navigating to Tools >
Change Reason.
c) If the option Require Reason, History and Raise Integration Events is selected:
when the field is changed, a reason window will always appear and a reason code
must be entered. History is captured but is not consolidated in the table
OE_AUDIT_ATTR_HISTORY and, therefore, the changes will not be displayed
in Audit History form or Audit History Report.
Also, an integration event will be raised: oracle.apps.ont.oi.xml_int.status. This
event is presently used by XML processing and can be used by any other product.
Important:
Actions of Requires History and Requires Reason and History for Audit History
are supported for UPDATE operation.
2. Define Lookups for the Reasons used (for the case where you choose Required
Reason and History option). This is optional.
Navigation: OM responsibility > Setup > QuickCodes >
Query for lookup type: CANCEL_CODE
Application: Order Management
Meaning: Cancel/Audit/Versioning Reasons
In this form, you can add new Reason Codes based on your business requirements or
you can use the existing ones.
Here you can define additional reason codes based on your business requirements.
These Reason Codes are available in the list of values from Reason window (see the
testcase2: Figure 16 – Reason window with reason code and comment).
The lookup codes are stored in the table FND_LOOKUP_VALUES and can be found
with the following query:
SELECT * FROM FND_LOOKUP_VALUES WHERE lookup_type =
'CANCEL_CODE' and view_application_id = 660 order by lookup_code;
After Audit Trial system parameter and appropriate processing constraints are
enabled, the history tables are populated with the audited data. Currently, there is no
purging routine available to purge the data from the history tables.
Order Management consolidates the following order entities within the table:
• Order Header
• Order Line
• Sales Credit (Order and Line)
• Price Adjustment (Order and Line)
The data within the table can be viewed within Oracle Applications via the View
Audit History window or printed for display via the Audit History Report.
Note: In Release 11i, when running Audit History Consolidator based on the history
date or order number parameter, the concurrent program will consolidate all the audit
data present in all operating units.
In Release 12,a new parameter called Operating Unit is available so that audit data
can be consolidated based on Operating Unit also. This feature is not available in
Release 11i.
The Audit History form is available if the function View Audit History
(ONT_OEXAUDHF_FORM) is added on the menu attached to the user’s
responsibility.
Tabs: Lines, Line Sales Credits, and Line Price Adjustments Tabs display the
attributes:
• History Date and Time
• Order Number
• Line Number
• Item
• Attribute Name
• Old Value
• New Value
• User
Figure 6- Processing Constraints form with the setup for Salesperson field
Important: In the case the Audit History is not captured even though Require
History constraint is dened, check if there is a versioning constraint for the same
operation. Versioning takes precedence and version is captured instead of the audit
record.
Example: You have processing constraints defined for:
• Update of Salesperson with action Require History
• Update of Salesperson with action Generate Version
The versioning will take precedence.
Figure 7 – Sales Order header form with the original value of the Salesperson
3. After you saved the Sales Order, try to change the value of the Salesperson field
from Albert Apex to Ambers, Ralph. Save the changes.
Figure 8 – Sales Order header with the changed value of the field Salesperson
4. Run Audit History Consolidator concurrent program for the changes from the last
days.
Navigation: OM responsibiliyt > Requests> Submit a new request
Choose from the list of values: Audit History Consolidator
5. Query Audit History form based on the desired criteria.
Navigation: OM responsibility > Orders, Returns> View Audit History
You must select a value in the Entity field prior to selecting any value in the Attribute
field.
The system recorded the old value of the field Salesperson and the new value.
The username who operated the changes is MFG.
Note: The Audit History window currently does not support the use of Folders to
customize display information.
If a new change is operated in the same field, for example, from Ambers, Ralph to a
new salesperson : Gregory Donaldson, this new change will be recorded too.
Figure 11 – The Sales Order form with the third change of the Salesperson field
6. Make sure that you run the Audit History Consolidator program prior to query the
Audit History form to see the results. The Audit History form displays the attribute
changes operated untill the latest run of Audit History Consolidator concurrent
program.
Figure 12 – the new results of the recorded changes in Salesperson field from Sales
Order form
Alternatively, the audit history data can be viewed by running the report Audit
History Report .
Navigation : OM responsibility > Reports, Requests> Run Reports > choose from the
list of values Audit History Report
Figure 13 – Audit History Report parameters
The report output is always sorted by effectivity date changed, order number, entity,
and attribute.
Also, the report displays the responsibility name associated with the user who
changed the audited attribute.
Test case: tracking changes of the salesperson field from the Sales Orders form,
header level (record the changes by specifying a reason code).
1. In the case the Require Reason and History option is selected in Processing
Constraints ( see Figure 6- Processing Constraints form with the setup for
Salesperson field), any change on the audited attribute requires a Reason Code.
2. In the Sales Orders form, when trying to modify the value from Salesperson field at
header level and save the change, the following window will be opened, requiring to
enter a Reason Code:
Figure 15 – Reason window is automatically opened when trying to save the changed
value
Figure 17 – Audit History form with the recorded reason code and comment
Also, the same data can be viewed in the Audit History Report
Navigation :
OM responsibility > Reports, Requests> Run Reports > choose from the list of values
Audit History Report
Figure 18 – Audit History Report showing the Reason Code and Comment
Note: If the order number has more than 10 characters (like in the example below for
SO 100000000000) then the order number in the Audit History Report is displayed as
*********.
Figure 19 - Audit History Report for a sales order number with more than 10
characters.
Currently, the following Enhancement Requests are logged for Audit History:
Enhancement Request 8432688 - CANNOT CAPTURE NEW LINES ON A
BOOKED ORDER IN AUDIT HISTORY
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com
Copyright © 2008, Oracle and/or its affiliates. All rights reserved.
This document is provided for information purposes only and the contents
hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any other
warranties or conditions, whether expressed orally or implied in law, including
implied warranties and conditions of merchantability or fitness for a particular
purpose. We specifically disclaim any liability with respect to this document and
no contractual obligations are formed either directly or indirectly by this
document.
This document may not be reproduced or transmitted in any form or by any
means, electronic or mechanical, for any purpose, without our prior written
permission.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.