Search Results cs_hz_sr_contact_pnts_audit




Overview
Explore in AI Chat

Overview

The CS_HZ_SR_CONTACT_PNTS_AUDIT table is a Service (CS) module audit table owned by the CS schema. Its documented purpose is to maintain audit history for service request party role information, capturing the before-and-after state of contact point associations attached to a service request. In Oracle EBS 12.1.1 and 12.2.2, it sits alongside the transactional contact point tables and is populated as changes are made to service request party roles, providing an append-only historical trail of those modifications.

Under the heuristic Data Vault classification derived from its foreign key structure, this table is satellite-leaning. In Data Vault modeling terms it behaves as a satellite attached to the service request contact point hub/link: it is keyed on its own surrogate audit identifier, carries descriptive and state attributes with "OLD_" counterparts, and references a parent contact point record through a foreign key. This modeling suggestion is consistent with an audit or history store rather than an independent business entity.

Key Information Stored

The table is documented with 27 columns. The most significant are described below.

Distinguishing surrogate key from business key: only SR_CONTACT_POINT_AUDIT_ID is documented as both primary key and unique index candidate, so the business-key candidate list is effectively limited to this surrogate identifier; no composite natural business key is documented.

Common Use Cases and Queries

Typical usage centers on compliance, dispute resolution, and service desk reporting where the historical state of a service request contact point must be reconstructed. A common query pattern retrieves the full audit history for a given service request:

SELECT a.sr_contact_point_audit_id,
       a.sr_contact_point_id,
       a.party_id, a.old_party_id,
       a.primary_flag, a.old_primary_flag,
       a.party_role_code, a.old_party_role_code,
       a.contact_point_modified_on,
       a.contact_point_modified_by
FROM   cs_hz_sr_contact_pnts_audit a
WHERE  a.incident_id = :incident_id
ORDER  BY a.contact_point_modified_on;

Analysts may also detect role changes by comparing current and prior values, for example filtering rows where party_role_code <> old_party_role_code or where primary_flag <> old_primary_flag. Reporting use cases include auditing reassignment of primary contacts, tracking party role transitions over time, and producing a "who changed what, and when" history for a specific contact point joined back to CS_HZ_SR_CONTACT_POINTS.

Related Objects

  • CS_HZ_SR_CONTACT_POINTS — the parent transactional table; joined via SR_CONTACT_POINTS.SR_CONTACT_POINT_ID = CS_HZ_SR_CONTACT_PNTS_AUDIT.SR_CONTACT_POINT_ID. This is the only foreign key relationship documented for the audit table.
  • CS_HZ_SR_CONTACT_PNTS_AUDIT primary key constraint CS_HZ_SR_CONT_PNTS_AUDIT_PK and unique index CS_HZ_SR_CNT_PNTS_AUDIT_U1, both on SR_CONTACT_POINT_AUDIT_ID.
  • HZ_PARTIES / HZ_PARTY_ROLES — referenced indirectly through PARTY_ID and PARTY_ROLE_CODE and their OLD_ counterparts to resolve party names and role descriptions for reporting.
  • CS_INCIDENTS (service request header) — joined through INCIDENT_ID to relate audit rows to the service request itself.
  • Related Service module history/audit tables (for example other CS audit tables keyed on INCIDENT_ID and PARTY_ID) provide parallel audit coverage for adjacent entities and are commonly reported together.

These relationships, grounded in the documented FK data, allow the audit table to be joined to its transactional parent for point-in-time reconstruction of service request party role changes.