Search Results insert_single_hold




Overview

APPS.AP_HOLDS_PKG is the PL/SQL package that encapsulates the insert, update, delete, and locking logic for hold records stored in the Oracle Payables hold tables. In Oracle EBS 12.1.1 and 12.2.2, holds are used to prevent payment, posting, or further processing of invoices that fail validation, match tolerance, or manual review criteria. Rather than manipulating the underlying tables directly, the Payables application and its forms invoke procedures in this package, ensuring that the correct base table, the appropriate multi-org views, and the DML-enabled security columns are maintained consistently. The package is declared AUTHID CURRENT_USER, meaning it executes with the privileges of the calling user, and it is classified in ETRM as an OTHER API rather than a fully supported public API. The source header indicates a long-maintained code line, reflecting its role as an internal table-handler layer used by the Payables hold maintenance screens. The package exposes seven documented entry points covering row-level data maintenance, single-hold placement, single-hold release, and a convenience routine for releasing multiple holds on an invoice.

Key Procedures and Functions

  • INSERT_ROW — The table-handler insert routine for AP_HOLDS. It accepts the full set of hold columns, including the invoice identifier, the line location identifier, the hold lookup code, hold date, held-by, reason, status flag, the release columns, the descriptive flexfield attribute columns, ORG_ID, and the calling sequence. It returns the generated hold identifier and rowid.
  • LOCK_ROW — Acquires a row-level lock on an existing AP_HOLDS record and verifies that none of the supplied column values have changed since the caller last read the row. This prevents lost updates when the hold maintenance form is saved.
  • UPDATE_ROW — Updates an existing hold record identified by rowid, applying the supplied column values. Used when a hold's status, release information, or descriptive attributes change.
  • DELETE_ROW — Removes a hold record identified by rowid, used when a hold is purged or cleared.
  • INSERT_SINGLE_HOLD — Places a single hold against an invoice using the hold lookup codes defined in AP_HOLD_CODES. It is the routine of primary interest to callers who need to apply one hold programmatically rather than through the form.
  • RELEASE_SINGLE_HOLD — Releases one previously applied hold on an invoice, updating the status flag and release-related columns.
  • QUICK_RELEASE — Provides a streamlined release operation intended to release holds in bulk circumstances without the full validation path of the single-release routine.

Tables Accessed

  • AP_HOLDS / AP_HOLDS_ALL / AP_HOLDS_S — The base hold table and its multi-org and security variants. These store the hold records the package inserts, updates, locks, and deletes.
  • AP_HOLD_CODES — The hold code definition table, consulted to validate hold lookup codes and derive hold behavior.
  • AP_INVOICES / AP_INVOICES_ALL — The invoice header tables, referenced to associate a hold with the correct invoice and to drive release logic.
  • AP_INVOICE_DISTRIBUTIONS — The distribution table, referenced when holds apply at the line location level.
  • DUAL — Used for single-row selection of values such as sequence-based identifiers and system values.
  • PLITBLM — The standard Oracle Forms/PL/SQL table of varchars used to pass multi-row key information to the form block handler.

Usage Notes

AP_HOLDS_PKG is invoked primarily by the Oracle Payables hold maintenance form, where the AP_HOLDS block handler calls INSERT_ROW, LOCK_ROW, UPDATE_ROW, and DELETE_ROW in response to user actions. INSERT_SINGLE_HOLD, RELEASE_SINGLE_HOLD, and QUICK_RELEASE are the calls most relevant to custom code, particularly release workflows and integrations that place or clear invoice holds without opening the form. Because the package is classified as OTHER rather than a supported public API, callers should treat the signatures as subject to change between releases and prefer a supported API where one exists. When invoking any procedure directly, custom code must supply ORG_ID, CREATED_BY, LAST_UPDATED_BY, login, and date columns correctly, and should pass a meaningful calling sequence to aid diagnosis. The package is referenced by four other packages, indicating it also serves as a shared low-level hold handler within the Payables schema. Testing any direct call in a non-production environment is strongly advisable.