How To Setup Database Row Changes Audit Trial

An Audit Trail retains a history of changes to data. It includes the following information:

1. What changed

2. Who changed it

3. When was the data changed

When you enter or update data in your forms, you change the database tables underlying those forms. An Audit Trail tracks which row in the database was updated at what time, and which user was logged in using the associated form(s). (Metalink)

Following are the steps required to set audit trial

I. Set Audit Trail Profile Option

Login by Using System Administrator Responsibility

Navigate To

Profile –> System

And find the Audit Trail: Activate it should be set to Yes it is available on site level only. We Must Re Login into Application to Activate audit Trial in Current Session

II. Select the Installations for Audit

Navigate To

Security –> Audit Trail –> Install

You will have to check all schemas enable for which you required audit trial and save the record first click on find button and find schema. Here I took fnd_user table for audit trial so I have to check APPLSYS as this table is in APPLSYS schema. Save the work after finding and filling information as shown in picture below

III. Create a New Audit Group

Navigate To

Security –>Audit Trail–>Groups

Fill the Form on Basis of required Information

1. Application Name

Select the name of an application to associate with your audit group. The combination of application name and group name uniquely identifies your audit group. An audit group may be used to audit tables in additional applications.

Value: - Application Object Library

2. Audit Group

Enter the name of the audit group.

Value: - FND_USER Audit Demo

3. Group State

Choose Enable requested if you are defining a new audit group

Value: - Enable requested

When you run the Audit Trail Update Tables report, the concurrent program creates database triggers for the tables in your audit group. Once you have run the program, this field displays Enabled for audit groups where Audit Trail is active.

Fill the table name for which you required Audit here in my case it is FND_USER and Save the new audit group

IV Define Table Columns to be Audited

Navigate To

Security –> Audit Trail –>Tables

For every table defined in step 3, you need to define the columns by using these steps –


Find the table name.


Primary key, Creation Date, Created by, Last Update Login, Last Update Date and Last Updated by Columns will always be saved.

Now add the audit required column in detail block as per following picture and save the record.

V. Run Audit Trail Update Program

Navigate To

Requests –> Run

Run the Audit Trail Update Tables program to activate the auditing you can schedule this program depends upon available resources.

VI. How to get audit trial data

There are no standard Oracle Applications reports to access Audit Trail data you can only access audit trial data through SQL. All information related to auditing is stored in “shadow” tables for each audited table for which you enabled audit and these shadow tables named as tablename_A. Here in my case all information is stored in fnd_user_A.

I have created a new user by name of Pricing and change its password from older one to new one.

Now after this transaction run the following query

SELECT audit_timestamp, audit_transaction_type, audit_user_name,

audit_true_nulls, audit_session_id, audit_sequence_id, audit_commit_id,

row_key, user_id, encrypted_user_password, last_updated_by,

password_accesses_left, password_date, encrypted_foundation_password,

user_name, created_by, employee_id

FROM applsys.fnd_user_a

Result in TOAD

Query returns my user name and other information

VII. Purging Audit Trial Data

There is no standard purge program and the Audit Trail must be manually disabled to permit purging. Use the following procedure to purge audit date –

Navigate to

Security –> Audit Trail –> Groups

Select the “Security Audit” group and set the group state to “Disable – Purge Table”

Run the “Audit Trail Update Tables” Report as mentioned above

Purge the data from the shadow table

Troubleshooting

I. Note 105624.1 Troubleshooting Audit Trail issues.

II. Note 60828.1 - Overview of Oracle Applications Audit Trails

III. Note:105630.1 Setup & Usage (Audit Trail)

IV. Oracle Applications System Administration Guide

Oracle Advanced Supply Chain Planning

Oracle Advanced Supply Chain Planning has component based architecture that separates the transaction data and processing associated in a source instance from the planning calculations done in a destination instance.

The Oracle Advanced Planning can plan a single instance or multiple instances. An instance is a database and a set of applications.

There are several types of instances:

