Search Results por_item_attribute_values




Overview
Explore in AI Chat

Overview

POR_ITEM_ATTRIBUTE_VALUES is an Oracle iProcurement (ICX) transactional table that stores descriptive item attribute values captured at the requisition line level. In Oracle EBS 12.1.1 and 12.2.2, iProcurement allows buyers and requesters to enter or inherit item attributes — such as color, size, dimension, or other configurable descriptors — during requisition creation. POR_ITEM_ATTRIBUTE_VALUES persists those values in a generic, column-based (flexible-attribute) structure, enabling the requisitioning flow to capture item-specific context beyond standard inventory item master fields.

The table is owned by the ICX schema and holds approximately 24 columns. Its documented primary key, POR_ITEM_ATTRIBUTE_VALUES_PK1, is composed of REQUISITION_LINE_ID, REQUISITION_HEADER_ID, and ITEM_TYPE; the unique index POR_ITEM_ATTRIBUTE_VALUES_U1 mirrors those same three columns as a business-key candidate. From a Data Vault modeling perspective, the metadata classifies this object as standalone, meaning it is a heuristic candidate for a satellite (or, given its composite business key, a hub-satellite combination) rather than functioning as a pure hub or link. This classification is a modeling suggestion derived from FK structure, not a statement of native EBS design.

Key Information Stored

The table's identity is anchored by three key columns that together form both the primary key and the unique index:

  • REQUISITION_LINE_ID — identifies the specific requisition line to which the attribute values belong.
  • REQUISITION_HEADER_ID — ties the record to its parent requisition header, supporting header-level reporting.
  • ITEM_TYPE — the item type classification associated with the captured attribute set.

The descriptive payload is held in fifteen generic attribute columns, ATTRIBUTE1 through ATTRIBUTE15. These are the workhorses of the table: each stores a discrete item attribute value whose meaning is context-driven (for example, a dimensional setting, a color, or a supplier-specific descriptor). Because the columns are generic, the semantic meaning of any given ATTRIBUTEn is typically resolved through the iProcurement configuration or the associated item definition rather than a fixed schema definition.

Multi-organization awareness is provided by ORG_ID, the operating unit identifier. Standard Oracle EBS audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN — track record creation and modification history. The absence of WHO-style columns beyond these confirms the table's role as a lightweight, per-line attribute store rather than a full audit-trailed entity.

Common Use Cases and Queries

Reporting on item attribute values is common in requisition analysis, punchout/round-trip integration validation, and troubleshooting missing or incorrect attribute data on submitted requisitions. A typical join retrieves attribute values alongside their transaction lines:

  • Line-level attribute extract: select ATTRIBUTE1 through ATTRIBUTE15 where REQUISITION_HEADER_ID and REQUISITION_LINE_ID match a target requisition. This is the core query for downstream interfaces and BI reports.
  • Header-to-line rollup: group by REQUISITION_HEADER_ID to consolidate attribute values across all lines of a requisition for header-level dashboards.
  • Operating-unit filtering: constrain by ORG_ID to respect multi-org security and produce organization-scoped reporting.
  • Item-type segmentation: filter by ITEM_TYPE to analyze attribute patterns across item classifications.
  • Audit and freshness checks: use CREATION_DATE and LAST_UPDATE_DATE to identify recently captured or stale attribute records for data-quality review.

Because the semantics of ATTRIBUTE1–ATTRIBUTE15 are configuration-dependent, effective reporting typically pairs this table with the requisition header and line tables and, where needed, the item master to resolve attribute meaning.

Related Objects

The relationship metadata classifies POR_ITEM_ATTRIBUTE_VALUES as standalone, with no documented foreign keys; joins are therefore established through the shared business-key columns rather than enforced constraints. The most significant related objects are:

Together these objects support the full requisition lifecycle from attribute capture through purchasing conversion.