Audit History in Order Management. An Oracle WhitePaper

Transcription

1 Audit History in Order Management An Oracle WhitePaper November 2010

2 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. Audit History Data Model Audit History functionality uses the following tables that store history information about fields (attributes) from Order Header, Order Line, Price Adjustments and Sales Credit. OE_ORDER_HEADER_HISTORY - Table that stores history of attribute change for Order Headers OE_ORDER_LINES_HISTORY - Table that stores history of attribute change for Order Lines OE_PRICE_ADJS_HISTORY Table that stores history of attribute changes of Entity Price. OE_SALES_CREDIT_HISTORY - Table which stores history of attribute changes of Entity Sales Credits 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. OE_AUDIT_ATTR_DESC_V - internal view that returns consolidated history data in a format needed for viewing and reporting history. OE_PC_ENTITIES_V internal view used by Audit History Consolidator program to select entity ids that requires history consolidation. OE_PC_ATTRIBUTES_V internal view used by Audit History Consolidator program to select audited attributes that requires history consolidation.

3 OE_LOOKUPS - view which returns the Order Management QuickCodes values from base table FND_LOOKUP_VALUES. All the Audit History related calls are within OE_AUDIT_HISTORY_PVT package (OEXPPCHB.pls). This is a private API. Setup and simple test cases with Audit History It is assumed that you have access to a Vision instance, version or comparable training instance. In order to use the Audit History functionality, it is necessary to do the following: 1. Setup Processing Constraints 2. Create Lookups (in the case you need to capture the reasons for change the value of the audited fields). This is an optional step. 3. Enable Audit Trial system parameter 4. Add function security View Audit History on the application menu for the responsibilities that need to view Audit History form. 5. Enter and process sales orders as usual. 6. Submit Audit History Consolidator concurrent program (OEXAUGEN) 7. Run Audit History Report (OEXAUDHR.rdf) or query the Audit History window (OEXAUDHF.fmb) in order to see the changes of audited attribute. 1. Setup Processing Constraints 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.

4 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. Figure 1 OM Lookups where the Reason Codes are defined 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; 3. Setup the OM System parameter: Audit Trail Navigation: OM responsibility > Setup > System Parameters> Values The audit trail parameter is used in order to capture audit history at either order entry or booking. The possible values are: Disable no audit history is recorded Enable when Order is Entered or Enable when Order is Booked.

5 Figure 2 Audit Trial system parameter 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. 4. Add the function View Audit History on the application menu Under System Administrator responsibility > Application > Menu Query for the menu associated with the user s responsibility. For example, in a Vision Instance, under the Order Management SuperUser, Vision Operations(USA) responsibility, the menu is ADS_OM_SUPERMENU. In the submenu ONT_SALES_ORDERS, there is the function security View Audit History.

6 Figure 3 Function View Audit History added to the submenu ONT_SALES_ORDERS 5. Enter and process orders as usual. See the test case with the Sales Orders and an example of audited attribute. 6. Run the Audit History Consolidator concurrent program. In order to consolidate order audit trail history via the concurrent program use the following navigation path: OM responsibility >Requests> Submit a new request> choose from the list of values Audit History Consolidator Figure 4 Parameters of Audit History Consolidator Enter the History Date From. This field is optional. Enter the History Date To.This field is optional. Enter the Order Number From. This field is optional.

7 Enter the Order Number To. This field is optional. Enter a numeric value in the Changes in Last N days field to capture audit history changes captured over a period of days. For example, if you wish to consolidate order changes captured for audit purposes during the last 7 days, enter the value 7. Select OK, and then submit the concurrent request. The Audit History Consolidator concurrent program, when submitted, populates an Order Management table (OE_AUDIT_ATTR_HISTORY) with consolidated audit trail details recorded for orders and lines. Each subsequent submission of the program updates any additional order audit trail details that have been captured since the previous successful submission of the program. 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. 7. Query Audit History form (OEXAUDHF.fmb) or run Audit History Report (OEXAUDHR.rdf). 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. This form consists of a Find window and a Results window. The Audit History Results window displays the following 6 tabs, which display the following order or line attributes: Tabs: Orders, Order Sales Credits, and Order Price Adjustments Tabs display the attributes: History Date and Time Order Number Attribute Name Old Value New Value User Tabs: Lines, Line Sales Credits, and Line Price Adjustments Tabs display the attributes:

