Results for “okl_bpd_receipt_summary_uv”

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

Overview

The APPS.OKL_BPD_RECEIPT_SUMMARY_UV view is a reporting and integration object within the Oracle Lease and Finance Management (OKL) module of Oracle E-Business Suite, valid in both release 12.1.1 and 12.2.2. It presents a consolidated, denormalized picture of cash receipts recorded against lease contracts, joining receipt header information with customer, receipt method, and remittance bank detail. The view is designed primarily to support downstream reporting, ad-hoc queries, and interface extraction where a single row per receipt is preferable to navigating the normalized transaction tables. Because it exposes business-friendly attributes such as customer name, customer number, receipt amount, and the remittance bank name, it serves as a convenient source for operational reporting on lease-related collections.

The "_UV" suffix conventionally denotes a "user view" — an Oracle Applications construct intended for customer-facing access rather than internal processing. As a result, the column set is curated toward recognizable business terms rather than surrogate keys alone, though internal identifiers are also retained for join-back purposes.

Underlying Base Objects

The view is defined over eight documented base objects accessible through APPS synonyms. The primary driving table is OKL_TRX_CSH_RECEIPT_B (aliased RCT), which holds the internal cash receipt records. The receipt is linked to its extended receipt detail in OKL_EXT_CSH_RCPTS_ALL_B (EXT) via RCT_ID = RCT.ID, and to the receipt-to-application mapping in OKL_TXL_RCPT_APPS_ALL_B (RCA) via RCT_ID_DETAILS. Customer context is resolved through HZ_CUST_ACCOUNTS (CA) and HZ_PARTIES (PY), joined on the customer account and party identifiers respectively. The consolidated invoice relationship is carried by OKL_CNSLD_AR_HDRS_ALL_B (CNR), and the associated lease contract is carried by OKC_K_HEADERS_ALL_B (KHR); both are outer-joined through RCA, meaning receipts without a consolidated invoice or contract still appear. Finally, AR_RECEIPT_METHODS (RM) supplies the receipt method name via IRM_ID.

Key Columns

• CUSTOMER_BANK_NAME — sourced from EXT.REMITTANCE_BANK_NAME; the remittance bank named on the extended receipt, directly answering the "customer_bank_name" search term.
• CUSTOMER_ID / CUSTOMER_NAME / CUSTOMER_NUMBER — the lessee's ILE_ID, the party name (truncated to 50 bytes via SUBSTRB), and the customer account number.
• RECEIPT_NUMBER — the check number from the extended receipt record.
• RECEIPT_DATE / RECEIPT_AMOUNT / CURRENCY_CODE — effective date, formatted amount, and currency of the receipt.
• RECEIPT_METHOD — the name of the AR receipt method used.
• ACCOUNT — the remittance account from the extended receipt.
• CONSOLIDATED_INVOICE_NUMBER / DATE_CONSOLIDATED / CONSOLIDATED_INVOICE_AMOUNT — consolidated AR header detail.
• CONTRACT_NUMBER — the lease contract number associated with the applied receipt.
• INT_RECEIPT_ID, EXT_RECEIPT_ID, CNSLD_AR_HDRS_ID, OKC_K_HEADERS_ID, ORG_ID, RECEIPT_TYPE — internal identifiers and multi-org context columns for join-back and filtering.

Common Use Cases and Queries

Typical uses include cash application reporting, remittance analysis, reconciliation of lease receipts to consolidated invoices, and extraction feeds into data warehouses. Reports frequently filter on ORG_ID to respect multi-org security and on RECEIPT_DATE ranges.

A representative query to retrieve receipt detail including the customer bank name:

• SELECT customer_name, customer_number, receipt_number, receipt_date, receipt_amount, customer_bank_name, receipt_method FROM okl_bpd_receipt_summary_uv WHERE org_id = :p_org_id AND receipt_date BETWEEN :p_from AND :p_to;
• SELECT contract_number, customer_bank_name, SUM(receipt_amount) FROM okl_bpd_receipt_summary_uv GROUP BY contract_number, customer_bank_name;

Because the view uses DISTINCT and outer joins, aggregation should account for potential duplicate suppression, and date-range predicates are recommended to constrain result sets on large receipt volumes.