Results for “clm_award_administrator”

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

Overview

PO_HEADERS_TRX_V is a reporting view owned by the APPS schema in Oracle E-Business Suite Purchasing (PO). As its name implies, it exposes the transactional header data held in the purchasing document header structure, and the ETRM metadata documents it simply as a "View on po_headers table." It presents one row per purchasing document header — requisition-sourced, blanket, contract, standard, or planned — together with the full set of columns that Oracle's purchasing workflow, approval, and EDI subsystems expect to find on a header record.

Because it is a view rather than a table, PO_HEADERS_TRX_V carries no storage of its own. Its value lies in shielding consumers from the physical layout of the underlying table while providing a stable, named interface for reports, interfaces, and concurrent programs. In the context of the search term "clm_standard_form," this object is noteworthy because it is the header source that feeds Oracle Procurement Contracts (CLM) style form and standard form logic. The CLM_DOCUMENT_NUMBER column visible in the view text is the direct link between a purchasing document and its associated contract/clause document identifier, which is why the view is frequently referenced where standard contract forms are rendered or reconciled.

Underlying Base Objects

The documented ETRM metadata for 12.2.2 lists a single referenced base object: PO_HEADERS, accessed through a SYNONYM. This means the view is a thin projection over PO_HEADERS rather than a join-based construct. Every column exposed by the view is drawn from that one table, and no aggregation, filtering, or outer join is applied. Consequently, PO_HEADERS_TRX_V inherits PO_HEADERS' cardinality one-for-one: there is no row multiplication and no risk of duplicate headers being returned by the view itself.

Its relationship to PO_HEADERS is therefore a dependency relationship, not a transformation. Updates, inserts, and deletes are generally performed against PO_HEADERS (or through the supported PO APIs), not through the view. Because the view is a straight projection, DML through the view is possible only where the optimizer can key-preserve the underlying row, and in practice Oracle's purchasing code performs DML directly on the base table. Reporting consumers should treat the view as read-only.

Key Columns

• PO_HEADER_ID — Primary key of the purchasing document header; the join key to PO_LINES_ALL, PO_LINE_LOCATIONS_ALL, and PO_DISTRIBUTIONS_ALL.
• CLM_DOCUMENT_NUMBER — Contract Lifecycle Management document number, associating the header with its contract/standard-form document. Central to CLM standard form reporting.
• AGENT_ID — Buyer (employee) responsible for the document, referencing PER_ALL_PEOPLE_F.
• TYPE_LOOKUP_CODE — Document type, such as STANDARD, BLANKET, CONTRACT, or PLANNED, from the PO document type lookup.
• VENDOR_ID, VENDOR_SITE_ID, VENDOR_CONTACT_ID — Supplier, supplier site, and contact for the document.
• AUTHORIZATION_STATUS, APPROVED_FLAG, APPROVED_DATE — Approval state and date, essential for status reporting.
• ORG_ID — Operating unit identifier supporting multi-org security and reporting filters.
• CLOSED_CODE, CLOSED_DATE, CANCEL_FLAG, FROZEN_FLAG — Lifecycle state indicators used in open/closed document analysis.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–15, GLOBAL_ATTRIBUTE_CATEGORY and GLOBAL_ATTRIBUTE1–14 — Descriptive flexfield contexts and segments for client-specific data.
• REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE — Concurrency audit columns identifying the program that last touched the row.

Common Use Cases and Queries

Typical uses include open purchase order reporting, contract/standard-form reconciliation by CLM document number, approval status dashboards, and extract programs feeding downstream systems. A representative query listing active standard purchasing documents for a given operating unit:

SELECT ph.po_header_id,
       ph.clm_document_number,
       ph.agent_id,
       ph.vendor_id,
       ph.authorization_status,
       ph.approved_date
FROM   apps.po_headers_trx_v ph
WHERE  ph.org_id = :p_org_id
AND    ph.type_lookup_code = 'STANDARD'
AND    ph.closed_code IS NULL;

A second common pattern joins the view to lines and locations to produce document-level totals and buyer accountability:

SELECT ph.po_header_id,
       ph.clm_document_number,
       ph.agent_id,
       COUNT(DISTINCT pll.line_location_id) AS num_schedules
FROM   apps.po_headers_trx_v ph,
       apps.po_lines_all pl,
       apps.po_line_locations_all pll
WHERE  ph.po_header_id = pl.po_header_id
AND    pl.po_line_id = pll.po_line_id
AND    ph.org_id = :p_org_id
GROUP  BY ph.po_header_id,
          ph.clm_document_number,
          ph.agent_id;

Because the view exposes ORG_ID and the full flexfield column set, it supports both multi-org secured queries and attribute-driven reporting without requiring direct access to PO_HEADERS. Access is ordinarily granted through the APPS schema, and users are advised to query the view rather than the base table to remain aligned with Oracle's documented interface.