Results for “cparty_code”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

XTR_CPARTY_ACCT_LOV_V is an APPS-owned database view within the Oracle E-Business Suite Treasury (XTR) module. It is an operational, read-only construct that presents a consolidated list of authorized counterparty bank accounts, exposing the bank account short name, the account number, and the associated bank name for each counterparty. As its name implies, the object is designed to serve as a List of Values (LOV) source: its shape and filtering logic make it suitable for populating an LOV region on an Oracle Forms-based Treasury screen or for supplying reference data to concurrent programs, reports, and inbound/outbound interfaces that require a validated pick-list of counterparty accounts.

Because the view returns only accounts that satisfy Treasury's authorization and set-off rules, it does not expose the full population of bank accounts defined in the system. Instead, it presents a curated, business-ready subset. This behavior is consistent with the role of a Treasury LOV, where users and downstream processes must be prevented from selecting unauthorized accounts or internal set-off (netting) accounts that are not intended for external counterparty transactions.

Underlying Base Objects

The documented metadata identifies two referenced base objects:

• XTR_BANK_ACCOUNTS_V (VIEW) — the primary source of account-level data. It supplies the counterparty code, currency, bank short code, account number, authorization flag, set-off indicator, bank code, and bank name used throughout the definition.
• XTR_PARTY_INFO (SYNONYM) — referenced in the second branch of the UNION to resolve a bank short name when the bank name is not available on the account record itself.

Structurally, the view is defined as a UNION of two SELECT statements drawn from XTR_BANK_ACCOUNTS_V. Both branches enforce the same predicates: NVL(AUTHORISED,'N') = 'Y' and NVL(SETOFF_ACCOUNT_YN,'N') <> 'Y'. The first branch returns rows where a bank name is present on the account record (BANK_NAME IS NOT NULL). The second branch covers the complementary case (BANK_NAME IS NULL) and performs an outer join to XTR_PARTY_INFO on A.BANK_CODE = B.PARTY_CODE (+) so that the bank's short name is substituted as the BANK_NAME value. This two-branch construction guarantees a bank name is returned wherever one can be derived, while keeping the single-select contract of an LOV source.

Key Columns

• CPARTY_CODE — the counterparty identifier, mapped from PARTY_CODE. It identifies the legal entity or institution with which the Treasury transaction is conducted and is the principal key used to associate the account with a counterparty.
• CURRENCY — the currency in which the bank account is denominated. Treasury operations are frequently multi-currency, so this column supports currency-restricted account selection.
• ACCOUNT_REFERENCE — the bank account short name, aliased from BANK_SHORT_CODE. This is the user-facing, human-readable label typically displayed in the LOV.
• ACCOUNT_NUMBER — the external bank account number, carried through unchanged for display and matching.
• BANK_NAME — the name of the bank holding the account. In the first UNION branch it originates from the account view; in the second it is derived from the party information record, so consumers receive a consistent, non-null bank name.

Common Use Cases and Queries

The view is most often referenced when building or extending Treasury LOVs and when producing reconciliation or payment instruction output that must be limited to authorized, non-set-off accounts. A typical retrieval filtered by counterparty and currency follows:

• SELECT cparty_code, currency, account_reference, account_number, bank_name FROM xtr_cparty_acct_lov_v WHERE cparty_code = :p_party AND currency = :p_currency ORDER BY account_reference;
• SELECT account_reference, account_number, bank_name FROM xtr_cparty_acct_lov_v WHERE cparty_code = :p_party;
• SELECT DISTINCT cparty_code FROM xtr_cparty_acct_lov_v ORDER BY cparty_code;

Because the view is defined over a view, no DML is permitted against it; it is strictly a query surface. Performance is governed by the cost of evaluating XTR_BANK_ACCOUNTS_V twice and performing the outer join to XTR_PARTY_INFO, so queries should be constrained by CPARTY_CODE and CURRENCY wherever possible. Organizations customizing Treasury LOVs or building interfaces should treat this view as a supported, upgrade-safe access path rather than querying the underlying account view directly, since the authorization and set-off filtering rules encoded here represent the documented business intent.