A question that comes up all the time on the OTN Forums is "How do I know who updated this record?". Generally the response is to point the member in the direction of the
last_updated_by column on the table. The next question often then comes up... So how do I see what the old value was?". Hmmmm... a little more tricky. We can try to look at flashback query however if the update was more than a few hours ago on a busy OLTP system then the chances are the undo has been cleared out. Sometimes we get lucky and the table holds a date-tracked history (HRMS tables for example). But usually it's just tough luck - once the data has been overwritten, it's gone (without resorting to backups).
So if you have some important tables in your E-Business Suite system that you wish to track changes on such as this, then you might want to consider enabling AuditTrail on those tables. It doesn't require any additional licences and is relatively easy to configure. Rather than just narrating what it does, I'll explain with an example.
Assume we have a concern that somebody might update the definition of a form function in EBS and do things we should be tracking; things like altering the parameters to the form. First we need to know what table(s) the data is being maintained in. There are several ways to do this, however often the easiest it to simply do Help > Record History or Help > Diagnostics > Examine > [SYSTEM|LAST_QUERY] and track the view through to the base table(s). So in our case it is fnd_form_functions.
In order to use AuditTrail the table needs to be registered with the application. For standard tables this is (generally) done - you can check for the existence of a record in FND_TABLES - however for custom tables you'll need to register the table using
ad_dd.register_column, then register the primary key of the table using
ad_dd.register_primary_key_column. Unfortunately there isn't a screen with update capabilities to do this. What I do for custom tables is use a script which reads the data dictionary for a given table and does all this for me. Anyway, once we have the table registered, we need to enable the owner of that table for auditing. In the System Administrator responsibility, navigate to Security > AuditTrail (all our configuration will be done via this menu path) and select the Install option. For our table, fnd_form_functions, the owner is APPLSYS.
SQL> Select owner, table_name
2 From all_tables
3 Where table_name='FND_TABLES';
In my vision instance this user is already enabled.
Next we need to create an Audit Group - this is a logical grouping of like audited tables. Navigate to the Groups menu option and we'll create that. Note that we have to set the initial status to Enable Requested. This is very important.