Search Results contact_area_code

Overview

The APPS.OKX_RCPT_METHOD_ACCOUNTS_V view is a Contracts Integration (OKX) object that exposes customer bank account information for use in receipt method and payment instrument processing within Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to contain bank accounts for customers, presenting a flattened, reporting-friendly projection of customer site use and bank account data. Rather than forcing callers to join multiple receivables, payments, and trading community tables directly, the view consolidates the relevant account, branch, and remittance attributes into a single query surface.

The view is significant because it links customer-facing site use records to internal bank account definitions, enabling receipt method configuration, automatic receipt application, and contract-related payment routing. It exposes both functional identifiers (customer, site use, bank account, branch) and descriptive attributes (bank name, account name, account number) alongside status and currency information. Notably, the view also projects contact-level columns such as CONTACT_FIRST_NAME, which explains why a search for "contact_first_name" surfaces this object. The contact columns allow downstream consumers to retrieve remittance or notification contact details associated with the account holder without a separate lookup.

Underlying Base Objects

The ETRM 12.2.2 metadata documents an unusually broad dependency footprint. Referenced base objects include FND_GLOBAL (package), FND_LOOKUPS (view), HZ_CUST_SITE_USES_ALL, HZ_PARTIES, IBY_CREDITCARD, IBY_CREDITCARD_ISSUERS_VL, IBY_EXTERNAL_PAYERS_ALL, IBY_EXT_BANK_ACCOUNTS, and IBY_PMT_INSTR_USES_ALL. This reflects the fact that customer receipt methods span the Trading Community Architecture (HZ), the Payments (IBY) schema, and Applications Foundation (FND) lookups.

The documented view text joins HZ_CUST_SITE_USES_ALL (SITE), CE_BANK_ACCOUNTS (AP_ACCT), CE_BANK_BRANCHES_V (AP_BANK), and IBY_EXT_BANK_ACCOUNTS (AP_ACCT_USES). The principal join is an outer join between site use and external bank accounts on SITE_USE_ID = EXT_BANK_ACCOUNT_ID, with branches linked to bank accounts via BRANCH_PARTY_ID = BANK_BRANCH_ID, and external bank accounts linked to internal bank accounts via EXT_BANK_ACCOUNT_ID = BANK_ACCOUNT_ID. The outer join ensures accounts without an assigned customer site use are still returned.

Key Columns

• NAME / DESCRIPTION — Composite display values built from bank account name, site location, and account number.
• BANK_ACCOUNT_ID / BANK_ACCOUNT_NUM / BANK_BRANCH_ID — Core identifiers for the account and its branch.
• CUSTOMER_ID / CUSTOMER_SITE_USE_ID — Trading Community customer and site use references.
• CURRENCY_CODE / MULTI_CURRENCY_FLAG / RECEIPT_MULTI_CURRENCY_FLAG — Currency and multi-currency receipt handling indicators.
• START_DATE_ACTIVE / END_DATE_ACTIVE / STATUS — Account effective dating and a derived status (A or I) computed from the start and end dates relative to SYSDATE.
• ORG_ID — Multi-org operating unit context.
• CONTACT_FIRST_NAME, CONTACT_MIDDLE_NAME, CONTACT_LAST_NAME, CONTACT_PREFIX, CONTACT_TITLE, CONTACT_AREA_CODE, CONTACT_PHONE — Contact/remittance attributes surfaced directly on the view.

Common Use Cases and Queries

Typical uses include receipt method validation, payment instrument selection, and contract receipt reporting. A basic query retrieves active accounts for a customer:

• SELECT bank_account_id, bank_name, bank_account_num, contact_first_name, status FROM okx_rcpt_method_accounts_v WHERE customer_id = :p_customer_id AND status = 'A';
• SELECT customer_site_use_id, name, currency_code, receipt_multi_currency_flag FROM okx_rcpt_method_accounts_v WHERE org_id = :p_org_id AND TRUNC(SYSDATE) BETWEEN start_date_active AND NVL(end_date_active, TRUNC(SYSDATE));
• SELECT bank_account_id, contact_last_name, contact_phone FROM okx_rcpt_method_accounts_v WHERE bank_account_num = :p_acct_num;

Because the view spans HZ and IBY objects, queries should filter on customer or account identifiers to keep performance acceptable. The derived STATUS and outer joins make it suitable for reporting that must include accounts lacking an assigned site use.