Search Results closure_status

Overview

PJM_PROJECT_BLANKET_PO_V is an APPS-owned database view in Oracle E-Business Suite, belonging to the PJM (Project Manufacturing) product family. Its documented purpose is to expose project-related blanket purchase releases for Web Inquiry, meaning it provides a consolidated, read-only projection of released blanket purchase order activity that is linked to a project and task. The object is reported with a status of VALID, and the view text is built over the standard Oracle Purchasing PO_HEADERS, PO_RELEASES, PO_LINES, and PO_DISTRIBUTIONS tables, joined to project distribution information. It serves primarily as a reporting and inquiry layer rather than a transactional object, surfacing vendor, site, contact, currency, terms, and shipping details alongside the project and task context required for project manufacturing visibility.

Underlying Base Objects

The documented referenced objects for the 12.2.2 release are:

• FND_CURRENCY_CACHE (PACKAGE)
• PJM_INQUIRY (PACKAGE)
• PO_DISTRIBUTIONS_ALL (SYNONYM)
• PO_HEADERS_ALL (SYNONYM)
• PO_INQ_SV (PACKAGE)
• PO_LINES_ALL (SYNONYM)
• PO_LINE_LOCATIONS_ALL (SYNONYM)
• PO_RELEASES_ALL (SYNONYM)

In the view definition, PO_HEADERS is joined to PO_RELEASES on PO_HEADER_ID, and PO_RELEASES is connected to PO_DISTRIBUTIONS (aliased DIST) to obtain PROJECT_ID and TASK_ID. PO_LINES supplies ITEM_DESCRIPTION, while MTL_SYSTEM_ITEMS_KFV supplies the concatenated item segment. Vendor data is retrieved via outer joins to PO_VENDORS, PO_VENDOR_SITES, and PO_VENDOR_CONTACTS. Location and terms data are outer-joined to HR_LOCATIONS and AP_TERMS. Lookup values for authorization status and other descriptive fields are resolved through multiple PO_LOOKUP_CODES aliases. The PO_INQ_SV package supplies the agent (buyer) name through GET_PERSON_NAME, FND_CURRENCY_CACHE supplies the currency format mask, and PJM_INQUIRY and PO_LINE_LOCATIONS_ALL support the project inquiry logic.

Key Columns

The view exposes identifiers and descriptive attributes needed for a complete blanket release picture:

• PROJECT_ID, TASK_ID — identify the project manufacturing project and task for each distribution.
• PO_HEADER_ID, SEGMENT1 — the blanket purchase order header and its document number.
• PO_RELEASE_ID, RELEASE_NUM, REVISION_NUM, REVISED_DATE, RELEASE_DATE, PRINTED_DATE — release-level detail.
• VENDOR_ID, VENDOR_NAME, VENDOR_CONTACT_ID, VENDOR_SITE_ID, VENDOR_SITE_CODE — supplier and contact information.
• SHIP_TO_LOCATION_ID, BILL_TO_LOCATION_ID — with corresponding HR_LOCATIONS LOCATION_CODE values.
• TERMS_ID and AT.NAME — payment terms.
• CURRENCY_CODE and the formatted release total derived from PO_TOTALS_PO_SV.GET_RELEASE_TOTAL using FND_CURRENCY_CACHE.GET_FORMAT_MASK.
• CONCATENATED_SEGMENTS, ITEM_DESCRIPTION, END_ITEM_UNIT_NUMBER — item and end-item unit context.
• AUTHORIZATION_STATUS and lookup DISPLAYED_FIELD values for classification.

Common Use Cases and Queries

This view is typically used for web-based project inquiry screens and custom project manufacturing reports, allowing users to drill into blanket releases associated with a project. A representative query filters releases by project and task:

SELECT project_id, task_id, segment1, release_num, vendor_name, currency_code, release_date FROM apps.pjm_project_blanket_po_v WHERE project_id = :project_id AND task_id = :task_id ORDER BY release_date DESC;

Another common pattern reconciles charges by vendor and authorization status:

SELECT vendor_name, vendor_site_code, authorization_status, release_num FROM apps.pjm_project_blanket_po_v WHERE vendor_id = :vendor_id;

Because the view joins many purchasing and HR objects with outer joins, queries should filter aggressively to avoid unnecessary scanning, and consumers should treat the data as read-only inquiry output rather than a transactional source.