Search Results chv_purge_schedule_list




Overview
Explore in AI Chat

Overview

The CHV_PURGE_SCHEDULE_LIST table is a core data object within the CHV (Supplier Scheduling) product family of Oracle E-Business Suite, owned by the PO schema. As its description indicates, it serves as a repository of "supplier schedule candidates for purge" — that is, it identifies supplier scheduling records that have been flagged or are eligible for archival or deletion processing. In the broader CHV architecture, this table acts as a staging or control list used by concurrent purge programs to select and subsequently process schedule items that are no longer required for active planning.

The table is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2, and contains seven physical columns in the 12.2.2 physical schema. Its primary key is the CHV_PURGE_SCHEDULE_LIST_PK, defined on the SCHEDULE_ITEM_ID column. From a Data Vault modeling perspective, the heuristic classification supplied in the metadata is standalone. This suggests that the table does not exhibit the foreign-key dependencies typically associated with hub, link, or satellite constructs; rather, it functions as an independent control or staging structure whose lifecycle is governed by concurrent purge requests rather than by direct transactional relationships to master data.

Key Information Stored

The table stores a minimal but purposeful set of columns supporting the purge process. The most significant include:

  • SCHEDULE_ITEM_ID — The surrogate primary key and the sole unique-indexed column (CHV_PURGE_SCHEDULE_LIST_U1). It is also the business-key candidate that links this purge list to the schedule items it targets.
  • PURGE_NAME — A descriptive identifier for the purge run or batch, enabling differentiation between multiple purge campaigns.
  • DOUBLE_CHECK_FLAG — A control flag used to indicate whether a record requires secondary verification before removal, safeguarding against premature deletion of active schedules.
  • REQUEST_ID — The concurrent request identifier that created or processed the purge entry, providing traceability back to the submitting concurrent program.
  • PROGRAM_APPLICATION_ID — The application owning the concurrent program responsible for the record.
  • PROGRAM_ID — The specific concurrent program definition that generated the entry.
  • PROGRAM_UPDATE_DATE — The timestamp of the last programmatic update, used for audit and aging analysis.

The surrogate key (SCHEDULE_ITEM_ID) should be distinguished from the surrogate nature of the row itself; the unique index confirms it as the definitive business key candidate for this purge list.

Common Use Cases and Queries

Typical usage centers on administering and auditing supplier schedule purge operations. A DBA or developer may query the table to determine which schedule items are queued for purge, or to correlate purge activity with specific concurrent requests. For example:

  • Identifying all schedule items flagged for purge in a given run:
    SELECT SCHEDULE_ITEM_ID, PURGE_NAME, DOUBLE_CHECK_FLAG FROM CHV_PURGE_SCHEDULE_LIST WHERE PURGE_NAME = :p_name;
  • Auditing concurrent program activity:
    SELECT REQUEST_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE FROM CHV_PURGE_SCHEDULE_LIST WHERE PROGRAM_UPDATE_DATE > SYSDATE - 30;
  • Cross-referencing purge candidates with downstream schedule tables to validate eligibility before deletion.

Reporting use cases include purge history analysis, flag verification for records requiring double-check, and reconciliation of purge lists against active supplier schedules to prevent inadvertent removal of live data.

Related Objects

The metadata documents several tables that reference CHV_PURGE_SCHEDULE_LIST via the SCHEDULE_ITEM_ID column, forming the functional context for purge processing:

These relationships allow purge candidates to be validated against the actual schedule records they reference, ensuring that only obsolete items are removed. Administrators should also consider the concurrent programs in the CHV/PO modules that populate and consume this table, as well as any archival or purging APIs invoked through the standard concurrent manager interface.