Search Results po_headers_all_ext_b




Overview
Explore in AI Chat

Overview

PO_HEADERS_ALL_EXT_B is a key flexfield (KFF) extensions table in the Oracle Purchasing (PO) schema. It stores the descriptive flexfield (DFF) attribute values that purchasing professional users attach to a Purchase Order header. In Oracle EBS 12.1.1 and 12.2.2, the base transactional columns of a purchase order reside in PO_HEADERS_ALL; the customer-defined, configurable attribute values that extend that header are held separately in this companion table. Because the purchasing DFF is a global descriptive flexfield in 12.2.2, the extension data is split across a _B (base) table and corresponding _TL (translation) table, with the _B table holding the language-independent attribute segments.

The table is owned by the PO schema and contains 107 documented columns. Its primary key, PO_HEADERS_ALL_EXT_B_PK, is defined on EXTENSION_ID, establishing a single-column surrogate identifier for each row. The single foreign-key relationship documented in the metadata links the DRAFT_ID column to PO_DRAFTS (PO_HEADERS_ALL_EXT_B.DRAFT_ID → PO_DRAFTS), indicating the extension rows can be associated with draft purchase order records. Using Data Vault modeling heuristics, this object is best classified as a satellite: it holds the descriptive, time-stamped attribute context (SET of C_EXT_ATTR, N_EXT_ATTR, UOM_EXT_ATTR, D_EXT_ATTR columns) of a purchase order header hub rather than defining independent business entities of its own. This classification is offered as a modeling suggestion based on the observed FK structure, not as a declared EBS property.

Key Information Stored

The following columns carry the substantive descriptive content of the table:

  • EXTENSION_ID — the surrogate primary key (PO_HEADERS_ALL_EXT_B_PK), uniquely identifying each extension row. Despite being the PK, it is not the business-key candidate for the header it describes.
  • PO_HEADER_ID — the foreign reference to the parent purchase order header. This is the principal join column back to PO_HEADERS_ALL.
  • ATTR_GROUP_ID — identifies the flexfield attribute group (context) to which the row's segments belong, allowing multiple DFF contexts to coexist for one header.
  • DATA_LEVEL_ID — distinguishes the data level (header-level versus line- or other-level context) applicable to the extension row.
  • PK1_VALUE through PK5_VALUE — the concatenated segment values that form the DFF context-determining key for the population.
  • C_EXT_ATTR1 … C_EXT_ATTR40 — forty character descriptive attribute columns, the primary holders of free-text or codified segment values.
  • N_EXT_ATTR1 … N_EXT_ATTR20 — twenty numeric descriptive attributes for quantities, amounts, or identifiers.
  • UOM_EXT_ATTR1 … UOM_EXT_ATTR20 — twenty unit-of-measure attributes for measure-related segments.
  • D_EXT_ATTR1 … D_EXT_ATTR10 — ten date attributes for date-valued segments.
  • UDA_TEMPLATE_ID — references the user-defined attribute template governing the extension layout.
  • DRAFT_ID — foreign key to PO_DRAFTS, linking an extension row to a draft order.
  • REVISION_NUM — revision control counter for the extension row.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard EBS audit (WHO) columns.

Common Use Cases and Queries

The principal use case is reporting on customer-defined purchase order attributes that are not exposed in PO_HEADERS_ALL. A DFF context may, for example, record a project code, an internal approval classification, or a contract reference. Reporting requires joining the extension table to the base header table:

  • Header plus DFF attributes:

    SELECT pha.segment1, pha.org_id, phe.c_ext_attr1, phe.c_ext_attr2, phe.d_ext_attr1
    FROM po.po_headers_all pha, po.po_headers_all_ext_b phe
    WHERE pha.po_header_id = phe.po_header_id
    AND phe.attr_group_id = :context_id;

  • Context-filtered extraction: filter on PK1_VALUE through PK5_VALUE to isolate a specific DFF context, which is essential when the same header can carry multiple contexts.
  • Data conversion and migration: interface and open-interface programs frequently write header DFF values into this table, so validating an import requires reconciling ATTR_GROUP_ID and the applicable attribute columns.
  • Personalization and auditing: comparing the WHO columns across REVISION_NUM changes supports audits of who altered configurable header information and when.

Because attribute columns are generically named, a functional or DBA reference of the flexfield registration must be consulted to translate C_EXT_ATTR, N_EXT_ATTR, UOM_EXT_ATTR, and D_EXT_ATTR positions into meaningful segment names before building user-facing reports.

Related Objects

  • PO_HEADERS_ALL — the parent purchase order header table; joined on PO_HEADERS_ALL.PO_HEADER_ID = PO_HEADERS_ALL_EXT_B.PO_HEADER_ID.
  • PO_DRAFTS — referenced by the documented foreign key PO_HEADERS_ALL_EXT_B.DRAFT_ID → PO_DRAFTS, associating extension data with draft orders.
  • PO_HEADERS_ALL_EXT_TL — the translation companion to this _B table in 12.2.2, holding translatable segment values keyed by EXTENSION_ID and language.
  • FND_DESCR_FLEX_COL_USAGE — descriptive flexfield usage registration that maps physical columns (C_EXT_ATTR, N_EXT_ATTR, UOM_EXT_ATTR, D_EXT_ATTR, and so on) to logical segment names.
  • FND_FLEX_VALUE_SETS and FND_FLEX_VALUES — provide the value sets and values validated by the DFF segments.
  • PO_HEADERS_ALL_EXT_TL and FND_DESCR_FLEX_CONTEXTS — the context definitions that populate ATTR_GROUP_ID and the PK1_VALUE through PK5_VALUE pairing.
  • PO_HEADERS_ALL related line tables such as PO_LINES_ALL and PO_LINE_LOCATIONS_ALL — frequently queried alongside header DFF data for complete procurement reporting.

Developers manipulating this table directly should preserve the EXTENSION_ID sequence and the ATTR_GROUP_ID/DATA_LEVEL_ID pairing; bypassing flexfield APIs such as the FND DFF routines risks inconsistent contexts that will not resolve in standard Purchasing forms.