How to Setup and Verify Audit Changes to Orders using Audit History

Setup Steps

The following example illustrates how to audit when a change is made to the Payment Terms of an order that is booked with a reason as to why it was changed. The steps to initiate Audit History are:

1. Turn Audit History on at the site level.

     a) Navigation: Order Management Super User > Setup > System Parameters > Values
     b) Change "Audit Trail" from Disable.

There are two choices:

Enable When Order is Entered: This will initiate auditing when a change is made to a specified field after the order has been Saved.
Enable When Order is Booked: This will initiate auditing when a change is made to a specified field after the order has been Booked.

2.  Identify a specified field when changed that will be audited.      

     a) Navigation: Order Management Super User > Setup > Rules > Security > Processing Constraints
     b) Setup Processing Constraints for Order header or Line attribute for UPDATE or CANCEL operation that requires
          1) Required Reason and History - a reason window will always appear and a reason with optional comments must be entered. History will be captured.
          2) Require History - a reason window will not appear when making a change and history will be captured. There is always the flexibility of entering a reason by navigating to Tools > Change Reason.
          3) Require Reason, History and Raise Integration Events
     c) Position your cursor on the field to be audited in the constraints block and click the plus icon in the toolbar. This will add a new row where information can be entered.
     d) You can then change to the Conditions tab in the form and select: Scope, Order Validation template.
     e) Next navigate to the applicable tab. The audit can be associated with a specific responsibility.  "All Responsibilities" can be selected.

3. Run Generate Constraints Validation Packages

     a) Navigation: Order Management Super User > Setup > Rules > Security > Generate Constraints Validation Packages

4. Now test the Audit Trail defined. 

     a) Enter Sales Order header and Line Information and Save as usual.
     b) After you saved the Sales Order, try to change the value of the field on which Processing Constraints.

5. In order to obtain data in the Audit History Report it is necessary to run on a regularly scheduled basis a consolidation program that will extract the audit information and add it to a history file.

     a) Navigation: Order Management Super User > Reports,Request > Run Requests > Select Audit History Consolidator (OEXAUGEN).
     b) Data can be extracted based on History Date From and To, Order Number From and To, or Changes in last N days.
     c) Enter 1 in the Changes in last N days.
     d) To view the data either an audit report. Navigation: Order Management Super User > Reports,Requests > Reports > Select Audit History.
     e) Report can be created based upon History Date From and To, Order Number From and To, Entity Name, Attribute, User, and Responsibility.

6. To view history online, Navigation: Order Management Super User > Orders, Returns > View Audit History and select the data you want to view.

How to track Comments field In Sales Order Form > Line tab

Comments and Reason fields on the Lines are never stored in OE_ORDER_LINES_ALL table. They are used by Processing Constraints (Auditing) frame work to store the reason/comments for each change being done by users.  Hence when ever a Line is saved, these fields are always cleared and made as blank, to again capture the reason/comments for any new changes.  This is intended behavior. Users will have to use DFF to store their comments.

You can see Comment field via View Audit History form:
Run: Audit History Consolidator
Order Management Responsibility:
Orders, Returns -> View Audit History
Query on Order Number: 
Go to Lines Tab
Put Cursor on each line..
You can see , bottom of the form,
Reason : Item Description: Comments:...

How to Verify Audit History changes:

Check the data in attribute change in Tables

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_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

     For example: If the processing constraint is setup for the
         Application: Order Management.
         Entity: Order Line and
        Attribute: Sales Person

     Select  *  from OE_ORDER_LINES_HISTORY 
     Where header_id = &Enter Order header for  which the changes were made.
     and line_id = &Enter line_id of the Order on which changes were made.

Similarly if the processing constraint was set up for the attributes on the ‘Order header’  or ‘Price adjustments’ window or ‘Sales Credits’ entity, the data for the attribute change can be checked in tables
         OE_ORDER_HEADER_HISTORY - Table that stores history of attribute change for Order Headers
         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

