Search Results xtr_a_party_defaults_v

Overview

XTR_A_PARTY_DEFAULTS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the XTR (Treasury) product family and available in both 12.1.1 and 12.2.2. Its status is VALID, indicating a compiled, functioning database object registered in the ETRM metadata repository. The view exposes party-level defaulting attributes used to drive the automatic population of deal and transaction parameters during Treasury deal entry.

In Treasury processing, counter-party-specific defaults reduce manual keying and enforce consistent treatment of interest settlement, principal settlement, tax, and brokerage across deals. XTR_A_PARTY_DEFAULTS_V presents these defaults in a flat, query-friendly structure suitable for reporting layers, custom concurrent programs, and integration extracts. Because the view is defined as a simple projection of a single base table, it introduces no join overhead or aggregation and can be queried directly by reports and interfaces that require read-only access to party defaulting rules.

Underlying Base Objects

The view resolves against a single documented base object, XTR_A_PARTY_DEFAULTS, exposed through a synonym in the APPS schema. The definition is a straight SELECT of all significant columns from that table, with no WHERE clause, DISTINCT, GROUP BY, or function-based transformations. The view therefore returns one row for every row present in XTR_A_PARTY_DEFAULTS and inherits the table's transactional columns unchanged.

Because the relationship between view and table is one-to-one and unfiltered, the view should be treated as a presentation alias rather than a separate data source. DML against the base table is reflected immediately in the view, and no materialization occurs. Any performance characteristics observed at the table level—index usage on columns such as PARTY_CODE or the audit columns—carry through unmodified.

Key Columns

The view exposes the following significant columns, each corresponding directly to the underlying table:

• TRANSACTION_NUMBER — Transaction identifier associated with the default record.
• PARTY_CODE — Counterparty identifier to which the defaulting rules apply.
• DEAL_TYPE / DEAL_SUBTYPE — The deal classification for which the defaults are valid.
• PRODUCT_TYPE — Treasury product context governing the default set.
• DFLT_PRINCIPAL_ACTION / DFLT_INTEREST_ACTION — Default actions applied to principal and interest processing.
• FREQ_INTEREST_SETTLED — Settlement frequency for interest.
• INTEREST_SETTLED_BY / PRINCIPAL_SETTLED_BY — Party responsible for each settlement stream.
• TAX_REFERENCE / BROKERAGE_REFERENCE — Reference values for tax and brokerage handling.
• DEFAULT_TYPE — Classification of the default record.
• SETTLEMENT_DEFAULT_CATEGORY, TAX_CATEGORY, BROKERAGE_CATEGORY — Category codes governing each domain of defaulting.
• AUDIT_INDICATOR / AUDIT_DATE_STORED — Audit-related flags and timestamps.
• UPDATED_BY / UPDATED_ON / CREATED_BY / CREATED_ON — Standard EBS who-columns supporting traceability.

Common Use Cases and Queries

Typical scenarios include verifying the defaults configured for a given counterparty, auditing who changed defaulting behavior for a product type, and extracting party defaults into a downstream deal-entry or reporting system. The following sample retrieves all defaults for a specific party:

• SELECT PARTY_CODE, DEAL_TYPE, DEAL_SUBTYPE, PRODUCT_TYPE, DFLT_PRINCIPAL_ACTION, DFLT_INTEREST_ACTION, INTEREST_SETTLED_BY, PRINCIPAL_SETTLED_BY FROM XTR_A_PARTY_DEFAULTS_V WHERE PARTY_CODE = :party_code;
• SELECT PARTY_CODE, DEFAULT_TYPE, SETTLEMENT_DEFAULT_CATEGORY, TAX_CATEGORY, BROKERAGE_CATEGORY FROM XTR_A_PARTY_DEFAULTS_V WHERE DEAL_TYPE = :deal_type AND PRODUCT_TYPE = :product_type;
• SELECT PARTY_CODE, UPDATED_BY, UPDATED_ON, AUDIT_INDICATOR, AUDIT_DATE_STORED FROM XTR_A_PARTY_DEFAULTS_V ORDER BY UPDATED_ON DESC;

Reports joining the view to party or deal-lookup views should join on PARTY_CODE and the deal classification columns to avoid ambiguous matches. Where historical defaulting changes are required, the audit indicator and audit date stored columns should be considered in conjunction with standard EBS audit history mechanisms.