Results for “unique_id”

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

Overview

FII_AP_DISC_AVAL_DTL_SUMMARY_V is a Financial Intelligence (FII) reporting view in Oracle E-Business Suite, documented as belonging to the FII - Financial Intelligence product, which is flagged as obsolete in the ETRM reference for releases 12.1.1 and 12.2.2. The view exists specifically to support the Payables Discount Available Detail Drill Downs Portlet, an FII dashboard component that allowed users to navigate from an aggregated "discount available" figure down to the individual invoices contributing to that balance. In practice, the view presents one row per qualifying Payables record, exposing operating unit, supplier (trading partner), invoice header, and discount amount and date attributes in a single flat structure that is directly consumable by the portlet's drill-down query layer.

Because the view is a thin projection rather than a complex join, its purpose is standardization: it renames and maps columns from its source object into the terminology expected by FII portlet definitions. The metadata notes the object is "Not implemented in this database," meaning the deployment investigated did not contain the view or its dependencies, which is consistent with the obsolescence of the FII product line in later 12.x environments.

Underlying Base Objects

The documented view text selects all columns from a single object, FII_AP_DISCOUNTS_SUMMARY, filtered by the predicate WHERE RECORD_TYPE = 'R'. No other base tables or joins are documented in the ETRM metadata, and the "Referenced base objects" field lists none. This makes the relationship a straightforward one-to-one or one-to-many projection depending on the cardinality of FII_AP_DISCOUNTS_SUMMARY itself. The filter on RECORD_TYPE restricts the result set to a particular record classification, typically the detail-level ("R" for regular/detail) rows, excluding aggregated or header-level rows that the same summary object may also store.

Key Columns

• OPERATING_UNIT_PK_KEY / OPERATING_UNIT_NAME — the operating unit owning the invoice, exposed as both a surrogate key for joins and a descriptive name for display.
• TRADING_PARTNER_PK_KEY / TRADING_PARTNER_NAME — supplier identifier and name, presented in FII trading-partner nomenclature rather than the native AP supplier naming.
• INVOICE_PK_KEY / INVOICE_NUMBER / INVOICE_DATE — the invoice unique identifier, the human-readable invoice number, and the invoice date; INVOICE_PK_KEY is sourced from INVOICE_UNIQUE_IDENTIFIER in the base object.
• UNIQUE_ID — mapped from RECORD_ID, providing the drill-down row identifier.
• INVOICE_AMOUNT — the invoice amount used to contextualize the discount.
• DISCOUNT_AVAILABLE — the discount amount currently available for capture on the invoice.
• DISCOUNT_DATE — the date through which the discount may be taken. This is the column most commonly searched, as it drives the "discount available" aging window and is typically the ordering and filtering key in drill-down portlet queries.

Common Use Cases and Queries

The primary use case is the Payables Discount Available Detail Drill Downs Portlet, which resolves a period-end discount-available figure into the underlying invoice list. Because the view is obsolete and often unimplemented, queries should be validated against the target instance before use. A representative query follows:

SELECT operating_unit_name,
       trading_partner_name,
       invoice_number,
       invoice_date,
       discount_available,
       discount_date
  FROM fii_ap_disc_avail_dtl_summary_v
 WHERE discount_date >= :p_from_date
   AND discount_date <= :p_to_date
 ORDER BY discount_date, trading_partner_name;

A second pattern filters by operating unit and supplier to reconcile a single trading partner's available discounts, and a third aggregates totals by operating unit for dashboard summaries. In all cases, the DISCOUNT_DATE predicate is the most selective and should be indexed or restricted to a narrow range, since the view itself performs no filtering other than the RECORD_TYPE restriction inherited from its definition.