Results for “hz_party_stage”

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

Overview

The APPS.HZ_PARTY_STAGE package is a member of the Oracle Trading Community Architecture (TCA) staging infrastructure within Oracle E-Business Suite Release 12.1.1 and 12.2.2. Its principal business function is to move bulk party, party site, contact, and contact point data from external source systems into the Registry staging tables, where the data is cleansed, deduplicated, and subsequently propagated into the operational TCA entities. The package is the orchestration layer that drives the "stage, clean, and load" pipeline for high-volume customer, supplier, and contact imports.

The source header identifies the package as HZ_PARTY_STAGE with the AUTHID CURRENT_USER clause, meaning it executes with the privileges of the invoking user rather than the definer. The revision tag 115.11 2002/12/05 confirms long-standing stability across the 12.x code line. A prominent declaration is the PARTY_STAGE_REC_TYPE record, which contains PARTY_ID, STATUS, and a very large set of generic character columns (TX1 through well beyond TX74). This wide, denormalized record type is characteristic of staging utilities that must accommodate arbitrary source-system attribute layouts mapped into positional columns.

Key Procedures and Functions

• STAGE — The primary entry point. It initiates the staging run for the parties and related records identified for import, coordinating the validation, insertion, and status-tracking activities that populate the HZ_STAGED_* tables.
• STAGE_WORKER — The worker routine invoked by the stage process, typically as a parallel child job. It performs the per-record staging work, allowing large imports to be split across parallel updates for throughput.
• STAGE_CREATE_INDEX — Builds supporting indexes on the staging tables and the Oracle Text index infrastructure required for fuzzy matching and deduplication of staged names and addresses.
• GENERATE_MAP_PKG_NOLOG — Generates supporting mapping package or index artifacts while suppressing redo logging, which reduces redo generation during large, rerunnable staging operations.

Tables Accessed

The package touches a combination of staging, operational, and configuration tables. Staging destinations include HZ_STAGED_PARTIES, HZ_STAGED_PARTY_SITES, HZ_STAGED_CONTACTS, and HZ_STAGED_CONTACT_POINTS, which hold unvalidated supplier data. HZ_PARTIES and HZ_DQM_SYNC_INTERFACE provide the operational and synchronization targets, while HZ_DQM_STAGE_LOG records staging outcomes. Configuration and reference data are read from HZ_TRANS_ATTRIBUTES_B, HZ_TRANS_FUNCTIONS_B, and HZ_WORD_REPLACEMENTS, the latter supporting noise-word elimination during matching. Infrastructure dependencies include AD_CTX_DDL, CTX_DDL, AD_PARALLEL_UPDATES, FND_CONCURRENT_REQUESTS, and FND_PRODUCT_INSTALLATIONS for text index creation, parallel worker scheduling, concurrent request tracking, and product registration checks.

Usage Notes

HZ_PARTY_STAGE is normally invoked indirectly. The DQM staging concurrent programs and the customer or contact import interfaces call it to prepare staged data before the TCA batch loader promotes records into HZ_PARTIES. Because the package depends on Oracle Text DDL and parallel update metadata, it must execute in an environment where these components are installed and the text indexes are not locked by competing DML. The AUTHID CURRENT_USER model requires that the executing account hold direct privileges on the CTX_DDL and AD_CTX_DDL packages. Referenced by thirty-nine other packages, it is a shared utility rather than a public interface; custom integrations should prefer the supported DQM APIs and concurrent programs over direct calls to STAGE_WORKER or GENERATE_MAP_PKG_NOLOG.