Results for “jtf_rs_groups_aud_b_u1”

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

Overview

JTF.JTF_RS_GROUPS_AUD_B is the base audit table for resource groups within the Oracle E-Business Suite CRM foundation layer (schema JTF). It is a transactional data object residing in the APPS_TS_TX_DATA tablespace, and it exists to capture the before-and-after image of every change made to a resource group record. Rather than overwriting history, the table stores parallel NEW_ and OLD_ column pairs so that each modification to a group's attributes is preserved as an individual, immutable audit row keyed by GROUP_AUDIT_ID.

Its role in Oracle EBS is supporting auditability, compliance, and historical reconstruction for the Resource Manager functionality that governs how sales, service, and field-service resources are organized into groups. The presence of the SECURITY_GROUP_ID column indicates that the table participates in Applications Hosting / multi-tenant data partitioning, and the table is registered under FND Design Data as JTF.JTF_RS_GROUPS_AUD_B.

From a heuristic Data Vault modeling perspective, the mined relationship structure classifies this object as satellite-leaning. That classification is a modeling suggestion only: the table hangs off the JTF_RS_GROUPS_B hub via GROUP_ID and records descriptive, time-stamped attribute history, which is precisely the profile of a satellite attached to a core hub entity.

Key Information Stored

The table is anchored by a surrogate primary key, GROUP_AUDIT_ID (NUMBER), which is also exposed through the unique index JTF_RS_GROUPS_AUD_B_U1 (UNIQUE, tablespace APPS_TS_TX_IDX). This index is the documented business-key candidate and the primary lookup path for retrieving a specific audit event. The true business key of the underlying group — the relationship to JTF_RS_GROUPS_B — is carried by GROUP_ID.

• GROUP_AUDIT_ID — primary key and unique index column; the audit event identifier.
• GROUP_ID — foreign key to the resource group master; identifies which group the audit row pertains to.
• NEW_GROUP_NUMBER / OLD_GROUP_NUMBER — the group's number before and after the change.
• NEW_EXCLUSIVE_FLAG / OLD_EXCLUSIVE_FLAG — membership exclusivity state, before and after.
• NEW_START_DATE_ACTIVE / OLD_START_DATE_ACTIVE and NEW_END_DATE_ACTIVE / OLD_END_DATE_ACTIVE — effective dating of the group, retained across updates.
• NEW_ACCOUNTING_CODE / OLD_ACCOUNTING_CODE — accounting classification changes.
• NEW_EMAIL_ADDRESS / OLD_EMAIL_ADDRESS — contact email changes.
• NEW_TIME_ZONE / OLD_TIME_ZONE — time zone changes.
• NEW_OBJECT_VERSION_NUMBER / OLD_OBJECT_VERSION_NUMBER — optimistic locking version stamps, useful for detecting concurrent updates.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS for hosting and data partitioning.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO columns identifying the user and timestamp of each audit row.

Common Use Cases and Queries

The most frequent use is historical reconstruction: determining what a resource group looked like at a point in time, or identifying who changed a specific attribute. Audit and compliance reporting also draws on this table, particularly around effective dates and accounting codes. A typical pattern reconstructs the change history for a group:

• Trace changes to a single group: SELECT * FROM JTF.JTF_RS_GROUPS_AUD_B WHERE GROUP_ID = :group_id ORDER BY CREATION_DATE DESC;
• Identify who changed a group number: filter on NEW_GROUP_NUMBER <> OLD_GROUP_NUMBER and join CREATED_BY to FND_USER.USER_ID.
• Detect concurrent-update conflicts by comparing NEW_OBJECT_VERSION_NUMBER against OLD_OBJECT_VERSION_NUMBER.
• Partition-scoped reporting by filtering on SECURITY_GROUP_ID when operating in a hosted environment.
• Point-in-time reporting by selecting the audit row with the greatest CREATION_DATE not exceeding the reporting date for a given GROUP_ID.

Related Objects

The audit table is tightly coupled to the group master and a small number of surrounding objects:

• JTF.JTF_RS_GROUPS_B — referenced via GROUP_AUDIT_ID.GROUP_ID; the base master table holding current group definitions.
• FND_SECURITY_GROUPS — referenced via SECURITY_GROUP_ID; controls hosting and data security partitioning.
• JTF.JTF_RS_GROUPS_AUD_TL — translation table referencing this table via GROUP_AUDIT_ID; holds translated audit attributes.
• FND_USER — implicit reference through CREATED_BY and LAST_UPDATED_BY for user attribution.
• FND_LOGINS — implicit reference through LAST_UPDATE_LOGIN for operating-system login tracking.

Because the table is populated by the Resource Manager audit mechanisms rather than by direct user entry, it should be treated as a read-only reporting source. Any queries against it should be filtered by GROUP_ID or a date range to avoid full-table scans on the APPS_TS_TX_DATA tablespace.