Search Results po_attribute_values_u1

Overview

PO.PO_ATTRIBUTE_VALUES is a transactional data structure in the Oracle E-Business Suite Purchasing (PO) schema that stores non-translatable descriptor values associated with purchasing documents. It is populated for blanket agreement lines, quotation lines, and requisition template lines, functioning as the attribute-value storefront for the Oracle iProcurement punchout and descriptive content model. The table is owned by the PO schema, holds a status of VALID, and resides in the APPS_TS_TX_DATA tablespace with a PCTFREE of 10.

The object carries a heuristic Data Vault classification of standalone, meaning the mined foreign-key structure does not reveal a hub, link, or satellite topology. This classification should be treated as a modeling suggestion only: the table behaves as a wide, denormalized attribute satellite keyed by a surrogate identifier rather than as a resolved hub or link entity. In practical terms, it is best understood as a child attribute store whose natural parent is a purchasing line or requisition template line, referenced through the documented business-key columns rather than through enforced foreign keys.

The table is sizable in breadth, documenting 327 columns across ETRM 12.2.2. The physical breadth reflects the Oracle "descriptor" pattern, in which a fixed pool of generic TEXT_BASE_ATTRIBUTE, NUM_BASE_ATTRIBUTE, TEXT_CAT_ATTRIBUTE, and NUM_CAT_ATTRIBUTE columns is flexed to hold item-level and category-level attributes configured through the purchasing descriptive flexfield and iProcurement content infrastructure.

Key Information Stored

The surrogate primary key is ATTRIBUTE_VALUES_ID, a NUMBER column enforced by the SYS_C00204806 primary key constraint and by the unique index PO_ATTRIBUTE_VALUES_U1. Two documented unique indexes serve as business-key candidates. PO_ATTRIBUTE_VALUES_U1 spans ATTRIBUTE_VALUES_ID alone and is functionally redundant with the primary key. PO_ATTRIBUTE_VALUES_U2 is the meaningful composite business key, spanning PO_LINE_ID, REQ_TEMPLATE_NAME, REQ_TEMPLATE_LINE_NUM, INVENTORY_ITEM_ID, and ORG_ID; this index is the recommended access path for any query that resolves a descriptor row by its owning purchasing entity. The user search term "po_attribute_values_u2" therefore corresponds directly to this composite unique index rather than to a column.

The most significant documented columns are:

• ATTRIBUTE_VALUES_ID — surrogate primary key; the row identifier.
• PO_LINE_ID — populated with a positive value when the row is a child of a blanket line or quotation line, and with -2 otherwise.
• REQ_TEMPLATE_NAME (VARCHAR2 25) — the requisition template the row belongs to, or -2 when not applicable.
• REQ_TEMPLATE_LINE_NUM — the requisition template line number, or -2 otherwise.
• INVENTORY_ITEM_ID and IP_CATEGORY_ID — the inventory item and the item category used by iProcurement.
• ORG_ID — the organization (operating unit) identifier, a mandatory discriminator in the composite unique key.
• LEAD_TIME — numeric lead time for the descriptor.
• MANUFACTURER_PART_NUM, MANUFACTURER_URL, SUPPLIER_URL, ATTACHMENT_URL, PICTURE, THUMBNAIL_IMAGE — supplier and content metadata surfaced in iProcurement punchout and catalog displays.
• UNSPSC and AVAILABILITY — classification and availability descriptors.
• TEXT_BASE_ATTRIBUTE1..100 and NUM_BASE_ATTRIBUTE1..100 — generic flexfield pools for base (item-level) descriptor values.
• TEXT_CAT_ATTRIBUTE1..50 and NUM_CAT_ATTRIBUTE1..50 — generic flexfield pools for category-level descriptor values.
• WHO columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, LAST_UPDATED_PROGRAM, plus REBUILD_SEARCH_INDEX_FLAG.

Common Use Cases and Queries

Typical use cases center on iProcurement catalog and punchout content, blanket and quotation line descriptors, and requisition template attribute resolution. The following query pattern is the canonical lookup, exploiting PO_ATTRIBUTE_VALUES_U2:

• Retrieve descriptor values for a specific blanket or quotation line:

  SELECT attribute_values_id, inventory_item_id, manufacturer_part_num, lead_time
  FROM   po.po_attribute_values
  WHERE  po_line_id = :p_line_id
  AND    org_id    = :p_org_id;

• Resolve requisition template line attributes:

  SELECT req_template_line_num, text_base_attribute1, num_base_attribute1
  FROM   po.po_attribute_values
  WHERE  req_template_name = :p_template
  AND    org_id = :p_org_id;

• Report iProcurement content per item and organization, filtering out non-applicable sentinel rows:

  SELECT inventory_item_id, unspsc, supplier_url, availability
  FROM   po.po_attribute_values
  WHERE  po_line_id > 0
  AND    org_id = :p_org_id;

Because both PO_LINE_ID, REQ_TEMPLATE_NAME, and REQ_TEMPLATE_LINE_NUM use the sentinel value -2 to denote non-applicability, reporting queries should apply explicit predicates on these columns rather than relying on null checks. Queries that omit ORG_ID will not use the composite unique index and may suffer full scans across a very wide table.

Related Objects

The ETRM relationship data classifies this table as standalone, with no mined foreign keys beyond the SYS_C00204806 primary key. The following are the most significant logical relationships based on the documented business-key columns:

• PO.PO_LINES_ALL — referenced through PO_LINE_ID; the parent blanket, quotation, or purchase order line for child descriptor rows.
• PO.PO_REQ_TEMPLATES and PO.PO_REQ_TEMPLATE_LINES — referenced through REQ_TEMPLATE_NAME and REQ_TEMPLATE_LINE_NUM for requisition template descriptors.
• INV.MTL_SYSTEM_ITEMS_B — referenced through INVENTORY_ITEM_ID for the item being described.
• INV.MTL_CATEGORIES_B — referenced through IP_CATEGORY_ID for the iProcurement category used.
• HR_OPERATING_UNITS / HR_ALL_ORGANIZATION_UNITS — referenced through ORG_ID for the operating unit context.
• PO_ATTRIBUTE_VALUES as a supporting source for iProcurement catalog and punchout views, which consume the URL, picture, and UNSPSC columns.

No enforcing foreign-key constraints are documented for these relationships, so joins should be written with awareness that orphaned or sentinel rows (for example, the -2 placeholders) may be returned and should be filtered by the consuming report or interface.