Search Results customer_receipt_reference

Overview

ICX_AR_CASH_RECEIPTS_V is a reporting and inquiry view within the Oracle iProcurement (ICX) module of Oracle E-Business Suite, documented for releases 12.1.1 and 12.2.2. The ETRM metadata classifies it as "Cash Receipts View," indicating that its purpose is to expose cash receipt information originating in Oracle Receivables (AR) to iProcurement-facing functions, dashboards, and self-service pages. The view presents one logical row per cash receipt together with the customer identity, receipt amount, payment type, bank information, and the applied, unapplied, and on-account breakdowns that receivers and internal users typically need when reconciling inbound customer payments.

The view is not a transactional object. Its ROWID-based ROW_ID column and its use of FND_CURRENCY.SAFE_GET_FORMAT_MASK confirm that it is a read-only projection intended for display formatting rather than data maintenance. The ETRM record notes "Not implemented in this database" for the implementation/DBA data, meaning the object exists in the delivered application definition but was not instantiated in the specific environment documented.

Underlying Base Objects

The documented metadata lists no separately enumerated referenced base objects, but the view text reveals its source tables through column aliasing. The principal object is the AR cash receipts table, referenced as CR (AR_CASH_RECEIPTS), which supplies the receipt identifier, receipt number, amount, currency, status, comments, exchange rate attributes, receipt method, deposit date, and the descriptive flexfield ATTRIBUTE columns. Customer identity is drawn from the AR customer table (CUST), yielding CUSTOMER_NAME and CUSTOMER_NUMBER. Bank data is assembled from customer bank branch and customer bank account records (CUST_BANK_BRANCH, CUST_BANK), returning BANK_NAME and CUSTOMER_BANK_ACCOUNT.

Application activity is obtained from the receipt application and payment schedule tables: RA supplies applied amounts decoded by application status, and PS (payment schedules) supplies AMOUNT_APPLIED, DUE_DATE, and MATURITY_DATE. The AL_PAY_TYPE lookup supplies the translated payment type MEANING. Currency formatting is delegated to the FND_CURRENCY.SAFE_GET_FORMAT_MASK function, so the view inherits the currency precision and format conventions of the FND layer.

Key Columns

• CASH_RECEIPT_ID and RECEIPT_NUMBER — primary identifier and user-facing receipt number for the cash receipt.
• ROW_ID — the underlying AR_CASH_RECEIPTS ROWID, usable for drill-down navigation.
• CUSTOMER_NAME, CUSTOMER_NUMBER, CUSTOMER_ID, CUSTOMER_SITE_USE_ID — customer identification attributes.
• AMOUNT, APPLIED_AMOUNT, UNAPPLIED_AMOUNT, ON_ACCOUNT_AMOUNT — receipt value and its distribution across applied, unapplied, and on-account states, each formatted through the currency mask.
• PAYMENT_TYPE and TYPE — the payment type code and its decoded lookup meaning.
• RECEIPT_DATE, DEPOSIT_DATE, MATURITY_DATE, EXCHANGE_RATE_DATE — key dates for aging and cash positioning.
• BANK_NAME, CUSTOMER_BANK_ACCOUNT, REMITTANCE_BANK_ACCOUNT_ID — banking details for the receipt.
• CURRENCY_CODE, EXCHANGE_RATE, EXCHANGE_RATE_TYPE — currency and conversion attributes.
• RECEIPT_STATUS — status flag on the cash receipt.
• DOC_SEQUENCE_ID, DOCUMENT_NUMBER, USSGL_TRANSACTION_CODE — document sequencing and accounting classification.
• REFERENCE_TYPE, REFERENCE_ID, VAT_TAX_ID, RECEIVABLES_TRX_ID — reference and receivables transaction linkage.

The user search term "reversal_reason_code" does not appear as a projected column in the documented view text. Reversal-related information for cash receipts resides in the base AR tables (for example, reversal reason and reversal date attributes on AR_CASH_RECEIPTS and its history), not in this view. Consumers requiring reversal_reason_code must query the underlying AR tables directly, or join this view back to AR_CASH_RECEIPTS on CASH_RECEIPT_ID.

Common Use Cases and Queries

Typical uses include cash receipt inquiry pages, customer payment reconciliation lists, and integration extracts feeding downstream reporting. A representative query retrieving receipt detail for a customer follows:

SELECT RECEIPT_NUMBER, CUSTOMER_NAME, AMOUNT, APPLIED_AMOUNT, UNAPPLIED_AMOUNT, ON_ACCOUNT_AMOUNT, CURRENCY_CODE, RECEIPT_DATE FROM ICX_AR_CASH_RECEIPTS_V WHERE CUSTOMER_NUMBER = :customer_number AND RECEIPT_DATE >= :from_date ORDER BY RECEIPT_DATE DESC;

To surface reversal context alongside receipt data, join to the base table:

SELECT V.RECEIPT_NUMBER, V.CUSTOMER_NAME, V.AMOUNT, V.RECEIPT_STATUS, CR.REVERSAL_REASON_CODE, CR.REVERSAL_DATE FROM ICX_AR_CASH_RECEIPTS_V V, AR_CASH_RECEIPTS CR WHERE CR.CASH_RECEIPT_ID = V.CASH_RECEIPT_ID AND V.RECEIPT_STATUS = 'REV';

Aggregation by bank and currency for cash positioning is equally common, using SUM on AMOUNT grouped by BANK_NAME and CURRENCY_CODE. Because all monetary columns are pre-formatted strings, arithmetic on AMOUNT, APPLIED_AMOUNT, UNAPPLIED_AMOUNT, or ON_ACCOUNT_AMOUNT requires explicit numeric conversion, a constraint worth noting in any integration design.