Search Results ap_auto_payment_pkg




Overview
Explore in AI Chat

Overview

AP_AUTO_PAYMENT_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It encapsulates the core logic used by the Oracle Payables AutoPayment process to select invoices for payment and to generate payment documents. This process, including the AutoPayment concurrent programs, processes the payment batches defined by the Payables user after the invoice selection criteria have been applied. AutoPayment does not perform the original selection of invoices; it operates on the selection criteria and payment schedules already built by the Payment Workbench and the invoice selection processes. AP_AUTO_PAYMENT_PKG works in coordination with other Payables packages that handle invoice selection, validation, and payment formatting. Its classification is OTHER, reflecting that it is primarily an internal helper package and not a documented public API with a published parameter contract. The package status is VALID in the ETRM repository and its dependency on STANDARD places it within the standard PL/SQL runtime environment.

Key Procedures and Functions

Four procedures and functions are documented in the ETRM metadata. The REPLACE_CHECK procedure handles replacement of a payment document, supporting the Payables operation in which a check or payment is voided or otherwise invalidated and must be reissued under the same or a new document number. SELECTION_CRITERIA_EXISTS is a function that determines whether selection criteria records exist for the payment process, allowing AutoPayment to validate that there is work to process before it proceeds. GET_CHECK_STOCK_IN_USE_BY identifies which check stock is in use for a given payment or payment document, supporting assignment of the correct payment document definition during check creation. OK_TO_CALL_WITHHOLDING is a validation function that indicates whether the withholding tax processing logic may be invoked for the payment being built, allowing the package to respect withholding tax and 1099 processing constraints. Parameter lists are deliberately omitted here; no public signature is documented in the ETRM repository, and custom code should not assume a stable callable interface.

Tables Accessed

The package references a broad set of Payables tables through APPS synonyms. AP_CHECKS, AP_CHECKS_ALL, and AP_CHECKS_S are the core payment document tables and are read and written as payment records are created, replaced, or voided. AP_CHECK_STOCKS is accessed to determine valid check stock definitions, supporting GET_CHECK_STOCK_IN_USE_BY. AP_INVOICES, AP_INVOICE_DISTRIBUTIONS, and AP_INVOICE_DISTRIBUTIONS_ALL supply invoice and distribution detail used to evaluate payment eligibility. AP_INVOICE_PAYMENTS and AP_INVOICE_PAYMENTS_S represent the link between invoices and the payments that satisfy them and are updated as payments are generated. AP_INVOICE_SELECTION_CRITERIA and AP_INV_SELECTION_CRITERIA_ALL store the selection criteria that drive which invoices enter the payment batch and support SELECTION_CRITERIA_EXISTS. AP_PAYMENT_HISTORY_ALL records the history of payment actions. AP_PAYMENT_SCHEDULES provides the scheduled amounts being paid. AP_SYSTEM_PARAMETERS supplies Payables system options that govern payment behavior, and FND_DOCUMENT_SEQUENCES provides the document numbering used when payment documents are created.

Usage Notes

AP_AUTO_PAYMENT_PKG is invoked indirectly by the Oracle Payables AutoPayment concurrent programs and by the Payment Workbench processing path, and it is referenced internally by AP_CHECKS_V. It is not intended as a public extension point. Customers extending Payables payment processing should prefer documented Oracle APIs and the Oracle-supplied hooks rather than calling procedures in this package directly, because the metadata does not document callable signatures and Oracle may change internal behavior between releases. Custom code that must observe or influence AutoPayment behavior should generally operate on the underlying Payables tables through supported interfaces, or through the documented payment APIs, and should be regression tested on both 12.1.1 and 12.2.2 given the differing table and view structures that exist across those releases.