Search Results ap_apxccput_xmlp_pkg




Overview

APPS.AP_APXCCPUT_XMLP_PKG is the generated PL/SQL package that backs the Oracle Payables credit card transaction XML Publisher report APXCCPUT (Credit Card Transactions Report). In Oracle EBS 12.1.1 and 12.2.2, Oracle Reports concurrent programs built on the XML Publisher (BI Publisher) architecture are accompanied by a package that declares the report's bind parameters, its NLS-translated literal strings, and its report-level formula and trigger functions. AP_APXCCPUT_XMLP_PKG holds that glue code for the payment credit card utilization extract.

The package exposes both the report parameter globals (ORG_ID, AMOUNT, START_DATE, END_DATE, CARD_NUMBER, PROCESS, TRACE_SWITCH, DEBUG_SWITCH, CONC_REQUEST_ID, SEND_NOTIFICATIONS) and a set of translated display strings used on the report output. Its header carries the $Header signature APXCCPUTS.pls 120.0, indicating a No Ship (noship) file shipped with the Payables product. The object is classified under the OTHER API classification, meaning it is not a supported public API and should not be called by external code.

Key Procedures and Functions

The documented callable units fall into three groups:

The user's search term "c_nls_yes_p" corresponds to C_NLS_YES_P, the accessor that returns the localized "Yes" literal for the report.

Tables Accessed

The package references two base tables through APPS synonyms:

  • AP_CARDS — the credit card definition table, supplying card number, masked card number, and cardholder attributes used by the masking formula and the report query.
  • AP_CREDIT_CARD_TRXNS — the credit card transaction table, providing the transaction amount, transaction date, and card reference that drive the amount and date range filters (START_DATE, END_DATE, AMOUNT) and the C_TRX_AMOUNT_FFORMULA output.

Usage Notes

AP_APXCCPUT_XMLP_PKG is invoked indirectly. When the Credit Card Transactions Report concurrent program is submitted, Oracle Reports calls BeforeReport, GET_NLS_STRINGS, the format functions, and AfterReport in sequence; no external package references it (Referenced by 0 other packages). Because it is generated report boilerplate under the OTHER classification, customizations should not call its functions directly. Instead, extensions should be made through the report definition or by adding a custom report rather than modifying this package, which Oracle may regenerate during patching.