Search Results dpp_txn_headers_int_all_u1

Overview

DPP.DPP_TXN_HEADERS_INT_ALL is a Price Protection interface table in the Oracle E-Business Suite DPP (Price Protection) schema. It stores header-level details of Price Protection Transactions received from suppliers, functioning as a staging area between external supplier submissions and the validated DPP transaction structures. Records enter the table through WebADI, XML, or script-based transaction sources and are subsequently processed by the Price Protection transaction import concurrent programs.

Physically, the table resides in the APPS_TS_INTERFACE tablespace with a PCT Free of 10. In Oracle EBS 12.1.1 and 12.2.2, it carries the standard EBS _ALL naming convention because it contains an ORG_ID column, signifying multi-org (Operating Unit) partitioning at the row level. The table's design includes the full complement of WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) plus request-tracking columns (REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE) and 30 descriptive flexfield attribute columns (ATTRIBUTE1 through ATTRIBUTE30). A heuristic Data Vault classification suggests this object behaves as a hub-like interface entity, since it holds the unique transactional identity (TRANSACTION_INT_HEADER_ID) around which line-level satellites attach.

Key Information Stored

The table's 63 documented columns capture supplier-supplied transaction metadata. The most operationally significant include:

• TRANSACTION_INT_HEADER_ID — The surrogate primary key (DPP_TXN_HEADERS_INT_ALL_PK) and the single-column unique index DPP_TXN_HEADERS_INT_ALL_U1. It is the business-key candidate used to link header records to their corresponding line records.
• ORIG_SYS_DOCUMENT_REF — The originating system's document reference, essential for traceability back to the supplier's source record.
• REF_DOCUMENT_NUMBER — An internal approval-tracking reference provided by the supplier.
• EFFECTIVE_START_DATE and DAYS_COVERED — Define the validity window of the Price Protection Transaction.
• ORG_ID and OPERATING_UNIT_NAME — Determine the owning Operating Unit for multi-org data segregation.
• VENDOR_ID, VENDOR_NAME, VENDOR_SITE_ID, and VENDOR_SITE — Identify the supplier and supplier site.
• VENDOR_CONTACT_NAME, CONTACT_EMAIL_ADDRESS, and CONTACT_PHONE — Capture the supplier contact for dispute resolution.
• CURRENCY — The transactional currency for the claim amounts flowing through the associated line table.
• SUPP_DIST_CLAIM_ID and SUPP_DIST_CLAIM_NUMBER — Supplier/distributor claim identifiers.
• SUPPLIER_APPROVED_BY and SUPPLIER_APPROVAL_DATE — Pre-approval evidence from the supplier.
• TRANSACTION_SOURCE — Indicates the inbound channel (WebADI, XML, or Script), useful for load-diagnostic reporting.
• INTERFACE_STATUS and ERROR_CODE — Drive the import validation lifecycle and error feedback to the submitter.

Common Use Cases and Queries

The table supports inbound supplier claim ingestion, pre-import validation reporting, and reconciliation of interface errors before records are promoted into the transactional DPP schema. Typical query patterns include:

• Pending interface records: SELECT TRANSACTION_INT_HEADER_ID, VENDOR_NAME, EFFECTIVE_START_DATE FROM DPP_TXN_HEADERS_INT_ALL WHERE INTERFACE_STATUS = 'NEW' OR INTERFACE_STATUS IS NULL;
• Error triage: SELECT TRANSACTION_INT_HEADER_ID, ERROR_CODE, TRANSACTION_SOURCE FROM DPP_TXN_HEADERS_INT_ALL WHERE ERROR_CODE IS NOT NULL;
• Operating Unit rollup reporting: grouping by ORG_ID or OPERATING_UNIT_NAME to measure claim volumes per business unit.
• Supplier scorecarding: joining header and line rows to sum claim values by VENDOR_ID over a date range bounded by EFFECTIVE_START_DATE and DAYS_COVERED.
• Source channel analysis: aggregating TRANSACTION_SOURCE to determine whether WebADI, XML, or Script loads predominate and to detect ingestion anomalies.

Because the table is an interface object, reports typically filter on INTERFACE_STATUS to isolate records that have not yet been processed, avoiding double-counting once records are purged or archived following successful promotion.

Related Objects

The most significant dependency is the line-level interface table defined by the documented foreign key:

• DPP.DPP_TXN_LINES_INT_ALL — References DPP_TXN_HEADERS_INT_ALL.TRANSACTION_INT_HEADER_ID, holding the item-level detail lines for each header. The header-to-line join is the primary navigational path for interface reporting: SELECT h.TRANSACTION_INT_HEADER_ID, l.* FROM DPP_TXN_HEADERS_INT_ALL h, DPP_TXN_LINES_INT_ALL l WHERE h.TRANSACTION_INT_HEADER_ID = l.TRANSACTION_INT_HEADER_ID;

Beyond this documented FK, downstream processing is performed by the Price Protection transaction import concurrent programs that read from this interface table and populate the base Price Protection transaction tables in the DPP schema. The base tables (whose names are not enumerated in the supplied metadata) represent the validated, post-import counterpart of this staging data. The presence of REQUEST_ID and PROGRAM_ID columns confirms that the import routines are registered concurrent programs, enabling users to trace which concurrent request loaded each interface row. Operating Unit context is resolved through the standard EBS multi-org views, which filter DPP_TXN_HEADERS_INT_ALL by ORG_ID, while suppliers and sites are validated against the PO/AP vendor tables using VENDOR_ID and VENDOR_SITE_ID.