Source instances
Source instances hold source information, for example, items, bill of materials, Orders. Source instances are Oracle Applications instances (from releases 10.7, 11.0, and 11i) or legacy systems.

Destination instance
The destination instance (APS planning server) holds planning information. Planners use the planning server to store information collected from the source instances. Run, analyze, and simulate plans; and implement planned orders.

Oracle Advanced Supply Chain Planning consist of following modules

1. Oracle Collaborative Planning
2. Oracle Demand Planning
3. Oracle Global Order Promising
4. Oracle Inventory Optimization
5. Oracle Manufacturing Scheduling

Order Management Links Oracle Order Management Track

Visit following to find some useful information of order Management

Order Management Links Oracle Order Management Track

How to get JV more then a specific Amount

Connect by Apps user name and just enter Amount when Prompted.We can use this query in Oracle Alerts to Notify GL Manager

SELECT gjh.NAME, gjh.running_total_cr, gjh.running_total_dr,
gjh.currency_code, gjlv.description, gsnv.NAME,
DECODE (NVL (gjlv.entered_dr, 1),
1, ‘CREDIT’,
gjlv.entered_dr, gjlv.entered_dr
) debit,
DECODE (NVL (gjlv.entered_cr, 1),
1, ‘DEBIT’,
gjlv.entered_cr, gjlv.entered_cr
) credit,
gjlv.period_name,
( gccv.segment1
|| ‘ ‘
|| gccv.segment2
|| ‘ ‘
|| gccv.segment3
|| ‘ ‘
|| gccv.segment4
|| ‘ ‘
|| gccv.segment5
|| ‘ ‘
|| gccv.segment6
|| ‘ ‘
|| gccv.segment7
|| ‘ ‘
|| gccv.segment8
) ACCOUNT,
gjlv.entered_cr, gjlv.entered_dr
FROM gl_je_headers gjh,
gl_je_lines_v gjlv,
gl_sob_names_v gsnv,
gl_code_combinations_v gccv
WHERE ( (gjlv.je_header_id = gjh.je_header_id)
AND (gsnv.set_of_books_id = gjlv.set_of_books_id)
AND (gjlv.code_combination_id = gccv.code_combination_id)
)
AND (gjh.running_total_dr > :amount OR gjh.running_total_cr > :amount)

How Oracle Credit Management Works

Why We Need Oracle Credit Management

Good customer scoring strategies will have better visibility, quicker decision making, reduces manual efforts and increase in the profitability

It can be easily configured on top of an existing 11i implementation

Easy configuration depending on requirements.

On line credit application and approval process will eliminate many home grown systems

Controls escalating and higher incidences of bad debts

Reduces collection cost and diminishing returns

Reduces the credit-to-cash life cycle

We can have aggressive and/or conservative credit policies based on customer classes

Track credit performances and history of credit decisions and run reports as needed

Continuous and scheduled periodic credit evaluations for high risk customers or for all customers

Matches global credit policies ( In MNC Scenario)

Strong internal controls

Lack of visibility in International Credit. Can handle financial risks in global market

TABLES & PROFILE OPTIONS ARE USED WITH THE MOVE ORDER FUNCTION

TABLES

1. MTL_TXN_REQUEST_HEADERS
This table stores all of the move order headers. The headers contain all information which pertains to entire move orders, including the transaction type of the move order, the move order type, the move order status, and the request number of the move order.

2. MTL_TXN_REQUEST_LINES
The table MTL_TXN_REQUEST_LINES stores all of the move order lines. The lines are requests to move some quantity of an item from a source location to a destination location or account. Each move order line must be tied to a specific move order header.When a line is detailed or pick released, the quantity detailed is updated appropriately and transaction lines are created in MTL_MATERIAL_TRANSACTIONS_TEMP. When the transaction lines are transacted, the quantity delivered is updated.

PROFILE OPTION

TP:INV Move Order Transact Form

This profile options will be set at Site Level with Following Possible values

On-line processing
Concurrent processing
Background processing

By Deafult it will be Online Processing