Search Results quotation_status

Overview

APPS.PJM_PROJECT_QUOT_V is a reporting view within the Oracle E-Business Suite PJM — Project Manufacturing product family. Its documented purpose is to expose project-related quotation information for consumption by the Web Inquiry interface. Rather than serving as a transactional entity, the view functions as a denormalized, read-only projection that joins procurement quotation data to the project and task identifiers required for project-aware inquiry screens.

Because quotation activity is natively owned by Oracle Purchasing (PO), the view straddles two functional domains: it derives its core records from PO_HEADERS and PO_LINES, while overlaying the PROJECT_ID and TASK_ID context needed by Project Manufacturing. The view is documented as VALID in the APPS schema and is surfaced through the Oracle ETRM (E-Business Suite Technical Reference Manual) for both 12.1.1 and 12.2.2.

Underlying Base Objects

The ETRM metadata for 12.2.2 documents the following referenced base objects:

• PO_HEADERS_ALL (synonym) — supplies quotation headers, including type, status, and class lookup codes, dates, vendor, agent, and the FROM_HEADER_ID linkage to the originating RFQ.
• PO_LINES_ALL (synonym) — provides the line records that carry the project and task references.
• PO_VENDORS (view) — resolves the supplier identifier into the SUPPLIER_NAME attribute.
• PO_LOOKUP_CODES (view) — decodes status, subtype, and class lookup codes into displayable field values.
• PO_INQ_SV (package) — supplies the GET_PERSON_NAME function used to resolve the buyer’s name.
• FND_GLOBAL (package) — provides the session context used by the underlying objects to enforce multi-org and responsibility security.

Additional base synonyms referenced in the documented view text include PO_HEADERS (aliased twice as POH and POH1) and PO_LINES, alongside three aliases of PO_LOOKUP_CODES (POLC, POLC1, POLC2). The SQL applies outer joins ((+) syntax) to the lookup, vendor, and RFQ-header joins, and restricts output with POH.TYPE_LOOKUP_CODE = 'QUOTATION', ensuring only quotation documents are returned.

Key Columns

• PROJECT_ID / TASK_ID — the project and task context for the quotation line, enabling inquiry filters by project.
• PO_HEADER_ID — primary identifier of the quotation document.
• QUOTATION_NUMBER (SEGMENT1) — the human-readable quotation number.
• QUOTATION_TYPE — decoded quotation subtype (defaulting to STANDARD).
• QUOTATION_CLASS — decoded class code (defaulting to CATALOG).
• QUOTATION_STATUS — decoded status (defaulting to 'I' when the status lookup code is null).
• RFQ_ID / RFQ_NUMBER — the originating RFQ header, derived via the FROM_HEADER_ID self-join to PO_HEADERS.
• EFFECTIVE_DATE / EXPIRATION_DATE — the start and end dates of the quotation.
• SUPPLIER_ID / SUPPLIER_NAME — vendor identity and name.
• BUYER_ID / BUYER_NAME — the purchasing agent and the name resolved by PO_INQ_SV.GET_PERSON_NAME.

Common Use Cases and Queries

The view is most commonly queried to present project quotations in inquiry and reporting dashboards, and to reconcile quotation activity against the RFQs from which they originated.

• Project inquiry: listing all active quotations for a given project, with supplier, buyer, and status visible in a single query.
• RFQ traceability: grouping quotations by RFQ_NUMBER to measure response coverage.
• Expiry monitoring: filtering on EXPIRATION_DATE to flag quotations approaching expiry.

Representative query:

SELECT quotation_number,
       quotation_type,
       quotation_status,
       supplier_name,
       buyer_name,
       effective_date,
       expiration_date
FROM   apps.pjm_project_quot_v
WHERE  project_id = :p_project_id
  AND  expiration_date >= SYSDATE
ORDER BY quotation_number;

To trace quotations back to their RFQs:

SELECT rfq_number,
       quotation_number,
       supplier_name,
       quotation_status
FROM   apps.pjm_project_quot_v
WHERE  rfq_id IS NOT NULL
ORDER BY rfq_number, quotation_number;

Because the view is a join-heavy projection rather than a keyed entity, queries should always be constrained by project, supplier, or date predicates to avoid full scans over the underlying purchasing tables.