Results for “party_cont”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CS_SR_SEARCH_V is an APPS-owned database view within the Oracle E-Business Suite Service (CS) module. Its documented purpose is to support the Service Request (SR) Find window, specifically the "Bali" spread table used by the SR search interface in release 12.1.1 and 12.2.2. The view consolidates service request header data from a primary incident table with descriptive lookup values, contact point information, and party-related attributes so that the SR search results region can render a denormalized, user-friendly result set without requiring the calling form to join multiple tables at runtime.

Because it exposes the incident record together with decoded type, severity, status, and urgency names, the view functions as a reporting and integration convenience object. It can be queried directly by custom reports, concurrent programs, or interface logic that needs SR details in a flattened form. The view inherits the standard WHO audit columns (creation and update information) and the multi-org ORG_ID column, reflecting the underlying incident structure.

Underlying Base Objects

According to the ETRM metadata, the view is defined over a set of synonyms, views, and a package. The principal driving object is CS_INCIDENTS_ALL_TL, which supplies the incident header, translated summary text, and most of the incident-level columns. Related translated lookup tables provide decoded names: CS_INCIDENT_TYPES_TL, CS_INCIDENT_SEVERITIES_TL, CS_INCIDENT_STATUSES_TL, and CS_INCIDENT_URGENCIES_TL. Each of these is joined using the corresponding ID and the runtime language returned by USERENV('LANG').

Contact and party information is sourced from HZ_CONTACT_POINTS, HZ_PARTIES, HZ_CUST_ACCOUNTS, HZ_TIMEZONES, and CS_HZ_SR_CONTACT_POINTS, which link the service request to customer contacts. Additional supporting objects include CS_INCIDENTS_B_SEC (a secured view on incidents), CS_LOOKUPS, FND_LOOKUP_VALUES, MTL_SYSTEM_ITEMS_KFV for inventory item descriptions, JTF_RS_GROUPS_VL for resource group information, and the FND_GLOBAL package for session and organizational context. The HZ_PARTIES relationship is directly relevant to the "party_cont" search term, as party and contact attributes are exposed through the contact point joins.

Key Columns

The view exposes the full incident identifier set. INCIDENT_ID and INCIDENT_NUMBER uniquely identify the service request, while ORG_ID scopes it to an operating unit. Status, type, severity, and urgency are represented both as IDs and as decoded names (STATUS_CODE, INCIDENT_TYPE, SEVERITY, URGENCY). SUMMARY carries the human-readable incident summary from the translation table. PROBLEM_CODE and RESOLUTION_CODE support categorization and resolution reporting.

Customer and location context is provided through CUSTOMER_PRODUCT_ID, INVENTORY_ITEM_ID, SHIP_TO_SITE_USE_ID, SHIP_TO_CONTACT_ID, BILL_TO_SITE_USE_ID, BILL_TO_CONTACT_ID, and INSTALL_SITE_USE_ID. These columns connect the SR to the party and contact data referenced by the search. Date columns include INCIDENT_DATE, EXPECTED_RESOLUTION_DATE, and ACTUAL_RESOLUTION_DATE. Fifteen generic INCIDENT_ATTRIBUTE_1 through INCIDENT_ATTRIBUTE_15 columns plus INCIDENT_CONTEXT allow extensible descriptive flexfield data to be surfaced. Audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE) and RECORD_IS_VALID_FLAG complete the projection.

Common Use Cases and Queries

The most direct use case is reproducing the SR Find window result set, for example searching by incident number, status, or party-related contact. A representative query selecting core fields might read:

• SELECT incident_number, summary, status_code, incident_type, severity, urgency FROM cs_sr_search_v WHERE org_id = :p_org_id;
• SELECT incident_number, incident_date, ship_to_contact_id FROM cs_sr_search_v WHERE incident_number = :p_number;
• SELECT s.incident_number, s.summary FROM cs_sr_search_v s WHERE s.incident_attribute_1 = :p_value;

Because the view already resolves translated lookup names and joins party/contact context, it is well suited to custom SR dashboards, data extracts for integration, and ad hoc analysis of open incidents by severity or urgency. When searching on party or contact terms such as "party_cont," developers typically join the view back to HZ_PARTIES or the contact point tables using the exposed site and contact IDs, since the view itself carries the identifiers rather than full party name text. The view should be treated as read-only reporting infrastructure and not as a target for DML.