Search Results dpp_transaction_headers_log_u1




Overview

DPP.DPP_TRANSACTION_HEADERS_LOG is a history (audit) table in the Oracle E-Business Suite DPP schema. Its documented purpose is to store historical information for changes made to the Price Protection Transaction Header. Every insert, update, or delete applied to the transactional header is captured here as a separate log row, allowing the full lifecycle of a Price Protection transaction to be reconstructed over time.

The table resides in the APPS_TS_TX_DATA tablespace with PCT FREE 10, and its unique index DPP_TRANSACTION_HEADERS_LOG_U1 resides in APPS_TS_TX_IDX. The object is marked VALID and is present in both EBS 12.1.1 and 12.2.2 (ETRM 12.2.2 documents 52 columns).

From a Data Vault modeling perspective, the mined relationship data classifies this object as a standalone table, but functionally it behaves as a satellite: it is keyed by a surrogate log identifier, carries a LOG_MODE flag that indicates the nature of the captured change, and holds the descriptive and foreign-key attributes of the source header at the point of modification. Treating it as a satellite of the Price Protection Transaction Header is a reasonable heuristic suggestion.

Key Information Stored

Common Use Cases and Queries

Typical reporting scenarios include approval audit trails, status-change history, and supplier amendment tracking. A frequent query retrieves the full change history for a single transaction:

  • SELECT log_id, log_mode, transaction_status, last_update_date, last_updated_by FROM dpp.dpp_transaction_headers_log WHERE transaction_header_id = :p_id ORDER BY log_id;
  • SELECT log_mode, COUNT(*) FROM dpp.dpp_transaction_headers_log WHERE org_id = :p_org GROUP BY log_mode; — volume and change-type analysis per operating unit.
  • SELECT transaction_header_id, transaction_status, effective_start_date FROM dpp.dpp_transaction_headers_log WHERE transaction_status = 'Rejected'; — exception reporting on rejected transactions.

Because the table carries ORG_ID and multi-org WHO columns, queries should be constrained by operating unit. Reporting is usually read-only; no DML should be issued against the log directly.

Related Objects