Results for “okl_cure_reports_all”
50+ results
AI-generated from documented ETRM metadata — verify critical details on the linked pages.
Overview
OKL_CURE_REPORTS_ALL is a transactional table in the Oracle E-Business Suite Leasing and Finance Management (OKL) module. It stores request header details for cure repurchase requests — the process by which a lessor or financing entity exercises its contractual right to require a vendor to repurchase a defaulted or cured lease contract. In Oracle EBS 12.1.1 and 12.2.2 the table resides in the OKL schema and is registered as VALID in the ETRM repository.
From a dimensional modeling perspective, the mined foreign-key structure suggests a link classification for this object: it resolves many-to-many style associations between a cure report header and the trading-partner entities (vendors, supplier sites, and supplier contacts) held in Oracle Payables. It is not a hub (no single, shared business key independent of context) and not a pure satellite (it carries its own surrogate primary key and multiple outbound references). Treat this as a heuristic suggestion only; the reference implementation may classify the object differently.
Key Information Stored
The table is documented with 38 columns in the 12.2.2 physical schema. The most strategically significant attributes are:
- CURE_REPORT_ID — Surrogate primary key, enforced by OKL_CURE_REPORTS_ALL_PK. This is the only documented unique identifier; no separate business-key unique index is recorded in the ETRM metadata.
- REPORT_NUMBER — Human-readable document number for the cure report; the principal business-key candidate for external reference.
- REPORT_DATE — Date the cure report header was raised.
- REPORT_TYPE — Classifies the nature of the cure/repurchase request.
- VENDOR_ID — Foreign key to AP_SUPPLIERS, identifying the vendor obligated to repurchase.
- VENDOR_SITE_ID — Foreign key to AP_SUPPLIER_SITES_ALL, identifying the specific supplier site.
- VENDOR_CONTACT_ID — Foreign key to AP_SUPPLIER_CONTACTS, identifying the responsible contact.
- APPROVAL_STATUS and APPROVAL_REASON — Workflow outcome and justification for the cure request.
- EXPIRATION_DATE — Deadline by which the cure action must be completed.
- CURRENCY_CODE — Currency of the underlying request.
- ORG_ID — Multi-org operating unit discriminator.
- REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — Concurrent program and request audit trail.
- OBJECT_VERSION_NUMBER — Optimistic locking column used by the OA Framework.
- CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard WHO audit columns, complemented by the ATTRIBUTE1–ATTRIBUTE15 and ATTRIBUTE_CATEGORY DFF flexfields.
Common Use Cases and Queries
Typical usage centers on tracking open cure requests, aging analysis, and vendor performance. A representative query joining the header to the vendor master follows:
SELECT r.report_number, r.report_date, r.approval_status, r.expiration_date, s.vendor_name FROM okl.okl_cure_reports_all r JOIN ap.ap_suppliers s ON s.vendor_id = r.vendor_id WHERE r.org_id = :p_org_id AND r.approval_status = 'PENDING';- Approval funnel reporting using
APPROVAL_STATUSandAPPROVAL_REASONgrouped byREPORT_TYPE. - Expiration aging: filter on
EXPIRATION_DATE < SYSDATEto surface overdue cure obligations. - Concurrent-program reconciliation via
REQUEST_IDandPROGRAM_IDagainst FND_CONCURRENT_REQUESTS.
Related Objects
- AP_SUPPLIERS — joined on
OKL_CURE_REPORTS_ALL.VENDOR_ID = AP_SUPPLIERS.VENDOR_ID. - AP_SUPPLIER_SITES_ALL — joined on
VENDOR_SITE_ID. - AP_SUPPLIER_CONTACTS — joined on
VENDOR_CONTACT_ID. - OKL_CURE_REPORTS_ALL child lines and workflow/approval tables that consume
CURE_REPORT_ID. - OKL contract and repurchase-line tables that drive the underlying obligation.
-
Stores request header details for cure repurcahse request
-
Stores request header details for cure repurcahse request
-
APPS.OKL_OUTSTANDING_CURE_UV·↳ OKC_UTIL·↳ OKL_CURE_AMOUNTS·↳ OKL_CURE_REPORTS_ALL·Explore OKL module →
-
APPS.OKL_OUTSTANDING_CURE_UV·↳ OKC_UTIL·↳ OKL_CURE_AMOUNTS·↳ OKL_CURE_REPORTS_ALL·Explore OKL module →
-
View: OKL_CURE_REQUEST_UV 12.1.1
View for Cure requests
APPS.OKL_CURE_REQUEST_UV·↳ HZ_PARTIES·↳ OKC_K_HEADERS_ALL_B·↳ OKC_K_PARTY_ROLES_B·Explore OKL module →
-
View: OKL_CURE_REQUEST_UV 12.2.2
View for Cure requests
APPS.OKL_CURE_REQUEST_UV·↳ HZ_PARTIES·↳ OKC_K_HEADERS_ALL_B·↳ OKC_K_PARTY_ROLES_B·Explore OKL module →
-
APPS.OKL_RECONCILE_DISPLAY_UV·↳ FND_GLOBAL·↳ OKC_K_HEADERS_V·↳ OKC_K_PARTY_ROLES_V·Explore OKL module →
-
APPS.OKL_RECONCILE_DISPLAY_UV·↳ FND_GLOBAL·↳ OKC_K_HEADERS_V·↳ OKC_K_PARTY_ROLES_V·Explore OKL module →
-
View: OKL_CURE_INVOICE_UV 12.1.1
View for cure requests
APPS.OKL_CURE_INVOICE_UV·↳ FND_GLOBAL·↳ FND_LOOKUPS·↳ OKC_K_HEADERS_B·Explore OKL module →
-
View: OKL_CURE_INVOICE_UV 12.2.2
View for cure requests
APPS.OKL_CURE_INVOICE_UV·↳ FND_GLOBAL·↳ FND_LOOKUPS·↳ OKC_K_HEADERS_B·Explore OKL module →
-
Stores cure and repurchase amounts generated per contract per period
-
Stores cure and repurchase amounts generated per contract per period
-
12.2.2 DBA Data 12.2.2
-
12.2.2 DBA Data 12.2.2
-
12.1.1 DBA Data 12.1.1
-
12.1.1 DBA Data 12.1.1
-
12.2.2 DBA Data 12.2.2
-
12.2.2 DBA Data 12.2.2
-
12.2.2 FND Design Data 12.2.2
-
12.1.1 FND Design Data 12.1.1