Search Results iby_fndcpt_payer_all_instrs_v




Overview
Explore in AI Chat

Overview

IBY_FNDCPT_PAYER_ALL_INSTRS_V is a consolidated APPS-owned database view in the Oracle Payments (IBY) module, shipped in Oracle E-Business Suite 12.1.1 and 12.2.2. Its name reflects its purpose: it presents a unified set of payer payment instruments — "all instruments" — drawn from the two distinct instrument families that Oracle Payments supports. A single query against this view returns credit card instruments and bank account instruments side by side, abstracted behind a common set of columns.

This unification is significant because credit cards and bank accounts are physically stored in entirely separate tables and normally require separate queries. The view shields callers from that physical split by aligning both sources into one projection and combining them with a UNION. Reporting tools, data extracts, and integration interfaces that need a complete inventory of a payer's instruments can therefore use a single object rather than orchestrating two. Because it exposes sensitive payment data such as card numbers, hashes, and bank account numbers, access is typically restricted to internal processes rather than end-user reporting, and the view is generally treated as a dependency of the Payments instrument model rather than as a public integration contract.

Underlying Base Objects

The view is defined as a UNION of two SELECT statements. The first branch reads credit card instruments from IBY_CREDITCARD, joined to IBY_CREDITCARD_ISSUERS_VL on CARD_ISSUER_CODE to resolve the human-readable issuer name. The second branch reads bank accounts, drawing from IBY_EXT_BANK_ACCOUNTS_V with an outer join from IBY_ACCOUNT_OWNERS on EXT_BANK_ACCOUNT_ID, so that accounts without an ownership row are still returned.

The documented base objects are IBY_CREDITCARD, IBY_CREDITCARD_ISSUERS_VL, IBY_EXT_BANK_ACCOUNTS_V, and IBY_ACCOUNT_OWNERS. The latter two bank-related sources are exposed as synonyms, as is IBY_CREDITCARD; IBY_CREDITCARD_ISSUERS_VL and IBY_EXT_BANK_ACCOUNTS_V are themselves views. The metadata additionally lists FND_GLOBAL (package) and FND_LOOKUPS (view) as referenced objects, which are standard EBS utilities used for session context and lookup decodes. In practice the core data paths flow from the credit card table, the credit card issuers view, the external bank accounts view, and the account owners table.

Key Columns

The view projects a common 22-column shape across both branches. The leading columns identify and classify each instrument:

The card-oriented columns include CARD_NUMBER (the masked number, MASKED_CC_NUMBER), CC_NUMBER_HASH1 and CC_NUMBER_HASH2, CARD_EXPIRYDATE, CARD_ISSUER_CODE, CARD_ISSUER_NAME, PURCHASECARD_SUBTYPE, CARD_HOLDER_NAME (CHNAME), CARD_BILLING_ADDRESS_ID, CARD_FI_NAME, and CARD_SINGLE_USE_FLAG. The account-oriented columns are ACCOUNT_NUMBER, BANK_NAME, BANK_NUMBER, BRANCH_NAME, BRANCH_NUMBER, and BIC_NUMBER. A trailing DESCRIPTION column is populated from either source. Columns not applicable to a given branch are returned as NULL, which is the mechanism that keeps both instrument types in one row shape.

Common Use Cases and Queries

Typical uses include building a party-level instrument inventory, reconciling credit cards against bank accounts for a payer, and feeding downstream extracts that must distinguish instrument type. Because the discriminator is explicit, filtering is straightforward:

  • Retrieve all instruments for a payer: SELECT instrument_type, instrument_id, currency_code, description FROM iby_fndcpt_payer_all_instrs_v WHERE party_id = :party_id;
  • List only bank accounts: SELECT account_number, bank_name, branch_name FROM iby_fndcpt_payer_all_instrs_v WHERE instrument_type = 'BANKACCOUNT';
  • List only credit cards with issuer names: SELECT card_number, card_issuer_name, card_expirydate FROM iby_fndcpt_payer_all_instrs_v WHERE instrument_type = 'CREDITCARD';
  • Count instruments by type: SELECT instrument_type, COUNT(*) FROM iby_fndcpt_payer_all_instrs_v GROUP BY instrument_type;

When writing queries, always constrain by PARTY_ID in production to limit the volume of unioned data. Join this view to IBY_PAYERS or related payment objects when payer-level context is required.