Results for “ar_icr_trx_v”

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

Overview

The APPS.AR_ICR_TRX_V view is an Oracle Receivables dictionary object whose definition, per the Oracle E-Business Suite documentation, is designated as Release 115 Only. In the ETRM 12.2.2 metadata the object retains a VALID status and remains owned by the APPS schema, defined over a set of Receivables and Trading Community Architecture (TCA) synonyms. The view presents a flattened, reporting-oriented projection of open Receivables payment schedules joined to their originating transactions, customer accounts, parties, and, where applicable, consolidated billing invoice records. Its principal purpose is to expose transactions eligible for receipt application or billing-related processing, filtered to exclude payment and guarantee classes and any schedule already reserved, selected for a receipt batch, or otherwise consumed. Because the view performs the joins and most of the eligibility filtering internally, it allows reporting tools, concurrent programs, and integration interfaces to retrieve a pre-qualified result set without reconstructing the underlying multi-table logic. Its age and Release 115 origin mean it is generally treated as a legacy or compatibility object rather than a current-development target.

Underlying Base Objects

The documented reference list identifies six base objects, all reached through APPS-owned synonyms: AR_PAYMENT_SCHEDULES, RA_CUSTOMER_TRX, AR_CONS_INV, HZ_CUST_ACCOUNTS, HZ_PARTIES, and HZ_CUSTOMER_PROFILES. AR_PAYMENT_SCHEDULES supplies the primary rows, with PAYMENT_SCHEDULE_ID as the driving key and STATUS, CLASS, and reserved-type columns used in the WHERE clause to isolate open, unreserved schedules. RA_CUSTOMER_TRX is inner-joined on CUSTOMER_TRX_ID to retrieve the transaction number and purchase order. The customer relationship is resolved through HZ_CUST_ACCOUNTS joined on CUSTOMER_ID, then to HZ_PARTIES via PARTY_ID for the customer name, and to HZ_CUSTOMER_PROFILES on CUST_ACCOUNT_ID with the constraint CP.SITE_USE_ID IS NULL, which restricts the profile join to the account-level rather than a site-level row. AR_CONS_INV is joined using an outer join (CI.CONS_INV_ID(+) = PS.CONS_INV_ID), so consolidated billing information is returned when present but does not eliminate transactions that lack a consolidated invoice.

Key Columns

• PAYMENT_SCHEDULE_ID — Primary identifier of the underlying payment schedule row.
• TRX_NUMBER — The Receivables transaction number from RA_CUSTOMER_TRX.
• BILLING_NUMBER — Derived from CI.CONS_BILLING_NUMBER; the consolidated billing invoice number. This is the column most relevant to searches for “billing_number” and is NULL when no consolidated invoice exists.
• INVOICE_CURRENCY_CODE — Currency of the transaction.
• CUSTOMER_NAME — Party name truncated to 50 bytes via SUBSTRB.
• CUSTOMER_NUMBER and CUSTOMER_ID — Account number and CUST_ACCOUNT_ID from HZ_CUST_ACCOUNTS.
• CUSTOMER_TRX_ID — Identifier of the associated transaction.
• CLASS — Transaction class from the payment schedule; PMT and GUAR are excluded by the view definition.
• PURCHASE_ORDER — Customer purchase order reference.
• RELATED_CUST_ID — Hard-coded NULL, annotated in the view text with BUG 2304009.
• ACCOUNT_DESCRIPTION — Documented column list entry; note the view text exposes CUST_ACCT.ACCOUNT_NAME under this list.

Common Use Cases and Queries

The view is typically queried to list open, unreserved transactions with customer and consolidated billing context for receipt application, collections, or reconciliation reporting.

SELECT billing_number, trx_number, customer_name, invoice_currency_code, purchase_order FROM apps.ar_icr_trx_v WHERE billing_number IS NOT NULL;

SELECT trx_number, customer_number, class, purchase_order FROM apps.ar_icr_trx_v WHERE customer_id = :cust_account_id ORDER BY trx_number;

Because the view embeds filters for open status, unreserved schedules, and profile SITE_USE_ID IS NULL, consumers should not assume it returns all transactions; unqualified queries yield only the qualified subset defined by the view text. Given the Release 115 designation, organizations on 12.1.1 and 12.2.2 should verify the object remains present and valid in their instance before relying on it for new integrations.