Results for “revision_num”

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

Overview

OE_RELATED_PO_NUMBERS_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite, documented across releases 12.1.1 and 12.2.2. It belongs to the Order Management (ONT) product family and carries an internal designation in Oracle's documentation, meaning it is intended primarily for seeded application logic rather than as a formally published integration interface. In practice the view exposes a consolidated, de-duplicated list of purchasing document numbers that are referenced by drop-ship sourcing relationships, joined to the buyer responsible for each purchase order. Its role in reporting and integration is to let Order Management functionality resolve, for a given drop-ship source, the purchase order number, revision, supplier name, and the full name of the purchasing agent without the caller needing to navigate the underlying purchasing and HR tables directly. The presence of FULL_NAME among the projected columns is significant: users searching on "full_name" encounter this view because it is one of the relatively few ONT-adjacent objects that surfaces a person's display name alongside transactional purchasing data.

Underlying Base Objects

The view is defined over three primary sources plus a correlated existence check. PO_HEADERS (accessed through the PO_HEADERS synonym) supplies the purchase order segment, revision number, vendor identifier, agent identifier, and the PO_HEADER_ID primary key. PO_VENDORS (a view) supplies VENDOR_NAME through an outer join on VENDOR_ID, so purchase orders without a resolvable vendor still return a row with a null supplier name. PER_PEOPLE_F, the date-effective HR view of person records, is joined on AGENT_ID = PERSON_ID to obtain FULL_NAME. The EXISTS subquery against OE_DROP_SHIP_SOURCES restricts output to purchase orders that are actually referenced as drop-ship sources, which is what ties the view to the Order Management drop-shipment flow. Documented dependency metadata further lists the HR_GENERAL, HR_PERSON_NAME, and HR_SECURITY packages; these are the packages that internalize the effective-dating and security logic underpinning PER_PEOPLE_F, and HR_SECURITY in particular enforces the person-level security profile of the querying user. This means FULL_NAME values visible through the view are filtered by the caller's HR security access, not merely by the join predicate.

Key Columns

• SEGMENT1 — the purchase order number as entered in the PO transaction, i.e. the user-facing PO document number.
• REVISION_NUM — the revision of that purchase order, allowing multiple revisions of the same PO number to be distinguished.
• VENDOR_NAME — the supplier name obtained from PO_VENDORS; null where the purchase order has no matching vendor record.
• FULL_NAME — the formatted full name of the purchasing agent, derived from PER_PEOPLE_F and subject to HR security.
• PO_HEADER_ID — the internal surrogate key for the purchase order header, used to join back to PO_HEADERS and related purchasing tables.

Common Use Cases and Queries

The most frequent usage is identifying the buyer behind a drop-ship purchase order, or listing all drop-ship purchase orders associated with a supplier. The view's internal deduplication logic — a DISTINCT over an inline view that retains only each person's maximum effective start and end dates — ensures one row per PO/agent combination despite the multiple temporal versions present in PER_PEOPLE_F, so callers do not need to write their own effective-date filtering. A simple lookup by name:

SELECT segment1, revision_num, vendor_name, full_name
FROM   apps.oe_related_po_numbers_v
WHERE  full_name LIKE 'SMITH%';

A join-driven variant retrieves all drop-ship POs for a known supplier:

SELECT segment1, revision_num, full_name, po_header_id
FROM   apps.oe_related_po_numbers_v
WHERE  vendor_name = :p_vendor_name
ORDER  BY segment1;

Because the view returns PO_HEADER_ID, it is conveniently used as a lookup in custom reports that must subsequently drill into PO distributions, receipts, or order line links. Two cautions apply: the internal designation means Oracle may alter or remove the view without notice, and results are constrained by the querying user's HR security profile, so reports run under different responsibilities can legitimately return different FULL_NAME populations for identical PO data.