Search Results okc_rep_imp_contracts_t_pk1

Overview

OKC_REP_IMP_CONTRACTS_T is a temporary (staging) table owned by the OKC schema within the Contracts Core module of Oracle E-Business Suite, and is documented as VALID in both release 12.1.1 and 12.2.2. It stores inbound contract header attributes during import operations performed through the Contracts Repository import process. The table functions as an intermediate landing area: rows are populated from a source file or feeder system, validated against contract rules, transformed into a structure suitable for insertion into the Contracts Repository schema, and finally used to drive error output files for invalid or rejected records.

The table is physically wide, containing 64 documented columns, which reflects that it mirrors the majority of contract header attributes needed to create a contract record. From a Data Vault modeling perspective, the mined metadata suggests a standalone classification, since the primary key is a single surrogate identifier (IMP_CONTRACT_ID) and the entity is not decomposed into hub, link, or satellite structures in the delivered ETRM data model. It is best treated as a transient staging entity rather than a persistent dimensional or historical store.

Key Information Stored

The table is keyed by a surrogate primary key, IMP_CONTRACT_ID, defined by constraint OKC_REP_IMP_CONTRACTS_T_PK1. A unique index, OKC_REP_IMP_CONTRACTS_T_U1, is also defined on the same column, making IMP_CONTRACT_ID the single documented business-key candidate for this staging table. The most significant columns fall into several groups:

• Contract identity: CONTRACT_ID, CONTRACT_NUMBER, CONTRACT_NAME, CONTRACT_VERSION_NUM, and LATEST_SIGNED_VER_NUMBER hold the target repository key and version information.
• Classification: CONTRACT_TYPE, CONTRACT_STATUS_CODE, AUTHORING_PARTY_CODE, and their descriptive counterparts CONTRACT_TYPE_TXT, CONTRACT_STATUS_TXT, AUTHORING_PARTY_TXT support validation against enabled lookup values.
• Dates and financials: CONTRACT_EFFECTIVE_DATE, CONTRACT_EXPIRATION_DATE, CURRENCY_CODE, and CONTRACT_AMOUNT capture the commercial core of the contract header.
• Ownership and organization: ORG_ID, ORG_NAME, OWNER_USER_ID, and OWNER_USER_NAME identify the responsible business unit and contract owner.
• External references: ORIG_SYSTEM_REFERENCE_CODE, ORIG_SYSTEM_REFERENCE_ID1, and ORIG_SYSTEM_REFERENCE_ID2 support reconciliation back to the originating system.
• Validation and audit: VALID_FLAG marks whether the staged row passed validation; RUN_ID, REQUEST_ID, PROGRAM_ID, and CREATION_DATE tie the row to the concurrent program execution that produced it.
• Flexfield support: ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 provide the descriptive flexfield surface used when contract headers carry user-defined attributes.

Termination/expiration metadata (TERMINATION_DATE, TERMINATION_COMMENTS, CANCELLATION_DATE, CANCELLATION_COMMENTS, EXPIRE_NTF_FLAG, EXPIRE_NTF_PERIOD) and risk indicators (OVERALL_RISK_CODE, OVERALL_RISK_TXT) are also present, along with NOTIFY_CONTACT_ROLE_ID and NOTIFY_CONTACT_ROLE_TXT for notification routing.

Common Use Cases and Queries

The primary use case is troubleshooting import runs. Because errors are written to a companion table, the typical diagnostic pattern joins the header staging rows to the error rows to isolate rejected contracts:

• Validate an import run: SELECT IMP_CONTRACT_ID, CONTRACT_NUMBER, CONTRACT_NAME, VALID_FLAG FROM OKC.OKC_REP_IMP_CONTRACTS_T WHERE RUN_ID = :run_id — this lists all staged headers for a given execution.
• Find rejected contracts: join OKC_REP_IMP_CONTRACTS_T to OKC_REP_IMP_ERRORS_T on IMP_CONTRACT_ID where VALID_FLAG = 'N'.
• Reconcile to the repository: compare staged rows against OKC_K_HEADERS_B (via CONTRACT_ID or CONTRACT_NUMBER) to confirm which headers were successfully created.
• Reporting on import volume: aggregate by RUN_ID, CREATION_DATE, or ORIG_SYSTEM_REFERENCE_CODE to trend successful versus failed imports.

Because this is a temporary staging table, queries should generally be scoped by RUN_ID to a specific import batch, and rows may be purged or reused by subsequent runs. Reports relying on this table should therefore avoid treating it as a historical archive.

Related Objects

The table is the parent of several child staging tables, all joined on IMP_CONTRACT_ID, forming a self-contained import staging schema:

• OKC_REP_IMP_RISKS_T — staged risk attributes linked via IMP_CONTRACT_ID.
• OKC_REP_IMP_CONTACTS_T — staged contract contacts linked via IMP_CONTRACT_ID.
• OKC_REP_IMP_DOCUMENTS_T — staged document references linked via IMP_CONTRACT_ID.
• OKC_REP_IMP_PARTIES_T — staged contract parties linked via IMP_CONTRACT_ID.
• OKC_REP_IMP_ERRORS_T — validation errors and rejection messages linked via IMP_CONTRACT_ID.

Downstream, the import process writes validated rows into the Contracts Repository schema, principally OKC_K_HEADERS_B and its associated version and party tables. The concurrent program that manages this staging cycle is the Contracts Repository import program, driven by the REQUEST_ID and PROGRAM_ID columns recorded on each staged row.