Search Results pot_contract_amount




Overview
Explore in AI Chat

Overview

APPS.POA_BIS_SAVINGS_RPT_V is a reporting view in the Oracle E-Business Suite Procurement family, built on the Oracle Procurement Analytics (POA) data model. It exposes the contents of the savings reporting table POA_BIS_SAVINGS_RPT, presenting pre-aggregated procurement performance metrics used by spend and savings analysis dashboards. The object is registered under the APPS schema and follows standard EBS naming conventions: the POA prefix identifies it as a Procurement Analytics object, BIS denotes Business Intelligence System lineage, and the _V suffix confirms it is a view rather than a table.

Its role is to serve as a convenient, security-neutral read interface for the underlying savings report structure. Rather than querying the physical table directly, BI Publisher reports, custom concurrent programs, and third-party integrations reference this view to obtain purchase amount, contract classification, and saving figures. Because the view is defined as a simple projection, column names and positions are identical to the base table, insulating consumers from changes in the physical table’s storage or partitioning without altering the published interface.

Underlying Base Objects

The view is defined by a straightforward SELECT statement, without joins, filters, or aggregation:

  • POA_BIS_SAVINGS_RPT — the sole documented base object. Every column in the view maps one-to-one to a column of this table, and the view applies no WHERE clause, so it returns all rows present in the table.

Although the view itself performs no joins, the base table is populated by the Procurement Analytics data collection process, which in turn draws from purchasing documents, distributions, suppliers, and items. ETRM does not document any other referenced base objects for this view, so dependencies on the broader PO/POA schema must be traced through the population program rather than the view definition.

Key Columns

Common Use Cases and Queries

Typical consumers include procurement savings dashboards, contract compliance analysis, and ad hoc spend reviews. A common query isolates contract-leverage opportunities by comparing potential contract amount against actual non-contract spend:

  • SELECT supplier_id, SUM(purchase_amount), SUM(non_contract_amount), SUM(pot_contract_amount), SUM(potential_saving) FROM apps.poa_bis_savings_rpt_v GROUP BY supplier_id ORDER BY SUM(potential_saving) DESC;
  • SELECT document_type_code, item_id, potential_saving FROM apps.poa_bis_savings_rpt_v WHERE pot_contract_amount > 0 AND purchase_creation_date >= :p_start_date;

Because the view exposes no row-level security, reports requiring data restriction must apply operating unit or buyer predicates explicitly. The PROGRAM_ID, REQUEST_ID, and LAST_UPDATE_DATE columns allow consumers to identify the concurrent request that last populated each row, which is useful when validating data freshness before publishing analytics.