Search Results pos_ap_invoices_pkg




Overview
Explore in AI Chat

Overview

POS_AP_INVOICES_PKG is an Oracle EBS PL/SQL package owned by the APPS schema and classified as a public API (API classification: OTHER). It belongs to the Public Sector (POS) product family and provides the data access layer that supports the invoice inquiry and expense-report views used by Oracle Purchasing, Payables, and Public Sector Procurement applications. The package encapsulates the business logic required to retrieve supplier invoice information together with its associated purchase order, receipt, payment, tax, prepayment, retainage, and hold data. Rather than exposing complex multi-table joins directly to the presentation layer, the package surfaces this information through a set of well-defined getter functions and procedures that the invoice inquiry views call.

Its principal consumers are the views POS_AP_INVOICES_V, POS_AP_EXPENSE_REPORTS_V, and POS_PO_SUP_ORDER_INVOICES_V, all of which rely on the package to aggregate invoice attributes from the Payables and Purchasing base tables. It is also referenced by three other PL/SQL packages within the APPS schema. The object is documented as VALID in ETRM releases 12.1.1 and 12.2.2.

Key Procedures and Functions

The package exposes sixteen documented program units. Their purposes are as follows:

Parameter lists are intentionally not documented here; callers should reference the package specification in the APPS schema.

Tables Accessed

The package reads from several Payables and Purchasing base tables via APPS synonyms:

The package is primarily read-oriented; any writes occur indirectly through the underlying Payables APIs rather than through direct DML on these tables.

Usage Notes

POS_AP_INVOICES_PKG is invoked almost exclusively through the invoice inquiry and expense-report views in Oracle Public Sector and Payables inquiry forms. Because the views depend on the package, any customization or extension of those views must preserve the package API contract. Concurrent programs and custom code that need summary invoice, PO, receipt, payment, tax, or retainage information can call the package functions directly to avoid re-implementing complex joins. When extending the package, developers should treat all sixteen procedures and functions as the supported interface and avoid altering their signatures, since dependent views and packages (POS_AP_INVOICES_V, POS_AP_EXPENSE_REPORTS_V, POS_PO_SUP_ORDER_INVOICES_V, and three referencing packages) will fail to compile if the specification changes.