Results for “okl_cure_report_amts_all”

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

Overview

The OKL_CURE_REPORT_AMTS_ALL table is a core transactional structure within the Oracle Lease and Finance Management (OKL) module of Oracle E-Business Suite, available in releases 12.1.1 and 12.2.2. It stores row-level amount detail associated with cure reporting activity in the lease and finance management lifecycle, serving as the line-level extension of the parent OKL_CURE_REPORTS table. In a lease portfolio, a "cure" denotes the process by which a delinquent contract is brought back into good standing through payment of past-due amounts, negotiation, or repurchase. This table captures the quantitative dimensions of that process at the individual cure amount level, enabling precise tracking of eligible, claimed, and outstanding balances per cure event.

From a Data Vault modeling perspective, the mined foreign-key structure suggests this entity behaves as a link table, resolving the many-to-many relationship between cure report headers and cure amount records. It sits between OKL_CURE_REPORTS (header-level) and OKL_CURE_AMOUNTS_ALL (amount repository), carrying descriptive measures alongside its surrogate and business identifiers.

Key Information Stored

The table contains 40 documented columns. The surrogate primary key is CURE_REPORT_AMOUNT_ID, which uniquely identifies each line. Two prominent foreign-key columns act as business-key candidates: CURE_REPORT_ID links to the parent cure report, and CURE_AMOUNT_ID links to OKL_CURE_AMOUNTS_ALL. The most functionally significant measure and descriptor columns include:

• REQUEST_TYPE – categorizes the cure request (for example, cure versus repurchase initiation).
• CURES_IN_POSSESSION – count of cure events currently held.
• CLAIMED_CURE_AMOUNT – amount claimed against the cure.
• PAST_DUE_AMOUNT – delinquent balance subject to cure.
• ELIGIBLE_CURE_AMOUNT – portion of the balance eligible for curing.
• REPURCHASE_AMOUNT – repurchase obligation tied to the line.
• OUTSTANDING_AMOUNT – residual balance remaining after cure activity.
• TIMES_CURED and PAYMENTS_REMAINING – behavioral counters describing cure history and remaining installments.
• STATUS – lifecycle state of the line record.
• ORG_ID – multi-org operating unit discriminator, critical for row-level security.
• OBJECT_VERSION_NUMBER – optimistic locking column used by the OAF/BC4J framework.
• Standard WHO columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

Reporting on cure exposure is a frequent requirement. Analysts join this table to the parent report to present cured amounts by contract, lessee, or operating unit:

• Aggregating claimed and eligible cure amounts grouped by ORG_ID for period-end provisioning reports.
• Identifying lines where OUTSTANDING_AMOUNT remains greater than zero and PAST_DUE_AMOUNT exceeds a threshold, flagging renewed delinquency risk.
• Tracking TIMES_CURED to profile lessees that repeatedly enter cure status.
• Driving correspondence or downstream interface programs via REQUEST_ID and PROGRAM_APPLICATION_ID, which indicate the concurrent program context that generated the row.

A representative query pattern retrieves line detail for a specific cure report:

SELECT a.CURE_REPORT_AMOUNT_ID, a.CLAIMED_CURE_AMOUNT, a.ELIGIBLE_CURE_AMOUNT, a.OUTSTANDING_AMOUNT FROM OKL_CURE_REPORT_AMTS_ALL a WHERE a.CURE_REPORT_ID = :p_report_id AND a.ORG_ID = :p_org_id;

Related Objects

The documented foreign-key relationships define the principal dependencies:

• OKL_CURE_REPORTS – parent header table (via CURE_REPORT_ID); supplies report-level context.
• OKL_CURE_AMOUNTS_ALL – referenced through CURE_AMOUNT_ID; holds the authoritative cure amount records.
• OKL_CURE_REPORT_AMOUNTS – referenced through CURE_REPORT_AMOUNT_ID; the reporting/canonical counterpart that shares the surrogate key namespace.
• Concurrent program infrastructure (REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID) and multi-org tables keyed by ORG_ID form indirect dependencies.

Because the table follows the _ALL naming convention, it participates in Oracle multi-org partitioning and should always be queried with an ORG_ID predicate to respect operating unit security.