Search Results ap_card_invoice_pkg




Overview
Explore in AI Chat

Overview

AP_CARD_INVOICE_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. Its principal purpose is to generate Payables invoices from corporate credit card transaction data that has been loaded and staged through the Procurement Cards (also known as Card Programs) functionality. Organizations that issue corporate cards to employees accumulate transaction feeds from card providers; these feeds must eventually be converted into expense-related invoices within Oracle Payables so that the liability can be accounted for, validated against card program rules, and settled. AP_CARD_INVOICE_PKG encapsulates that conversion logic. It reads the card program definition, evaluates the staged expense feed lines and distributions that fall within a caller-supplied date range, and creates the corresponding invoice header, invoice lines, and invoice distributions. The package is classified in the ETRM metadata as an "OTHER" API, meaning it is a supporting package rather than a formally published public interface such as the Oracle Payables Open Interfaces or the Invoice API. It is referenced by one other package, indicating that it is invoked internally by a higher-level Payables component rather than being intended for direct customer invocation.

Key Procedures and Functions

The ETRM metadata documents exactly one procedure in the package specification: CREATE_INVOICE. The header comment shows a "$Header" of version 120.2 dated 2005/07/29, which reflects the lineage of the package across the 11i and R12 code lines.

  • CREATE_INVOICE — The sole documented procedure. Its declared parameters are P_CARD_PROGRAM_ID (the card program that governs the transaction set), P_INVOICE_ID (an IN OUT NOCOPY parameter, indicating the procedure both accepts an existing or target invoice identifier and returns the created invoice identifier), P_START_DATE and P_END_DATE (optional DATE parameters defaulting to NULL, which bound the transaction records to be processed), and P_ROLLUP_FLAG (a VARCHAR2 defaulting to 'Y', which controls whether transaction lines are rolled up into a consolidated invoice or processed individually). The procedure is responsible for assembling invoice headers, lines, and distributions from the staged card expense data for the given program and date window. No other procedures or functions are exposed in the documented specification; any additional internal logic is private to the package body and not part of the published API surface.

Tables Accessed

The package operates against the following APPS-synonymed tables, which correspond to the standard Payables and Procurement Cards data model:

The pattern of writing through the AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE tables, then into the base AP_INVOICES, AP_INVOICE_DISTRIBUTIONS tables, reflects the standard Payables import mechanism: records are staged in the interface, validated, and then created as actual invoices.

Usage Notes

AP_CARD_INVOICE_PKG is not a general-purpose public API. In practice it is invoked from the Payables Credit Card invoice creation flow, typically driven by a concurrent program or by the internal component that processes card program feeds. Customizations that need to generate card invoices should generally use the standard Oracle Payables Open Interfaces (AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE) rather than calling CREATE_INVOICE directly, because the procedure relies on staged expense feed data being present in AP_EXPENSE_FEED_LINES and AP_EXPENSE_FEED_DISTS. The P_ROLLUP_FLAG parameter, defaulting to 'Y', determines whether multiple card transactions are consolidated onto a single invoice; setting it to 'N' produces separate handling per transaction. The default NULL date parameters cause the procedure to consider the full available feed for the program. Because the procedure performs DML against interface and base Payables tables, callers must supply a valid card program identifier and commit or roll back the transaction after the call. Developers extending this functionality should treat the signature as fixed and version-sensitive across 12.1.1 and 12.2.2, and should verify current behavior against the installed package body, since the documentation reflects the 120.2 specification header.