Search Results cs_hz_sr_contact_points_v




Overview

The CS_HZ_SR_CONTACT_POINTS_V view is an APPS-owned database object within the Service (CS) product family of Oracle E-Business Suite. It is documented as a backward-compatibility view created for the CS_HZ_SR_CONTACT_POINTS table. In the EBS 12.1.1 and 12.2.2 data models, Service Request contact point data was migrated into the Trading Community Architecture (TCA) / HZ (Oracle Customers Online) schema. Rather than exposing the raw HZ-backed structure to existing Service forms, reports, and integrations, Oracle retained this view as a stable interface so that pre-existing customizations and dependent code continue to resolve without modification.

The view is registered in APPS with a VALID status, confirming it is a synonym-backed access path rather than a physically distinct datastore. Its primary purpose is to present Service Request / party contact point relationships in the legacy column layout expected by historical Service reporting and integration code.

Underlying Base Objects

The documented ETRM metadata identifies a single referenced base object: the synonym CS_HZ_SR_CONTACT_POINTS. The view text performs a direct projection from that object, with two important filters applied at the view definition level:

  • PARTY_ROLE_CODE = 'CONTACT' — restricts returned rows to records whose party role is the standard contact role.
  • An effective-dating filter using START_DATE_ACTIVE and END_DATE_ACTIVE, compared against TRUNC(SYSDATE) with NVL defaults so that null start and end dates are treated as open-ended.

Because the view is a straightforward select over the base synonym with row-level filters, it inherits the base object's columns without transformation. Any DML against the view is controlled by the updatability of the underlying synonym, and administrators should treat the view as read-oriented for reporting purposes.

Key Columns

Common Use Cases and Queries

The view is typically queried to enumerate active contact points for a Service Request or party, to identify the primary contact, and to join Service Request data with TCA party information in custom reports and extracts.

Example — active contact points for a given incident:

  • SELECT sr_contact_point_id, party_id, contact_point_type, contact_type, primary_flag FROM apps.cs_hz_sr_contact_points_v WHERE incident_id = :incident_id;

Example — primary contacts by party:

  • SELECT party_id, contact_point_id, contact_type FROM apps.cs_hz_sr_contact_points_v WHERE party_id = :party_id AND primary_flag = 'Y';

Because the effective-dating predicate is embedded in the view, callers do not need to add date filters for point-in-time "active now" queries. When the search term involves party_role_code, note that this column will always evaluate to 'CONTACT' when queried through the view; use the base CS_HZ_SR_CONTACT_POINTS object if other role codes must be retrieved.