Search Results hz_party_site




Overview

The view APPS.CS_SR_INCIDENT_ADDRESS_V is a service-oriented database view used within Oracle E-Business Suite Release 12.1.1 and 12.2.2. It presents consolidated address and party information associated with incidents and service requests handled through the TeleService and Service Request Manager modules. The view assembles a human-readable address string alongside location, party, and party site identifiers, providing a denormalized presentation layer over the TCA (Trading Community Architecture) model. It is intended for incident-related reporting and integration, allowing developers and report authors to retrieve address details without directly navigating the multi-table relationships of the HZ schema. The view also normalizes the distinction between a standalone location and a party site by returning a location type code that indicates which identifier applies.

Underlying Base Objects

The view is defined over three primary TCA tables referenced through APPS synonyms: HZ_LOCATIONS, HZ_PARTY_SITES, and HZ_PARTIES. The documented metadata also lists HZ_CONTACT_POINTS as a referenced base object synonym, which reflects the broader dependency footprint of the service request address model. The joins are implemented as outer joins, with the party site, location, and party status filters all applied with the (+) operator so that location records are retained even when no active party site or party is present. The relationship chain is location to party site via location_id, and party site to party via party_id, with active status ('A') enforced on both party sites and parties. The view therefore returns one row per location, enriched with party site and party context where it exists.

Key Columns

  • address — A concatenated address line built from address1 through address4, with lines 2 to 4 separated by semicolons when present; a DECODE suppresses separators for null components.
  • city, state, province, postal_code, county, country — Standard location attributes sourced from HZ_LOCATIONS.
  • location_id — A DECODE that returns the party_site_id when available, otherwise the underlying location_id. This makes the column a unified identifier for either a party site or a raw location.
  • location_type_code — A DECODE returning 'HZ_PARTY_SITE' when a party_site_id exists, or 'HZ_LOCATION' when it does not. This discriminator tells the consumer how to interpret location_id.
  • party_id, party_name, party_type — Party identity attributes from HZ_PARTIES, populated only when an active party site and party are linked.

Common Use Cases and Queries

This view is typically used to display and validate incident addresses, to resolve the party or party site behind a service request location, and to produce address listings for customer service reporting. A representative query retrieves all active party site addresses for a given party:

  • SELECT location_id, location_type_code, address, city, state, postal_code, party_name FROM apps.cs_sr_incident_address_v WHERE party_id = :p_party_id ORDER BY city;
  • SELECT location_id, address, party_name FROM apps.cs_sr_incident_address_v WHERE location_type_code = 'HZ_PARTY_SITE' AND postal_code = :p_zip;
  • SELECT party_type, COUNT(*) FROM apps.cs_sr_incident_address_v GROUP BY party_type;

Because the view relies on outer joins, consumers should test for null party_id and party_name values, which indicate a location not currently linked to an active party site or party. Queries against the concatenated address column are best suited to display rather than exact-match filtering, since formatting characters are embedded in the string.