Search Results unid_amount_prim




Overview
Explore in AI Chat

Overview

The view APPS.FII_AR_RCT_AGING_BASE_MV_P_V is a reporting-layer projection over the materialized view FII_AR_RCT_AGING_BASE_MV within the Oracle E-Business Suite Receivables (AR) intelligence schema. It exposes accounts receivable receipts aging data that has been staged and pre-aggregated for consumption by Oracle Business Intelligence (OBIEE) and other analytical reporting tools. The suffix convention "MV_P_V" indicates a view defined over a materialized view ("MV") used as the presentation ("P") layer ("V") for a specific subject area.

The view presents one row per combination of time period, party, customer account, collector, operating unit, and receipt classification, together with pre-computed aging bucket amounts and counts. Its principal purpose is to decouple dashboard and report queries from the physical materialized view, providing a stable column list and an abstraction point for refresh and tuning. The _PRIM suffix on monetary columns denotes amounts expressed in the primary ledger currency of the operating unit, as opposed to a converted or reporting currency.

Underlying Base Objects

The view is defined over a single documented source object:

  • FII_AR_RCT_AGING_BASE_MV — the aged receipts base materialized view, which consolidates receipt application and unapplied balances into pre-aggregated aging buckets.

The view definition is a straight projection with no joins, filters, or calculated expressions. No additional base tables are documented for this object; all supporting detail and aggregation logic resides one level below in the materialized view. Consequently, the refresh characteristics, snapshot dependencies, and row-level security behavior of the materialized view are inherited directly by this view.

Key Columns

  • TIME_ID, PERIOD_TYPE_ID — Identify the reporting period and the period type (for example, day, week, or accounting period) against which aging is measured.
  • PARENT_PARTY_ID, PARTY_ID — Support party hierarchy roll-ups, allowing detail parties to aggregate to a parent trading partner.
  • CUST_ACCOUNT_ID, COLLECTOR_ID, ORG_ID — The customer account, assigned collector, and operating unit dimensions used to scope collections and credit reporting.
  • CLASS_CODE, CLASS_CATEGORY — Receipt classification attributes used to segment results by business category.
  • AGING_BUCKET_1_AMOUNT_PRIM through AGING_BUCKET_3_AMOUNT_PRIM — Primary-currency amounts allocated to each aging bucket, with corresponding AGING_BUCKET_n_COUNT columns recording transaction counts per bucket.
  • UNID_AMOUNT_PRIM — Primary-currency amount of unidentified receipts not yet associated with a customer.
  • UNAPP_AMOUNT_PRIM — Primary-currency amount of unapplied receipts, the column most commonly referenced in unapplied-cash analysis. This is the object of the search term "unapp_amount_prim."
  • TOTAL_UNAPPLIED_AMOUNT_PRIM, TOTAL_UNAPPLIED_COUNT — Aggregate unapplied value and count across included categories.
  • GID — Internal grouping identifier used by the reporting layer to enforce consistent aggregation.

Common Use Cases and Queries

A typical application is reporting unapplied and unidentified cash by operating unit and collector for a given period and currency:

SELECT org_id, collector_id, time_id,
       SUM(unapp_amount_prim)  AS unapplied_primary,
       SUM(unid_amount_prim)   AS unidentified_primary,
       SUM(total_unapplied_amount_prim) AS total_unapplied
FROM   apps.fii_ar_rct_aging_base_mv_p_v
WHERE  period_type_id = :p_period_type
  AND  time_id        = :p_time_id
GROUP BY org_id, collector_id, time_id;

A second common pattern examines aging distribution for customer accounts exceeding a threshold, ranking buckets to prioritize collection activity. A third pattern joins the view to party or collector dimension views to resolve names for presentation. Because the view exposes only _PRIM currency columns, any requirement for reporting-currency balances must be met from a companion materialized view or by currency conversion downstream.

Queries should constrain TIME_ID and PERIOD_TYPE_ID aggressively, since the underlying materialized view holds all periods and parties. Users requiring fresh figures should coordinate with the materialized view refresh schedule, as the view itself carries no independent data.