Search Results do_pay_accounting

Overview

APPS.AP_ACCOUNTING_PAY_PKG is the accounting engine for Oracle Payables payment events in Oracle E-Business Suite 12.1.1 and 12.2.2. Its stated purpose, taken directly from the package header comment, is to select payment events for processing and to call the Payment Distributions and Prepay Application Distributions generators that create payment and prepay application distribution rows. It is described as the single point of entry for payment processing within the Subledger Accounting (SLA) architecture, meaning that all payment-side accounting line generation is routed through this body.

The package executes under the APPS schema and is classified in ETRM as OTHER rather than as an open public API. It is referenced by five other packages, confirming its role as a shared internal service rather than a standalone entry point.

Key Procedures and Functions

The ETRM metadata documents nineteen procedures and functions in the body. The primary driver is DO_PAY_ACCOUNTING, which does not accept an invoice identifier but processes the set of candidate events. The excerpted source shows its cursor reads XLA_Events_GT for rows where the entity code is AP_PAYMENTS or the event type is PREPAYMENT APPLIED, PREPAYMENT UNAPPLIED, or PREPAYMENT APPLICATION ADJ, and where the event status code is not 'N', ordered by Event_ID. This confirms DO_PAY_ACCOUNTING as the orchestrator that feeds the distribution generators.

• DELETE_HIST_DISTS — the procedure targeted by the user's search. It removes historical payment distribution rows associated with the accounting event being reprocessed, clearing stale lines before regeneration.
• PRORATE_HISTORICAL_DISTS — performs proration of historical distributions, used when payment amounts must be allocated across previously created lines.
• GET_CASC_PAY_SUM, GET_CASC_INV_DIST_SUM, GET_CASC_BANK_CURR_SUM, GET_CASC_PREPAY_SUM, GET_CASC_TAX_DIFF_SUM, GET_CASC_DISCOUNT_SUM, GET_CASC_INV_DIST_DISC_SUM, GET_CASC_BANK_CURR_DISC_DISC_SUM — a family of cascading summation functions that aggregate payment, invoice distribution, bank currency, prepay, tax difference, and discount amounts used during distribution calculation.
• GET_PAY_SUM, GET_PAY_BASE_SUM, GET_PREPAY_SUM, GET_PREPAY_BASE_SUM, GET_BASE_AMOUNT — retrieve entered and base currency amounts for payments and prepayments, providing the values required for SLA line generation.
• IS_UPGRADE_PRORATION_EXISTS, IS_FINAL_PAYMENT, IS_FINAL_EVENT — Boolean-style status checks controlling whether proration logic applies and whether the payment or event is the final one in the series.

Tables Accessed

Through APPS synonyms the package reads and writes core Payables and SLA tables. Payment and check data come from AP_CHECKS_ALL, AP_INVOICE_PAYMENTS_ALL, and AP_INVOICES_ALL. Distribution generation and cleanup depend on AP_PAYMENT_HIST_DISTS, AP_PREPAY_APP_DISTS, and AP_PAYMENT_HISTORY_ALL (with AP_PAYMENT_HISTORY for history). Invoice-side amounts are drawn from AP_INVOICES, AP_INVOICE_DISTRIBUTIONS, and AP_INVOICE_DISTRIBUTIONS_ALL. Prepay activity is sourced from AP_PREPAY_HISTORY_ALL. System configuration is read from AP_SYSTEM_PARAMETERS, AP_SYSTEM_PARAMETERS_ALL, and FINANCIALS_SYSTEM_PARAMS_ALL. SLA integration reads XLA_EVENTS_GT. Because DELETE_HIST_DISTS operates on AP_PAYMENT_HIST_DISTS, that table is the focal object for the deletion logic.

Usage Notes

AP_ACCOUNTING_PAY_PKG is not intended for direct custom invocation. It is driven by the SLA event model, which populates XLA_EVENTS_GT before DO_PAY_ACCOUNTING runs, and it is normally reached through concurrent accounting programs such as the Payables Accounting Process and related payment accounting generators, or through the five dependent packages that call it. DELETE_HIST_DISTS is typically reached indirectly during event reprocessing, where existing historical distributions must be purged before regeneration. Custom development should avoid calling these routines directly; instead, custom logic should raise or reprocess accounting events and allow the standard payment accounting flow to invoke this package. Because the header reflects a 2008 file revision (120.12.12010000.4), administrators should confirm the deployed file version matches the 12.1.1 or 12.2.2 code level in use.