Search Results eft_swift_code

Overview

The APPS.AR_CBA_EFT_USER_NUMBER_V view is a Receivables (AR) reporting object that exposes electronic funds transfer (EFT) identifiers associated with bank branch parties. It is a lightweight, two-table join view that resolves the EFT user number and EFT SWIFT code stored as contact point information on the HZ_PARTIES model. The view carries the documented annotation "(Release 11.6 Only)", indicating that it originated in the 11.6 E-Business Suite release as part of the Cash-Based Accounting (CBA) and EFT remittance functionality, where bank routing and identification data for electronic payments had to be surfaced in a party-centric form.

In Oracle EBS 12.1.1 and 12.2.2 the object remains present and VALID in the APPS schema, but it is best understood as a legacy compatibility view rather than an actively extended interface. It presents finance and integration developers with a single, denormalised row per EFT contact point, mapping a bank party to its EFT user number and SWIFT code, and it is used primarily for reporting, data verification, and downstream EFT file generation where the party model is the authoritative source.

Underlying Base Objects

The view is defined over two registered base objects, both reached through APPS synonyms:

• HZ_PARTIES — the Trading Community Architecture (TCA) party master. In this view the alias BRANCHPARTY supplies the bank or bank branch party identifier that anchors each EFT record.
• HZ_CONTACT_POINTS — the TCA contact point table (alias EFT), which stores EFT-type contact points for parties. The view filters rows where CONTACT_POINT_TYPE = 'EFT' and joins the contact point back to the party through OWNER_TABLE_NAME = 'HZ_PARTIES' and OWNER_TABLE_ID = BRANCHPARTY.PARTY_ID.

The join to HZ_CONTACT_POINTS is written as an outer join on EFT.STATUS (+) = 'A', so parties without an active EFT contact point are still returned with null EFT values. This polymorphic owner construction is characteristic of TCA contact points and means the view depends on the party-to-contact-point relationship rather than on any AR-specific EFT table.

Key Columns

• BANK_PARTY_ID — the PARTY_ID of the bank or branch party from HZ_PARTIES. This is the logical key linking the EFT data to the bank record used by payment and remittance processes.
• EFT_USER_NUMBER — the user number or beneficiary identifier held on the EFT contact point; the value typically transmitted in an EFT or direct-debit message to identify the account holder or user at the bank.
• EFT_SWIFT_CODE — the SWIFT/BIC identifier for the bank, sourced from the same EFT contact point record. This column is the direct match for the "eft_swift_code" search term and is the value consumers read when they need the institution's international routing code.

Because both EFT columns originate from a single contact point row, EFT_USER_NUMBER and EFT_SWIFT_CODE are logically paired; a party with multiple active EFT contact points can produce more than one row.

Common Use Cases and Queries

Typical usage covers EFT reporting, SWIFT code lookup, and validation of TCA setup. A basic query retrieving SWIFT and user numbers for a bank party is:

• SELECT bank_party_id, eft_user_number, eft_swift_code FROM apps.ar_cba_eft_user_number_v WHERE eft_swift_code IS NOT NULL;
• SELECT v.bank_party_id, v.eft_swift_code, p.party_name FROM apps.ar_cba_eft_user_number_v v, apps.hz_parties p WHERE v.bank_party_id = p.party_id ORDER BY p.party_name;
• SELECT bank_party_id, eft_swift_code FROM apps.ar_cba_eft_user_number_v WHERE bank_party_id = :party_id;

Analysts use these queries to reconcile bank records against expected SWIFT codes, to drive EFT payment file extracts, and to troubleshoot missing or duplicated EFT contact point data introduced during bank setup. Where the view returns no rows for an expected party, the cause is usually an absent or inactive EFT contact point in HZ_CONTACT_POINTS rather than a defect in the view.