Search Results css_def_audit_history_b




Overview
Explore in AI Chat

Overview

The CSS_DEF_AUDIT_HISTORY_B table is a core data object within the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 releases, specifically for the CSS (Customer Support) module, which is now marked as obsolete. This table serves as a detailed audit trail, systematically logging historical changes to key attributes of a support defect or case. Its primary role is to provide a comprehensive, immutable record of modifications—such as status updates, priority changes, or reassignments—enabling compliance tracking, troubleshooting, and historical analysis of the support lifecycle. The table's structure, with numerous foreign key relationships, indicates its function as a central hub for linking audit events to the specific defect, the involved parties, and the various code sets that define the support process.

Key Information Stored

While the specific column list is not fully detailed in the provided metadata, the documented foreign key relationships reveal the critical data points this table captures. The primary identifier is the AUDIT_HISTORY_ID. Each record is fundamentally linked to a specific defect via the DEFECT_ID column. The table stores the identifiers for the user who filed the update (FILER_ID) and the user who last updated the record (UPDATED_BY_ID), along with the originating customer (ORIGINATING_CUSTOMER_ID). Crucially, it logs the historical values for key defect attributes by storing references to their respective code tables: PROBLEM_TYPE_ID, PHASE_ID, STATUS_ID, TERRITORY_ID, SEVERITY_ID, and PRIORITY_ID. This design allows the reconstruction of a defect's state at any point in its audit history.

Common Use Cases and Queries

A primary use case is generating audit reports for a specific defect to understand its resolution path. For example, a query might join to the defects and user tables to list all status changes:

  • SELECT d.defect_number, u.user_name, ah.creation_date, s.name status_name FROM css_def_audit_history_b ah, css_def_defects_b d, fnd_user u, css_def_statuses_b s WHERE ah.defect_id = d.defect_id AND ah.filer_id = u.user_id AND ah.status_id = s.status_id AND d.defect_id = :p_defect_id ORDER BY ah.creation_date;

Another common scenario is compliance auditing, where reports identify all defects whose severity or priority was downgraded, potentially by joining the audit history with the severities or priorities tables and comparing sequential records. Data integrity checks are also vital; queries often verify that every AUDIT_HISTORY_ID in the child CSS_DEF_AUDIT_COLUMNS_B table has a valid parent record in this table.

Related Objects

The table is centrally connected to numerous other EBS objects, primarily through foreign key constraints. Its parent table is CSS_DEF_DEFECTS_B, linked via DEFECT_ID. It references several code and setup tables to store historical values: CSS_DEF_PROB_TYPES_B (PROBLEM_TYPE_ID), CSS_DEF_PHASES_B (PHASE_ID), CSS_DEF_STATUSES_B (STATUS_ID), CSS_DEF_SEVERITIES_B (SEVERITY_ID), and CSS_DEF_PRIORITIES_B (PRIORITY_ID). For party and user information, it links to HZ_PARTIES (ORIGINATING_CUSTOMER_ID) and FND_USER (FILER_ID, UPDATED_BY_ID). It also references JTF_TERR_ALL (TERRITORY_ID) for territory assignments. A key child table is CSS_DEF_AUDIT_COLUMNS_B, which likely stores the detailed column-level old and new values for each audit history event, linked by AUDIT_HISTORY_ID.