Search Results purge_batch

Overview

The APPS.HZ_IMP_PURGE_PKG package is a utility package within the Oracle E-Business Suite Trading Community / Customer (HZ) module that manages the removal of staged bulk-import data. Its single documented entry point, Purge_Batch, allows an administrator or concurrent program to delete all interface rows that were loaded for a specific import batch identifier. After bulk customer, contact, address, and classification data has been successfully imported into the base HZ tables, the staging rows in the HZ_IMP_* interface tables become obsolete; the purge package provides the controlled cleanup of that residual data.

The package is declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the invoker. The header comment identifies the source as ARHLPRGS.pls (version 115.2), placing it within the Receivables/Trading Community import program family. Its API classification is documented as OTHER, distinguishing it from the standard public HZ APIs, since it is intended for internal maintenance rather than third-party integration.

Key Procedures and Functions

• PURGE_BATCH — The single documented procedure in this package. It performs the batch-level purge operation, removing the interface records associated with the supplied batch. It returns the standard concurrent-program output parameters (errbuf and retcode) so it may be hosted either inside a concurrent program or called from other PL/SQL. The batch identifier is passed in as P_BATCH_ID.

The signature exposes a single business input (the batch identifier) plus the conventional OUT error and return-code parameters. No additional public procedures or functions are documented for the package; the HZ import process is otherwise handled by separate loader and importer packages, while this package is dedicated solely to post-import cleanup.

Tables Accessed

The package reads and writes the HZ_IMP_* staging tables, accessed through APPS synonyms. The documented set spans the principal customer-import record types:

• HZ_IMP_ADDRESSES_INT and HZ_IMP_ADDRESSES_SG — staged address interface and its surrogate/processed staging counterpart.
• HZ_IMP_ADDRESSUSES_INT and HZ_IMP_ADDRESSUSES_SG — address-use (purpose) records for each imported location.
• HZ_IMP_CONTACTS_INT and HZ_IMP_CONTACTS_SG — contact person interface and staging rows.
• HZ_IMP_CONTACTPTS_INT and HZ_IMP_CONTACTPTS_SG — contact point (phone, e-mail, URL) interface and staging rows.
• HZ_IMP_CONTACTROLES_INT and HZ_IMP_CONTACTROLES_SG — contact-to-customer role assignments.
• HZ_IMP_CLASSIFICS_INT and HZ_IMP_CLASSIFICS_SG — customer and contact classification (category) assignments.
• HZ_IMP_CREDITRTNGS_INT and HZ_IMP_CREDITRTNGS_SG — credit-rating interface and staging rows.
• HZ_IMP_BATCH_SUMMARY — the batch header/summary record that ties each staging row to its originating batch; this is the key table used to scope the deletion.

The _INT suffixed tables hold raw incoming data, while the _SG (surrogate) tables hold processed staging rows populated during the import run. Purging by batch removes rows from both families as well as the batch summary entry itself. The package is referenced by one other package, confirming it is called as part of the broader HZ import processing chain rather than standing alone.

Usage Notes

HZ_IMP_PURGE_PKG.Purge_Batch is typically invoked as a concurrent program, which is why it exposes errbuf and retcode. In a 12.1.1 or 12.2.2 environment, an administrator submits the purge with a specific batch identifier after the corresponding HZ import batch has completed and been reconciled. It may also be called from custom PL/SQL, another packaged API, or a wrapper program that iterates over multiple batches to reclaim interface storage and reduce the volume of stale records scanned by subsequent imports.

Because the procedure deletes staging data permanently, it should be invoked only when the batch has been fully processed and verified. No commit or rollback semantics are documented here; the calling program is responsible for transaction control. As a non-public utility package it is subject to change between releases, so customizations relying on it should be tested during upgrades.