Search Results por_item_attribute_values_u1

Overview

ICX.POR_ITEM_ATTRIBUTE_VALUES is a transactional table in the Oracle E-Business Suite Internet Procurement (iProcurement) schema, ICX. It stores the attribute values associated with requisition lines that originate from punchout sessions — catalog content sourced from external supplier systems and returned to iProcurement for inclusion on a requisition. Each row captures a requisition item together with a set of descriptive attribute values (item type, for example) keyed against the originating requisition header and line. The table resides in the APPS_TS_TX_DATA tablespace, with its unique index in APPS_TS_TX_IDX, placing it firmly in the transactional data tier rather than a setup or reference tier.

The ETRM metadata classifies this object heuristically as standalone within a Data Vault modelling scheme. No foreign-key dependencies were mined, so it is not modelled as a link between other hubs. In practice it is better understood as a satellite-style detail table: its grain is the requisition line, and its descriptive attribute columns are functionally dependent on the requisition header and line identifiers. The primary key POR_ITEM_ATTRIBUTE_VALUES_PK1 is composed of REQUISITION_LINE_ID, REQUISITION_HEADER_ID, and ITEM_TYPE, which reinforces the line-level grain.

Key Information Stored

The table contains 24 documented columns. The most significant are the composite key columns and the generic attribute payload:

• REQUISITION_LINE_ID (NUMBER) — the requisition line identifier; part of the composite primary key and the principal join key to requisition line data.
• REQUISITION_HEADER_ID (NUMBER) — the parent requisition header identifier; also part of the primary key.
• ITEM_TYPE (VARCHAR2(15)) — the item type discriminator; the third component of the primary key and the first column of the unique index.
• ATTRIBUTE1 … ATTRIBUTE15 (VARCHAR2(240) each) — fifteen generic descriptive columns holding the punchout attribute values carried on the requisition item. These provide vertical flexibility for supplier-defined or category-specific attributes without schema changes.
• ORG_ID (NUMBER) — the operating unit identifier, supporting multi-org partitioning in reporting and access control.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns tracking row creation and modification.

The documented surrogate primary key (POR_ITEM_ATTRIBUTE_VALUES_PK1) spans REQUISITION_LINE_ID, REQUISITION_HEADER_ID, and ITEM_TYPE. A unique index, POR_ITEM_ATTRIBUTE_VALUES_U1 — the object the user searched for — enforces the same three-column combination and therefore serves as the business-key candidate for the table, guaranteeing a single attribute row per requisition item of a given type.

Common Use Cases and Queries

Typical usage centres on reconciling punchout requisition items with their captured attribute values for procurement reporting, supplier analysis, and troubleshooting of catalog round-trips.

• Retrieve attributes for a requisition line — join on the requisition identifiers to inspect the stored attribute values:

  SELECT ITEM_TYPE, REQUISITION_HEADER_ID, REQUISITION_LINE_ID,
         ATTRIBUTE1, ATTRIBUTE2, ATTRIBUTE3
  FROM   ICX.POR_ITEM_ATTRIBUTE_VALUES
  WHERE  REQUISITION_LINE_ID = :line_id;

• Reporting by operating unit — filter on ORG_ID to scope attribute reporting to a single operating unit, often combined with requisition header data for spend or catalogue-source analysis.
• Audit and lineage checks — use CREATION_DATE and LAST_UPDATE_DATE to identify recently created or amended attribute rows, useful when validating a punchout integration.
• Index-driven access — since POR_ITEM_ATTRIBUTE_VALUES_U1 leads with REQUISITION_LINE_ID followed by REQUISITION_HEADER_ID and ITEM_TYPE, queries supplying all three predicates benefit from a unique index range scan.

Related Objects

The documented relationship data classifies this table as standalone, with no mined foreign keys. Consequently the join relationships below follow the natural requisition hierarchy implied by the key columns rather than enforced constraints:

• ICX.POR_REQUISITION_HEADERS_ALL — join on REQUISITION_HEADER_ID to reach the parent requisition header.
• ICX.POR_REQUISITION_LINES_ALL — join on REQUISITION_LINE_ID (and REQUISITION_HEADER_ID) to reach the requisition line and its item details.
• PO_REQUISITION_HEADERS_ALL — the Purchasing requisition header table, joined via REQUISITION_HEADER_ID for downstream purchasing analysis.
• PO_REQUISITION_LINES_ALL — the Purchasing requisition line table, joined via REQUISITION_LINE_ID.
• PO_LINE_LOCATIONS_ALL — shipment and location detail reached through the requisition line linkage.
• ICX.POR_ITEM_ATTRIBUTES — where present, the attribute definition metadata that gives meaning to ATTRIBUTE1 … ATTRIBUTE15.

Because no foreign keys are enforced, joins should be validated against the requisition line and header identifiers and, where relevant, constrained by ORG_ID to preserve multi-org integrity.