Results for “okl_cure_request_list_uv”
30 results
AI-generated from documented ETRM metadata — verify critical details on the linked pages.
Overview
The OKL_CURE_REQUEST_LIST_UV view is a reporting and inquiry object within the Oracle Lease and Finance Management (OKL) module, owned by the APPS schema. Its purpose is to expose cure request (cure report) records in a denormalized, user-friendly form. Cure requests are part of the lease contract remediation process, where a lessee or vendor must resolve a contract exception or breach within a defined cure period. The view centralizes the identifying, approval, financial, and audit attributes of each cure report alongside several decoded "meaning" columns derived from Oracle's FND_LOOKUPS reference data.
The view's name is that of a User View (the "UV" suffix). Its most direct role is in EBS reporting: it eliminates the need for report developers and form/inquiry builders to manually join the base OKL_CURE_REPORTS table to the FND and vendor master objects. Because the view carries both the coded value (for example, APPROVAL_STATUS) and its translated meaning (APPROVAL_STATUS_MEANING), it is particularly valuable in ad-hoc SQL, Oracle Discoverer worksheets, and BI Publisher data templates where a business user requires readable output. The view also supports multi-org access because it carries the ORG_ID column.
Underlying Base Objects
Per the documented 12.2.2 metadata, the view is defined over the following objects:
- OKL_CURE_REPORTS (SYNONYM) — the driving base table, aliased CRT. All cure request header records originate here.
- FND_LOOKUPS (VIEW) — joined twice. The alias
FNDdecodesCRT.APPROVAL_STATUS, and the aliasREQdecodesCRT.REPORT_TYPE. Both joins useLOOKUP_CODEequality and restrictLOOKUP_TYPEwith literal values. - PO_VENDORS (VIEW) — aliased VEN, providing the supplier name for the joining
VENDOR_ID. - FND_GLOBAL (PACKAGE) — referenced in the view definition (typically for Multi-Org context via
FND_GLOBAL.ORG_ID), which enforces the operating unit security policy.
Because OKL_CURE_REPORTS and PO_VENDORS are accessed as synonyms and views rather than raw tables, the object resolves through the APPS granting layer and inherits Supplier (PO) security behavior for the vendor columns.
Key Columns
CURE_REPORT_ID— surrogate primary key for the cure report.REPORT_NUMBER— user-facing document number.REPORT_TYPEandREPORT_TYPE_MEANING— coded value and decoded description from lookup typeOKL_CURE_REQUEST_TYPE.REPORT_DATE— date the cure report was raised; the view is ordered by this column descending.APPROVAL_STATUSand the keyAPPROVAL_STATUS_MEANING— coded approval state and its FND_LOOKUPS decode from lookup typeOKL_CURE_REQUEST_APPROVE_STATU.APPROVAL_REASON— free-text rationale captured at approval or rejection.EXPIRATION_DATE— date by which the cure must be completed.VENDOR_ID,VENDOR_SITE_ID,VENDOR_CONTACT_ID, andVENDOR_NAME— supplier identity and contact attributes.CURRENCY_CODE,ORG_ID— financial and operating-unit context.REQUEST_ID,PROGRAM_APPLICATION_ID,PROGRAM_ID,PROGRAM_UPDATE_DATE— concurrent program audit trail.OBJECT_VERSION_NUMBER— optimistic locking / concurrency column.CREATED_BY,CREATION_DATE,LAST_UPDATED_BY,LAST_UPDATE_DATE,LAST_UPDATE_LOGIN— standard WHO audit columns.ATTRIBUTE_CATEGORYandATTRIBUTE1–ATTRIBUTE15— the DFF (descriptive flexfield) segment columns.
Common Use Cases and Queries
The view is typically queried to build approval worklists, cure-aging reports, and vendor exception dashboards. The most common filter is APPROVAL_STATUS_MEANING, and this is the specific attribute users search on when looking for the literal value approval_status_meaning. A representative query is:
SELECT cure_report_id, report_number, vendor_name, approval_status_meaning, expiration_date FROM okl_cure_request_list_uv WHERE approval_status_meaning = 'Pending Approval' ORDER BY report_date DESC;SELECT org_id, report_type_meaning, TO_CHAR(report_date,'YYYY-MM'), COUNT(*) FROM okl_cure_request_list_uv GROUP BY org_id, report_type_meaning, TO_CHAR(report_date,'YYYY-MM');— a volume analysis by operating unit, cure type, and reporting period.SELECT * FROM okl_cure_request_list_uv WHERE expiration_date < SYSDATE AND approval_status_meaning IS NOT NULL AND approval_status_meaning <> 'Approved';— identifies overdue cure requests still awaiting resolution.
Because reporting should never rely on hard-coded lookup IDs, the decoded meaning columns exist precisely so that queries, Discoverer workbooks, and BI Publisher templates remain readable and portable across 12.1.1 and 12.2.2 environments. Where DFF values are involved, consumers should join to the flexfield definition views if attribute semantics are required.
-
View for cure requests
APPS.OKL_CURE_REQUEST_LIST_UV·↳ FND_LOOKUPS·↳ OKL_CURE_REPORTS·↳ PO_VENDORS·Explore OKL module →
-
View for cure requests
APPS.OKL_CURE_REQUEST_LIST_UV·↳ FND_LOOKUPS·↳ OKL_CURE_REPORTS·↳ PO_VENDORS·Explore OKL module →
-
12.2.2 FND Design Data 12.2.2
-
12.2.2 DBA Data 12.2.2
-
12.1.1 DBA Data 12.1.1
-
12.1.1 FND Design Data 12.1.1
-
VIEW: APPS.PO_VENDORS 12.2.2
-
VIEW: APPS.PO_VENDORS 12.1.1
-
VIEW: APPS.FND_LOOKUPS 12.2.2
-
VIEW: APPS.FND_LOOKUPS 12.1.1
-
Set Distribution Table.
-
12.2.2 DBA Data 12.2.2
-
12.1.1 DBA Data 12.1.1
-
Set Distribution Table.
-
PACKAGE: APPS.FND_GLOBAL 12.2.2
-
PACKAGE: APPS.FND_GLOBAL 12.1.1
-
eTRM - OKL Tables and Views 12.2.2
Translatable columns from OKL_XTL_SELL_INVS_B, per MLS standards
-
eTRM - FND Tables and Views 12.2.2
No longer used
-
eTRM - OKL Tables and Views 12.1.1
Translatable columns from OKL_XTL_SELL_INVS_B, per MLS standards
-
eTRM - FND Tables and Views 12.1.1
No longer used
-
Set Distribution Table.
-
Set Distribution Table.
-
eTRM - FND Tables and Views 12.2.2
No longer used
-
eTRM - FND Tables and Views 12.1.1
No longer used
-
eTRM - OKL Tables and Views 12.2.2
Translatable columns from OKL_XTL_SELL_INVS_B, per MLS standards
-
eTRM - OKL Tables and Views 12.1.1
Translatable columns from OKL_XTL_SELL_INVS_B, per MLS standards