Search Results dm_amount_sec

Overview

FII_AR_NET_REC_AGRT_MV_S_V is an APPS-owned database view within the FII (Financial Intelligence) product family in Oracle E-Business Suite 12.1.1 and 12.2.2. The suffix conventions in the object name identify its character: the "MV" segment denotes that the object materializes data derived from a materialized aggregate, the "S" segment indicates a secured (row-level security enabled) variant, and the terminal "V" confirms it is a view rather than a table. The view exposes a comprehensive set of Accounts Receivable net receipt, agreement, and aging metrics at the transaction-time, party, customer account, collector, and operating unit grain.

Its principal role is to serve as a secured reporting surface for AR receipt performance and collection analytics. Because it is the row-level-secured view over the corresponding materialized view, it is the object that BI Publisher reports, Oracle Business Intelligence dashboards, and custom operational reports should reference so that the querying user's data access privileges are enforced through the FII security model.

Underlying Base Objects

The documented view definition selects its entire column list from a single underlying object: FII_AR_NET_REC_AGRT_MV, the financial intelligence materialized view for AR net receipts and agreement metrics. No other base tables, synonyms, or joins appear in the retrieved view text, indicating a thin projection layer. The materialized view itself is understood to be sourced from AR transactional and subledger data — receipt, receipt application, transaction, customer account, and collector reference sources — but those upstream dependencies are not enumerated in the documented metadata for this view.

As a secured view, FII_AR_NET_REC_AGRT_MV_S_V is expected to be paired with an Oracle row-level security policy applied through DBMS_RLS, filtering rows by operating unit, party, or collector domain according to the responsibility or user context. Queries against the secured view therefore return only the subset of materialized rows the session is entitled to see, while direct queries against the base materialized view FII_AR_NET_REC_AGRT_MV would bypass that filtering.

Key Columns

• TIME_ID, PERIOD_TYPE_ID, HEADER_FILTER_DATE — Time dimension keys that identify the reporting period and the as-of filter date for the row.
• PARENT_PARTY_ID, PARTY_ID, CUST_ACCOUNT_ID, COLLECTOR_ID, ORG_ID — The conformance dimensions: customer hierarchy, trading party, customer account, assigned collector, and operating unit.
• CURRENT_BUCKET_1..3_AMOUNT_SEC / _COUNT — Amount and item counts for current (non-past-due) aging buckets.
• PAST_DUE_BUCKET_1..7_AMOUNT_SEC / _COUNT — Amount and item counts for the seven past-due aging buckets.
• CURRENT_OPEN_AMOUNT_SEC, CURRENT_OPEN_COUNT, PAST_DUE_OPEN_AMOUNT_SEC, PAST_DUE_COUNT, TOTAL_OPEN_AMOUNT_SEC, TOTAL_OPEN_COUNT — Open receivable balances and item counts, split by current versus past due.
• WTD_TERMS_OUT_OPEN_NUM_SEC, WTD_TERMS_OUT_CURRENT_NUM_SEC, WTD_DDSO_DUE_NUM_SEC, WTD_DAYS_PAID_NUM_SEC, WTD_TERMS_PAID_NUM_SEC — Weighted days-terms-out, days-sales-outstanding, and days-to-pay measures.
• APP_AMOUNT_SEC, APP_COUNT, TOTAL_RECEIPT_AMOUNT_SEC, TOTAL_RECEIPT_COUNT — Receipt application amounts and counts, including the APP_COUNT metric most frequently referenced in this view.
• INV_AMOUNT_SEC, DM_AMOUNT_SEC, CB_AMOUNT_SEC, BR_AMOUNT_SEC, DEP_AMOUNT_SEC, ON_ACCOUNT_CREDIT_AMOUNT_SEC, UNAPP_DEP_AMOUNT_SEC, PREPAYMENT_AMOUNT_SEC, CLAIM_AMOUNT_SEC, REV_AMOUNT_SEC, REV_COUNT — Receipt type and adjustment breakdowns (invoice, debit memo, chargeback, bank risk, deposit, on-account, unapplied, prepayment, claim, reversal).
• EARNED_DISCOUNT_AMOUNT_SEC, UNEARNED_DISCOUNT_AMOUNT_SEC, BILLED_AMOUNT_SEC, BILLING_ACTIVITY_AMOUNT_SEC, BILLING_ACTIVITY_COUNT, AVG_DD_NUM_SEC — Discount, billing, and average deduction metrics.
• GID, UMARKER — Warehouse-style surrogate key and change-detection marker inherited from the materialized view.

Common Use Cases and Queries

Typical usage includes collector performance scorecards, aging and DSO trend reporting, receipt application and unapplied cash analysis, and drill-through from aggregate dashboards to party or account detail. Because the row set is pre-aggregated by time and party dimensions, queries are inexpensive relative to joining AR base tables directly. A representative query returning application volumes and open balances for a specific period follows:

• SELECT party_id, cust_account_id, collector_id, org_id, TOTAL_OPEN_AMOUNT_SEC, PAST_DUE_OPEN_AMOUNT_SEC, APP_AMOUNT_SEC, APP_COUNT, TOTAL_RECEIPT_AMOUNT_SEC FROM apps.fii_ar_net_rec_agrt_mv_s_v WHERE org_id = :p_org_id AND time_id = :p_time_id AND period_type_id = :p_period_type;
• SELECT collector_id, SUM(PAST_DUE_BUCKET_1_AMOUNT_SEC) pd1, SUM(PAST_DUE_BUCKET_2_AMOUNT_SEC) pd2, SUM(PAST_DUE_BUCKET_7_AMOUNT_SEC) pd7, SUM(WTD_DDSO_DUE_NUM_SEC) dso FROM apps.fii_ar_net_rec_agrt_mv_s_v WHERE time_id = :p_time_id GROUP BY collector_id;
• SELECT party_id, CURRENCY_AGG(APP_COUNT) FROM apps.fii_ar_net_rec_agrt_mv_s_v WHERE header_filter_date BETWEEN :p_from AND :p_to GROUP BY party_id;

All queries should run as an APPS or FII responsibility user so that the underlying row-level security policy is applied, and should constrain TIME_ID and ORG_ID to leverage the materialized view's aggregation grain and avoid full scans.