Results for “pofv_requests_for_quotation”

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

Overview

The APPS.POFV_REQUESTS_FOR_QUOTATION view is a Purchasing (PO) module database object that presents Request for Quotation (RFQ) header information in a denormalized, reporting-friendly format. It is a "retrofitted" view, meaning it was originally designed for an earlier Oracle EBS forms and reporting architecture (notably Oracle Reports and the Oracle Business Intelligence/Discoverer layer) and has been carried forward into Oracle EBS 12.1.1 and 12.2.2. Its primary role is to expose RFQ and quotation header data—vendor details, buyer information, currency, terms, freight, and shipping attributes—combined with lookup descriptions and descriptive flexfield references, so that reports, concurrent programs, and integrations can retrieve RFQ information without navigating the underlying normalized tables.

The view is owned by the APPS schema and holds VALID status. The embedded lookup syntax (for example, '_LA:QU.QUOTATION_CLASS_CODE:PO_LOOKUP_CODES:QUOTATION CLASS:DISPLAYED_FIELD') indicates that the view was designed to drive descriptive or flexfield-enabled reporting, where lookup codes are resolved through the PO lookup types and the FOB code through AR_LOOKUPS.

Underlying Base Objects

The view is defined over a substantial set of base tables, synonyms, and views. The central driving table is PO_HEADERS_ALL (aliased QU), restricted to records where TYPE_LOOKUP_CODE = 'RFQ'. This restriction ensures only RFQ documents are returned. Supporting joins include:

• HR_ALL_ORGANIZATION_UNITS and FINANCIALS_SYSTEM_PARAMS_ALL for operating unit context; MTL_PARAMETERS for the inventory organization code.
• PO_DOCUMENT_TYPES_ALL for the RFQ type name; AP_TERMS for payment terms; FND_CURRENCIES_VL for currency name; GL_DAILY_CONVERSION_TYPES for the rate type description.
• PER_PEOPLE_F for the buyer (agent) details; HR_LOCATIONS for bill-to and ship-to locations; ORG_FREIGHT for ship-via descriptions.
• PO_VENDORS, PO_VENDOR_SITES_ALL, and PO_VENDOR_CONTACTS for supplier name, site code, and contact name.
• Packages FND_GLOBAL, HR_GENERAL, HR_PERSON_NAME, and HR_SECURITY, which support operating unit and security context within the view's runtime behavior.

Most joins use outer-join syntax (the (+) operator) for terms, currency, rate type, agent, and vendor-related tables, allowing RFQ header records to be returned even when some referenced attributes are absent.

Key Columns

• PO_HEADER_ID, SEGMENT1, ORG_ID — primary key, RFQ document number, and operating unit identifier.
• NAME (organization name), TYPE_NAME (RFQ document type).
• COMMENTS, START_DATE, END_DATE, RFQ_CLOSE_DATE — RFQ descriptive and date information.
• RATE, RATE_DATE, CURRENCY_CODE, RATE_TYPE — currency conversion context.
• VENDOR_ID, VENDOR_NAME, VENDOR_SITE_ID, VENDOR_SITE_CODE, VENDOR_CONTACT_ID — supplier identification.
• AGENT_ID, EMPLOYEE_NUMBER, FULL_NAME — the buyer responsible for the RFQ.
• BILL_TO_LOCATION_ID, SHIP_TO_LOCATION_ID, SHIP_VIA_LOOKUP_CODE, FREIGHT_TERMS_LOOKUP_CODE, FOB_LOOKUP_CODE — logistics attributes.
• TERMS_ID/NAME, PRINT_COUNT, PRINTED_DATE, REPLY_METHOD_LOOKUP_CODE, REPLY_DATE — procurement and response tracking attributes.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — standard audit columns.

Common Use Cases and Queries

The view is typically queried for RFQ reporting, buyer dashboards, and vendor solicitation extracts. A representative query retrieves open RFQs with supplier and buyer details:

SELECT segment1, name, vendor_name, full_name,
       rfq_close_date, currency_code, rate
FROM   apps.pofv_requests_for_quotation
WHERE  org_id = :p_org_id
AND    rfq_close_date >= SYSDATE
ORDER BY rfq_close_date;

Because lookup codes are exposed as descriptive fields, reports can present valid meanings directly. Typical consumers include custom Oracle Reports, OBIEE/Discoverer queries, and interface programs that need to reconcile RFQ headers against supplier responses. In 12.1.1 and 12.2.2 the view behavior is consistent, though multi-org and MOAC security should be applied through ORG_ID filtering using FND_GLOBAL context. Teams extending or migrating reports should treat this view as a compatibility layer over PO_HEADERS_ALL and verify that any lookup-based descriptive fields remain available in their target release.