Search Results itg_sp_po_headers_v




Overview
Explore in AI Chat

Overview

ITG_SP_PO_HEADERS_V is a database view owned by the APPS schema in Oracle E-Business Suite, catalogued under the ITG — Internet Procurement Enterprise Connector product family. Its documented purpose is to generate XML at the purchase order header level for use in the Sync PO message. In practice, this means the view acts as a flattened, integration-ready projection of purchasing document headers that the Enterprise Connector reads when exchanging purchase order data between EBS and an external procurement or requisitioning system.

Rather than exposing raw transactional columns, the view reshapes source data into the field naming convention expected by the outbound Sync PO payload: document identifier, document datetime, extended amount, currency, buyer, deliver-to location, status, and type. Because it is a view rather than a table, it holds no data of its own and always reflects the current state of the underlying purchasing and HR tables at query time. In 12.1.1 and 12.2.2 the object carries a VALID status in APPS, and it is a supporting object rather than an end-user form or concurrent program.

Underlying Base Objects

The view is defined over three primary sources joined in a single SELECT with outer joins. PO_HEADERS_ALL supplies the purchase order header rows, including PO_HEADER_ID, SEGMENT1, CURRENCY_CODE, ORG_ID, AUTHORIZATION_STATUS, TYPE_LOOKUP_CODE, SHIP_TO_LOCATION_ID, AGENT_ID, APPROVED_DATE, and COMMENTS. PER_PEOPLE_F, the effective-dated people view, provides the buyer name via FULL_NAME and is joined on PERSON_ID to PHA.AGENT_ID with the outer-join operator. HR_LOCATIONS_ALL supplies the deliver-to value via LOCATION_CODE and is joined on LOCATION_ID to PHA.SHIP_TO_LOCATION_ID, also outer-joined.

The ETRM metadata additionally records HR_GENERAL, HR_PERSON_NAME, and HR_SECURITY as referenced base objects; these are consumed indirectly through PER_PEOPLE_F, which relies on HR security and name-formatting logic. ITG_X_UTILS is the most significant dependency: the view calls ITG_X_UTILS.SUMPOLINELOCS to compute extended amounts and ITG_X_UTILS.GETATTACHMENTS to retrieve attachment content for multiple categories (PO INTERNAL, MISC, APPROVER, BUYER, PAYABLES, RECEIVER, VENDOR). This makes the view logically dependent on package APIs rather than on simple column references alone.

Key Columns

  • PO_HEADER_ID — Primary key of the purchase order header; the anchor used by all function calls and downstream line-level queries.
  • DATETIME_DOCUMENT — Derived from PHA.APPROVED_DATE; the approval timestamp of the document.
  • OPERAMT_EXTENDED — Extended document amount returned by ITG_X_UTILS.SUMPOLINELOCS, summarizing line and location values.
  • OPERAMT_CURRENCY — Document currency code.
  • POID — Purchase order number (SEGMENT1).
  • BUYERID — Buyer full name from PER_PEOPLE_F.
  • DELIVERTO — Ship-to location code from HR_LOCATIONS_ALL.
  • NOTES — Free-text header comments.
  • POENTITY — Operating unit identifier expressed as a character string.
  • PORELEASE — Always NULL in this header-level definition; releases are handled elsewhere.
  • POSTATUS / POTYPE — Authorization status and document type lookup code.
  • TAXWHEXMPT — Always NULL; tax exemption is not surfaced at this level.
  • TO_* columns — Attachment payloads per category, produced by ITG_X_UTILS.GETATTACHMENTS.

Common Use Cases and Queries

The primary use case is troubleshooting and validating the XML produced for the Sync PO message. A basic header listing can be produced as follows:

SELECT poid, buyerid, deliverto, postatus, potype,
       operamt_extended, operamt_currency, datetime_document
FROM   apps.itg_sp_po_headers_v
WHERE  poid = :po_number;

To inspect attachment retrieval for a specific document, query the TO_* columns directly; a non-null value indicates that content exists for that category and that GETATTACHMENTS resolved successfully. Because the attachment and amount functions execute per row, unrestricted queries against large data sets can be expensive, so predicates on PO_HEADER_ID or POID are recommended.

For integration diagnostics, the view can be joined back to PO_HEADERS_ALL on PO_HEADER_ID to compare the Sync PO representation against the underlying transactional record, and the POENTITY value used to confirm that the correct operating unit is transmitted. The PORELEASE and TAXWHEXMPT columns, being NULL by design, should be treated as placeholders that downstream mapping or line-level views populate rather than as defects in the view logic.