Search Results modifiable_name

Overview

APPS.CSF_PO_CONTACT_POINTS_V is a supplementary database view in the Oracle E-Business Suite APPS schema, registered under FND Design Data as CSF.CSF_PO_CONTACT_POINTS_V. It exposes contact point information associated with service request incidents, presenting a denormalized projection of contact data drawn from the Service (CSF/CS) and Trading Community Architecture (HZ) data models. The view consolidates contact point records, party relationships, contact names, communication preferences, and lookup-derived display values into a single queryable interface.

Oracle explicitly classifies this object as a "supplementary view used to simplify forms coding" and warns that it is not intended for direct querying or data alteration, since its definition may change substantially across minor or major releases. Despite this caveat, the view remains a documented dependency for at least one packaged object, CSP_PICK_UTILS, indicating that Oracle's own forms and utilities reference it internally. Developers performing reporting or integration work against service request contact data should treat it as a stable-but-unsupported interface and validate behavior against the target release (12.1.1 or 12.2.2).

Underlying Base Objects

The view is defined over a set of APPS synonyms and views that map to core application tables. The primary Service foundation objects are CS_HZ_SR_CONTACT_POINTS, which stores the association between service request contact points and incident records, and CS_INCIDENTS_ALL_VL, the multi-language incident view supplying incident context. Trading Community Architecture objects include HZ_CONTACT_POINTS, HZ_PARTIES, and HZ_RELATIONSHIPS, which provide the contact point definitions, party identity, and party-to-party relationship structures. Person and assignment data are sourced from PER_ALL_PEOPLE_F, PER_ALL_ASSIGNMENTS_F, and PER_PHONES. Lookup decoding is performed against AR_LOOKUPS, CS_LOOKUPS, and HR_LOOKUPS.

Runtime context and security are supplied through the FND_GLOBAL package, while HR_API contributes derived columns, most notably CONTACT_NAME and CONTACT_COMM_PREF, which are computed through HR APIs rather than stored directly on a base table. This layered dependency chain explains the view's wide column footprint and its sensitivity to changes in the underlying HR and HZ schemas.

Key Columns

• SR_CONTACT_POINT_ID — Primary identifier for the service request contact point record.
• CONTACT_PARTY_ID and SUBJECT_PARTY_ID — Party identifiers for the contact and the subject of the interaction.
• INCIDENT_ID — Foreign reference to the service request incident in CS_INCIDENTS_ALL_VL.
• CONTACT_POINT_TYPE and CONTACT_POINT_ID — Classify and identify the underlying contact point (for example, phone, email, or web).
• PRIMARY_FLAG and DISPLAY_PRIMARY_FLAG — The stored primary designation and its formatted, lookup-resolved display equivalent. The DISPLAY_* columns exist specifically so that forms can present decoded values without additional client-side logic.
• CONTACT_TYPE, LOOKUP_MEANING, and DISPLAY_CONTACT_TYPE — Raw and decoded contact role values derived from the lookup views.
• CONTACT_NAME (VARCHAR2 391) and CONTACT_COMM_PREF (VARCHAR2 2081) — API-generated contact name and communication preference strings.
• RELATIONSHIP_ID, MODIFIABLE_TYPE, and MODIFIABLE_NAME — Relationship context and flags indicating whether the contact record can be modified.

Common Use Cases and Queries

The view is most commonly consumed to list contacts attached to a service request, to determine which contact is designated primary, and to render decoded contact type descriptions in reports and extensions.

SELECT sr_contact_point_id
     , incident_id
     , contact_party_id
     , contact_name
     , display_contact_type
     , display_primary_flag
  FROM apps.csf_po_contact_points_v
 WHERE incident_id = :p_incident_id
 ORDER BY display_primary_flag DESC;

To isolate the primary contact for a given incident:

SELECT contact_party_id
     , contact_name
     , contact_comm_pref
  FROM apps.csf_po_contact_points_v
 WHERE incident_id = :p_incident_id
   AND primary_flag = 'Y';

Because the view joins forms-oriented lookup and API logic, queries should always filter by INCIDENT_ID or CONTACT_PARTY_ID to avoid full scans, and any custom code should be re-tested during EBS patching or upgrades to 12.2.2, given Oracle's explicit non-support statement for direct access to supplementary views.