Search Results dpp_transaction_headers_all




Overview
Explore in AI Chat

Overview

DPP_TRANSACTION_HEADERS_ALL is the header-level transaction table for the Oracle Price Protection (DPP) module in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the master record for each price protection transaction, capturing the vendor, document references, effective dates, currency, and workflow status that drive downstream price protection processing. Unlike inventory or order management tables, DPP_TRANSACTION_HEADERS_ALL is dedicated to tracking price protection claims and their lifecycle, from initial entry through approval, decline, or follow-up action.

The table resides in the DPP schema, is marked VALID, and is documented with 61 columns in ETRM 12.2.2. Because it holds descriptive transaction attributes keyed to a surrogate identifier rather than resolving many-to-many relationships between other hubs, the heuristic Data Vault classification is standalone; as a modeling suggestion, it behaves like a satellite centered on its own transaction hub, without documented foreign-key links to parent hubs in the provided metadata.

Key Information Stored

The primary key is the surrogate column TRANSACTION_HEADER_ID, which uniquely identifies each transaction header row and is also exposed through the unique index DPP_TRANSACTION_HEADERS_ALL_U1. A second unique index, DPP_TRANSACTION_HEADERS_ALL_U2, is built on TRANSACTION_NUMBER, making it the principal business-key candidate for user-facing identification.

The most significant columns include:

Common Use Cases and Queries

Typical reporting and integration scenarios include listing open price protection transactions by vendor, filtering by status, or reconciling transactions to source documents. A common pattern retrieves headers for a given operating unit and status:

  • SELECT transaction_number, vendor_id, effective_start_date, transaction_status FROM dpp.dpp_transaction_headers_all WHERE org_id = :org_id AND transaction_status = :status;
  • Joining to vendor and site master for descriptive reporting using VENDOR_ID and VENDOR_SITE_ID.
  • Tracking declined transactions via DECLINE_REASON_CODE and pending follow-ups via FOLLOWUP_ACTION.
  • Auditing changes using LAST_REFRESHED_BY, LAST_REFRESHED_DATE, and the standard WHO columns.

Related Objects

The provided relationship data classifies this table as standalone, with no mined foreign-key links to parent hubs. Consequently, joins are typically made at the application level rather than through enforced database constraints. The most relevant associated objects include: