Search Results hz_staged_party_sites

Overview

The HZ_STAGED_PARTY_SITES table is a core data object within the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 architecture, specifically owned by the Receivables (AR) module. Its primary function is to serve as a staging repository for party site information before it is processed by the Data Quality Management (DQM) engine. DQM is a critical component of the Trading Community Architecture (TCA) responsible for cleansing, standardizing, and deduplicating customer, supplier, and other party data. This table acts as a temporary holding area, allowing for the validation and correction of address and location details associated with a party before they are formally integrated into the master TCA tables, thereby ensuring the integrity and quality of the enterprise's master data.

Key Information Stored

While the provided metadata does not list specific columns, the table's description indicates it stores staged party site information. Based on its role in DQM and standard TCA patterns, this table typically contains columns mirroring those in the primary TCA party site table (HZ_PARTY_SITES), but with staging-specific attributes. Key data likely includes the staged party site identifier, a reference to the parent staged party record, address lines (address1-4), city, state, postal code, country, location details, and contact information. Crucially, it will contain status columns to track the DQM processing state (e.g., PENDING, PROCESSED, ERROR) and columns linking back to the original source transaction or import batch that generated the staged data.

Common Use Cases and Queries

The primary use case revolves around DQM operations and data migration. During bulk imports of customer data via interfaces like the Customer Interface, address records are often inserted into HZ_STAGED_PARTY_SITES for DQM processing before becoming active sites. Common queries involve monitoring the staging queue and troubleshooting. For instance, to review pending staged party sites, a query might be: SELECT staged_party_site_id, party_id, address1, city, country, status FROM hz_staged_party_sites WHERE status = 'PENDING';. Another typical query joins to the staged parties table to get a comprehensive view: SELECT sp.party_name, sps.address1, sps.city FROM hz_staged_parties sp, hz_staged_party_sites sps WHERE sp.staged_party_id = sps.staged_party_id;. Reporting use cases focus on analyzing DQM match results, error rates for address validation, and the volume of data flowing through the staging process.

Related Objects

HZ_STAGED_PARTY_SITES is intrinsically linked to other staging and master TCA tables. As per the provided metadata, it has a foreign key relationship to HZ_ORG_CONTACTS via the ORG_CONTACT_ID column, linking staged site data to organization contact records. Its most direct relationship is with HZ_STAGED_PARTIES, which holds the parent staged party record. It is the staging counterpart to the master table HZ_PARTY_SITES. Data is typically moved from this staging table to the master tables via DQM APIs and processes, such as those in the HZ_DQM_SYNC package. For reporting, views like HZ_STAGED_PARTY_SITES_VL may provide translated descriptions.