Search Results get_invoice_info

Overview

POS_AP_CHECKS_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema. Its header identifies it as a Payables-side utility (the "POS" prefix denotes the Oracle Purchasing/Procurement family, while "AP_CHECKS" reflects the intersection with Oracle Payables payment processing). The package provides lightweight lookup routines that resolve a payment check identifier into the purchasing and invoicing documents that funded the payment. In practice, given an AP check (payment) identifier, it returns whether a purchase order and/or release is associated with that check, and symmetrically whether an invoice and its distributions are associated with it.

This behavior is characteristic of a read-only informational package used to answer the business question: "Which procurement document generated this payment?" The high-point version header (120.0, dated 2005/06/01) indicates the package has remained stable across releases and is carried forward into EBS 12.1.1 and 12.2.2 largely unchanged.

Key Procedures and Functions

The ETRM metadata documents two procedures, both of which are lookup-style routines that accept a check identifier as their single IN parameter and return a set of OUT NOCOPY values.

• GET_PO_INFO — Accepts a check/payment identifier and returns a PO switch indicator, a PO number, a PO header identifier, and a PO release identifier. It resolves the purchasing document (header plus optional release) that the payment is tied to, enabling callers to display or act on the originating PO.
• GET_INVOICE_INFO — Accepts a check/payment identifier and returns an invoice switch indicator, an invoice number, and an invoice identifier. It resolves the Payables invoice associated with the check so the caller can trace the payment back to its invoice source.

Both procedures use OUT NOCOPY parameters, meaning the values are passed by reference and modified in place. Callers must supply declared variables for every OUT parameter, and should initialize the return switch variables (which act as presence flags indicating whether a PO or invoice is actually linked to the check).

Tables Accessed

The documented table set spans both the Payables and Purchasing models, which is consistent with the lookup role described above.

• Payables tables: AP_INVOICES_ALL (invoice header details such as invoice number and invoice ID), AP_INVOICE_DISTRIBUTIONS_ALL (distribution lines linking invoices to purchase orders), and AP_INVOICE_PAYMENTS_ALL (the bridge between payments/checks and invoices).
• Purchasing tables: PO_DISTRIBUTIONS_ALL (distribution lines matched back to the invoice distributions), PO_HEADERS_ALL (the purchase order header, supplying PO number and header ID), and PO_RELEASES_ALL (release information for blanket/planned orders).

Collectively, these tables allow the package to traverse the chain: Payment → Invoice → Invoice Distribution → PO Distribution → PO Header/Release. No write activity is implied by the API classification of OTHER and the READ-oriented parameter set.

Usage Notes

POS_AP_CHECKS_PKG is not referenced by any other documented package (referenced by 0 packages), which marks it as a terminal utility rather than a shared infrastructure dependency. It is typically invoked from:

• Form-based or OAF-based payment inquiry screens that need to surface PO/invoice detail for a given check.
• Custom concurrent programs or report scripts performing payment-to-PO reconciliation.
• Ad-hoc SQL*Plus or custom PL/SQL that needs a compact, single-call way to resolve the procurement documents behind a payment.

Because both procedures are pure lookups, they are safe to call in read-only contexts. When invoking GET_PO_INFO, callers should first evaluate the returned PO switch flag to determine if a PO is present before dereferencing the PO number, header ID, or release ID. The same pattern applies to GET_INVOICE_INFO with its invoice switch. This guard pattern prevents null-handling issues when the check has no procurement linkage. As with any APPS package, execute grants should be managed through standard EBS security, and the package should not be modified without following Oracle's customization and patching guidance.