Search Results call_get_payment_info

Overview

IBY_AR_UTILS is a PL/SQL utility package owned by the APPS schema in Oracle E-Business Suite, delivered as part of the Payments (IBY) module that underpins Oracle Payments and its integration with Oracle Receivables. The package provides helper routines used during the extraction and construction of payment-related XML documents, particularly the documents receivable structure consumed by payment processing, credit card authorization, and settlement flows. Its central design goal is performance: several of its functions are explicitly documented as "short-circuit" routines that avoid joining the full documents receivable XML extract view when a given transaction does not require that sub-element, such as online authorizations, which would otherwise incur unacceptable join costs. The package also exposes utilities for retrieving authorization status, order and line level amounts (tax, freight, and total), tax rates, transaction reference numbers, and payment information. It is referenced by seven other packages, confirming its role as a shared low-level utility rather than an end-user-facing API.

Key Procedures and Functions

The documented interface comprises twelve procedures and functions, including the following notable entries:

• GET_DOCUMENT_RECEIVABLE — Returns the documents receivable for a given transaction as an XMLType. The header comment marks the original signature obsolete in R12; an overloaded, transaction-extension-driven form (keyed on p_extension_id) supersedes it and is the version used in R12.
• GET_AUTHORIZATION_STATUS — Returns the authorization flag for a given transaction extension identifier.
• CALL_GET_PAYMENT_INFO — Invokes retrieval of payment information associated with a transaction.
• GET_ORDER_AMOUNT — Returns the order-level amount for a transaction; this is the routine the user searched for. It supports amount aggregation at the order grain, complementing the tax and freight variants.
• GET_ORDER_TAX_AMOUNT — Returns the order-level tax amount.
• GET_ORDER_FREIGHT_AMOUNT — Returns the order-level freight amount.
• GET_LINE_TAX_AMOUNT — Returns the tax amount at the transaction line level.
• GET_LINE_TAX_RATE — Returns the applicable tax rate for a line.
• GET_TRXN_REF_NUMBER2 — Returns a transaction reference number used for reconciliation and reference purposes.

The package additionally declares constants identifying tax types (G_TAX_TYPE_SALES and G_TAX_TYPE_VAT), which the tax-related functions rely upon to distinguish sales tax from VAT treatment.

Tables Accessed

The package reads from several core Payments and Receivables tables via APPS synonyms. IBY_TRXN_SUMMARIES_ALL and IBY_TRXN_CORE supply transaction summary and core attributes (tangible ID, transaction type, instrument type, card data level). IBY_FNDCPT_TX_EXTENSIONS and IBY_FNDCPT_TX_OPERATIONS provide the transaction extension and operation records that drive the R12 extension-based document retrieval and authorization status. Receivables data is drawn from AR_CASH_RECEIPTS and AR_RECEIVABLE_APPLICATIONS to resolve receipt and application context. Payment system and user profile tables (IBY_FNDCPT_SYS_CC_PF_B, IBY_FNDCPT_SYS_DC_PF_B, IBY_FNDCPT_SYS_EFT_PF_B, and their USER counterparts) supply credit card, debit card, and EFT profile configuration. The global temporary table IBY_AR_DOC_HEADER_GT is used for header staging during XML document assembly, and XMLTYPE and PLITBLM support XML generation and PL/SQL table handling respectively.

Usage Notes

IBY_AR_UTILS is an internal utility rather than a user-invoked API. It is typically called from Oracle Payments extraction and authorization flows, from concurrent programs that build documents receivable XML extracts, and from other IBY packages (seven documented dependents). Custom code should invoke the R12 extension-based overload of GET_DOCUMENT_RECEIVABLE and avoid the obsoleted signature. Because the routines are optimized to bypass unnecessary joins, they are best called only for transactions that actually require the requested sub-element, preserving the performance intent of the design. Tax-related functions should be used in conjunction with the declared SALESTAX/VAT constants so that amount and rate retrieval reflects the correct tax regime.