Search Results okl_cure_refund_lines_v

Overview

OKL_CURE_REFUND_LINES_V is a reporting and integration view in the Oracle E-Business Suite Leasing and Finance Management module (OKL). It exposes line-level detail for refunds issued against a contract. In Oracle Leasing terminology, "CURE" refers to contract/lease management refund processing, and this view presents each refund line together with its amount, transaction reference, workflow status, and approval outcome. The view is a thin projection over the base table OKL_CURE_REFUND_LINES, joining no additional objects and applying no filtering logic, row-level security predicates, or joins. Its purpose is to provide a stable, read-only, denormalized access point for reporting tools, concurrent programs, and external integrations that need to interrogate individual refund lines without directly querying the transactional base table.

Underlying Base Objects

The view text is defined exclusively over a single base object: OKL_CURE_REFUND_LINES, aliased as CRL. Every column in the SELECT list maps one-to-one to a column on that table. Although the ETRM metadata lists "Referenced base objects: none documented" and the implementation note states "Not implemented in this database," the view definition embedded in the documentation confirms the sole dependency is OKL_CURE_REFUND_LINES. Because no joins or subqueries are present, the view inherits the base table's partitioning, indexing, and ORG_ID multitenancy characteristics directly. There is no documented synonym, no materialized form, and no editioning or secure-view wrapping above the base table.

Key Columns

• CURE_REFUND_LINE_ID — Primary identifier for an individual refund line; the unique key used to reference a specific line.
• CURE_REFUND_ID — Foreign key to the parent refund header, linking lines to the refund event as a whole.
• ORG_ID — Operating unit identifier, enforcing multi-org data separation for the line.
• AMOUNT — Monetary value of the refund line, expressed in the contract or functional currency as maintained upstream.
• TRANSACTION_ID — Reference to the associated transaction that generated or is settled by the refund line.
• STATUS — Processing status of the refund line.
• APPROVAL_STATUS — Outcome of the approval workflow for the line (for example, pending, approved, or rejected).
• APPROVAL_REASON — Free-text or lookup-backed justification recorded when the line was approved or rejected; this is the column most commonly targeted by users searching for approval rationale.
• OBJECT_VERSION_NUMBER — Optimistic locking column used by the underlying OAF/ADF entity objects.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — Standard concurrent program audit columns identifying which request last wrote the row.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — Descriptive flexfield (DFF) context and segment columns permitting customer-specific extensions.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard "WHO" audit columns.
• ROW_ID — The database ROWID of the base row, useful for high-performance direct-row access.

Common Use Cases and Queries

The primary use cases are refund approval auditing, reconciliation of refund lines to transactions, and integration feeds into payment or general ledger systems. A typical query retrieves all lines for a parent refund, including the approval rationale:

SELECT cure_refund_line_id,
       cure_refund_id,
       amount,
       status,
       approval_status,
       approval_reason
FROM   okl_cure_refund_lines_v
WHERE  cure_refund_id = :p_refund_id
AND    org_id = :p_org_id;

To isolate lines rejected or approved with a specific reason — the classic "approval_reason" search — the following pattern applies:

SELECT cure_refund_id,
       cure_refund_line_id,
       amount,
       approval_status,
       approval_reason
FROM   okl_cure_refund_lines_v
WHERE  approval_reason IS NOT NULL
AND    approval_status = 'REJECTED'
AND    org_id = :p_org_id
ORDER BY last_update_date DESC;

Because the view adds no logic of its own, all predicates, including ORG_ID enforcement, must be supplied by the caller; integrations should always bind ORG_ID to respect multi-org security. For high-volume extracts, querying the base table OKL_CURE_REFUND_LINES directly may yield identical plans, but the view remains the recommended, documented interface for downstream consumers seeking refund line detail and approval justification.