Search Results iby_void_check

Overview

APPS.AP_VOID_PKG is a server-side PL/SQL package in the Oracle E-Business Suite Payables (AP) module. Its business purpose is to encapsulate the logic required to void or reverse payment instruments and the accounting entries associated with them. In the payment lifecycle, once a payment is created, formatted, and confirmed, there are situations in which it must be stopped—for example, when the payment instrument is lost, damaged, or cancelled before it is negotiated, when the bank rejects a payment, or when an electronic funds transfer fails and the payment must be cancelled. The package provides the centralized programmatic entry point for those voiding and reversal operations, ensuring that the payment record, its distributions, any holds applied to related invoices, and the associated accounting are updated consistently.

The package sits within the application object library alongside related components such as AP_PMT_CALLOUT_PKG and FUN_NET_CANCEL_PKG, which reference it, and relies on FND_API for its error and message handling. Because payment voiding touches payment accounting, invoices, holds, and distributions, it is critical that all updates occur within a controlled transaction to preserve data integrity across the Payables and Payments subsystems.

Key Procedures and Functions

Two documented procedures are exposed by the package:

• AP_REVERSE_CHECK — Handles the reversal of a payment (a check or other payment instrument) recorded in Payables. It is responsible for reversing the payment's accounting entries and updating the payment status so that the instrument is no longer treated as an outstanding or issued payment. This is the core routine used when a user voids a payment from within Payables or when an external process must programmatically reverse a check.
• IBY_VOID_CHECK — Provides the integration with Oracle Payments (IBY). It coordinates the voiding of a payment with the Payments module, ensuring the payment instruction and payment process request records reflect the void, and that the instrumentation status is synchronized between Payables and Payments.

The two procedures operate together: IBY_VOID_CHECK manages the Payments-side coordination while AP_REVERSE_CHECK performs the Payables-side reversal of the payment and its accounting.

Tables Accessed

The package reads and writes a range of Payables base tables through APPS synonyms, reflecting the breadth of a payment reversal:

• AP_CHECKS and AP_CHECKS_ALL — The payment/check records that are reversed or voided.
• AP_INVOICE_PAYMENTS and AP_INVOICE_PAYMENTS_ALL — Linkages between invoices and the payment; these are updated to unwind the payment-to-invoice relationship.
• AP_INVOICES and AP_INVOICES_ALL — Invoice header records affected when the payment is unwound and the invoice balance is restored.
• AP_INVOICE_DISTRIBUTIONS and AP_INVOICE_DISTRIBUTIONS_ALL — Distribution-level accounting is reversed as part of the void.
• AP_INVOICE_LINES_ALL — Invoice line detail underlying the distributions.
• AP_HOLDS, AP_HOLDS_ALL, and AP_HOLDS_S — Hold records that may be applied or released in conjunction with a reversed payment.
• AP_HOLD_CODES — The hold code definitions referenced by those holds.

Collectively these tables allow the package to reverse the payment, restore invoice balances, unwind distributions, and manage holds in a single controlled operation.

Usage Notes

AP_VOID_PKG is normally invoked indirectly rather than called directly by end users. In standard Payables, the void and reversal of payments is driven from the Payments workbench and the Payment Process Requests, or from the Cancel/Void actions within the Invoice Workbench. Those flows call AP_PMT_CALLOUT_PKG and related components, which in turn invoke AP_VOID_PKG. It is also referenced by FUN_NET_CANCEL_PKG for netting/cancellation scenarios and is self-referenced, indicating internal recursion or delegation among its routines.

For custom development, the package should be treated as an extension point only when a requirement genuinely cannot be met through standard void processing. Because callers must supply the relevant payment and context information and handle the FND_API error stack, custom code invoking these procedures must carefully manage transaction control, commit only after success, and roll back on any returned error. Organizations should also confirm that the version of the package in their 12.1.1 or 12.2.2 environment is VALID and has not been customized, since the voiding logic is tightly coupled to Oracle Payments and to the underlying AP accounting model.