Search Results cs_hz_sr_contact_points_u2

Overview

CS.CS_HZ_SR_CONTACT_POINTS is a transactional table in the Oracle E-Business Suite Service (CS) schema that stores the contact points associated with a Service Request. Each row links a Service Request incident to a party (contact) and, optionally, to a specific contact point such as a phone number, fax number, or e-mail address. In effect, the table answers the question "who was involved in this service request, and through which contact channel were they reached?" It is a core component of the Service Request management data model and supports both inbound and outbound contact tracking.

Under the Data Vault classification heuristic supplied in the metadata, this object leans toward a satellite. It describes relationships between hubs (parties and incidents) and is versioned through standard Who columns and OBJECT_VERSION_NUMBER, but the presence of a composite business key (PARTY_ID, INCIDENT_ID) also gives it link-like characteristics. Modelers should treat it as a link-satellite hybrid depending on the warehouse design.

Key Information Stored

The table's surrogate primary key is SR_CONTACT_POINT_ID, and the unique index CS_HZ_SR_CONTACT_POINTS_U2 enforces it. A separate unique index (CS_HZ_SR_CONTACT_POINTS_UK1) constrains the composite of PARTY_ID and INCIDENT_ID, making that pair the primary business-key candidate.

• SR_CONTACT_POINT_ID – surrogate primary key uniquely identifying each contact-point row.
• PARTY_ID – foreign key to HZ_PARTIES; identifies the contact associated with the SR.
• INCIDENT_ID – foreign key to CS_INCIDENTS_ALL_B; identifies the Service Request.
• CONTACT_POINT_ID – foreign key to HZ_CONTACT_POINTS; the specific phone, fax, or e-mail record.
• CONTACT_POINT_TYPE – free-text classification such as PHONE or EMAIL.
• CONTACT_TYPE – classification of the party, for example PERSON or EMPLOYEE.
• PRIMARY_FLAG – marks the primary contact for the Service Request.
• PARTY_ROLE_CODE – foreign key to CS_PARTY_ROLES_B; role played by the contact.
• START_DATE_ACTIVE / END_DATE_ACTIVE – effective dating of the contact-point assignment.
• OBJECT_VERSION_NUMBER – optimistic locking control for HTML-based UI updates.
• SECURITY_GROUP_ID – foreign key to FND_SECURITY_GROUPS for hosted environments.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN – standard Who audit columns.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE – concurrent program markers identifying the batch that last updated the row.

Common Use Cases and Queries

Typical reporting and integration scenarios include listing all contacts for an incident, identifying the primary contact, and auditing which concurrent program modified a row. The supporting indexes (CS_HZ_SR_CONTACT_POINTS_N1 on PARTY_ID and N2 on INCIDENT_ID) allow efficient lookups in either direction.

Example: retrieve all contact points for a given Service Request.

• SELECT sr_contact_point_id, party_id, contact_point_type, contact_point_id, primary_flag FROM cs_hz_sr_contact_points WHERE incident_id = :incident_id ORDER BY primary_flag DESC;

Example: find all Service Requests on which a specific party is a contact.

• SELECT incident_id, contact_point_type, primary_flag FROM cs_hz_sr_contact_points WHERE party_id = :party_id AND NVL(end_date_active, SYSDATE) >= SYSDATE;

Example: audit rows last touched by a specific concurrent program.

• SELECT sr_contact_point_id, request_id, program_id, last_update_date FROM cs_hz_sr_contact_points WHERE program_id = :program_id;

Reporting use cases include agent productivity analysis (contact channel mix per SR), primary-contact verification for notification workflows, and data-quality checks for missing or duplicate contact points.

Related Objects

• CS_INCIDENTS_ALL_B – joined on INCIDENT_ID; the parent Service Request record. It also references this table via PRIMARY_CONTACT_ID.
• HZ_PARTIES – joined on PARTY_ID; the contact's master party record.
• HZ_CONTACT_POINTS – joined on CONTACT_POINT_ID; supplies the actual phone, fax, or e-mail value.
• CS_PARTY_ROLES_B – joined on PARTY_ROLE_CODE; defines the contact's role on the SR.
• FND_SECURITY_GROUPS – joined on SECURITY_GROUP_ID; relevant in hosted/multi-tenant deployments.
• CS_HZ_SR_CONTACT_PNTS_AUDIT – audit trail table referencing SR_CONTACT_POINT_ID for change history.
• FND_USER – implicit join on CREATED_BY / LAST_UPDATED_BY for user attribution.