Search Results ap_invoice_corrections_pkg




Overview
Explore in AI Chat

Overview

APPS.AP_INVOICE_CORRECTIONS_PKG is a PL/SQL package body in the Oracle E-Business Suite Payables (AP) module. Its business purpose is to support the correction of existing supplier invoices after they have been entered, validated, or accounted. Corrections in Payables differ from simple updates: the application must preserve auditability, respect accounting period status, recalculate withholding tax, revalidate distributions and lines, and maintain the relationships between an invoice header, its lines, and its distributions. This package encapsulates those rules so that invoice correction logic is executed consistently regardless of the interface that triggers it. The metadata classifies the object as an "OTHER" API under the APPS schema, with VALID status in both 12.1.1 and 12.2.2, indicating a supported and stable component. It is not referenced by any other database object in the dependency graph, which suggests it is invoked directly by application forms, concurrent programs, or custom extension code rather than being a low-level utility consumed by other server-side packages.

Key Procedures and Functions

The ETRM metadata documents a single procedure for this package: INVOICE_CORRECTION. No parameter list is published, and none should be assumed. Functionally, INVOICE_CORRECTION is the entry point through which a caller requests that an invoice be modified. Because the package depends on AP_ETAX_PKG, AP_UTILITIES_PKG, AP_AWT_GROUPS, GL_PERIOD_STATUSES, and AP_SYSTEM_PARAMETERS, the procedure is expected to perform the following activities internally: validate that the invoice is eligible for correction, apply the requested changes to the invoice header and its lines and distributions, recompute tax and withholding where applicable, verify that the affected accounting period is still open, and raise messages through FND_MESSAGE and FND_MSG_PUB when validation fails. The dependency on APP_EXCEPTION and FND_LOG further indicates structured error handling and debug logging. Custom code should call INVOICE_CORRECTION rather than issuing direct DML against the underlying tables, because the procedure enforces these Payables business rules.

Tables Accessed

The package reads and writes the core Payables invoice tables. AP_INVOICES and AP_INVOICES_ALL hold the invoice header, while AP_INVOICE_LINES and AP_INVOICE_LINES_ALL hold invoice lines; AP_INVOICE_DISTRIBUTIONS, AP_INVOICE_DISTRIBUTIONS_ALL, and the sequence AP_INVOICE_DISTRIBUTIONS_S support distribution records and their surrogate keys. AP_AWT_GROUPS is referenced for withholding tax group processing, and AP_BATCHES for invoice batch context. Supplier information is resolved through AP_SUPPLIERS, AP_SUPPLIER_SITES_ALL, PO_VENDORS, and PO_VENDOR_SITES. AP_SYSTEM_PARAMETERS supplies Payables system options, FND_CURRENCIES provides currency attributes, GL_CODE_COMBINATIONS supplies accounting flexfield combinations, GL_PERIOD_STATUSES confirms whether the relevant accounting period is open, and MO_GLOBAL supports multi-org (operating unit) security. Together these tables give the package everything needed to correct an invoice while preserving accounting integrity.

Usage Notes

AP_INVOICE_CORRECTIONS_PKG is typically invoked from the Payables invoice workbench when a user performs an invoice correction, and it may also be called by concurrent programs or custom PL/SQL that must apply corrections programmatically. Because the package relies on MO_GLOBAL and AP_SYSTEM_PARAMETERS, the correct operating unit and Payables options must be initialized in the session before invocation. Callers should ensure the invoice is not already accounted in a closed period, since GL_PERIOD_STATUSES validation will reject such changes. All error conditions should be handled through the standard FND message stack. In releases 12.1.1 and 12.2.2 the object remains VALID, so no recompilation or remediation is required; nevertheless, because it is an internal package rather than a formally published public API, Oracle may change its internals, and customizations should be regression-tested during patching or upgrades.