Search Results insert_hold

Overview

IGI_AP_CANCEL_PKG is an Oracle Application Object Library package body owned by the APPS schema that provides the cancellation engine for Oracle Payables invoices in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It is classified in the ETRM repository under the API classification "OTHER," indicating it is a supporting infrastructure package rather than a released public interface. Its principal purpose is to centralize the validation and reversal logic required to cancel a single invoice or a set of invoices while preserving accounting integrity. The package encapsulates the multi-step business rules that must be satisfied before an invoice may be cancelled, including verification of payment status, matching status, prepayment applications, project-related adjustments, and tax withholding. By exposing this logic through a single function, the package allows callers to perform cancellation in a controlled, atomic fashion rather than manipulating the underlying invoice, distribution, and payment schedule rows directly.

Key Procedures and Functions

The ETRM metadata documents two callable units within this package body:

• AP_CANCEL_SINGLE_INVOICE — A function that cancels exactly one invoice. It returns a Boolean indicating success or failure. The source listing documents a fixed sequence of validation and reversal steps: it returns FALSE if the invoice has an effective payment, is selected for payment, is already cancelled, has invoices applied against it as a prepayment, is matched to Finally Closed purchase orders, or (for project-related invoices) has pending adjustments. When the invoice is matched, matching is reversed; when the tax calculation level is line, tax is recalculated; when tax has been withheld, withholding is undone. The function then clears payment schedules, creates allocations for existing charges where required, creates reversing distribution lines (fetching the maximum distribution line number, setting encumbered flags to 'N', and inserting reversals based on existing lines), zeroes out the invoice, runs AutoApproval, and cancels the invoice if no posting holds remain, finishing with a commit.
• AP_CANCEL_INVOICES — The companion entry point for cancelling a set of invoices, providing a bulk wrapper around the single-invoice logic.

The package body also contains a private helper, INSERT_HOLD, which is intended to create a CANCEL hold on the invoice using a translated message string as the hold reason; in the shipped source revision the body is a stub containing only a NULL statement.

Tables Accessed

The ETRM metadata for this object does not enumerate specific tables through APPS synonyms. Based on the documented processing steps, the package necessarily reads and writes the core Oracle Payables invoice tables, including AP_INVOICES_ALL (invoice header zeroing and cancellation), AP_INVOICE_DISTRIBUTIONS_ALL (reversing distribution lines and encumbered flags), AP_PAYMENT_SCHEDULES_ALL (clearing and allocation of payment schedules), AP_INVOICE_PAYMENTS_ALL and AP_INVOICE_SELECTIONS_ALL (effective payment and payment selection checks), AP_HOLDS_ALL (posting and cancellation holds), and the tax and withholding tables consulted during tax recalculation and withholding reversal. Project-related checks against pending adjustments involve the Oracle Projects integration tables.

Usage Notes

IGI_AP_CANCEL_PKG is primarily invoked from Oracle Payables forms and concurrent processing rather than from customer-written code; the ETRM repository records zero packages referencing it, which reflects its role as an internal implementation package. Callers should treat AP_CANCEL_SINGLE_INVOICE and AP_CANCEL_INVOICES as the supported entry points when programmatic cancellation is required, noting that the function performs its own COMMIT and therefore should not be called from within an existing uncommitted transaction. Because the function returns FALSE for a broad range of preconditions, callers must inspect the return value and surface an appropriate error message. Direct calls to INSERT_HOLD yield no effect in the shipped revision, as its body is a placeholder. All calls should pass the caller's last-updated-by and login identifiers so that audit columns and the calling sequence are recorded correctly.