Results for “po_date”

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

Overview

PO_BY_BUYER_V is an APPS-owned database view in the Oracle E-Business Suite Purchasing (PO) module. It exposes summarized purchase order information organized by buyer, providing a denormalized read-only presentation of approved purchase order activity. The view is registered with a status of VALID in ETRM and is available in both Oracle EBS 12.1.1 and 12.2.2. Because it joins header, line, vendor, and HR person data into a single projection, it is intended primarily for reporting, inquiry, and integration scenarios where a buyer-centric rollup of purchase order commitments is required. It is not a transaction-entry object and carries no DML semantics; it is a query surface over base purchasing tables.

Underlying Base Objects

The view is defined over the following documented base objects: PO_HEADERS (synonym), PO_LINE_LOCATIONS_ALL (synonym), PO_VENDORS (view), and PER_PEOPLE_F (view). The ETRM reference additionally lists HR_GENERAL, HR_PERSON_NAME, and HR_SECURITY packages as transitive dependencies, which are consumed indirectly through PER_PEOPLE_F for person-name resolution and security filtering.

The join logic links PO_HEADERS.PO_HEADER_ID to PO_LINE_LOCATIONS_ALL.PO_HEADER_ID, PO_HEADERS.VENDOR_ID to PO_VENDORS.VENDOR_ID, and PO_HEADERS.AGENT_ID to PER_PEOPLE_F.PERSON_ID. Only approved documents are included, enforced by the predicate NVL(POH.APPROVED_FLAG, 'N') = 'Y'. Because PO_LINE_LOCATIONS_ALL is joined at the header level and the amount is aggregated with SUM, multiple shipments per line are consolidated into a single row per header grouping.

Key Columns

• PO_NO — Sourced from POH.SEGMENT1; the purchase order number as displayed to users.
• PO_TYPE — From POH.TYPE_LOOKUP_CODE; identifies the document type (for example, standard, blanket, or planned order).
• PO_DATE — From POH.CREATION_DATE; the date the purchase order record was created.
• BUYER_NAME — From PPF.FULL_NAME; the full name of the purchasing agent.
• VENDOR_NAME — From POV.VENDOR_NAME, passed through RTRIM to strip trailing whitespace.
• PO_AMOUNT — ROUND(SUM(PLL.PRICE_OVERRIDE * (PLL.QUANTITY - PLL.QUANTITY_CANCELLED)), 2); the net committed value of the order after cancellations, rounded to two decimals.
• CURRENCY — From POH.CURRENCY_CODE; the document currency.
• ORG_ID — The operating unit identifier from POH.ORG_ID, supporting multi-org reporting.

Common Use Cases and Queries

The most frequent use is buyer workload and spend analysis, where purchasing managers aggregate committed value by buyer. A representative query to locate a specific order by number, consistent with the common search term "po_no," is:

SELECT po_no, po_type, po_date, buyer_name, vendor_name, po_amount, currency FROM apps.po_by_buyer_v WHERE po_no = '100234';

For multi-org environments, the operating unit should be constrained explicitly:

SELECT buyer_name, currency, SUM(po_amount) FROM apps.po_by_buyer_v WHERE org_id = :p_org_id GROUP BY buyer_name, currency;

Additional practical scenarios include vendor exposure reporting across buyers, monthly trend analysis on PO_DATE, and feeder queries for downstream data warehouses or BI extracts. Users should note that the view returns only approved orders, aggregates at the header grouping level, and relies on PER_PEOPLE_F, so person security rules may restrict the set of buyers returned.