Search Results okc_rep_imp_errors_t_pk1

Overview

OKC_REP_IMP_ERRORS_T is a temporary staging table in the OKC (Contracts Core) schema of Oracle E-Business Suite, present in releases 12.1.1 and 12.2.2. It stores the error messages generated during the validation phase of contract import processing. When bulk contract data is loaded through the Contracts Core import interface, each incoming record is validated; records that fail validation produce one or more error rows in this table. Those rows are subsequently used to generate an output CSV file containing the invalid records alongside their corresponding error messages, giving the user actionable feedback on why a given contract or line was rejected. The table is transient by design: its contents are purged after each import run completes, so it functions as a working buffer rather than a persistent audit log.

The ETRM metadata classifies this object heuristically as a standalone Data Vault model. Although it carries a foreign key to the import contract staging table, that relationship is procedural rather than a durable business association, and the table is scoped to a single batch run. As a modeling suggestion, the table is therefore best treated as a transient satellite-like buffer of validation outcomes rather than as a hub or link participating in a long-lived integration model.

Key Information Stored

The table is defined in the OKC schema with 11 documented columns. The most significant of these are:

• IMP_ERROR_ID — The surrogate primary key, enforced by OKC_REP_IMP_ERRORS_T_PK1 and by the unique index OKC_REP_IMP_ERROR_T_U1. It uniquely identifies each error row.
• IMP_CONTRACT_ID — Foreign key to OKC_REP_IMP_CONTRACTS_T, identifying the staged contract record that failed validation.
• ERROR_OBJECT_TYPE — Indicates the type of object (for example contract header or line) that produced the error.
• ERROR_OBJECT_ID — The identifier of the specific object instance within the imported contract that triggered the message.
• ERROR_MESSAGE — The human-readable validation error text written to the output CSV.
• CREATION_DATE — Timestamp of error row creation, used to isolate rows belonging to a particular run.
• REQUEST_ID — The concurrent request that generated the error, enabling traceability to the concurrent program log.
• RUN_ID — Identifier for the specific import execution, used to group error rows by batch.
• PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_LOGIN_ID — Standard WHO-style audit columns identifying the concurrent program and the login under which the import executed.

Because IMP_ERROR_ID is the sole unique business-key candidate, all other columns should be regarded as descriptive payload attached to that key.

Common Use Cases and Queries

The principal use case is diagnosing failed contract imports. A typical query retrieves all errors for the most recent run:

SELECT e.IMP_ERROR_ID, e.IMP_CONTRACT_ID, e.ERROR_OBJECT_TYPE,
       e.ERROR_OBJECT_ID, e.ERROR_MESSAGE
FROM   OKC.OKC_REP_IMP_ERRORS_T e
WHERE  e.RUN_ID = :run_id
ORDER BY e.IMP_CONTRACT_ID, e.IMP_ERROR_ID;

Support analysts may correlate errors with the concurrent request by querying on REQUEST_ID, or aggregate message frequency to identify systemic data issues in the source file. Reporting against this table should always be time-bounded, since rows are deleted after each import cycle.

Related Objects

• OKC_REP_IMP_CONTRACTS_T — Referenced via IMP_CONTRACT_ID; holds the staged contract records being validated.
• OKC_REP_IMP_ERRORS_T_PK1 / OKC_REP_IMP_ERROR_T_U1 — Primary key and unique index on IMP_ERROR_ID.
• Contract Import concurrent program — The process that populates and purges this table and produces the CSV output.
• FND_CONCURRENT_REQUESTS — Joined on REQUEST_ID to obtain run status and timing.
• FND_LOG_MESSAGES — Optional companion source for deeper diagnostics alongside ERROR_MESSAGE.