Search Results cs_sr_incident_address_v




Overview
Explore in AI Chat

Overview

The CS_SR_INCIDENT_ADDRESS_V view is an APPS-owned database view in the Oracle E-Business Suite Service (CS) module. It presents the formatted address of the contacts associated with a service request, consolidating location, party site, and party information into a single queryable object. The view is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2 and resides in the APPS schema. Its purpose is to supply a human-readable, denormalized address record that can be joined to service request data without requiring the report or integration layer to resolve the underlying Oracle Trading Community Architecture (TCA) relationships manually.

Because it joins the TCA party model to the location model, the view is especially useful in service request reporting, customer correspondence, field service dispatch, and any integration that must resolve the primary address of a contact tied to an incident. The presence of the LOCATION_TYPE_CODE column allows consumers to distinguish whether a row originates from a standalone location record or from a party site association.

Underlying Base Objects

The view is defined over the TCA synonyms HZ_LOCATIONS, HZ_PARTY_SITES, and HZ_PARTIES. Documentation also lists HZ_CONTACT_POINTS among the referenced base objects for the 12.2.2 metadata; however, the view text itself does not select from that synonym directly, and its inclusion reflects the broader contact data model from which the view draws.

The joins are constructed with outer joins on party site status, party site location, and party status, ensuring that a location row can still be returned even when no active party site or party exists. This design permits the view to expose address data for orphaned or unassociated locations, which is significant for service requests whose contact has not been fully provisioned in TCA. The view therefore behaves as a left-outer-join composite across the three principal TCA tables.

Key Columns

  • ADDRESS — Concatenation of ADDRESS1 through ADDRESS4, with semicolons inserted as separators when address lines two through four are populated.
  • CITY, STATE, COUNTRY, PROVINCE, POSTAL_CODE, COUNTY — Standard geographic address attributes sourced from HZ_LOCATIONS.
  • LOCATION_ID — Resolves to HZ_PARTY_SITES.PARTY_SITE_ID when a party site exists; otherwise falls back to HZ_LOCATIONS.LOCATION_ID.
  • LOCATION_TYPE_CODE — A derived discriminator returning 'HZ_PARTY_SITE' when a party site ID is present, or 'HZ_LOCATION' when it is not. This column is the key indicator of which TCA entity the LOCATION_ID references, and it is frequently used to filter or pivot service request address data.
  • PARTY_ID, PARTY_NAME, PARTY_TYPE — Identity attributes of the party associated with the contact address, taken from HZ_PARTIES.

Common Use Cases and Queries

The view is typically used to enrich service request queries with address detail. A common pattern joins the view to CS_INCIDENTS_ALL or related incident tables by location or party identifiers, and filters on LOCATION_TYPE_CODE when only party-site addresses are required.

SELECT v.PARTY_NAME,
       v.ADDRESS,
       v.CITY,
       v.STATE,
       v.POSTAL_CODE,
       v.LOCATION_TYPE_CODE
FROM   APPS.CS_SR_INCIDENT_ADDRESS_V v
WHERE  v.LOCATION_TYPE_CODE = 'HZ_PARTY_SITE'
ORDER  BY v.PARTY_NAME;

Other scenarios include generating correspondence labels, validating dispatch destinations for field service, and feeding CRM or data-warehouse extracts. When the metadata is limited, developers should verify join keys against the specific service request tables in their release, since the view itself carries no incident foreign key and must be linked through party or location identifiers.