Search Results dpp_transaction_headers_all_n1

Overview

DPP.DPP_TRANSACTION_HEADERS_ALL is the header-level transaction table for the Oracle E-Business Suite Price Protection (DPP) module. It stores the master record for each Price Protection transaction, capturing supplier identification, effective dating, transactional currency, approval workflow state, and audit metadata. In Oracle EBS 12.1.1 and 12.2.2 this table serves as the primary parent object for Price Protection processing, providing the header context against which transactional line details, covered inventory calculations, and approval actions are resolved.

The table is owned by the DPP schema and resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10. It is registered in FND Design Data as DPP.DPP_TRANSACTION_HEADERS_ALL and is classified as VALID. The documented physical schema lists 61 columns, of which 30 are generic ATTRIBUTE1 through ATTRIBUTE30 descriptive flexfield segments, together with the standard EBS WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) and concurrent program context columns (REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE).

From a Data Vault modeling perspective, the mined relationship data classifies this object as standalone, which suggests treating it as a hub-style structure: TRANSACTION_HEADER_ID functions as the durable surrogate business key, while the descriptive and status attributes behave as satellite content. This classification is a heuristic modeling suggestion rather than a declarative constraint in EBS itself.

Key Information Stored

The primary key is enforced by the unique index DPP_TRANSACTION_HEADERS_ALL_U1 on TRANSACTION_HEADER_ID, the surrogate identifier for the Price Protection transaction. A second unique index, DPP_TRANSACTION_HEADERS_ALL_U2 on TRANSACTION_NUMBER, serves as the natural business-key candidate; this is the index the user search term references. The most significant stored attributes include:

• TRANSACTION_HEADER_ID — unique numeric identifier and primary key of the transaction header.
• TRANSACTION_NUMBER — the user-visible transaction number, enforced unique by U2.
• TRANSACTION_STATUS — lifecycle state of the transaction: New, Pending Approval, Active, Rejected, Cancelled, or Closed.
• TRANSACTION_SOURCE — origin channel of the record: Manual, WebADI, XML, or Script.
• EFFECTIVE_START_DATE — the date from which the Price Protection transaction becomes valid.
• DAYS_COVERED — number of days covered by the transaction, used in coverage and expiry calculations.
• TRX_CURRENCY — the transactional currency of the price protection terms.
• VENDOR_ID, VENDOR_SITE_ID, VENDOR_CONTACT_ID — supplier, supplier site, and supplier contact identifiers.
• VENDOR_CONTACT_NAME, CONTACT_EMAIL_ADDRESS, CONTACT_PHONE — supplier contact detail for negotiation and notification.
• REF_DOCUMENT_NUMBER — internal approval or supplier-provided reference document number.
• ORG_ID — the operating unit that owns the transaction.
• LAST_REFRESHED_BY, LAST_REFRESHED_DATE — who and when the covered inventory calculation was last refreshed.
• DECLINE_REASON_CODE — reason captured when a transaction is rejected or declined.
• FOLLOWUP_ACTION — follow-up processing indicator.

Supporting non-unique indexes accelerate the most frequent access paths: DPP_TRANSACTION_HEADERS_ALL_N1 on (TRANSACTION_STATUS, EFFECTIVE_START_DATE) supports status-and-date filtering, while DPP_TRANSACTION_HEADERS_ALL_N3 on TRANSACTION_SOURCE supports source-based reporting.

Common Use Cases and Queries

Typical usage centers on approval worklists, supplier and operating-unit reporting, coverage tracking, and refresh monitoring. A worklist query for the pending approval queue:

• SELECT h.transaction_number, h.transaction_status, h.effective_start_date, h.trx_currency FROM dpp.dpp_transaction_headers_all h WHERE h.transaction_status = 'Pending Approval' AND h.org_id = :p_org_id;
• SELECT h.transaction_number, h.transaction_source, h.days_covered, h.effective_start_date FROM dpp.dpp_transaction_headers_all h WHERE h.effective_start_date >= :p_start AND h.effective_start_date < :p_end AND h.transaction_status = 'Active';
• SELECT h.last_refreshed_by, h.last_refreshed_date FROM dpp.dpp_transaction_headers_all h WHERE h.transaction_header_id = :p_header_id;
• SELECT h.transaction_status, COUNT(*) FROM dpp.dpp_transaction_headers_all h GROUP BY h.transaction_status;

Because the unique index U2 guarantees a single row per TRANSACTION_NUMBER, lookups by transaction number are deterministic and are the preferred entry point for integrations importing transactions through WebADI, XML, or scripts. Multi-org reporting must filter by ORG_ID, since the table is partitioned logically by operating unit rather than physically. Reporting on approval latency can join creation and program context columns to derive processing timelines.

Related Objects

DPP_TRANSACTION_HEADERS_ALL operates as the header parent for the Price Protection transaction model. Join the header to detail and calculation objects on TRANSACTION_HEADER_ID, which is the documented primary key column. The most significant related objects include:

• DPP_TRANSACTION_LINES_ALL — line-level detail for each Price Protection transaction, linked on TRANSACTION_HEADER_ID.
• DPP_TRANSACTION_HEADERS_ALL_U1 / _U2 — the unique indexes that enforce the surrogate and business keys respectively.
• DPP_TRANSACTION_HEADERS_ALL_N1 — the status-and-effective-date index used by approval and coverage queries.
• DPP_TRANSACTION_HEADERS_ALL_N3 — the transaction-source index used by integration and channel reporting.
• Vendor master views (AP_SUPPLIERS / PO_VENDORS) — resolve VENDOR_ID and VENDOR_SITE_ID to supplier names and sites.
• HR / FND user tables — resolve CREATED_BY and LAST_UPDATED_BY to application user names.
• FND concurrent program tables — resolve REQUEST_ID, PROGRAM_ID, and PROGRAM_APPLICATION_ID for the process that created or updated the header.

Standard EBS WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) and OBJECT_VERSION_NUMBER provide optimistic locking and audit traceability for all DPP transaction processing.