Search Results okc_contract_docs




Overview

OKC_CONTRACT_DOCS is a table owned by the OKC schema (Contracts Core) in Oracle E-Business Suite. It is classified as an intermediate table used by Contract Documents functionality to store Business Document attachment entries. In the Contracts module, business documents such as contracts, templates, and clauses require the ability to associate external or generated files—such as signed PDFs, terms documents, or supporting correspondence—and OKC_CONTRACT_DOCS serves as the junction that records these attachment relationships. It does not store the binary document content itself; rather it maps a business document to an attached document record managed by the Oracle Attachment framework (FND_DOCUMENTS / FND_ATTACHED_DOCUMENTS).

From a Data Vault modeling perspective, the metadata's heuristic classification identifies this table as standalone, meaning no foreign-key relationships were mined that would place it definitively within a hub, link, or satellite pattern. As a modeling suggestion, its structure—combining business document identity columns with an attached document identifier—is more consistent with a link-style association table (connecting a business document to an attachment) than with a pure hub or satellite. The classification should be treated as indicative rather than authoritative.

Key Information Stored

The table contains 24 documented columns. The most significant are the business-identity and attachment-mapping columns, which together form the unique key candidates:

Two unique indexes are documented as business-key candidates: OKC_CONTRACT_DOCS_UK1 and OKC_CONTRACT_DOCS_U1 (plus OKC_CONTRACTS_DOCS_U1), both keyed on BUSINESS_DOCUMENT_TYPE, BUSINESS_DOCUMENT_ID, BUSINESS_DOCUMENT_VERSION, and ATTACHED_DOCUMENT_ID, confirming that this four-column combination is the intended business identifier. The table does not expose a separately documented surrogate primary key column; the unique index acts as the effective primary key.

Common Use Cases and Queries

Typical reporting and integration scenarios involve retrieving all attachments for a given contract or confirming which document is flagged primary or externally visible.

  • Listing attachments for a specific contract: SELECT ATTACHED_DOCUMENT_ID, PRIMARY_CONTRACT_DOC_FLAG, EXTERNAL_VISIBILITY_FLAG FROM OKC_CONTRACT_DOCS WHERE BUSINESS_DOCUMENT_ID = :contract_id AND BUSINESS_DOCUMENT_TYPE = :doc_type;
  • Identifying the primary contract document: filter on PRIMARY_CONTRACT_DOC_FLAG = 'Y' and DELETE_FLAG = 'N'.
  • Auditing externally visible attachments for compliance and disclosure review.
  • Reconciling generated versus manually uploaded documents via GENERATED_FLAG.
  • Joining to FND_ATTACHED_DOCUMENTS on ATTACHED_DOCUMENT_ID to retrieve file names, media, and datastore references.

Related Objects

  • OKC_CONTRACTS (OKC schema) — the primary business document for contracts; joined via BUSINESS_DOCUMENT_ID where BUSINESS_DOCUMENT_TYPE indicates a contract.
  • OKC_CONTRACT_TEMPLATES — attachment owner when the business document type is a template.
  • FND_DOCUMENTS — the Oracle Attachment datastore record pointed to by ATTACHED_DOCUMENT_ID.
  • FND_ATTACHED_DOCUMENTS — the framework table linking entities to attachments; joined on ATTACHED_DOCUMENT_ID.
  • OKC_CONTRACT_DOCS_UK1 / OKC_CONTRACT_DOCS_U1 — unique indexes enforcing the four-column business key.
  • OKC Contract Documents concurrent programs and DFF/attachment APIs — which insert, update, and query rows in this table during contract authoring and approval.

Because the metadata classifies the table as standalone, join behavior should be validated against the actual column values of BUSINESS_DOCUMENT_TYPE and BUSINESS_DOCUMENT_ID before relying on any single parent entity.