8 History Date and Time Order Number Line Number Item Attribute Name Old Value New Value User History data displayed by Audit History Report is illustrated in Figure 14 - Output of Audit History Report Figure 5 The parametes of Audit History Report The Audit History report has a mandatory parameter: History Date(From). The other input parameters are optional. If you leave any of the non-required parameters blank, this report displays the history changes of all attributes. However, it is recommended to run this report at least with History Date (From), Entity Name and Attribute Name input parameters in order to reduce report processing run times. Important: Audit History tracks the changes on order attributes when they are produced on Sales Order, Quick Sales Orders, Order Organizer or Quick Order Organizer forms. If the audited attributes are updated through SQL Plus, Audit History cannot capture this change. Test cases to demonstrate the Audit History functionality Test case1: tracking changes of the salesperson field from the Sales Orders form, header level (record the changes without specifying a reason code).

9 Assumption: You must have access to an Oracle Application Vision database or comparable training or test instance at your site. 1. Enable the Require History option in Processing Constraints form, for the field Salesperson from Sales Order form, Header level. Navigation: OM responsibility > Setup> Rules>Security>Processing Constraints 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 de ned, 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. 2. Go to the Sales Order form: Navigation: OM responsibility > Orders, Returns > Sales Orders form.

10 Create a new sales order and set a value in the field Salesperson. Save the change. 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

11 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. Figure 9 The query criteria in the Audit History form The result is as follows : Figure 10 The recorded changes of the Salesperson 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.

12 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. 7. See the new results in Audit History form: 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

13 Figure 13 Audit History Report parameters The output of this report shows the following: Figure 14 Output of Audit History Report 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.

14 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 3. After entering a reason code(mandatory) and a comment (optional), the change of the Salesperson field is allowed.

15 Figure 16 Reason window with reason code and comment Press OK and then save the changes in Sales Orders form. 4. Run Audit History Consolidator concurrent request. 5. Go to Audit History form and see the new history results: 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 :

16 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 ) 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. Investigating issues with Audit History 1. Check the version of the following files: OEXAUDHR.rdf, OEXPPCHB.pls, OEXPPCHS.pls and OEXAUDHF.fmb using the following commands in Unix:

17 strings -a $ONT_TOP/reports/US/OEXAUDHR.rdf grep -i '$Header' strings -a $ONT_TOP/patch/115/sql/OEXPPCH*.pls grep '$Header' strings -a $ONT_TOP/forms/US/OEXAUDHF.fmx grep -i '$Header' or run the concurrent request of Diagnostics: AppsCheck for Order Management. 2. Check Note :Order Management Cumulative Patches for & for the latest rollup OM patches that include bug fixes for Audit History functionality. 3. Search Knowledge Base for a similar issue. 4. Raise a Service Request with Oracle Support. Known issues with Audit History BUG : AUDIT HISTORY ORDERED QTY HAS DUPLICATE RECORDS FROM DIFFERENT DATES Solution: Download and review the readme and pre-requisites for Patch Confirm the following file versions: OEXPPCHB.pls Retest the issue. (per note ) Bug AUDIT TRAIL ASSISTANCE FOR THE CALCULATE PRICE FLAG ON ORDER LINES Solution: Download and review the readme and pre-requisites for Patch After applying this patch the old values of calculate price flag will be shown correctly in view audit history form. Confirm the following file versions: OEXVCHGB.pls, version OEXVCHGS.pls, version Retest the issue (per note ). Bug : FP 11I9-11I10: AUDIT HISTORY CONSOLIDATOR PERFORMANCE Solution: 1. Download and review the readme and pre-requisites for Patch Ensure that you have taken a backup of your system before applying the recommended patch. 3. Apply the patch in a test environment. 4. Confirm the following file versions: OEXPPCHB.pls, version Retest the issue. (per note )

