Search Results p_rollup_flag

Overview

APPS.AP_CARD_INVOICE_PKG is a credit card invoice generation package in Oracle E-Business Suite Payables. Its central purpose is to automate the creation of invoices payable to credit card issuers for approved corporate card transactions that have already been expensed within the application. The package bridges the gap between expense data captured in the corporate card expense feed tables and the standard Payables invoice interface, allowing credit card charges to be settled through the normal invoice lifecycle without manual data entry.

The package operates by reading approved distributions from AP_EXPENSE_FEED_DISTS and inserting corresponding records into the open interface tables AP_INVOICE_LINES_INTERFACE and AP_INVOICES_INTERFACE. It then updates the source expense feed distributions to mark them as invoiced, thereby preventing duplicate invoice creation on subsequent runs. As documented in the package header comments, the object is owned by APPS and classified as an OTHER API under ETRM 12.2.2.

Key Procedures and Functions

The package exposes a single documented procedure, CREATE_INVOICE. According to the source comments, this procedure drives the entire invoice creation cycle. It accepts a card program identifier, an invoice identifier passed as an IN OUT NOCOPY parameter, optional start and end dates, and a rollup flag. No additional procedures or functions are documented in the ETRM metadata for this package body.

The behavior of CREATE_INVOICE turns on the p_rollup_flag parameter, which is the term referenced in the source comments and is the subject of common user queries against this object. When the rollup flag is set to 'Y' (the declared default), transactions are summarized — or "rolled up" — by the distribution code combination identifier, tax code, and the amount-includes-tax flag. This consolidation reduces the number of invoice lines written to the interface tables. When the flag is not 'Y', transactions are processed without this summarization, producing one interface line per qualifying source distribution. The procedure also applies filtering criteria: the card program identifier on AP_EXPENSE_FEED_LINES must match, the transaction date must fall between the supplied start and end dates, and the distribution status must be APPROVED or otherwise not excepted from payment at the card program level.

Tables Accessed

The package reads AP_EXPENSE_FEED_DISTS and AP_EXPENSE_FEED_LINES to obtain the approved card transaction distributions and their driving expense lines. Card program configuration and payment exception logic are drawn from AP_CARD_PROGRAMS. The package writes summarized or line-level detail into AP_INVOICE_LINES_INTERFACE and a single grouping header record into AP_INVOICES_INTERFACE, using the associated interface sequence objects AP_INVOICES_INTERFACE_S and AP_INVOICE_LINES_INTERFACE_S. After a successful insert, it updates AP_EXPENSE_FEED_DISTS to set INVOICED_FLAG to 'Y' and to record the generated INVOICE_ID and INVOICE_LINE_ID, ensuring traceability between the source distribution and the resulting invoice. References to AP_INVOICES and AP_INVOICE_DISTRIBUTIONS support lookup and validation against posted invoices, while DUAL is used for utility queries. A known change documented under Bug 4997769 replaced the transaction date filter with the posted date.

Usage Notes

CREATE_INVOICE is typically invoked through the credit card invoice creation flow in Oracle Payables, often from concurrent processing or the standard corporate card batch programs rather than from interactive forms. Because the rollup flag defaults to 'Y', standard processing produces consolidated invoice lines, and custom integrators should set it explicitly when line-level detail is required. Calling the procedure updates the expense feed tables, so it should not be re-run against the same date range without an understanding of the INVOICED_FLAG state. The package is referenced by one other package in the documented metadata, indicating that it participates as a dependent routine within a broader card settlement flow.