Search Results eft_auth_method




Overview
Explore in AI Chat

Overview

IBY_TRANS_BANKACCT_V is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the IBY (Payments) product family. It presents a consolidated, denormalized projection of payment transaction data specifically scoped to bank account payment schemes. The view restricts its result set to records where the payment scheme name equals BANKACCOUNT, meaning it exposes only those transactions routed through a bank account instrument rather than other disbursement mechanisms.

Because it joins transactional, instrument, payee, and bank account attributes into a single flat row, the view is well suited for extracts, reconciliation reports, payment file diagnostics, and integration touchpoints that require both transaction-level status and the underlying bank account credentials in one pass. Notably, it exposes EFT_AUTH_METHOD (sourced from IBY_TANGIBLE) and ORDER_MEDIUM, which are relevant to electronic funds transfer processing and payment media selection.

Underlying Base Objects

The view is defined over eight synonym-referenced base objects, joined on instrument, tangible, payee, and scheme keys:

  • IBY_TRXN_SUMMARIES_ALL — the driving transaction summary table (alias B), supplying transaction identifiers, payee, payer instruction, status, dates, and organization context.
  • IBY_TRXN_FI — first-party/instruction detail (alias C), supplying reference code, service request ID, process fee, and split identifier.
  • IBY_PMTSCHEMES — payment scheme definition (alias E), constrained to PMTSCHEMENAME = 'BANKACCOUNT'.
  • IBY_TANGIBLE — the tangible/payment instruction detail (alias T), contributing amount, currency, account number, memo, order medium, and EFT authorization method.
  • IBY_BANKACCT — bank account master (alias BK), supplying bank account ID, branch, routing number, institution name, and account holder name.
  • IBY_BEPKEYS — BEP (bank entry point) key mapping (alias P), linking payee/owner and BEP identifiers.
  • IBY_ACCTTYPE — account type lookup (alias Y), resolving the account type code.
  • IBY_PAYEE — payee master (alias PY), providing the payee name.

Key Columns

  • BEPKEY, TRANSACTIONID, TRXNMID, BEPID — core identifiers linking the transaction to its bank entry point and instruction record.
  • PAYEEID, PAYEENAME — the payee identity and display name.
  • STATUS, REQDATE, SETTLEDATE, UPDATEDATE — transaction lifecycle state and key timestamps used in aging and reconciliation reporting.
  • AMOUNT, CURRENCYNAMECODE — payment value rounded to two decimals, with ISO currency code.
  • ACCTNO, BANKACCOUNTID, ROUTINGNO, BRANCHNAME, FINAME, INSTRNAME, ACCOUNT_HOLDER_NAME — full bank account attribution for the disbursement.
  • ACCTTYPE, ACCTTYPEID — the account classification (for example, checking or savings).
  • EFT_AUTH_METHOD — the EFT authorization method governing the electronic transfer, exposed directly for audit and file-generation logic.
  • ORDER_MEDIUM — the payment delivery medium (for example, EFT or check).
  • ORG_ID, NLSLANG — multi-org operating unit and language context, supporting secure, locale-aware querying.
  • PROCESSFEE, REFERENCECODE, SRVID, SPLITID — servicing and fee attributes from the FI detail record.

Common Use Cases and Queries

The view is typically queried to reconcile bank account payments by operating unit, to troubleshoot failed or pending EFT transactions, and to extract bank account and EFT authorization details for downstream banking integrations.

  • Listing pending bank account payments within an operating unit.
  • Auditing EFT authorization methods across transactions.
  • Extracting bank account and routing details for a given payee.

Sample query for EFT authorization method reporting:

SELECT transactionid, payeename, amount, currencynamecode, eft_auth_method, order_medium, status FROM iby_trans_bankacct_v WHERE org_id = :p_org_id AND eft_auth_method IS NOT NULL ORDER BY reqdate DESC;

Because the view is a join of multiple payment tables, queries should filter on ORG_ID and date ranges to maintain performance, and all access should respect the multi-org security model applied to the underlying IBY tables.