Search Results date_reported




Overview

OKL_ASSET_CNDTN_LNS_V is a PL/SQL view owned by the APPS schema within the OKL – Leasing and Finance Management product family of Oracle E-Business Suite, valid in releases 12.1.1 and 12.2.2. It presents the individual line records of an asset condition report, capturing the item description, the damage identified, and the associated repair and claim decisions. In the leasing lifecycle, asset condition reporting supports end-of-lease inspections, mid-term asset assessments, early termination settlements, and residual value adjustments. Each row represents one condition line attached to a parent condition report header.

The view is a reporting and integration layer rather than a transactional entity. Because it joins the base table to its translation table, consumers receive damage descriptions and claim narratives already resolved for the session language, without needing to join the _TL table themselves. The view therefore appears in condition report inquiries, lessee and lessor correspondence, billing adjustments for damage recovery, and custom extracts that feed downstream asset management or financial systems. The DATE_REPORTED column, which the user searched for, is exposed directly from the base table and records the date on which the damage or condition was reported.

Underlying Base Objects

The view is defined over two documented base objects:

  • OKL_ASSET_CNDTN_LNS_B – the base table holding the condition line records, including dates, amounts, approval status, descriptive flexfield attributes, currency conversion details, and standard WHO and concurrent program columns.
  • OKL_ASSET_CNDTN_LNS_TL – the translation table supplying language-specific text such as damage description, claim description, recommended repair, and part name.

The SELECT aliases the base table as ACNB and the translation table as ACNT. Both are referenced through APPS synonyms, and the view carries the standard ORG_ID column, indicating multi-org (operating unit) security applies to the underlying data. Translations are typically resolved using the user environment language, so the view returns only the relevant language row per condition line.

Key Columns

Common Use Cases and Queries

Typical scenarios include producing a condition report detail listing for a lease, extracting damage lines reported within a date range for turnaround analysis, and reporting estimated versus actual repair costs by operating unit.

Listing condition lines for an operating unit:

SELECT id, sequence_number, date_reported, damage_description,
       estimated_repair_cost, actual_repair_cost, currency_code
FROM   apps.okl_asset_cndtn_lns_v
WHERE  org_id = :p_org_id
ORDER  BY date_reported, sequence_number;

Filtering on the searched column to measure reporting lag:

SELECT id, date_reported, date_approved, approved_yn,
       (date_approved - date_reported) days_to_approve
FROM   apps.okl_asset_cndtn_lns_v
WHERE  date_reported BETWEEN :p_from_date AND :p_to_date;

Aggregating recovery exposure by currency:

SELECT currency_code,
       SUM(NVL(estimated_repair_cost,0)) est_total,
       SUM(NVL(actual_repair_cost,0))    act_total
FROM   apps.okl_asset_cndtn_lns_v
WHERE  org_id = :p_org_id
GROUP  BY currency_code;

Because the view contains no pagination or buffering logic, large extracts should always be constrained by ORG_ID, DATE_REPORTED, or a join to the parent condition report to avoid full scans of the base table.