Check the data in Audit Attribute History Tables

Check the 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.

Select * from OE_AUDIT_ATTR_HISTORY  
Where ORDER_NUMBER = &Enter Order number for which the history data is consolidated

Investigating issues with Audit History

Important: In the case the Audit History is not captured even though Require History constraint is defined, check
a) 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.

b) Check processing constraint is setup for the 'All responsibilities' or the Responsibility used for making the changes the is listed in 'Constrained Responsibilities'
     Navigation: Navigation: Order Management Super User > Setup > Rules > Security > Processing Constraints
     Check under ‘Applicable To’ tab

Credit Check functionality in Oracle applications functional

Credit checking feature of Oracle OM provides the ability to check that the customer has sufficient credit available with the organization at the point of order booking ,picking, packing and shipping. Credit check rules, order transaction type, payment terms and credit profiles are the key setup entities that influence the credit check process.

Oracle OM credit checking includes:

• Validating orders and lines against existing credit limits defined in the credit profile.
• Placing credit holds at either the order or line level.
• Sending credit hold notifications to order creator.
• Automatically apply or release order or order line credit holds using credit check processor program.
• Reporting and querying tools to effectively manage your credit processes and ensure credit holds are processed in a timely manner.

Main purpose of Credit checking process is to minimize the financial risk that the organization assumes as a result of day-to-day transactions.

For Detailed setup of this functionality kindly check below video. It has covered all the mandatory setups required to have this functionality. Also, It has one test cycle included into it. 

Consigned Inventory in Oracle Applications Setup & Process

Consigned Inventory is an inventory which is in possession of Customer but the items lies in it is owned by Supplier.

To perform this concept in Oracle Apps, following setups required.

Make new item for consigned inventory, item template is Purchased Item and tick on Use Approved Supplier in Purchasing tab, also enable Consigned Check box in General Planning Tab.  

 

 And then save it and assign the item to organization.

Now we need two subinventories, one for Asset sub inventory which is in possession of Customer and one for Expense in which supplier puts item. Expense subinventory will be placed in Customer Premises but possession of that subinventory will be to Supplier.

For creating subinventory go to Inventory > Setup > Organizations > Subinventories

And then create new subinventory (Asset subinventory).

 

Now define Expense subinventory 

 

At supplier site, we need to setup in self billing section. 

Navigation: Purchasing > Supply Base > Suppliers 

Set Pay On = ‘Use’ and Invoice Summary Level = ‘Pay Site’

  

After doing setup at supplier level we need to create Blanket Purchase Order between Supplier and Customer.

Navigation: Purchasing > Purchase Order > Purchase Orders

 

 Then it will go for Approval. 

After creating BPA, Define consumption transaction rules and selected transfer type as Subinventory Transfer, given weight as 10, Entered Owning Party details, Entered from & To Sub inventory details and item details.

Navigation: Inventory > Setup > Consigned/VMI Consumption

 

In Approved Supplier List, we need to setup for ‘con_01’ for Supplier ‘Manual Supp01’

Navigation: Purchasing > Supply Base > Approved Supplier List

 

 Now go to attributes, Source Document Tab

 

At inventory tab, tick on Consigned from Supplier 

 

Now all setup regarding Consigned Inventory has been done. 

Process: create Standard PO for same supplier and item.

  

Go to shipments tab,

 

Here consigned tab is checked.

Submit for approval that PO.

 

Now receipt the ordered item

 

Receive the items, receive items at CON_EXPENS subinventory.

 

Now items are received and in the CON_EXPENS subinventory which is Expense subinventory, under the possession of Supplier.

Created Consigned Transaction and Selected Transaction Type as “Transfer to Regular “.

Go to Inventory > Transactions > Consigned Transactions

 

Perform the transaction And save it.

Now, Run the concurrent “create consumption advice”

Run the concurrent Pay on Receipt Auto Invoice with a transaction source of “ERS_AND_USE” for our inventory receipt number.