Results for “cparty_account_no”

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

Overview

XTR_EFT_CREDITS_V is a Treasury (XTR) reporting view owned by the APPS schema that consolidates credit-side cash flows requiring electronic funds transfer (EFT) settlement. It is a negative-amount filter view: every row it returns represents an outflow (debit to the company, credit to the counterparty), which is why the view is named for "credits" from the counterparty's perspective. The view is built on top of XTR_DEAL_DATE_AMOUNTS_V and XTR_USER_ACCESS, and it is primarily consumed by Treasury settlement, netting, and bank file generation processes that must identify which parties are to be paid on a given value date.

In Oracle EBS 12.1.1 and 12.2.2 the view text is unchanged; it remains a pure SQL UNION ALL construct with no procedural logic, making it safe to query directly from custom reports, BI Publisher data templates, and OAF-based Treasury pages.

Underlying Base Objects

• XTR_DEAL_DATE_AMOUNTS_V (VIEW) — supplies all deal-level cash flow amounts, party codes, beneficiary information, settlement dates, currency, and netting attributes. XTR_EFT_CREDITS_V projects and aggregates this view rather than referencing base deal tables directly.
• XTR_USER_ACCESS (PACKAGE) — the documented access-control package used by Treasury views to enforce company and counterparty visibility; it governs which rows a given responsibility may retrieve from the underlying cash flow view.

The view applies the predicate TRANS_MTS = 'Y' AND SETTLE = 'Y', restricting output to transactions that are marked for multi-transfer settlement and flagged for settlement. Its two branches are separated by netting status: rows with a populated NETOFF_NUMBER are grouped and summed, while rows with a null NETOFF_NUMBER are returned individually.

Key Columns

• SETTLE_AMOUNT — for netted rows, SUM(CASHFLOW_AMOUNT) per netting group; for non-netted rows, the raw CASHFLOW_AMOUNT. Always negative, confirming the credit/outflow direction.
• SETTLE_PARTY — derived as NVL(BENEFICIARY_PARTY, CPARTY_CODE). This is the column most often matched when users search for "settle_party": it resolves the party to be paid, preferring the beneficiary where one is defined and falling back to the counterparty code.
• CPARTY_CODE — the underlying counterparty code, retained alongside SETTLE_PARTY for reconciliation back to deal records.
• CPARTY_ACCOUNT_NO — NVL(BENEFICIARY_ACCOUNT_NO, CPARTY_ACCOUNT_NO); the bank account credited on settlement.
• ACCOUNT_NO — the company-side (internal) account.
• ACTUAL_SETTLEMENT_DATE — the value date applied to the cash flow.
• CURRENCY — settlement currency of the cash flow.
• COMPANY_CODE — the Treasury company/legal entity owning the flow.
• NETOFF_NUMBER / NETOFF_GROUP_FLAG — netting reference and indicator; NETOFF_NUMBER is null for individually settled items.
• SETTLEMENT_ACTIONED — whether settlement has already been processed.
• TRANS_MTS — the multi-transfer settlement flag driving the view's filter.

Common Use Cases and Queries

Typical scenarios include producing payment proposals by value date, verifying netting group totals before generating EFT bank files, and reconciling beneficiary versus counterparty identification for payment routing.

List all credit settlements for a specific date and currency:

SELECT settle_party, cparty_account_no, company_code,
       currency, settle_amount, netoff_number
FROM   apps.xtr_eft_credits_v
WHERE  actual_settlement_date = :p_date
AND    currency = :p_currency
AND    settlement_actioned = 'N'
ORDER BY settle_party;

Aggregate net payable by settle party to confirm where the "settle_party" resolution lands:

SELECT settle_party, cparty_code, currency,
       SUM(settle_amount) total_credit
FROM   apps.xtr_eft_credits_v
GROUP BY settle_party, cparty_code, currency;

Isolate netted versus individual items:

SELECT netoff_number, settle_party, SUM(settle_amount)
FROM   apps.xtr_eft_credits_v
WHERE  netoff_number IS NOT NULL
GROUP BY netoff_number, settle_party;

Because SETTLE_PARTY is derived through NVL, reports that must distinguish a true beneficiary from a fallback counterparty should also select CPARTY_CODE and compare the two values.