18 BUG AUDIT HISTORY CONSOLIDATOR PROGRAM HAS PERFORMANCE ISSUES Solution:. Download and review the readme and pre-requisites for Patch Ensure that you have taken a backup of your system before applying the recommended patch. 3. Apply the patch in a test environment. 4. Confirm the following file versions: OEXPPCHB.pls OEXPPCHS.pls Retest the issue ( per note ) BUG CODE FIX: AUDIT HISTORY FAILING WITH THE UNIQUE INDEX VIOLATION Solution : To implement the solution, please execute the following steps: 1. Download and review the readme and pre-requisites for Patch Ensure that you have taken a backup of your system before applying the recommended patch. 3. Apply the patch in a test environment. 4. Confirm the following file versions: -> patch/115/odf/onttab.odf > patch/115/sql/oexppchb.pls > patch/115/sql/oexppchs.pls Use the following commands to confirm the file versions 6. strings -a $ONT_TOP/patch/115/odf/onttab.odf grep '$Header' strings -a $ONT_TOP/patch/115/sql/OEXPPCH*.pls grep '$Header'. 7. Migrate the solution as appropriate to other environments. (per note ) Bug CONCURRENT REQUEST AUDIT HISTORY CONSOLIDATOR/REPORT ARE RUNNING TOO LONG Solution: To implement the solution, please execute the following steps: 1. Download and review the readme and pre-requisites for Patch Ensure that you have taken a backup of your system before applying the recommended patch. 3. Apply the patch in a test environment. 4. Confirm the following file versions: OEXAUDHR.rdf Retest the issue. (per note ) BUG: Oexaugen - Audit History Consolidator Running Long After Upgrade To Solution: To implement the solution, please execute the following steps: 1. Please download and review the readme and pre-requisites for Patch Please ensure that you have taken a backup of your system before applying the recommended patch.

19 3. Please apply the patch in a test environment. 4. Please confirm the following file versions: OEXPPCHB.pls version (per note ) Currently, the following Enhancement Requests are logged for Audit History: Enhancement Request CANNOT CAPTURE NEW LINES ON A BOOKED ORDER IN AUDIT HISTORY Enhancement Request AUDIT HISTORY CONSOLIDATOR PROGRAM IS NOT MULTI-ORG COMPLIANT Enhancement Request VIEW AUDIT HISTORY FORM DOES NOT ALLOW FOR QUERYING ON ORDER LINE. Enhancement Request OEXOEOED - HEADING CHANGE TO CANCELLATION HISTORY INSTEAD OF QUANTITY HISTORY Enhancement Request OEXOETEL NEED NEW FIELD FOR ORIGINAL ORDERED QUANTITY Enhancement Request AUDIT HISTORY SHOULD ALSO TRACK RECORD CREATE OPERATION Enhancement Request ORDER LINE REASON AND COMMENTS ARE NOT AVAILABLE TO VIEW AFTER THEY ARE SAVED Enhancement Request REASON HISTORY FOR ORDER LINE WASN'T MADE WHEN CHANGING SHIPMENT PRIORITY Enhancement Request REQUIRE LINE NUMBER AS SEARCH CRITERIA TO VIEW AUDITHISTORY FORM Enhancement Request USE ORDER TYPE AS PARAMETER FOR AUDIT CONSOLIDATOR REQUEST Enhancement Request UPGRADE THE FUNCTIONALITY OF VIEW AUDIT HISTORY FORM Enhancement Request CHANGES TO ATTRIBUTES ARE NOT PROPERLY DISPLAYED IN OEXAUDHF Enhancement Request NEED TO CAPTURE MULTIPLE REASON CODE/COMMENTS ENTERED FOR AUDIT HISTORY Enhancement Request OEXAUDHF, AUDIT REPORT/FORM LOVS DISPLAY DESCRIPTIVE FLEXFIELD ATTRIBUTEXX

20 Audit History in Order Management Author: Marian Stan Principal Technical Support Analyst Global Software Support Special thanks to Chidananda Pati, Project Leader in Order Management Development for the help in reviewing this whitepaper. Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Worldwide Inquiries: Phone: Fax: 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.