Search Results catchup_frequency_code

Overview

APPS.OKL_K_RATE_PARAMS_V is a reporting view in the Oracle E-Business Suite (EBS) Lease and Finance Management (formerly Oracle Lease Management, OKL) module. It exposes the contents of the rate parameter configuration for lease contracts and related financial instruments, presenting a flattened, query-friendly projection of the underlying rate parameter records. The view is owned by the APPS schema and is intended to be consumed by reports, concurrent programs, integrations, and custom extensions that need to read interest rate and rate-adjustment definitions without navigating the full transactional base table.

The view is particularly relevant to users searching on "catchup_frequency_code," a column that governs the frequency at which catch-up interest adjustments are applied. By surfacing this attribute alongside the broader set of rate-definition columns, the view allows rate configurations to be audited and reported in a single pass.

Underlying Base Objects

According to the documented ETRM metadata, OKL_K_RATE_PARAMS_V is defined over a single referenced base object: the synonym OKL_K_RATE_PARAMS (aliased as KRP in the view text). The view is a straightforward SELECT against that object, projecting all significant columns rather than joining multiple tables. Because it references a synonym, the physical segment resolves to the OKL_K_RATE_PARAMS table in the applications schema, and the view inherits the table's constraints, indexes, and history tracking (Created By, Creation Date, Last Updated By, Last Update Date, Last Update Login). No aggregations, filters, or derived expressions are present in the documented view text, so the view is effectively a denormalized read layer over the base table.

Key Columns

The view exposes a wide set of columns describing how interest is calculated and adjusted for a given rate parameter set. Important columns include:

• KHR_ID — Primary identifier linking the rate parameter record to its parent header/rate definition.
• PARAMETER_TYPE_CODE — Classifies the type of rate parameter being defined.
• EFFECTIVE_FROM_DATE / EFFECTIVE_TO_DATE — Validity window for the parameter set.
• INTEREST_INDEX_ID, BASE_RATE, ADDER_RATE, MAXIMUM_RATE, MINIMUM_RATE — Core interest rate components.
• PRINCIPAL_BASIS_CODE, DAYS_IN_A_MONTH_CODE, DAYS_IN_A_YEAR_CODE, INTEREST_BASIS_CODE — Day-count and accrual conventions.
• RATE_DELAY_CODE, RATE_DELAY_FREQUENCY — Delay rules before rate application.
• COMPOUNDING_FREQUENCY_CODE, CALCULATION_FORMULA_ID — Compounding and formula linkage.
• CATCHUP_BASIS_CODE, CATCHUP_START_DATE, CATCHUP_SETTLEMENT_CODE, CATCHUP_FREQUENCY_CODE — The catch-up interest regime, including the frequency that determines how often catch-up amounts are recalculated or settled.
• RATE_CHANGE_START_DATE, RATE_CHANGE_FREQUENCY_CODE, RATE_CHANGE_VALUE — Scheduled rate-change parameters.
• CONVERSION_OPTION_CODE, NEXT_CONVERSION_DATE, CONVERSION_TYPE_CODE — Rate conversion details.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–15 — Descriptive flexfield columns for extensibility.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

This view is typically queried in lease rate configuration reports, catch-up interest analysis, and data migration or integration scripts. A common pattern is to filter by a specific catch-up frequency to identify contracts using a given settlement cadence. For example:

SELECT khr_id, parameter_type_code, catchup_basis_code, catchup_frequency_code, catchup_start_date, effective_from_date, effective_to_date FROM apps.okl_k_rate_params_v WHERE catchup_frequency_code = 'MONTHLY';

Analysts may also join KHR_ID back to lease header tables to correlate rate parameters with specific contracts, or combine the view with interest index lookups via INTEREST_INDEX_ID. Because the view performs no filtering, developers should always apply effective-date predicates to restrict results to currently valid parameter sets. The exposed ATTRIBUTE1–15 columns support customer-specific reporting extensions defined through descriptive flexfields.