Search Results party_relationship




Overview
Explore in AI Chat

Overview

APPS.CSD_INCIDENTS_NON_SEC_V is a reporting and integration view in Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 that exposes service request (incident) data from the CRM/TeleService schema without applying the row-level security clauses that constrain the underlying transactional view CS_INCIDENTS_ALL_VL. It is part of the CSD (Customer Service/Depot Repair) object family and predates the Service Request Management and Knowledge Management (CS/CSM) schema consolidation in Release 12. Because it omits the security predicate, it is used internally by concurrent programs, workflow, and diagnostic queries where the caller must already hold unrestricted access, or where data must be joined across organizations.

The view flattens a service request into a single denormalized row combining incident header attributes, item and product revision context, caller identity, and caller contact information. It resolves lookup codes to meanings and formats telephone numbers for display, making it convenient for direct report and interface consumption. Users searching for party_relationship typically encounter this view because caller and contact details are resolved through the TCA party model (HZ_PARTIES, HZ_RELATIONSHIPS, HZ_CONTACT_POINTS) rather than through the legacy customer tables, so any querying of caller identity against a party relationship traverses the HZ joins embedded here.

Underlying Base Objects

The view is defined over a mix of transactional base tables, public synonyms, and _VL (translated) views. Documented base objects include:

The presence of HR_SECURITY and FND_GLOBAL is significant: although the view is "non-secured" relative to service request security, it still resolves the caller and owner through HR person name APIs and TCA party relationships, so row visibility for person records may depend on HR security profiles in the underlying joins.

Key Columns

Common Use Cases and Queries

The view is appropriate for cross-organization reporting, data migration extraction, and diagnostics where the standard secured incident view returns incomplete results. A typical query selects open incidents with caller and item context:

  • SELECT incident_number, caller, cust_phone, item, item_desc, org_id FROM apps.csd_incidents_non_sec_v WHERE record_is_valid_flag = 'Y' AND incident_status_id NOT IN (SELECT incident_status_id FROM apps.csd_incidents_non_sec_v WHERE UPPER(status) LIKE 'CLOSED%');
  • Joining to HZ_RELATIONSHIPS to locate the party relationship linking a caller to an account: SELECT v.incident_number, v.caller, r.relationship_code, r.subject_id, r.object_id FROM apps.csd_incidents_non_sec_v v, hz_relationships r WHERE v.incident_owner_id = r.subject_id AND r.relationship_code = 'CONTACT_OF' AND v.org_id = :p_org_id;
  • Extracting incidents by item for install base analysis: SELECT v.incident_number, v.item, v.item_desc, v.inv_item_revision, c.instance_id FROM apps.csd_incidents_non_sec_v v, csi_item_instances c WHERE v.customer_product_id = c.instance_id;

Because the view bypasses service request security, use it only in trusted reporting contexts and always constrain by ORG_ID and valid-record flags. For end-user inquiries, prefer the secured CS_INCIDENTS_ALL_VL view so that TCA and HR security semantics remain enforced through HZ_RELATIONSHIPS and HR_SECURITY.