Results for “jtf_task_audits_vl”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

JTF_TASK_AUDITS_VL is a Multi-Lingual Support (MLS) view owned by the APPS schema in Oracle E-Business Suite, belonging to the JTF – CRM Foundation product. It presents task audit history maintained by the CRM task management framework, exposing both the "OLD_" and "NEW_" state of a task at the moment an audit record was captured. Every row represents a discrete change event against a task, with paired old/new values, change indicator flags, and standard audit WHO columns. Because it is an MLS view, translated descriptive attributes are resolved to the caller's language while the underlying transactional values remain language-independent.

The view serves reporting, integration, and reconciliation purposes rather than online transaction entry. Developers, DBAs, and functional analysts query it to reconstruct who changed a task, when, and what the prior and resulting values were — particularly useful in CRM Service, TeleService, and Field Service deployments where task assignment, scheduling, and effort tracking are audited.

Underlying Base Objects

JTF_TASK_AUDITS_VL is defined over two documented base objects, both referenced through synonyms:

• JTF_TASK_AUDITS_B — the base table holding the language-independent audit rows, including the paired OLD_/NEW_ value columns, change flags, and audit WHO columns.
• JTF_TASK_AUDITS_TL — the translation table holding language-specific descriptive text, joined on the audit identifier and the language context.

The view is a standard MLS view pattern: it outer-joins the transactional base to its translation table so callers retrieve both the audit data and the translated descriptions in a single query. The two base objects are related by a shared audit identifier foreign key, and each audit row inherits its ownership context (ORG_ID) from the task being audited.

Key Columns

The view exposes a large, systematically named column set. The most significant groupings are:

• Identifiers and WHO columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN establish when and by whom the audit record was written.
• OLD_* columns — the pre-change values, including OLD_OWNER_ID, OLD_CUST_ACCOUNT_ID, OLD_TASK_STATUS_ID, OLD_PLANNED_START_DATE, and OLD_ACTUAL_EFFORT, among many others.
• NEW_* columns — the post-change equivalents, such as NEW_OWNER_ID, NEW_CUST_ACCOUNT_ID, NEW_TASK_STATUS_ID, NEW_SCHEDULED_END_DATE, and NEW_PERCENTAGE_COMPLETE.
• Change indicator flags — BILLABLE_CHANGED_FLAG, HOLIDAY_CHANGED_FLAG, LAPTOP_CHANGED_FLAG, DEVICE1_CHANGED_FLAG through DEVICE3_CHANGED_FLAG, MULTI_BOOKED_CHANGED_FLAG, MILESTONE_CHANGED_FLAG, and NOTIFICATION_CHANGED_FLAG identify which attributes were modified.

The user's search term, old_location_id, corresponds to the "OLD" side of the audit pattern. The documented view text lists OLD_ columns such as OLD_ADDRESS_ID, OLD_ORG_ID, and OLD_OWNER_ID; where a location attribute is audited, it is recorded in the same OLD_/NEW_ pairing convention. Analysts should inspect the actual column list in the data dictionary (ALL_TAB_COLUMNS for APPS.JTF_TASK_AUDITS_VL) to confirm whether a location column exists in their point release, since the view text provided is truncated.

Common Use Cases and Queries

Typical uses include auditing ownership reassignments, tracking schedule slippage, and validating effort revisions.

• Listing recent audit events for a specific task:

SELECT audit_id, created_by, creation_date,
       old_owner_id, new_owner_id,
       old_task_status_id, new_task_status_id,
       old_scheduled_end_date, new_scheduled_end_date
FROM   apps.jtf_task_audits_vl
WHERE  task_id = :p_task_id
ORDER  BY creation_date DESC;

• Finding all changes to an audited attribute (for example, address or location) within a date range:

SELECT audit_id, task_id, created_by, creation_date,
       old_address_id, new_address_id
FROM   apps.jtf_task_audits_vl
WHERE  creation_date BETWEEN :p_from_date AND :p_to_date
AND    old_address_id <> new_address_id;

• Filtering by change flags to isolate a specific modification type, such as billable status:

SELECT audit_id, task_id, creation_date
FROM   apps.jtf_task_audits_vl
WHERE  billable_changed_flag = 'Y';

Because the view resolves translations dynamically, queries executed under different language sessions return the same OLD_/NEW_ transactional values but translated descriptive text.