Search Results ap_supplier_contacts

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_STATUS and APPROVAL_REASON grouped by REPORT_TYPE.
• Expiration aging: filter on EXPIRATION_DATE < SYSDATE to surface overdue cure obligations.
• Concurrent-program reconciliation via REQUEST_ID and PROGRAM_ID against 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.