Search Results okc_doc_qa_lists




Overview
Explore in AI Chat

Overview

The OKC_DOC_QA_LISTS table resides in the OKC schema (Contracts Core) and is a foundational configuration object within Oracle E-Business Suite's Contract Lifecycle Management module. Its documented purpose is to store the list of all Quality Assurance (QA) checks to be performed for a given business document type, together with the severity of each check. In practical terms, it acts as a rule matrix that tells the Contracts application which validation or review activities apply to a specific contract or business document category, and how strictly violations should be treated.

From a Data Vault modeling perspective, the metadata's heuristic classification is satellite-leaning. This is consistent with the table's structure: a natural business key of (DOCUMENT_TYPE, QA_CODE) is qualified by descriptive attributes such as SEVERITY_FLAG and ENABLE_QA_YN, which describe properties of the relationship rather than acting as standalone hubs or links. Modelers may therefore find it useful to treat OKC_DOC_QA_LISTS as a satellite attached to a hub/link representing business document types and QA checks.

Key Information Stored

The table contains 11 documented columns. The primary key, OKC_DOC_QA_LISTS_PK, is defined over (DOCUMENT_TYPE, QA_CODE). A unique index, OKC_DOC_QA_LISTS_U1, spans (DOCUMENT_TYPE, QA_CODE, ZD_EDITION_NAME), indicating the business-key candidate when edition context is included.

  • DOCUMENT_TYPE — Identifier of the business document type the QA rule applies to; part of the composite primary key and the FK to OKC_BUS_DOC_TYPES_B.
  • QA_CODE — Code identifying the individual QA check; the other half of the composite primary key.
  • SEVERITY_FLAG — Indicates the severity of the QA check, determining whether a failed check is blocking or advisory.
  • ENABLE_QA_YN — Flag controlling whether the specific QA check is active for the document type.
  • OBJECT_VERSION_NUMBER — Optimistic-locking column used by the framework to detect concurrent updates.
  • CREATED_BY, CREATION_DATE — Standard audit columns recording who created the row and when.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard audit columns capturing the most recent modification.
  • ZD_EDITION_NAME — Editioning column supporting EBS online patching (Edition-Based Redefinition).

Common Use Cases and Queries

Functional and technical teams query OKC_DOC_QA_LISTS to understand which QA checks are configured for a document type, to verify that a given check is enabled, and to review severity settings when diagnosing contract validation behavior.

  • List all QA checks for a specific document type:

    SELECT qa_code, severity_flag, enable_qa_yn FROM okc.okc_doc_qa_lists WHERE document_type = :p_doc_type;

  • Identify enabled checks only:

    SELECT document_type, qa_code FROM okc.okc_doc_qa_lists WHERE enable_qa_yn = 'Y';

  • Join to document type definitions to obtain descriptive names:

    SELECT l.document_type, b.document_type_name, l.qa_code, l.severity_flag FROM okc.okc_doc_qa_lists l JOIN okc.okc_bus_doc_types_b b ON b.document_type = l.document_type;

Related Objects

The most significant relationship documented is the foreign key from OKC_DOC_QA_LISTS.DOCUMENT_TYPE to OKC_BUS_DOC_TYPES_B, which defines the business document types referenced by each QA rule. Beyond this documented FK, related objects in the Contracts Core module typically include the QA check definition tables that provide QA_CODE descriptions, the document types translation views such as OKC_BUS_DOC_TYPES_TL, and the contract validation APIs that consume these QA rules during contract authoring. Reporting joins should generally use OKC_BUS_DOC_TYPES_B as the master reference for document type attributes, with QA_CODE resolution handled through the corresponding QA definition object.