Search Results dpp_xla_headers_u1




Overview

DPP.DPP_XLA_HEADERS is a transaction extraction header table within the Price Protection (DPP) module of Oracle E-Business Suite, present in release levels 12.1.1 and 12.2.2. The table's documented purpose is to store transaction extract header information for Price Protection processing. Each row represents a single Price Protection transaction header that is staged for downstream extraction, cost update, or claim settlement activity. The table carries two secondary indexes and is physically stored in the APPS_TS_TX_DATA tablespace with a PCT Free of 10, which is consistent with a moderately sized transactional staging table rather than a high-volume interface table.

The ETRM metadata classifies this object heuristically as standalone, meaning no foreign key constraints are documented against it. From a Data Vault modeling perspective, this classification suggests the table behaves as a hub-like or satellite-like structure: the transaction header identity is captured by a composite business key, while descriptive and audit attributes such as PROCESSED_FLAG and ERROR_DESCRIPTION act as satellite-style descriptive payload. The absence of documented references indicates the referential integrity is enforced by the application layer rather than the database.

Key Information Stored

The table contains ten documented columns. The composite primary key, DPP_XLA_HEADERS_PK, is defined over TRANSACTION_HEADER_ID, PP_TRANSACTION_TYPE, and BASE_TRANSACTION_HEADER_ID. The unique index DPP_XLA_HEADERS_U1 mirrors these same three columns, making them the business-key candidates for the object.

  • TRANSACTION_HEADER_ID (NUMBER) — the Price Protection Transaction Header ID, and the leading column of the primary key and unique index.
  • PP_TRANSACTION_TYPE (VARCHAR2, 30) — the Price Protection transaction type; part of the composite key and the primary discriminator between transaction categories.
  • BASE_TRANSACTION_HEADER_ID (NUMBER) — the Trade Management claim header ID for claim settlement, or the Price Protection execution process ID for cost update; also part of the composite key.
  • PROCESSED_FLAG (VARCHAR2) — processing status indicator with a documented default of 'N'.
  • ERROR_DESCRIPTION (VARCHAR2, 500) — free-text description of any error encountered while processing the header.
  • CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — the standard WHO audit columns.

Common Use Cases and Queries

The most frequent operational access pattern is the indexed retrieval of unprocessed headers by status. The nonunique index DPP_XLA_HEADERS_N1 on PROCESSED_FLAG directly supports this pattern, which is the standard driver for concurrent extraction programs.

SELECT TRANSACTION_HEADER_ID, PP_TRANSACTION_TYPE,
       BASE_TRANSACTION_HEADER_ID, ERROR_DESCRIPTION
  FROM DPP.DPP_XLA_HEADERS
 WHERE PROCESSED_FLAG = 'N';

A second common pattern is point lookup by the full business key to confirm whether a given claim or execution process has already been staged:

SELECT PROCESSED_FLAG, ERROR_DESCRIPTION
  FROM DPP.DPP_XLA_HEADERS
 WHERE TRANSACTION_HEADER_ID = :p_id
   AND PP_TRANSACTION_TYPE = :p_type
   AND BASE_TRANSACTION_HEADER_ID = :p_base_id;

Reporting use cases include reconciliation of failed Price Protection transactions (rows where PROCESSED_FLAG remains 'N' and ERROR_DESCRIPTION is populated), throughput analysis by transaction type, and aging of unprocessed headers using CREATION_DATE. Because the composite key links a Price Protection header to a Trade Management claim or execution process, the table also serves as the bridge reference for cross-module audits between Price Protection and Trade Management.

Related Objects

The documented dependency section reports that DPP_XLA_HEADERS references no database object, but it is referenced by DPP.DPP_XLA_HEADERS#, an object maintained in the DPP schema. The heuristic relationship classification is standalone, so no FK-constrained child tables are documented. Practically, application-level joins are expected to the following:

  • DPP.DPP_XLA_HEADERS# — the referenced dependent object in the DPP schema, joined on the composite key columns.
  • Trade Management claim headers — joined via BASE_TRANSACTION_HEADER_ID when PP_TRANSACTION_TYPE indicates claim settlement.
  • Price Protection execution process definitions — joined via BASE_TRANSACTION_HEADER_ID when PP_TRANSACTION_TYPE indicates cost update.
  • Price Protection transaction header entities — joined via TRANSACTION_HEADER_ID and PP_TRANSACTION_TYPE.
  • FND concurrent request and log objects — correlated via CREATED_BY and LAST_UPDATED_BY to trace the extraction program that populated each row.

Queries joining these objects should rely on the composite key triplet rather than TRANSACTION_HEADER_ID alone, since the same header ID may recur across transaction types and base references within a single business cycle.