Search Results okc_contract_docs_uk1

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:

• BUSINESS_DOCUMENT_TYPE — identifies the type of business document (for example, a contract or template) that owns the attachment.
• BUSINESS_DOCUMENT_ID — the identifier of the specific business document instance.
• BUSINESS_DOCUMENT_VERSION — the version of the business document to which the attachment applies.
• ATTACHED_DOCUMENT_ID — the identifier of the attachment record associated with the business document.
• EXTERNAL_VISIBILITY_FLAG — indicates whether the attachment is visible to external parties.
• INCLUDE_FOR_APPROVAL_FLAG — controls whether the document participates in the approval workflow.
• GENERATED_FLAG — denotes documents produced by the system rather than uploaded manually.
• DELETE_FLAG — soft-delete marker for the attachment entry.
• PRIMARY_CONTRACT_DOC_FLAG — identifies the primary contract document among multiple attachments.
• MERGEABLE_DOC_FLAG — indicates whether the document may be included in document merge operations.
• PARENT_ATTACHED_DOC_ID — references a parent attachment, supporting hierarchical document relationships.
• EFFECTIVE_FROM_TYPE, EFFECTIVE_FROM_ID, EFFECTIVE_FROM_VERSION — capture the effective-dating context for the attachment.
• Standard WHO columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, plus OBJECT_VERSION_NUMBER for optimistic locking.

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.