Search Results icx_headers

Overview

APPS.ICX_PO_HEADER_DIFF_V is a reporting and integration view in Oracle E-Business Suite, owned by the APPS schema. It exposes a filtered subset of the purchase order revision staging data held in the underlying temporary table, returning only those rows whose revision changes were recorded at the header level. The view's defining predicate, LEVEL_ALTERED = 'ICX_HEADERS', restricts output to header-level change records, characterising it as a header-scoped projection of the broader revision-tracking data set.

Within the Oracle iProcurement and Internet Procurement architecture, the ICX prefix denotes objects associated with the Internet Computing/Commerce (ICX) product family. The view plays a supporting role in the purchase order change notification and revision display process, allowing header-level modifications to be presented to users or passed to downstream processes without exposing line-level or shipment-level alterations contained in the same physical table. Because its definition is a simple, selective projection rather than a join, the view is lightweight and inherits the storage and lifecycle characteristics of the base staging table.

Underlying Base Objects

The view is defined over a single referenced base object, documented in ETRM 12.2.2 as the synonym ICX_PO_REVISIONS_TEMP. The view performs no joins, aggregations, or unions; it is a vertical and horizontal subset of that object, returning seven named columns and filtering on the LEVEL_ALTERED column.

Because the base object is a temporary revision-staging structure, the contents of the view are transient. Rows are populated during the purchase order change processing cycle and are typically consumed shortly thereafter by notification, comparison, or display logic. This transience is significant for reporting design: the view should be regarded as a working set of pending header-level differences rather than a historical audit repository. Persistent revision history is generally retained in the core purchasing revision entities, while this view reflects the delta currently staged for processing.

Key Columns

• LINE_SEQ — A sequence value ordering the staged change records, used to preserve the order in which header-level alterations were detected or registered.
• HEADER_ID — The identifier of the purchase order header to which the revision change applies. This is the primary linkage key back to the purchasing document header.
• RELEASE_ID — The release identifier associated with the change, applicable where the header belongs to a blanket purchase agreement with releases.
• LEVEL_ALTERED — The attribute that qualifies the granularity of the change. In this view the value is always ICX_HEADERS, distinguishing header-level changes from line or shipment level alterations.
• FIELD_ALTERED — The name of the header field that was modified, enabling a field-by-field presentation of what changed.
• CHANGES_FROM — The prior value of the altered field, representing the "before" state of the revision.
• CHANGES_TO — The new value of the altered field, representing the "after" state of the revision.

Common Use Cases and Queries

The view is most commonly used to display or audit header-level changes on a purchase order, for example to drive change notification content or to populate a comparison report showing before-and-after values for modified header fields. A typical query retrieves all staged header changes for a specific purchase order:

• SELECT header_id, release_id, field_altered, changes_from, changes_to FROM apps.icx_po_header_diff_v WHERE header_id = :p_header_id ORDER BY line_seq;
• A generic inspection of pending header changes: SELECT * FROM apps.icx_po_header_diff_v ORDER BY header_id, line_seq;
• Filtering for a specific altered field across documents: SELECT header_id, changes_from, changes_to FROM apps.icx_po_header_diff_v WHERE field_altered = :p_field;

Because the base object is a temporary table, these queries should be executed within the processing window during which revision data is staged. Results are not expected to persist indefinitely, and any durable reporting requirement should be satisfied from the permanent purchasing revision tables instead.