Search Results ap_cancel_pkg




Overview
Explore in AI Chat

Overview

AP_CANCEL_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite that encapsulates the business logic for cancelling and reversing Oracle Payables invoices. It provides a programmatic, API-driven alternative to the standard Invoice Workbench cancellation action, allowing invoices to be voided, cancelled, or reversed in a controlled manner while enforcing the validation rules that Payables applies to those operations. Because it centralizes the cancellation logic, the package is a foundational dependency for a broad range of Payables, Purchasing, Treasury, and localization modules. In both 12.1.1 and 12.2.2 the object is reported as VALID, and the documented API classification is OTHER rather than a formal public API, which is significant for integrators: it means the package is intended primarily for internal consumption by Oracle's own code, though it is widely invoked from custom extensions as a de facto API.

Key Procedures and Functions

The ETRM 12.2.2 metadata documents three callable units within the package:

  • IS_INVOICE_CANCELLABLE — A function that evaluates whether a given invoice is eligible for cancellation. It applies the Payables business rules governing cancellability, such as invoice validation status, payment status, accounting status, period status, and the presence of holds or distributions. Callers typically use this as a pre-check to avoid raising exceptions from the cancellation routines.
  • AP_CANCEL_SINGLE_INVOICE — The procedure that performs cancellation for one invoice. It handles the reversal of the invoice and its associated accounting, releases or adjusts dependent records such as payment schedules and holds, and applies the appropriate cancellation semantics for the invoice type.
  • AP_CANCEL_INVOICES — A bulk procedure that drives cancellation across a set of invoices, providing a looping front end over the single-invoice logic and typically used by concurrent processes or mass-maintenance routines.

The package body is not exposed in the metadata excerpt, so parameter signatures are deliberately not reproduced here. The API classification of OTHER indicates these units are not supported as an open, documented public interface.

Tables Accessed

AP_CANCEL_PKG reads and writes a wide set of Payables and cross-module tables, accessed through APPS synonyms. Invoice header and line data are handled through AP_INVOICES_ALL, AP_INVOICE_LINES, AP_INVOICE_DISTRIBUTIONS_ALL, and AP_PAYMENT_SCHEDULES. Payment-related state is managed via AP_CHECKS and AP_INVOICE_PAYMENTS. Hold information is read and adjusted through AP_HOLDS and AP_HOLD_CODES. Period and system-control checks draw on GL_PERIOD_STATUSES and FINANCIALS_SYSTEM_PARAMS_ALL. Purchasing integration reads PO_HEADERS and PO_DISTRIBUTIONS. Ancillary reads occur against AP_INVOICES, AP_INVOICE_DISTRIBUTIONS, and AP_PRODUCT_REGISTRATIONS, the latter supporting the licensing/registration checks common in EBS code. The breadth of this footprint reflects the fact that cancellation is not a simple status update.

Usage Notes

Cancellation logic is normally triggered by the Invoice Workbench form action or by Payables concurrent programs such as invoice deletion, voiding, or mass cancellation. In those paths, AP_CANCEL_PKG is called internally. The metadata confirms the package is referenced by thirteen other packages, including AP_VOID_PKG, AP_INVOICE_LINES_PKG, AP_WORKFLOW_PKG, AP_IAW_PKG, AP_ISP_UTILITIES_PKG, ARP_REVERSE_RECEIPT, AR_REFUNDS_PVT, PO_INVOICES_SV1, LNS_FUNDING_PUB, and the localization packages JAI_AP_TDS_CANCELLATION_PKG and JAI_AP_TDS_OLD_PKG. Custom code should call IS_INVOICE_CANCELLABLE before invoking AP_CANCEL_SINGLE_INVOICE or AP_CANCEL_INVOICES, and should avoid direct DML on the underlying tables so that accounting, holds, and payment reconciliation remain consistent. Because the package is classified as OTHER rather than a supported public API, upgrades between 12.1.1 and 12.2.2 can alter signatures or behavior, and custom integrations should be re-verified after patching or release upgrades.