Search Results contract_currency_code




Overview
Explore in AI Chat

Overview

APPS.OKL_CURE_RFND_VND_DTLS_UV is a reporting view in the Oracle EBS Oracle Lease and Finance Management (OKL) module that consolidates vendor-level refund amounts due under cure processing. Cure, within OKL terminology, refers to the contractual mechanism by which a lessee or vendor remedies an obligation — for example, making a past-due payment or refunding an overbilled amount. This view aggregates refund amounts owed back to a vendor at the vendor-site grain and simultaneously produces an "Include All Sites" roll-up at the vendor grain, presented as a single UNION ALL result set.

The view is designed for inquiry and reporting surfaces, such as refund workbenches or ad hoc vendor analysis, where the user needs to see both the site-specific refund due and a vendor-wide total without issuing two separate queries. Because the first literal column, 'VENDOR_SITE' / 'ACROSS_SITES', acts as a row-type discriminator, consuming reports can group or filter on that column to control whether site detail or the rolled-up summary row is displayed.

The user's search term, contract_currency_code, is the principal currency dimension exposed by this view. Refund amounts are grouped by contract currency, so totals are never commingled across currencies. Any report or integration that retrieves refund amounts must read contract_currency_code alongside the aggregated amount to interpret the monetary value correctly.

Underlying Base Objects

The documented base objects referenced by this view are FND_GLOBAL (Package), OKC_UTIL (Package), OKL_BILLING_UTIL_PVT (Package), and OKL_CURE_REFUNDS_DTLS_UV (View). The first three are standard Oracle Application Object Library and OKL utility packages commonly used for security context resolution (organization and responsibility identifiers), currency and date formatting helpers, and billing-related derivation logic. They supply the session and formatting context in which the vendor refund amounts are presented.

The critical underlying object is OKL_CURE_REFUNDS_DTLS_UV, which the view text references twice — once in each branch of the UNION ALL. That detail view supplies the columns contract_currency_code, vendor_name, vendor_id, vendor_site_id, vendor_cure_due, vendor_site_cure_due, and refund_amount_due. OKL_CURE_RFND_VND_DTLS_UV therefore functions as a thin aggregation and presentation layer on top of the refund detail view, applying grouping and constructing the alternate "all sites" row. It exposes no independent business logic of its own beyond the UNION ALL structure and the SUM aggregation of refund_amount_due.

Key Columns

  • contract_currency_code — The currency of the underlying contract; the primary grouping key for all monetary aggregates.
  • vendor_name, vendor_id — Supplier identity, grouped so each vendor (and site combination) yields one row per currency.
  • vendor_site_id — Vendor site identifier. In the "VENDOR_SITE" branch this carries the real site; in the "ACROSS_SITES" branch it is set to TO_NUMBER(NULL).
  • vendor_cure_due — Cure amount due at the vendor level.
  • vendor_site_cure_due (rendered via TO_CHAR) — Cure amount due at the site level; the "ACROSS_SITES" branch substitutes a single space.
  • refund_amount_due — Aggregated with SUM(), producing the total refund owed for the row's grain.
  • Row-type literal — 'VENDOR_SITE' versus 'ACROSS_SITES' with a descriptive label ("Vendor Site" / "Include All Sites").

Common Use Cases and Queries

Typical usage includes reviewing refund exposure by vendor and currency, and comparing site-level detail against the vendor-wide roll-up. A representative query filtering the site-detail rows follows:

  • SELECT vendor_name, vendor_site_id, contract_currency_code, refund_amount_due FROM okl_cure_rfnd_vnd_dtls_uv WHERE row_type = 'VENDOR_SITE' ORDER BY vendor_name;
  • SELECT vendor_name, contract_currency_code, SUM(refund_amount_due) FROM okl_cure_rfnd_vnd_dtls_uv WHERE row_type = 'ACROSS_SITES' GROUP BY vendor_name, contract_currency_code;

Because the view already aggregates, consumers should not re-aggregate across the two row types without first filtering on the discriminator column, or refund amounts will be double counted. All amounts must be interpreted in conjunction with contract_currency_code.