Search Results dpp_xla_lines_u1

Overview

DPP.DPP_XLA_LINES is a transaction extract lines table in the Oracle E-Business Suite DPP (Price Protection) schema. It stores line-level detail generated by the Price Protection transaction extract process, which interfaces Price Protection activity with Oracle Subledger Accounting (XLA) and, downstream, with the trade management claim settlement and cost update processes. The table serves as a staging and mapping layer: each row ties a Price Protection transaction line to an underlying base transaction — either a Trade Management claim header/line pair for claim settlement, or a price protection execution process detail/transaction pair for cost updates.

The object resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10, consistent with other transactional staging objects in EBS 12.1.1 and 12.2.2. It is registered in FND Design Data as DPP.DPP_XLA_LINES and is owned by the DPP schema; the APPS synonym DPP_XLA_LINES exposes it to application code. Heuristic Data Vault classification mined from the foreign-key structure is standalone, meaning the table does not reference other database objects per the documented dependency data. In Data Vault terms, this leans toward a hub or link style of modeling: the four-column natural key identifies a relationship between a transaction line and a base transaction line, rather than describing descriptive attributes of a single entity.

Key Information Stored

The table contains ten documented columns. The physical primary key, DPP_XLA_LINES_PK, is composed of TRANSACTION_HEADER_ID, TRANSACTION_LINE_ID, BASE_TRANSACTION_HEADER_ID, and BASE_TRANSACTION_LINE_ID. The unique index DPP_XLA_LINES_U1 covers the same four columns, making this composite the business-key candidate that enforces uniqueness of each transaction-to-base-transaction pairing.

• TRANSACTION_HEADER_ID — Price Protection Transaction Header identifier; part of both the primary key and the unique index.
• TRANSACTION_LINE_ID — Price Protection transaction line identifier; completes the transaction side of the key.
• BASE_TRANSACTION_HEADER_ID — the Trade Management claim header ID when the extract supports claim settlement, or the price protection execution process detail ID for cost updates; forms the base side of the key.
• BASE_TRANSACTION_LINE_ID — the Trade Management claim line ID for claim settlement, or the transaction ID for cost update.
• TRANSACTION_SUB_TYPE — VARCHAR2(20) applicable only to Cost Update, storing either PRICE_INCREASE or PRICE_DECREASE.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard WHO audit columns populated by the application for row-level traceability.

No descriptive attributes beyond TRANSACTION_SUB_TYPE and the WHO columns are documented, which reinforces the view that this is a mapping/relationship table rather than a transactional detail master.

Common Use Cases and Queries

Typical usage is diagnostic and integration-oriented: confirming which Price Protection transaction lines were extracted to XLA, tracing a claim settlement back to the originating transaction line, or verifying cost update directionality through TRANSACTION_SUB_TYPE. A basic lookup by transaction header returns all extracted lines together with their base mapping:

• Extract audit: SELECT TRANSACTION_HEADER_ID, TRANSACTION_LINE_ID, BASE_TRANSACTION_HEADER_ID, BASE_TRANSACTION_LINE_ID, TRANSACTION_SUB_TYPE FROM DPP.DPP_XLA_LINES WHERE TRANSACTION_HEADER_ID = :header_id.
• Cost update split: filter WHERE TRANSACTION_SUB_TYPE IN ('PRICE_INCREASE','PRICE_DECREASE') to isolate cost update rows and reconcile price movement direction.
• Stale or duplicate detection: compare counts against the source Price Protection transaction lines and rely on DPP_XLA_LINES_U1 to enforce uniqueness during re-extraction.
• WHO-based troubleshooting: use CREATION_DATE and LAST_UPDATE_DATE ranges to identify rows produced by a specific extract run.

Related Objects

The documented dependency section states that DPP_XLA_LINES does not reference any database object and is referenced only by the APPS synonym DPP_XLA_LINES. No FK relationships are recorded, which is consistent with the standalone Data Vault classification. The closest related objects are therefore identified by shared columns rather than declared constraints:

• APPS.DPP_XLA_LINES — the synonym through which application and reporting code accesses the table.
• DPP_XLA_LINES_U1 — the unique index on the four business-key columns; the access path for point lookups and enforcement of extraction uniqueness.
• DPP_XLA_LINES_PK — the primary key on the same four columns.
• Price Protection transaction header and line tables in the DPP schema, joined on TRANSACTION_HEADER_ID and TRANSACTION_LINE_ID.
• Trade Management claim header and line tables in the OZF schema, joined on BASE_TRANSACTION_HEADER_ID and BASE_TRANSACTION_LINE_ID for claim settlement.
• Price protection execution process detail and cost update source tables, joined on the same BASE_* columns for cost updates.

Because the metadata records no explicit foreign keys, join paths should be confirmed against the owning schemas before being codified in production reporting.