Results for “multi_booked_changed_flag”

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

Overview

JTF_TASK_AUDITS_B is the base table in the JTF (CRM Foundation) schema that stores audit trail information for tasks managed within Oracle E-Business Suite Release 12.1.1 and 12.2.2. Every time a task attribute is modified through the Task Manager or related CRM flows, the application records a row in this table capturing the before-image and after-image of the changed values. This provides a complete, queryable change history for task records without requiring database-level auditing on JTF_TASKS_B itself.

The table is owned by the JTF schema and is documented as VALID in ETRM. It contains 107 columns, which reflects the breadth of a task's editable attributes: status, priority, type, owner, customer, dates, effort, recurrence, workflow linkage, and device synchronization flags. The heuristic Data Vault classification mined from the foreign-key structure is link. This suggests modeling the table as a relationship/event entity that connects a task to the actors and reference values involved in each change event, rather than as a standalone hub or a pure descriptive satellite.

The primary key is constrained by JTF_TASK_AUDITS_B_PK on the column TASK_AUDIT_ID, and a unique index JTF_TASK_AUDITS_B_U1 provides a second business-key candidate on the same column.

Key Information Stored

The surrogate primary key is TASK_AUDIT_ID, which uniquely identifies each audit row. The foreign key TASK_ID links the audit record back to the audited task in JTF_TASKS_B, and is the column most commonly used to retrieve the history of a single task.

The core of the table is a set of OLD_/NEW_ column pairs that capture the before and after values of each attribute at the time of change. The most significant pairs are:

• OLD_TASK_STATUS_ID / NEW_TASK_STATUS_ID and OLD_TASK_PRIORITY_ID / NEW_TASK_PRIORITY_ID — status and priority transitions, referencing JTF_TASK_STATUSES_B and JTF_TASK_PRIORITIES_B.
• OLD_TASK_TYPE_ID / NEW_TASK_TYPE_ID — task classification changes against JTF_TASK_TYPES_B.
• OLD_OWNER_ID / NEW_OWNER_ID with OLD_OWNER_TYPE_CODE / NEW_OWNER_TYPE_CODE — reassignment events.
• OLD_ASSIGNED_BY_ID / NEW_ASSIGNED_BY_ID — referencing FND_USER, recording who performed assignment.
• OLD_PLANNED_START_DATE / NEW_PLANNED_START_DATE, the scheduled date pair, and the actual date pair — schedule slippage analysis.
• OLD_CUSTOMER_ID / NEW_CUSTOMER_ID and the corresponding CUST_ACCOUNT pair — party reassignment.
• OLD_PARENT_TASK_ID / NEW_PARENT_TASK_ID — hierarchy restructuring.

Standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN), OBJECT_VERSION_NUMBER, and SECURITY_GROUP_ID support concurrency control and multi-org/security-group filtering. Boolean-style change flags such as PRIVATE_CHANGED_FLAG and MULTI_BOOKED_CHANGED_FLAG indicate which attribute groups were touched.

Common Use Cases and Queries

The principal use case is reconstructing the change history of a specific task for audit, dispute resolution, or SLA reporting. A typical query joins the audit table to reference tables to resolve IDs into readable values:

• Retrieve full change history for one task, ordered by creation date, filtering on TASK_ID = :task_id.
• Report on status transition counts: group by OLD_TASK_STATUS_ID and NEW_TASK_STATUS_ID to identify the most frequent state changes.
• Measure schedule slippage by comparing OLD_PLANNED_START_DATE and NEW_PLANNED_START_DATE for recurring delay patterns.
• Audit reassignment activity by joining OLD_OWNER_ID and NEW_OWNER_ID to the owner lookup, typically within a date range using CREATION_DATE.
• Track escalation and priority churn via OLD_ESCALATION_LEVEL / NEW_ESCALATION_LEVEL and the priority pair.

Because the table is a base table (_B suffix), reporting should join to the corresponding _TL translation views where lookups are language-dependent. Queries should always constrain by TASK_ID or date range to avoid full scans given the high row volume typical of audit tables.

Related Objects

The most significant related objects, based on documented foreign-key relationships, include:

• JTF_TASKS_B — the parent task table; joined on TASK_ID, and also referenced via OLD_PARENT_TASK_ID and NEW_PARENT_TASK_ID for hierarchy changes.
• JTF_TASK_STATUSES_B — referenced through OLD_TASK_STATUS_ID and NEW_TASK_STATUS_ID.
• JTF_TASK_PRIORITIES_B — referenced through OLD_TASK_PRIORITY_ID and NEW_TASK_PRIORITY_ID.
• JTF_TASK_TYPES_B — referenced through OLD_TASK_TYPE_ID and NEW_TASK_TYPE_ID.
• JTF_TASK_RECUR_RULES — referenced through the OLD/NEW recurrence rule columns.
• FND_USER — provides the assigned-by identity for OLD_ASSIGNED_BY_ID and NEW_ASSIGNED_BY_ID.
• HZ_PARTIES and HZ_CUST_ACCOUNTS — resolve customer and account references.
• HZ_PARTY_SITES and HZ_TIMEZONES — resolve address and timezone changes.
• CS_INCIDENTS_ALL_B — links audit records to service incidents via the source object columns.
• FND_SECURITY_GROUPS — enforces the security group context through SECURITY_GROUP_ID.

Together these relationships make JTF_TASK_AUDITS_B the central link capturing who changed what, when, and from which prior value across the CRM task domain.