Search Results po_rfqs_for_quote_all_v




Overview

PO_RFQS_FOR_QUOTE_ALL_V is a PL/SQL view owned by the APPS schema in Oracle E-Business Suite, classified under the PO (Purchasing) product family. Its documented description in the ETRM repository is "10SC ONLY - Retrofitted," indicating that the object originated in an earlier release lineage and was retrofitted for compatibility within the 12.1.1 and 12.2.2 code lines. The view exposes Request for Quotation (RFQ) header records that are eligible for supplier quotation entry, joining each RFQ to its invited vendors and those vendors' sites.

Functionally, the view serves as a reporting and integration surface rather than a transactional entry point. It presents a consolidated, denormalized row set combining RFQ header attributes, status display text, vendor identity, and vendor site information. Because it filters out cancelled RFQs and restricts results to the RFQ document type, consumers receive only active sourcing events that are still open to quote capture. This makes it suitable for downstream quotation portals, buyer worklists, and third-party sourcing integrations that must enumerate open RFQs per supplier.

Underlying Base Objects

The view is defined over five referenced base objects, documented in the 12.2.2 ETRM metadata as follows:

  • PO_HEADERS (synonym) — supplies the RFQ header record, including segment, dates, comments, and status lookup.
  • PO_LOOKUP_CODES (view) — resolves the RFQ or quote status lookup code to a translated display value.
  • PO_RFQ_VENDORS (synonym) — the RFQ-to-vendor assignment (invitation) table, providing vendor and vendor site identifiers.
  • PO_VENDORS (view) — provides the supplier name.
  • PO_VENDOR_SITES_ALL (view) — provides the supplier site code and organization context.

The join structure links PO_HEADERS to PO_LOOKUP_CODES on the status lookup code, then to PO_RFQ_VENDORS on PO_HEADER_ID, and onward to PO_VENDORS and PO_VENDOR_SITES_ALL on their respective vendor and site keys. The view text also references FND_GLOBAL (package), the standard EBS mechanism for resolving the current organization and user context. The join between PO_HEADERS.ORG_ID and PO_VENDOR_SITES_ALL.ORG_ID enforces multi-org consistency so that only vendor sites valid for the RFQ's operating unit are returned.

Key Columns

  • SEGMENT1 — the RFQ document number as entered or generated by the system.
  • DISPLAYED_FIELD — the user-facing status description derived from PO_LOOKUP_CODES for the RFQ/QUOTE STATUS lookup type.
  • RFQ_CLOSE_DATE — the date on which the RFQ stops accepting supplier responses.
  • COMMENTS — free-text remarks captured on the RFQ header.
  • PO_HEADER_ID — the primary key of the RFQ header; the join key back to PO_HEADERS and PO_RFQ_VENDORS.
  • TYPE_LOOKUP_CODE — the document type; the view restricts this to 'RFQ'.
  • APPROVAL_REQUIRED_FLAG — indicates whether the RFQ requires approval before release.
  • VENDOR_ID / VENDOR_NAME — supplier identifier and name for the invited vendor.
  • VENDOR_SITE_ID / VENDOR_SITE_CODE — the specific supplier site invited to respond.
  • QUOTATION_CLASS_CODE — classification of the quotation, such as catalog, blanket, or standard.
  • ORG_ID — the operating unit that owns the RFQ and vendor site association.

Common Use Cases and Queries

Typical uses include building supplier-facing open RFQ lists, calculating RFQs nearing their close date, and feeding external quotation systems. The following sample retrieves open RFQs for a specific supplier, ordered by close date:

SELECT r.segment1, r.displayed_field, r.rfq_close_date,
       r.vendor_name, r.vendor_site_code, r.org_id
  FROM po_rfqs_for_quote_all_v r
 WHERE r.vendor_id = :p_vendor_id
   AND r.rfq_close_date >= SYSDATE
 ORDER BY r.rfq_close_date;

A second pattern counts invited suppliers per open RFQ within an operating unit:

SELECT h.segment1, h.rfq_close_date, COUNT(DISTINCT h.vendor_id) invited_vendors
  FROM po_rfqs_for_quote_all_v h
 WHERE h.org_id = :p_org_id
 GROUP BY h.segment1, h.rfq_close_date;

Because the view already excludes cancelled RFQs and enforces document type and organization consistency, such queries require minimal additional filtering and remain safe for read-only integration use.