Search Results beneficiary_party




Overview
Explore in AI Chat

Overview

APPS.XTR_EFT_CREDITS_V is a reporting view in the Oracle E-Business Treasury (ETRM) module, shipped in Oracle EBS 12.1.1 and 12.2.2. It exposes the credit-side (outgoing) cashflows that are eligible for electronic funds transfer (EFT) settlement. The view consolidates and nets deal settlement amounts so that downstream EFT payment processing, bank file generation, and settlement reconciliation reports obtain a single aggregated figure per beneficiary account, settlement date, and currency.

The view is primarily consumed by the settlement and payment execution components of Treasury, and is commonly inspected by implementers and support analysts investigating settlement discrepancies, beneficiary mapping issues, and netting behaviour. Because it derives its content from XTR_DEAL_DATE_AMOUNTS_V and applies built-in filters, it always returns only transactions flagged for settlement and multi-transaction settlement.

Underlying Base Objects

The documented referenced base objects for this view are XTR_DEAL_DATE_AMOUNTS_V (VIEW) and XTR_USER_ACCESS (PACKAGE).

  • XTR_DEAL_DATE_AMOUNTS_V — the primary source view supplying deal, cashflow, account, counterparty, netting, and settlement attributes. XTR_EFT_CREDITS_V filters and aggregates this data.
  • XTR_USER_ACCESS — the security package used within the ETRM framework to enforce company and counterparty access restrictions, ensuring users see only the settlement data they are authorised to view.

The view applies two predicates to the source: TRANS_MTS = 'Y' (transaction participates in multi-transaction settlement) and SETTLE = 'Y' (line is flagged for settlement). It is itself referenced by EFT payment and settlement processes within Treasury.

Key Columns

  • SETTLE_AMOUNT — the aggregated cashflow amount. For netted groups it is SUM(CASHFLOW_AMOUNT); for non-netted rows it is the individual CASHFLOW_AMOUNT. The UNION ALL branch ensures only credit (negative) amounts are returned.
  • SETTLE_PARTY — resolves the settlement beneficiary as NVL(BENEFICIARY_PARTY, CPARTY_CODE). This is the column most relevant to searches for "beneficiary_party": it exposes the beneficiary party identifier used to route EFT credits, defaulting to the counterparty code when no explicit beneficiary is defined.
  • CPARTY_ACCOUNT_NO — the settlement account, derived as NVL(BENEFICIARY_ACCOUNT_NO, CPARTY_ACCOUNT_NO). This is the beneficiary bank account used for the credit.
  • CPARTY_CODE — the underlying counterparty code, retained alongside SETTLE_PARTY for reference.
  • ACCOUNT_NO — the internal Treasury/company account.
  • ACTUAL_SETTLEMENT_DATE — the value date on which the credit settles.
  • NETOFF_NUMBER and NETOFF_GROUP_FLAG — the netting group identifiers; NETOFF_NUMBER is NOT NULL for the aggregated branch.
  • CURRENCY, COMPANY_CODE, SETTLEMENT_ACTIONED, TRANS_MTS — currency, owning company, settlement action flag, and multi-transaction settlement indicator.

Common Use Cases and Queries

Typical uses include extracting outstanding EFT credits for a payment run, validating netting per beneficiary, and investigating failed or mismatched beneficiary mappings. A representative query:

  • List all pending EFT credits by beneficiary: SELECT settle_party, cparty_account_no, currency, actual_settlement_date, settle_amount FROM apps.xtr_eft_credits_v WHERE company_code = :p_company AND settlement_actioned = 'N' ORDER BY actual_settlement_date;
  • Reconcile netted versus non-netted credits: SELECT netoff_number, netoff_group_flag, SUM(settle_amount) FROM apps.xtr_eft_credits_v GROUP BY netoff_number, netoff_group_flag;
  • Trace beneficiary resolution: filter on SETTLE_PARTY where CPARTY_CODE differs, indicating an explicit beneficiary party was used instead of the default counterparty.

Because only negative cashflows pass the HAVING/WHERE filters, the view represents credits exclusively, complementing the corresponding debit-side view used for collections and receipts.