Results for “okl_cure_reports”

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

Overview

The OKL_CURE_REPORTS table is a component of the Oracle Lease and Finance Management (OKL) module in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the request header details for a cure repurchase request — a transaction in which a lessor exercises a contractual remedy to repurchase a leased asset from a third party (typically the vendor) when an underlying lease or financing obligation has reached a default or cure condition. As a header table, OKL_CURE_REPORTS captures the transactional context of the cure request, while providing the foreign-key linkage to the vendor, vendor site, and vendor contact records used to route and process the request.

From a Data Vault modeling perspective, the mined foreign-key structure classifies this object as satellite-leaning. This is a heuristic suggestion rather than an Oracle-declared classification: the table carries descriptive attributes attached to a transactional parent (a cure repurchase request), which is characteristic of a satellite. Modelers designing an integration or warehouse layer should treat it as a descriptive detail set hanging off the cure request business key, not as an independent hub or an associative link.

Key Information Stored

The table is anchored by the surrogate primary key constraint OKL_CURE_REPORT_PK, which governs the CURE_REPORT_ID column. This identifier is the internal, system-generated unique key for each cure repurchase request header and is the column carried forward into dependent child tables.

• CURE_REPORT_ID — the surrogate primary key and the join key to the child amount lines.
• VENDOR_ID — foreign key to PO_VENDORS; identifies the vendor against which the cure repurchase is directed.
• VENDOR_SITE_ID — foreign key to PO_VENDOR_SITES_ALL; the specific vendor site used for the transaction.
• VENDOR_CONTACT_ID — foreign key to PO_VENDOR_CONTACTS; the contact person at the vendor for the cure request.

The remaining columns are the descriptive request-header attributes (amounts are held on the child table rather than here). Where documented, the surrogate CURE_REPORT_ID should be distinguished from any business-key candidate; the ETRM metadata does not declare an alternate unique index, so the surrogate key remains the authoritative identifier within the module.

Common Use Cases and Queries

Typical reporting and reconciliation scenarios center on tracing cure repurchase requests by vendor and by vendor site, and on reconciling header data with the amount lines in OKL_CURE_REPORT_AMOUNTS.

Example — retrieve cure request headers for a given vendor with resolved vendor master data:

• Join OKL_CURE_REPORTS to PO_VENDORS on VENDOR_ID to obtain vendor name and numbering.
• Join to PO_VENDOR_SITES_ALL on VENDOR_SITE_ID to resolve the operating site location.
• Join to PO_VENDOR_CONTACTS on VENDOR_CONTACT_ID to resolve the contact for notification.

Example — aggregate repurchase amounts per cure request by joining the header to the line table:

SELECT r.cure_report_id, SUM(a.amount)
FROM   okl_cure_reports r,
       okl_cure_report_amounts a
WHERE  r.cure_report_id = a.cure_report_id
GROUP BY r.cure_report_id;

These patterns support audit trails, vendor liability reporting, and default/cure analytics within Lease and Finance Management.

Related Objects

• OKL_CURE_REPORT_AMOUNTS — child table; joins on CURE_REPORT_ID and holds the monetary lines of the cure repurchase request.
• PO_VENDORS — parent vendor master; joins on VENDOR_ID.
• PO_VENDOR_SITES_ALL — vendor site master; joins on VENDOR_SITE_ID.
• PO_VENDOR_CONTACTS — vendor contact master; joins on VENDOR_CONTACT_ID.

Note that the ETRM documentation states the object is not implemented in the reference database; validation of these relationships should therefore be performed against the target instance before use in production queries.