Search Results okl_yes_no




Overview
Explore in AI Chat

Overview

The view APPS.OKL_INSTANCE_CHECKLIST_DTL_UV is a user-facing (UV) database object in the Oracle E-Business Suite (EBS) Enterprise Contracts (OKL) module, exposed under the APPS schema. It presents detailed checklist instance data, joining the underlying checklist detail records to Oracle Application Object Library lookups to translate descriptive codes into business-readable meanings. The view is used in reporting, Forms personalization, and integration scenarios where a checklist item's status, mandatory flag, user completion flag, and validation outcome must be presented. The _UV suffix indicates that this is a view intended for direct user or application-layer consumption, rather than an internal processing artifact.

In the context of EBS 12.1.1 and 12.2.2, the view is stable; the Online Patching (ADOP) architecture in 12.2.2 requires editioning-compatible views, and this view's definition against synonymed base tables remains valid across both releases. Because it references FND_LOOKUPS, it relies on lookup values seeded under lookup types such as OKL_YES_NO.

Underlying Base Objects

The view is defined over the following documented objects:

  • OKL_CHECKLIST_DETAILS (synonym, aliased CLD) — the driving table holding each checklist detail row (checklist ID, TODO item code, flags, notes, and validation results).
  • OKL_DATA_SRC_FNCTNS_B (synonym, aliased FUN) — the base table for data source functions, providing FUNCTION_NAME and FUNCTION_SOURCE.
  • FND_LOOKUPS (view, aliased FLK, FLK2, FLK3, FLK4, FLK6, FLK7) — joined multiple times to resolve lookup codes into MEANING and DESCRIPTION values.
  • FND_GLOBAL (package) — referenced in the documented metadata, typically for environment context (ORG_ID, user, responsibility).

The primary joins are equality joins on lookup codes and lookup types, including OKL_TODO_ITEMS, OKL_YES_NO, and OKL_FUN_VALIDATE_RSTS. Notably, the OKL_YES_NO lookup is joined twice — once for the mandatory flag and once for the user completion flag — because both columns use the same domain.

Key Columns

Common Use Cases and Queries

Typical scenarios include checklist status reporting, contract authoring validation, and integration extracts that require resolved lookup meanings rather than raw codes.

  • Extracting all checklist items for a given checklist with resolved meanings.
  • Filtering to mandatory, incomplete items to support completion gating.
  • Reporting validation results by data source function.

Sample query:

SELECT ckl_id,
       todo_item_code,
       TODO_ITEM_MEANING,
       MANDATORY_FLAG,
       MANDATORY_FLAG_MEANING,
       USER_COMPLETE_FLAG,
       USER_COMPLETE_FLAG_MEANING,
       FUNCTION_VALIDATE_RSTS,
       FUNCTION_VALIDATE_RSTS_MEANING,
       Checkist_results
FROM   APPS.OKL_INSTANCE_CHECKLIST_DTL_UV
WHERE  ckl_id = :p_checklist_id
ORDER  BY todo_item_code;

A second example, selecting mandatory items not yet complete:

SELECT ckl_id, todo_item_code, TODO_ITEM_MEANING
FROM   APPS.OKL_INSTANCE_CHECKLIST_DTL_UV
WHERE  MANDATORY_FLAG = 'Y'
AND    USER_COMPLETE_FLAG = 'N'
AND    org_id = :p_org_id;

Because the view embeds the OKL_YES_NO and OKL_FUN_VALIDATE_RSTS lookup joins directly, no additional lookup resolution is required by consumers.