Search Results okl_checklists_all_pk




Overview

OKL_CHECKLISTS_ALL is a foundational table within the Oracle Lease and Finance Management (OKL) module of Oracle E-Business Suite. It stores checklist item templates that are used across Credit Line and Funding Request processing, allowing organizations to define standardized sets of tasks, documents, or verification steps that must be completed before a credit line or funding request can be approved or processed. The table serves as the master repository for checklist definitions, capturing descriptive information, validity periods, status, and functional classification of each checklist template.

From a Data Vault modeling perspective, the heuristic classification for this object is standalone, indicating that it does not participate in a hub-link-satellite structure through foreign key dependencies in the documented schema. This suggests it functions as an independent reference or master data entity within the OKL data model, rather than as a transactional or associative table. Its primary key is defined by the constraint OKL_CHECKLISTS_ALL_PK on the ID column, with a unique index OKL_CHECKLISTS_ALL_U1 also on ID, confirming the surrogate key as the sole documented unique identifier.

Key Information Stored

The table contains 40 documented columns. The most functionally significant include:

  • ID — The surrogate primary key, uniquely identifying each checklist template record.
  • CHECKLIST_NUMBER — A business-facing identifier for the checklist, likely used in user interfaces and reports.
  • DESCRIPTION / SHORT_DESCRIPTION — Full and abbreviated textual descriptions of the checklist purpose and content.
  • CHECKLIST_TYPE — Classifies the checklist, potentially distinguishing between credit line and funding request checklists.
  • CHECKLIST_PURPOSE_CODE — Further categorizes the intended purpose of the checklist.
  • STATUS_CODE — Indicates whether the checklist template is active, inactive, or in another lifecycle state.
  • START_DATE / END_DATE — Define the effective date range during which the checklist template is valid and applicable.
  • ORG_ID — The operating unit identifier, supporting multi-org access control.
  • CHECKLIST_OBJ_ID / CHECKLIST_OBJ_TYPE_CODE — Reference the object (such as a credit line or funding request) to which the checklist applies.
  • CKL_ID — An additional identifier, possibly linking to related checklist instances or versions.
  • DECISION_DATE — Captures a date associated with checklist decision or approval activity.
  • OBJECT_VERSION_NUMBER — Supports optimistic locking for concurrent update control.
  • Standard audit columnsCREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, and the PROGRAM_* columns track record creation and modification history.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — A flexible descriptive flexfield (DFF) region allowing customers to extend the table with site-specific attributes.

Common Use Cases and Queries

Typical usage scenarios include identifying active checklist templates for a given operating unit, retrieving checklists by type or purpose, and joining checklist definitions to their associated credit line or funding request records. A common query pattern retrieves all active checklists valid as of the current date:

  • SELECT checklist_number, description, checklist_type, status_code FROM okl.okl_checklists_all WHERE status_code = 'ACTIVE' AND TRUNC(SYSDATE) BETWEEN start_date AND NVL(end_date, TRUNC(SYSDATE)+1) AND org_id = :p_org_id;
  • Reporting on checklist templates by type: SELECT checklist_type, COUNT(*) FROM okl.okl_checklists_all GROUP BY checklist_type;
  • Joining to credit line or funding request tables via CHECKLIST_OBJ_ID and CHECKLIST_OBJ_TYPE_CODE to list applicable checklists per request.

These queries support compliance reporting, credit analysis workflows, and configuration auditing.

Related Objects

Because the documented Data Vault classification is standalone, explicit foreign key relationships are not enumerated in the provided metadata. However, based on the OKL module context, the following objects are significant: