Search Results okl_cs_credit_memo_request_uv




Overview
Explore in AI Chat

Overview

The view OKL_CS_CREDIT_MEMO_REQUEST_UV is a user-facing reporting object within the Oracle E-Business Suite (EBS) Leasing and Finance Management (OKL) module. As documented in the ETRM metadata for release 12.2.2 (and applicable to 12.1.1), the view presents a consolidated list of credit memo requests, exposing request header details, processing status, financial amounts, and requestor information in a single queryable structure.

The object is classified as a VIEW owned by the APPS schema with a status of VALID. Its primary purpose is to provide a denormalized, human-readable presentation of credit memo transaction requests, decoding internal status codes into meaningful lookup descriptions and resolving user IDs into user names. This makes it well suited for reporting, dashboarding, and integration scenarios where consumers require descriptive status and requestor values rather than raw code values.

The name of the view is significant: the _UV suffix typically denotes a "user view" in the ETRM/OKL framework. Such views are designed for external consumption, abstracting the underlying transactional tables and their complex joins into a stable, readable interface. This is particularly relevant to the user search term "okl_request_status," because the view explicitly decodes the OKL_REQUEST_STATUS lookup type into a status meaning column.

Underlying Base Objects

The documented base objects referenced by OKL_CS_CREDIT_MEMO_REQUEST_UV are FND_GLOBAL (PACKAGE), FND_LOOKUPS (VIEW), FND_USER (SYNONYM), OKL_TRX_AR_INVOICES_B (SYNONYM), and OKL_TRX_REQUESTS (SYNONYM).

The view is defined as a UNION of two SELECT statements, both anchored on the OKL_TRX_REQUESTS table, which stores the transactional requests. The first branch joins FND_LOOKUPS (aliased STAT) on the condition that the request status code matches a lookup code where the lookup type is OKL_REQUEST_STATUS, and joins FND_USER to resolve the creator. This branch excludes requests whose status code is 'ENTERED'.

The second branch further joins OKL_TRX_AR_INVOICES_B to reconcile the request against its associated AR invoice transaction, obtaining the transaction status code and decoding it via a second FND_LOOKUPS instance (INV_STAT) under the OKL_TRANSACTION_STATUS lookup type. This dual-branch design allows the view to present either the request-level status or the downstream invoice transaction status depending on the join path.

Key Columns

The view exposes the following documented columns:

  • REQUEST_NUMBER — The human-readable identifier of the credit memo request.
  • REQUEST_ID — The unique internal identifier of the request record.
  • TAI_ID — The transaction/AR invoice identifier linking the request to its invoice.
  • DNZ_KHR_ID — Internal identifier associated with the leasing contract hierarchy.
  • LSM_ID — Identifier referencing the lease/loan servicing record.
  • CREDIT_REQUEST_AMOUNT — The monetary value requested for credit.
  • CURRENCY_CODE — The currency in which the credit amount is denominated.
  • CREATED_BY — The user ID of the request creator.
  • REQUEST_STATUS_CODE — The raw status code (decoded from the OKL_REQUEST_STATUS lookup).
  • REQUEST_STATUS — The descriptive meaning of the status code.
  • REQUESTOR — The user name resolved from FND_USER.
  • REQUEST_DATE — The creation date of the request.
  • REQUEST_TYPE_CODE — The request type, fixed as CREDIT_MEMO within this view's filter.

Common Use Cases and Queries

Because the view already decodes status and requestor values, it is commonly used in operational reporting and monitoring of credit memo requests. A typical query retrieves all open credit memo requests with their status:

SELECT request_number, request_status, credit_request_amount, currency_code, requestor, request_date FROM okl_cs_credit_memo_request_uv WHERE request_status <> 'CLOSED' ORDER BY request_date DESC;

A second common scenario filters by requestor or by amount threshold, for example to review high-value credit requests awaiting approval. The view's reliance on the OKL_REQUEST_STATUS lookup ensures that any new statuses configured in the application immediately surface in reporting output without code changes. The union with invoice data further supports reconciliation reporting where users need visibility into both the request state and the resulting AR transaction status.