Search Results po_bpos_hdr_pk

Overview

The PO_BPOS_HDR table is a core data object within the Oracle E-Business Suite (EBS) Process Manufacturing Logistics (GML) module. It serves as the primary repository for header-level information pertaining to blanket purchase orders (BPOs). A blanket purchase order is a long-term agreement with a supplier for the provision of goods or services, against which specific release orders (PO_ORDR_HDR) are issued. This table is fundamental to the procurement lifecycle in process manufacturing environments, establishing the contractual framework that governs subsequent transactions. Its status as VALID and its ownership under the GML schema confirm its active role in EBS versions 12.1.1 and 12.2.2.

Key Information Stored

The table's structure is defined by its primary and foreign key relationships. The primary key, PO_BPOS_HDR_PK, is based on the BPO_ID column, which uniquely identifies each blanket purchase order record. A unique key constraint, PO_BPOS_HDR_U1, enforces the combination of ORGN_CODE (organization code) and BPO_NO (blanket purchase order number), ensuring order numbers are unique within an operating unit. Key stored data includes vendor identifiers (SHIPVEND_ID, PAYVEND_ID), shipping and payment terms (SHIP_MTHD, FRTBILL_MTHD, TERMS_CODE, FOB_CODE), currency (CONTRACT_CURRENCY), purchasing class (ICPURCH_CLASS), and organizational address (ORGNADDR_ID). It also holds codes for tracking the order's status, such as hold, cancellation, and closure reasons (BPOHOLD_CODE, CANCELLATION_CODE, CLOSURE_CODE).

Common Use Cases and Queries

This table is central to reporting and transactional integrity for blanket agreements. Common use cases include generating a master list of all active BPOs for a vendor, analyzing BPO value and lifecycle status, and serving as the source for downstream release order creation. A typical query might join PO_BPOS_HDR with PO_VEND_MST to retrieve vendor details and with PO_BPOS_DTL to summarize line-level commitments. For example, to find all open BPOs for a specific organization, one might use: SELECT bpo.bpo_no, bpo.creation_date, vend.vendor_name FROM gml.po_bpos_hdr bpo, po_vend_mst vend WHERE bpo.orgn_code = :p_org_code AND bpo.shipvend_id = vend.vendor_id AND bpo.closure_code IS NULL;. Data from this table is also critical for auditing procurement compliance and spend analysis against long-term contracts.

Related Objects

The PO_BPOS_HDR table maintains extensive relationships with other EBS entities, as documented by its foreign keys. It is the parent table for detail lines (PO_BPOS_DTL via BPO_ID) and release orders (PO_ORDR_HDR via BPO_ID). Key foreign key dependencies link it to master data tables, including:

• SY_ORGN_MST / SY_ORGN_MST_B (Organization) via ORGN_CODE
• PO_VEND_MST (Vendor) via SHIPVEND_ID and PAYVEND_ID
• SY_REAS_CDS / SY_REAS_CDS_B (Reason Codes) via BPOHOLD_CODE, CANCELLATION_CODE, and CLOSURE_CODE
• GL_CURR_MST (Currency) via CONTRACT_CURRENCY
• IC_PRCH_CLS (Purchasing Class) via ICPURCH_CLASS
• OP_SHIP_MTH, OP_FRGT_MTH, OP_TERM_MST, OP_FOBC_MST, OP_SHIP_MST (Shipping, Freight, Terms, FOB, and Shipper codes)
• SY_ADDR_MST (Address) via ORGNADDR_ID
• PO_TEXT_HDR (Text) via TEXT_CODE

These relationships ensure referential integrity and enforce business rules across the procurement process.