Search Results total_amt

Overview

IBY_DBCCARD_PVT is a private PL/SQL package body in the Oracle Payments (IBY) module of Oracle E-Business Suite, released in the 12.1.1 and 12.2.2 code lines under the APPS schema. It provides the internal implementation logic that supports debit and credit card processing for payables and receivables transactions, exposed indirectly through the public APIs and concurrent programs that Payments relies upon. The "PVT" classification indicates that the package is not intended as a direct integration point; its procedures and functions are called by other Payments components rather than by external clients. The package encapsulates two categories of behavior: currency conversion for card transactions and the aggregation of transaction activity into summary views used for reporting and monitoring. The keyword total_amt is central to the summary functions because each of the GET_*_SUMMARY procedures returns aggregated monetary totals computed from underlying transaction data.

The header comment (ibyvdbcb.pls 120.4) places the original implementation in the 11.5/12.0 timeframe, and the package remains present through 12.2.2. A package-level flag g_validation_level is initialized to FND_API.G_VALID_LEVEL_FULL, confirming that the package follows the standard Oracle EBS API validation conventions.

Key Procedures and Functions

The ETRM metadata documents six callable units. Descriptions below reflect their documented purpose.

• GET_TRXN_SUMMARY — Returns aggregated debit/credit card transaction totals, including the total amount (total_amt), for a given query context. It is the principal summary routine and drives detail-level reporting.
• GET_FAILURE_SUMMARY — Aggregates failed card transactions, allowing support and operations staff to quantify declined or rejected authorization attempts.
• GET_CARDTYPE_SUMMARY — Groups transaction totals by card type (for example, Visa, MasterCard, American Express), enabling analysis of volume and value by card brand.
• GET_PROCESSOR_SUMMARY — Groups transaction totals by payment processor, supporting reconciliation of settlement files and processor-level reporting.
• GET_RISK_SUMMARY — Aggregates transactions according to risk-related attributes, supporting fraud and risk monitoring of card activity.
• CONVERT_AMOUNT — A wrapper on the GL currency conversion function. It accepts a from-currency, to-currency, effective date, amount, and conversion type and returns the converted amount. If the amount is NULL, it is treated as zero. If the rate or currency is not found, or an unexpected error occurs, the function returns a negative value (−1) to signal failure.

The package also contains an internal status-mapping function that classifies raw status codes into SUCCESS, FAILED, PENDING, or UNKNOWN categories used by the summary routines.

Tables Accessed

The package reads from the following tables, referenced through APPS synonyms:

• IBY_TRXN_SUMMARIES_ALL — The primary source of summarized card transaction data, supplying the amount and count columns aggregated by the GET_*_SUMMARY functions.
• IBY_BEPINFO — Holds payment system and processor configuration information used to resolve processor-level groupings.
• IBY_PAYEE — Provides payee details associated with card transactions, supporting filtering and joining of summary results.
• PLITBLM — A PL/SQL index-by table type declaration referenced internally; it is not a data-bearing table in the conventional sense.

No insert, update, or delete operations are documented for this package; it is predominantly a query and calculation layer.

Usage Notes

IBY_DBCCARD_PVT is invoked by other Payments packages (the metadata records three referencing packages) rather than directly by end users. In a 12.1.1 or 12.2.2 environment, the summary functions typically surface through Payments dashboards, card activity reports, and internal concurrent programs that display transaction totals, failure counts, and processor or card-type breakdowns. The CONVERT_AMOUNT function is used whenever a card transaction amount must be expressed in a functional or reporting currency.

Because the package is classified as PVT, customization or direct calls are discouraged. Any change control should go through the supported Payments APIs, and developers tracing a total_amt discrepancy should inspect IBY_TRXN_SUMMARIES_ALL first, since that table is the documented origin of the aggregated values.