Search Results sys_c00204806

Overview

PO_ATTRIBUTE_VALUES is a Purchasing (PO) module table in the Oracle E-Business Suite, owned by the PO schema and marked VALID in both 12.1.1 and 12.2.2. Its documented purpose is to store descriptor values for records that are searchable in iProcurement. In practice, it acts as the descriptive and searchable metadata storefront for purchasing content: each row carries the merchandising, categorization, and multi-format attribute values that iProcurement uses to display item detail pages, enrich search results, and support comparison and punchout-style browsing. The table persists supplier-side and internal attributes such as manufacturer part numbers, images, supplier URLs, availability, lead time, and UNSPSC classification, alongside large banks of generic text, numeric, and category-specific attribute slots.

Although it is a base table rather than an interface, it functions as a staging and presentation layer between item master / purchasing source records and the iProcurement search index. Its documented dependency is internal to the Purchasing flow, and its structure is highly denormalized by design, which is typical of search-target tables that must be read cheaply and repeatedly.

From a Data Vault modeling perspective, the ETRM metadata classifies this object heuristically as standalone, meaning it is not identified as a hub or link through foreign-key mining. A reasonable modeling suggestion would be to treat it as a sat-ellite-like attribute store attached to a purchasing line or item business key, with its own surrogate ATTRIBUTE_VALUES_ID acting as the technical primary key.

Key Information Stored

The table is extremely wide, with 327 documented columns in the 12.2.2 physical schema. The most operationally significant columns are:

• ATTRIBUTE_VALUES_ID — the surrogate primary key, backed by SYS_C00204806 and unique index PO_ATTRIBUTE_VALUES_U1.
• PO_LINE_ID — the purchasing line to which the descriptor values apply, and a component of the business-key candidate PO_ATTRIBUTE_VALUES_U2.
• REQ_TEMPLATE_NAME and REQ_TEMPLATE_LINE_NUM — identify the requisition template context, also part of PO_ATTRIBUTE_VALUES_U2.
• INVENTORY_ITEM_ID and ORG_ID — the inventory item and operating unit, completing the composite business key PO_ATTRIBUTE_VALUES_U2.
• IP_CATEGORY_ID — the iProcurement category used to align the row with category-specific attribute sets.
• MANUFACTURER_PART_NUM, UNSPSC, AVAILABILITY, LEAD_TIME — core searchable supplier and item descriptors.
• PICTURE, THUMBNAIL_IMAGE, SUPPLIER_URL, MANUFACTURER_URL, ATTACHMENT_URL — rich media and external link values surfaced in iProcurement detail pages.
• TEXT_BASE_ATTRIBUTE1–100 and NUM_BASE_ATTRIBUTE1–100 — generic base attribute slots.
• TEXT_CAT_ATTRIBUTE1–50 and NUM_CAT_ATTRIBUTE1–50 — category-specific attribute slots.
• REBUILD_SEARCH_INDEX_FLAG — controls whether the record must be re-indexed for iProcurement search.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard WHO audit columns.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, LAST_UPDATED_PROGRAM — concurrent program context columns.

The distinction between the surrogate key and the business-key candidate is important: ATTRIBUTE_VALUES_ID uniquely identifies a row technically, while PO_LINE_ID, REQ_TEMPLATE_NAME, REQ_TEMPLATE_LINE_NUM, INVENTORY_ITEM_ID, and ORG_ID together identify the business context.

Common Use Cases and Queries

Typical usage centers on extracting, validating, and re-indexing iProcurement searchable content. Common reporting scenarios include auditing which lines have descriptor values, confirming that images and UNSPSC codes are populated, and diagnosing why an item does not appear in iProcurement search.

A basic lookup by purchasing line:

• SELECT attribute_values_id, po_line_id, inventory_item_id, org_id, manufacturer_part_num, unspsc, availability, lead_time FROM po.po_attribute_values WHERE po_line_id = :po_line_id;

A completeness check across the composite business key:

• SELECT COUNT(*) FROM po.po_attribute_values WHERE po_line_id = :po_line_id AND req_template_name = :template AND req_template_line_num = :line_num AND inventory_item_id = :item AND org_id = :org;

A re-index candidate query driven by the search flag:

• SELECT attribute_values_id, po_line_id, inventory_item_id FROM po.po_attribute_values WHERE rebuild_search_index_flag = 'Y';

Reporting against generic and category attributes requires explicit column selection because the 300+ attribute columns are positional; BI Publisher and OBIEE extracts typically map the 1–100 text and numeric slots to external attribute names defined in the iProcurement category setup.

Related Objects

Because the metadata classifies PO_ATTRIBUTE_VALUES as standalone, joins are driven by its business-key columns rather than by declared foreign keys. The most significant related objects are:

• PO_LINES_ALL — joined on PO_LINE_ID; the primary purchasing line whose searchable descriptors this table stores.
• PO_LINE_LOCATIONS_ALL — joined through PO_LINE_ID to reach shipment and receipt context.
• PO_HEADERS_ALL — reached via PO_LINE_ID to PO_LINES_ALL for header-level reporting.
• MTL_SYSTEM_ITEMS_B — joined on INVENTORY_ITEM_ID and ORG_ID for item descriptions and categories.
• MTL_CATEGORIES_B and MTL_ITEM_CATEGORIES — joined on IP_CATEGORY_ID and item/category relationships.
• PO_REQ_TEMPLATES tables — joined on REQ_TEMPLATE_NAME and REQ_TEMPLATE_LINE_NUM for requisition template context.
• ICX catalogue / iProcurement search objects — consume rows where REBUILD_SEARCH_INDEX_FLAG is set to drive search index refreshes.
• PO_ATTRIBUTE_VALUES U1/U2 indexes — PO_ATTRIBUTE_VALUES_U1 on ATTRIBUTE_VALUES_ID and PO_ATTRIBUTE_VALUES_U2 on the composite business key.

These relationships make PO_ATTRIBUTE_VALUES the descriptive backbone for iProcurement content, linking purchasing lines, items, categories, and requisition templates to the attribute values that end users actually search and see.