Search Results csd_party_sites_v




Overview
Explore in AI Chat

Overview

The CSD_PARTY_SITES_V view is a reporting and integration object owned by the APPS schema in Oracle E-Business Suite, delivered as part of the CSD (Depot Repair) product family. It exposes a denormalized, read-only projection of party site and address information sourced from the Oracle Trading Community Architecture (TCA) tables, allowing Depot Repair and downstream reporting components to retrieve location and site details through a single, convenient interface.

Because TCA models party addresses across multiple normalized tables — party sites, site uses, and locations — consumers that simply need a flattened address-and-site record would otherwise be forced to write multi-table joins. CSD_PARTY_SITES_V encapsulates that join logic, presenting party site attributes, site use attributes, and location/address attributes in one row per party site/use combination. The view is marked VALID and is defined with a standard outer join on the party site use, meaning a party site row is retained even when no corresponding site use exists.

In EBS 12.1.1 and 12.2.2, the object retains the same APPS ownership and structure, since TCA remains the underlying data model in both releases. This view is therefore relevant for customers performing upgrades and for developers building concurrent programs, OAF pages, or ad-hoc extracts against Depot Repair data.

Underlying Base Objects

The documented definition joins three TCA base objects, all referenced through synonyms in the APPS schema:

  • HZ_PARTY_SITES (alias A) — the primary entity, supplying the party site identity, numbering, and descriptive attributes.
  • HZ_PARTY_SITE_USES (alias B) — the site use layer, joined via a left outer join on PARTY_SITE_ID, supplying the purpose for which a site is used (for example, billing, shipping, or receiving).
  • HZ_LOCATIONS (alias C) — the address layer, joined on LOCATION_ID, supplying the formatted address components and location-level flags.

The join predicates are strictly A.LOCATION_ID = C.LOCATION_ID and A.PARTY_SITE_ID = B.PARTY_SITE_ID(+). Because of the outer join on site uses, a single party site can appear multiple times where several site uses exist, or once with null site use columns where none is defined. This cardinality behavior is important when consumers aggregate or count records returned by the view.

Key Columns

The view exposes identifiers, TCA descriptive columns, and a comprehensive set of WHO/audit columns. Notable columns include:

Common Use Cases and Queries

Typical use cases include integrating Depot Repair with customer address data, producing address extracts for reporting, and validating site usage during repair order processing. A common query retrieves all sites for a given party with their primary usage type:

  • Filtering by PARTY_ID to list every site and address for a customer.
  • Filtering by SITE_USE_TYPE (for example, 'SHIP_TO') to isolate shipping locations.
  • Restricting on VALIDATED_FLAG or SITE_STATUS to return only active, validated addresses.
  • Joining back to HZ_PARTIES on PARTY_ID to combine party names with site details.

Sample SQL:

SELECT party_site_id, party_site_number, site_use_type, address1, city, state, postal_code
FROM apps.csd_party_sites_v
WHERE party_id = :p_party_id
  AND (site_use_type = 'SHIP_TO' OR site_use_type IS NULL)
ORDER BY primary_per_type DESC, party_site_number;

Because of the outer join and multi-use cardinality, consumers should apply DISTINCT or aggregate functions when a one-row-per-site result is required.