PeopleSoft Audit record for multiple tables

Manageability
Field level auditing is manageable when you are interested in auditing one or two fields. Beyond that the complexity increases drastically. That’s certainly not the case with Record level auditing where you can easily manage entire records.
Situation
Based on the factors outlines above, it would be wise to choose Record level auditing when the situation demands the auditing of a number of fields or a record as a whole. However, you always have another option in Field level audit when you are chasing just a filed or two.

Is it possible to have one single audit record for multiple PeopleSoft records(tables)?
Yes, today I came to know a feature that a single audit record can be used to audit multiple PeopleSoft records. As I write about this, I have also specified all about a PeopleSoft Audit record.

The easiest way to create an audit record is to open the record definition of the base record that you wish to audit. Remove the all edit and key attributes from the newly saved audit record. Also remove any attributes such as PARENT records, Query Security Records, and PeopleCode must be removed for the audit record. The audit record must be saved with the prefix AUDIT_.

To the top of this new audit record the following key fields have to be added in the same order and they should also be made as key fields.

• AUDIT_OPRID
• AUDIT_STAMP
• AUDIT_ACTN
• AUDIT_RECNAME**

In most cases we include only AUDIT_OPRID, AUDIT_STAMP, and AUDIT_ACTN. The AUDIT_STAMP must be given the attribute AUTOUPDATE attribute must be checked for the field AUDIT_STAMP. AUDIT_STAMP field must also be made a descending key field.

• AUDIT_OPRID - Identifies the user who caused the system to trigger the audits
• AUDIT_STAMP -Identifies the date and time the audit was triggered 
• AUDIT_ACTN - Indicates the type of action that the system audited.

         Possible audit actions include:

• A: Row inserted. 
• D: Row deleted.
• C: Row changed (updated), but no key fields changed. The system writes old values to the audit table.
• K: Row changed (updated), and at least one key field changed. The system writes old values to the audit table.
• N: Row changed (updated), and at least one key field changed. The system writes new values to the audit table.

** - AUDIT_RECNAME must be added only if the audit table needs to audit more than one record definition.

The audit table need not have to include all the columns of the base table. In fact, for performance reasons, it’s best to only to include those fields in the audit record that are deemed to be changed.

In the record to be audited go to Record Properties -> Record Audit, specify the below options

Record Name – Specify the user-defined audit record.

Specify the required Audit Options – following are the audit options to choose for auditing the record.

• Add - Inserts an audit table row whenever a new row is added to the table underlying this record definition.
• Change - Inserts one or two audit table rows whenever a row is changed on the table underlying this record definition.
• Selective - Inserts one or two audit table rows whenever a field that is also included in the record definition for the audit table is changed.
• Delete - Inserts an audit table row whenever a row is deleted from the table underlying this record definition.

Everytime the record is being inserted, deleted, updated a corresponding row gets inserted in the audit table as per the options specified.