Results for “language_id”

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

Overview

CS_INCIDENTS_AUDIT_B is a Service (CS) module table in Oracle E-Business Suite 12.1.1 and 12.2.2 that stores non-translated audit information for service requests. Each row captures a change-history record for a service request (internally an "incident"), recording the new value, the prior value, and a change flag for every auditable attribute on the incident. The table is owned by the CS schema and is documented as VALID in ETRM metadata for release 12.2.2, with a physical schema of 466 columns and a Data Vault classification (heuristic, mined from its foreign-key structure) of satellite-leaning. In Data Vault terms, this suggests modeling CS_INCIDENTS_AUDIT_B as a satellite attached to the CS_INCIDENTS_ALL_B hub: it is descriptive, time-variant, and keyed by an identifier tied to the incident, rather than acting as an independent hub or a pure relationship link.

Key Information Stored

The table is principally an audit trail. The most significant columns fall into three groups.

• Identity and primary key: The documented primary key CS_INCIDENTS_AUDIT_B_PK is INCIDENT_ID, while the unique index CS_INCIDENTS_AUDIT_B_U1 defines INCIDENT_AUDIT_ID as a business-key candidate. INCIDENT_ID is also the foreign key to CS_INCIDENTS_ALL_B, so each audit row is anchored to a specific service request.
• Audited attributes with before/after pairs: The dominant pattern is a current value, an OLD_ value, and a CHANGE_ flag. Examples include INCIDENT_STATUS_ID / OLD_INCIDENT_STATUS_ID / CHANGE_INCIDENT_STATUS_FLAG; INCIDENT_TYPE_ID, INCIDENT_URGENCY_ID, and INCIDENT_SEVERITY_ID with their OLD_ counterparts; INCIDENT_OWNER_ID and RESPONSIBLE_GROUP_ID with OLD_ and CHANGE_ columns; CLOSE_DATE / OLD_CLOSE_DATE; ACTUAL_RESOLUTION_DATE / OLD_ACTUAL_RESOLUTION_DATE; and INCIDENT_NUMBER / OLD_INCIDENT_NUMBER.
• Who, when, and how: LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN, and OBJECT_VERSION_NUMBER record the change metadata and optimistic-locking token. ACTION_ID identifies the manual action associated with the change, and AUDIT_FIELD, UPDATED_ENTITY_CODE, and UPDATED_ENTITY_ID help classify what was modified.

The extensive set of CHANGE_* flags allows queries to filter only those audit rows where a particular attribute actually changed, rather than returning every historical snapshot.

Common Use Cases and Queries

The primary use case is change-history reporting for service requests: identifying who reassigned a request, when a status or severity changed, or whether resolution and close dates slipped. A typical pattern joins the audit table to its parent incident:

• SELECT a.incident_id, a.incident_audit_id, a.last_update_date, a.last_updated_by, a.incident_status_id, a.old_incident_status_id FROM cs.cs_incidents_audit_b a WHERE a.incident_id = :p_incident_id AND a.change_incident_status_flag = 'Y' ORDER BY a.last_update_date;
• Aging and SLA analysis can key on the OLD_ and current SLA_DATE_1 through SLA_DATE_6 columns together with CHANGE_SLA_DATE_*_FLAG, isolating requests whose SLA milestones were renegotiated.
• Ownership and routing audits commonly filter on CHANGE_INCIDENT_OWNER_FLAG or CHANGE_RESPONSIBLE_GROUP_FLAG to reconstruct reassignment histories for workload or escalation reporting.
• Because the table carries 466 columns, list specific columns in reporting SQL rather than selecting *, both for performance and to keep result sets readable.

Related Objects

The foreign-key relationships documented for this table identify its principal dependencies.

• CS_INCIDENTS_ALL_B via CS_INCIDENTS_AUDIT_B.INCIDENT_ID — the base (non-translated) incident hub that each audit row describes.
• CS_INCIDENT_STATUSES_B, CS_INCIDENT_TYPES_B, CS_INCIDENT_URGENCIES_B, and CS_INCIDENT_SEVERITIES_B via the corresponding INCIDENT_*_ID columns — reference tables resolving the audited classification values.
• CS_CP_REVISIONS via CP_REVISION_ID — ties the audited change to a customer-product revision context.
• CSS_DEF_LANGUAGES_B via LANGUAGE_ID and FND_SECURITY_GROUPS via SECURITY_GROUP_ID — standard language and Multi-Org security references.
• PSB_EMPLOYEES via EMPLOYEE_ID — the employee reference associated with the incident audit record.

These relationships confirm that the table functions as an attribute-rich history store hanging off the service request hub, consistent with its satellite-leaning classification.