Search Results laclfm_id

Overview

OKL_CRD_FUND_CHECKLISTS_TPL_UV is a user interface view owned by the APPS schema within the OKL (Leasing and Finance Management) product module. It serves as the presentation-layer data source for the credit and funding checklist instance page, exposing one row per checklist template line associated with a leasing contract. The view is documented in the ETRM reference for release 12.2.2 and remains valid in the 12.1.1 / 12.2.2 application footprints. Because it is a view rather than a table, it does not store data; instead it projects and decorates rule rows held in the OKC rules infrastructure so that the OKL self-service and forms-based checklist pages can render human-readable meaning text alongside coded values.

The view is significant for integration and reporting because it resolves raw lookup codes, status codes, profile options, and date stamps into a denormalized, business-friendly shape. Analysts querying the credit and funding checklist can obtain the todo item description, its mandatory indicator, its effective dating window, its approval requirement, and, where applicable, the associated function name and source without joining multiple lookup and rule tables manually.

Underlying Base Objects

The view is defined over the following documented base objects:

• OKC_RULES_B (referenced twice, aliased RULT for the checklist line and RULH for the header/instance rules), which holds the rule information stored under the LACLFD rule information category. The join condition RULT.OBJECT1_ID1 = RULH.ID with RULT.OBJECT1_ID2 = '#' links each checklist line to its parent rule structure.
• FND_LOOKUPS (aliased LK1, LK2, and LK3), used to translate coded values into meanings for the OKL_TODO_ITEMS, YES_NO, and OKL_CHECKLIST_TYPE lookup types respectively.
• OKC_STATUSES_V (aliased STATUS), which maps the stored status code to a status meaning.
• OKL_DATA_SRC_FNCTNS_V (aliased FUN), an outer-joined source for function identifiers and names.
• FND_DATE, FND_GLOBAL, and FND_PROFILE packages, invoked within the SELECT list for date canonicalization and profile option retrieval.

The relationships are enforced through outer and inner joins that filter specifically to the LACLFD rule category, ensuring only credit and funding checklist template lines are returned.

Key Columns

• ID, RGP_ID, KHR_ID, LACLFM_ID — identifiers linking the checklist line to its parent record, contract, and rule group.
• TODO_ITEM_CODE / TODO_ITEM_MEANING — the coded checklist action and its decoded description.
• MANDATORY_FLAG / MANDATORY_FLAG_MEANING — a Yes/No indicator (defaulting to 'N') showing whether completion is required.
• STATUS / STATUS_MEANING — the instance status, defaulting to 'NEW', resolved through OKC_STATUSES_V.
• EFFECTIVE_FROM / EFFECTIVE_TO — canonical dates derived via FND_DATE.CANONICAL_TO_DATE.
• APPROVERYN — populated from the OKL_CREDIT_LINE_APPROVER profile option; defaults to 'N'.
• FUNCTION_ID, FUNCTION_NAME, FUNCTION_SOURCE — the related data source function identifier, name, and source, sourced from OKL_DATA_SRC_FNCTNS_V. The FUNCTION_SOURCE column is particularly relevant to users searching for function source information.
• CHECKLIST_TYPE / CHECKLIST_TYPE_MEANING — distinguishes funding versus credit checklists, defaulting to 'FUNDING'.
• NOTE and ADMIN_NOTE — free-text remarks attached to the checklist line.

Common Use Cases and Queries

Typical reporting scenarios include auditing outstanding mandatory checklist items, extracting the effective-dated checklist configuration for a contract, and identifying the function source behind automated checklist population. A representative query is:

SELECT id, khr_id, todo_item_code, todo_item_meaning, mandatory_flag, status_meaning, effective_from, effective_to, checklist_type_meaning, function_name, function_source FROM okl_crd_fund_checklists_tpl_uv WHERE khr_id = :p_contract_id ORDER BY effective_from;

For function-focused analysis, filtering on FUNCTION_SOURCE isolates checklist lines populated by a given data source function. Because the view applies NVL defaults and outer joins, it is safe to query even where optional attributes such as function assignments or effective dates are absent.