Search Results dpp_transaction_lines_log




Overview
Explore in AI Chat

Overview

DPP_TRANSACTION_LINES_LOG is a history (audit) table owned by the DPP schema within Oracle Price Protection, a module that manages supplier price protection claims and related purchasing, inventory, and pricing adjustments. The table stores historical snapshots of Price Protection Transaction Line level detail. Each row captures the state of a transaction line at a point in time, recorded as a log entry rather than as a live transactional record. This design preserves the audit trail of price changes, claim amounts, inventory quantities, and downstream update/notification flags, allowing users to reconstruct how a transaction line evolved.

From a heuristic Data Vault modeling perspective mined from the FK structure, this object is classified as standalone, meaning no foreign key relationships were detected. That classification suggests it functions less like a link or hub within a normalized vault model and more like a self-contained satellite or history store, keyed only by its own surrogate LOG_ID.

Key Information Stored

The table contains 58 documented columns. The most significant are summarized below.

Common Use Cases and Queries

Typical usage centers on audit and reconciliation reporting: reconstructing the price-change history for a transaction line, comparing claim amounts over time, and verifying which downstream updates or notifications were triggered.

  • Retrieve the full history for a transaction line:
SELECT log_id, log_mode, transaction_line_id, prior_price,
       change_type, change_value, claim_amount, supp_dist_claim_status,
       creation_date, created_by
FROM   dpp.dpp_transaction_lines_log
WHERE  transaction_line_id = :line_id
ORDER BY creation_date;
  • Report on claim status by operating unit:
SELECT org_id, supp_dist_claim_status,
       SUM(claim_amount) total_claim
FROM   dpp.dpp_transaction_lines_log
WHERE  creation_date BETWEEN :from_date AND :to_date
GROUP BY org_id, supp_dist_claim_status;
  • Identify manual adjustments or notification activity by filtering on MANUALLY_ADJUSTED and the NOTIFY_*/UPDATE_* flags.

Related Objects

The metadata documents no foreign keys for this object, so no referential constraints are declared. In practical terms, the most relevant related objects are those referenced by shared identifier columns rather than enforced constraints:

Because there are no declared foreign keys, joins rely on application-managed relationships via TRANSACTION_LINE_ID and ORG_ID. Reports should therefore validate orphan conditions and apply organization security carefully when querying across operating units.