Search Results confirm_seeded_data

Overview

AP_PURGE_PKG is a seeded Oracle Payables package that implements the purge and archive processing used by the Payables application in Oracle E-Business Suite 12.1.1 and 12.2.2. Its business purpose is to remove aged transaction data from the live Payables tables after that data has been summarized into history tables, thereby controlling table growth and preserving the record of closed accounting periods. The package body begins with private variable declarations such as g_purge_name, g_activity_date, g_category, g_organization_id and g_range_size, together with a set of status flags (g_chv_status, g_payables_status, g_purchasing_status, g_pa_status, g_assets_status, g_edi_status and g_mrp_status) that track which downstream applications are participating in the current purge run. Header information in the source references bug 5052748, which addressed SQLREP performance problems by introducing NO_UNNEST hints and explicit references to AP_INVOICES_ALL and AP_SYSTEM_PARAMETERS_ALL to force access paths and avoid full table scans on large tables. The package is classified as OTHER and is not referenced by any other package, which confirms that it is invoked directly rather than as a subordinate API.

Key Procedures and Functions

The ETRM metadata documents eight procedures and functions within the package. SET_PURGE_STATUS records the status of the purge process, driving the global status flags that coordinate the individual sub-processes. CHECK_NO_PURGE_IN_PROCESS validates that no conflicting purge run is currently active before processing begins. SEED_PURGE_TABLES populates the work tables used to stage identifiers for the current purge range. CREATE_SUMMARY_RECORDS builds the summarized history records from the live transaction data. CONFIRM_SEEDED_DATA verifies the seeded data — this is the routine most commonly located by the search term "confirm_seeded_data" — and corresponds to the confirmation step that must succeed before deletion is permitted. DELETE_SEEDED_DATA performs the actual removal of the confirmed rows from the live tables. ABORT_PURGE terminates a purge run that cannot or should not continue, and PURGE_ACCTG_AND_AP_TABLE removes the associated accounting and Payables entries. The Print helper procedure splits log messages into 80-character segments and writes them to the concurrent request log via FND_FILE.PUT_LINE.

Tables Accessed

The package operates against the major Payables transaction tables, all accessed through APPS synonyms. AP_INVOICES and AP_INVOICES_ALL hold invoice header data; AP_BATCHES and AP_BATCHES_ALL hold invoice batches; AP_CHECKS and AP_CHECKS_ALL hold payment documents; and AP_DOC_SEQUENCE_AUDIT holds document sequencing audit rows. AP_ENCUMBRANCE_LINES and AP_HOLDS provide encumbrance and hold detail. The history tables — AP_HISTORY_INVOICES, AP_HISTORY_INVOICES_ALL, AP_HISTORY_CHECKS, AP_HISTORY_CHECKS_ALL, AP_HISTORY_INVOICE_PAYMENTS and AP_HISTORY_INV_PAYMENTS_ALL — are the destinations written by CREATE_SUMMARY_RECORDS and read during the confirmation and deletion phases. Live rows are therefore summarized into history before CONFIRM_SEEDED_DATA and DELETE_SEEDED_DATA remove them from the transactional tables.

Usage Notes

AP_PURGE_PKG is a seeded, internal Payables package and is normally invoked through Oracle Payables concurrent programs rather than from custom code. The standard entry points are the Payables purge/archive concurrent programs executed from the Payables responsibility, which call the package to seed, summarize, confirm and delete transaction data for a selected purge range. Because the package is not referenced by other packages, its procedures should be treated as internal implementation and not called directly from user exits or custom extensions. Administrators should ensure no other purge process is running, since CHECK_NO_PURGE_IN_PROCESS gates execution, and should review the concurrent request log generated by the Print procedure, because Confirm Seeded Data failures will halt the run before any deletion occurs. In 12.2.2 the same structure applies, with ONLINE data access handled through the standard _ALL views and synonyms exposed to the APPS schema.