Search Results dpp_execution_processes

Overview

DPP_EXECUTION_PROCESSES is a table owned by the DPP schema, where DPP denotes Oracle Price Protection. It stores the list of all DPP processes associated with price protection transactions. In Oracle E-Business Suite 12.1.1 and 12.2.2, this table functions as a registry that records which processing routines have been executed against a given transaction header, allowing the application to track, audit, and control the sequence of DPP processing activities.

The heuristic Data Vault classification mined from the foreign key structure is standalone. In Data Vault modeling terms this suggests the table is not a pure hub, link, or satellite, but rather an association-style entity that combines a transaction reference with a process identifier. Because the object carries descriptive and audit columns (CREATION_DATE, CREATED_BY, and the LAST_UPDATE family), it behaves partly like a satellite recording state transitions over time, while its composite primary key gives it link-like characteristics binding a transaction to a process. Modelers may therefore treat it as a degenerate link or a link-satellite hybrid rather than a standalone reference table.

Key Information Stored

The documented physical schema for ETRM 12.2.2 contains seven columns. The most significant are:

• TRANSACTION_HEADER_ID — the identifier of the parent price protection transaction header to which the process record belongs.
• PROCESS_CODE — the code identifying the specific DPP process that was executed or registered for the transaction.
• CREATION_DATE — the timestamp when the process record was created.
• CREATED_BY — the user or application account that created the record.
• LAST_UPDATE_DATE — the timestamp of the most recent modification.
• LAST_UPDATED_BY — the user or application account responsible for the last modification.
• LAST_UPDATE_LOGIN — the login context associated with the last update.

The primary key is composite, defined on (TRANSACTION_HEADER_ID, PROCESS_CODE). A unique index, DPP_EXECUTION_PROCESSES_U1, enforces the same column pair, confirming it as the business-key candidate: a given transaction can appear only once per process code. There is no separate surrogate key column documented; the composite pair itself serves as the identifying key. The remaining columns are standard Oracle EBS audit (WHO) columns rather than business attributes.

Common Use Cases and Queries

Typical scenarios include determining which processes have run for a transaction, identifying transactions where an expected process is missing, and auditing when and by whom a process record was created or changed.

To list all processes recorded for a specific transaction:

• SELECT process_code, creation_date, created_by FROM dpp.dpp_execution_processes WHERE transaction_header_id = :p_header_id;

To find whether a particular process has executed for a header:

• SELECT COUNT(*) FROM dpp.dpp_execution_processes WHERE transaction_header_id = :p_header_id AND process_code = :p_process_code;

To identify headers lacking a required process code, report all transaction headers from the parent header table and use a NOT EXISTS or outer join against DPP_EXECUTION_PROCESSES on TRANSACTION_HEADER_ID and PROCESS_CODE. For aggregate reporting, group by PROCESS_CODE to measure process volume across a date range filtered on CREATION_DATE. Because the table is keyed on transaction and process, these queries are efficient through the DPP_EXECUTION_PROCESSES_U1 unique index. Queries should be executed with appropriate privileges on the DPP schema or through the corresponding Oracle Price Protection application views and concurrent programs rather than against the base table directly where possible.

Related Objects

The following objects are most significant in relation to DPP_EXECUTION_PROCESSES:

• DPP transaction header table — joined on TRANSACTION_HEADER_ID, providing the parent transaction context for each process record.
• DPP_PROCESSES / process definition reference — joined on PROCESS_CODE, supplying the description and behavior of each process.
• DPP_EXECUTION_PROCESSES_U1 — the unique index on (TRANSACTION_HEADER_ID, PROCESS_CODE) that enforces the composite business key.
• DPP transaction line or detail tables — related indirectly through TRANSACTION_HEADER_ID where process execution is scoped to header-level transactions.
• Oracle Price Protection concurrent programs and PL/SQL APIs — the runtime components that insert and update rows in this table as processes execute.
• FND audit and WHO columns — the standard EBS audit framework populated through CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN.

Because the mined FK classification is standalone, no additional foreign keys are documented beyond the composite key relationship implied by the primary key and unique index. Report authors should therefore validate parent-child joins against the Oracle Price Protection header structures before building custom queries.