Search Results icx_edm_purchase_order_v




Overview

ICX_EDM_PURCHASE_ORDER_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, defined within the ICX (Oracle iProcurement) product family. Its documented description is "Project Related Purchase Orders View." The view consolidates purchase order header, supplier, terms, shipping, and project distribution information into a denormalized, read-friendly structure intended for project-related procurement reporting and integration. Because it joins purchasing data to project and task identifiers sourced from PO_DISTRIBUTIONS_ALL, it is particularly useful when purchase orders must be analyzed against project accounting contexts rather than purely operational procurement data. The view is documented as VALID and is present in both the 12.1.1 and 12.2.2 reference environments, with an ETRM 12.2.2 metadata set confirming its dependent objects.

Underlying Base Objects

The view is defined over a large set of purchasing, supplier, HR, and project-related objects. Documented referenced base objects include PO_HEADERS_ALL, PO_DISTRIBUTIONS_ALL, PO_DOCUMENT_TYPES_ALL, PO_RELEASES_ALL, PO_VENDORS, PO_VENDOR_SITES_ALL, PO_VENDOR_CONTACTS, PO_LOOKUP_CODES (a view over lookup tables), HR_LOCATIONS, and AP_TERMS, together with server-side packages PO_TOTALS_PO_SV, PO_INQ_SV, FND_CURRENCY, FND_GLOBAL, HR_GENERAL, and MRP_GET_PROJECT. The principal join establishes PO_HEADERS_ALL as the driving table, linked to PO_DISTRIBUTIONS_ALL to supply PROJECT_ID and TASK_ID. PO_VENDORS, PO_VENDOR_SITES_ALL, and PO_VENDOR_CONTACTS supply supplier details, while PO_LOOKUP_CODES is referenced multiple times to translate lookup codes for authorization status, FOB, freight terms, and closure status. AP_TERMS provides payment terms, and HR_LOCATIONS resolves ship-to and bill-to locations. MRP_GET_PROJECT supplies the project and task names derived from the distribution identifiers.

Key Columns

The view exposes a broad column list. PROJECT_ID and TASK_ID identify the associated project and task from the distribution, while MRP_GET_PROJECT.PROJECT and MRP_GET_PROJECT.TASK return their names. PO_NUM (POH.SEGMENT1) is the purchase order number, and TYPE_NAME describes the document type. AUTHORIZATION_STATUS, FOB, FREIGHT_TERMS, and CLOSURE_STATUS are resolved through PO_LOOKUP_CODES via DISPLAYED_FIELD. ORDER_DATE, PRINTED_DATE, REVISION_NUM, and REVISED_DATE describe the header lifecycle. AMOUNT is computed by PO_TOTALS_PO_SV.GET_PO_TOTAL and formatted using FND_CURRENCY.SAFE_GET_FORMAT_MASK against CURRENCY_CODE. BUYER_NAME is derived from PO_INQ_SV.GET_PERSON_NAME on AGENT_ID. Supplier fields include SUPPLIER_NAME (VENDOR_NAME), SUPPLIER_CONTACT_NAME, VENDOR_SITE_CODE, and SUPPLIER_URL (vendor ATTRIBUTE14). TERMS_NAME, SHIP_TO_LOCATION, BILL_TO_LOCATION, and SHIP_VIA_LOOKUP_CODE complete the logistics picture. Identifier columns include PO_HEADER_ID, BUYER_ID, SUPPLIER_ID, VENDOR_CONTACT_ID, VENDOR_SITE_ID, TERMS_ID, BILL_TO_LOCATION_ID, and SHIP_TO_LOCATION_ID; PO_RELEASE_NUMBER and PO_RELEASE_ID are returned as NULL placeholders.

Common Use Cases and Queries

Typical scenarios include project-level spend analysis, iProcurement requisition-to-order reconciliation, supplier performance reporting, and extract feeds for downstream project accounting or BI systems. Because the view is already denormalized, it can be queried directly without additional joins for most reporting needs.

  • Project spend review: SELECT project_id, task_id, po_num, amount, currency_code FROM icx_edm_purchase_order_v WHERE project_id IS NOT NULL ORDER BY project_id, po_num;
  • Supplier and buyer summary: SELECT po_num, supplier_name, buyer_name, terms_name FROM icx_edm_purchase_order_v WHERE supplier_name LIKE :p_supplier;
  • Authorization and closure tracking: SELECT po_num, authorization_status, closure_status FROM icx_edm_purchase_order_v WHERE closure_status = 'OPEN';
  • Ship-to and bill-to detail: SELECT po_num, ship_to_location, bill_to_location, ship_via_lookup_code FROM icx_edm_purchase_order_v;

Queries should filter aggressively on PROJECT_ID, ORDER_DATE, or SUPPLIER_ID where possible, since several columns are computed by PL/SQL package calls and the join list is extensive. During upgrades from 12.1.1 to 12.2.2, dependent objects such as PO_LOOKUP_CODES and PO_VENDORS should be validated to confirm continued compatibility.