Results for “okc_qa_check_lists_b”

50+ results




AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The OKC_QA_CHECK_LISTS_B table resides in the OKC schema (Contracts Core) and is a foundational entity within Oracle E-Business Suite's Contracts module. Its documented purpose is to associate a list of quality assurance processes with a specific contract or contract template. In practice, this table serves as the master registry of QA check lists that can be attached to contracts, contract templates, or applied as org-level defaults. Each row represents a reusable quality assurance definition (a "check list") whose individual inspection items are stored in child tables.

Following the heuristic Data Vault classification provided in the metadata, the table leans toward a hub. It carries a single-column surrogate primary key (ID), minimal descriptive payload on the business key itself, and is referenced by multiple dependent tables via the QCL_ID foreign key column. In Data Vault terms, the hub would persist the durable identity of a QA check list, while descriptive attributes such as DEFAULT_YN, BEGIN_DATE, END_DATE, and the ATTRIBUTE1..15 columns would typically be modeled as a satellite. This classification should be treated as a modeling suggestion, not a physical constraint, as the table is a standard EBS transactional table with WHO audit columns.

Key Information Stored

The table contains 29 documented columns. The most significant include:

The unique index OKC_QA_CHECK_LISTS_B_U1 spans (ID, ZD_EDITION_NAME). Because ID alone is the PK, this composite unique index serves primarily to support Edition-Based Redefinition rather than to represent an independent business key. No natural business key column is separately documented, meaning the surrogate ID is the primary means of identifying a check list.

Common Use Cases and Queries

Typical scenarios include identifying which QA check lists are attached to a contract or template, listing all default check lists for a given operating unit, and reporting on active QA definitions within a date range. A representative query retrieving active default check lists is:

SELECT qcl.id,
       qcl.default_yn,
       qcl.begin_date,
       qcl.end_date
  FROM okc.okc_qa_check_lists_b qcl
 WHERE qcl.default_yn = 'Y'
   AND SYSDATE BETWEEN NVL(qcl.begin_date, SYSDATE)
                   AND NVL(qcl.end_date, SYSDATE + 1);

To find the check lists attached to a specific contract header, join on the QCL_ID relationship:

SELECT h.id contract_id,
       qcl.id check_list_id
  FROM okc.okc_k_headers_b h,
       okc.okc_qa_check_lists_b qcl
 WHERE h.qcl_id = qcl.id
   AND h.id = :p_contract_id;

Reporting use cases include an inventory of QA processes by operating unit (filtering on SECURITY_GROUP_ID) and auditing of check list changes through the WHO columns.

Related Objects

The following objects reference or depend on OKC_QA_CHECK_LISTS_B through the documented QCL_ID foreign-key relationship:

  • OKC_K_HEADERS_B — Contract headers. Column QCL_ID identifies the QA check list attached to a contract or template.
  • OKC_QA_LIST_PROCESSES — The individual QA process line items belonging to each check list; joined via QCL_ID.
  • OKS_K_DEFAULTS — Contract defaults setup; a QCL_ID here ties a default QA check list to an org or template configuration.
  • FND_SECURITY_GROUPS — Referenced by SECURITY_GROUP_ID for multi-org security context.

Together these relationships confirm the table's role as the hub linking QA process definitions to contract-level and default-level configuration, making it a central reference point for QA reporting within the OKC Contracts Core module.