Results for “ar_payment_schedules_trx_v”

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

Overview

AR_PAYMENT_SCHEDULES_TRX_V is a view owned by the APPS schema in Oracle E-Business Suite Receivables (AR). The ETRM metadata explicitly annotates this object as "(Release 115 Only)", indicating that it was documented for the Release 11.5 code line and remains present, valid, and accessible in the APPS schema of later releases such as 12.1.1 and 12.2.2. Its purpose is to present payment schedule information in the specific context of cross-transaction receivable applications — that is, the application of a payment or credit memo to a transaction, or more precisely the relationship between a transaction and the payment schedule of a related transaction.

The view is a reporting and integration convenience object. Rather than requiring the caller to join AR_PAYMENT_SCHEDULES, AR_RECEIVABLE_APPLICATIONS, and RA_CUSTOMER_TRX manually and to apply the rather specific filter predicates that characterize this view, the view encapsulates that logic behind a stable column list. This makes it suitable for custom reports, reconciliation queries, and interfaces that need to see original versus remaining amounts on a payment schedule alongside the amounts applied to it.

Underlying Base Objects

The documented ETRM metadata lists three referenced base objects, all exposed through synonyms in the APPS schema:

• AR_PAYMENT_SCHEDULES (aliased PS) — supplies the payment schedule rows and the original/remaining amount columns.
• AR_RECEIVABLE_APPLICATIONS (aliased RA) — supplies the applied amounts and the DISPLAY flag.
• RA_CUSTOMER_TRX (aliased CT) — supplies the transaction header used to reach the related transaction and to filter on COMPLETE_FLAG.

The join conditions are significant. The view restricts to transactions where CT.COMPLETE_FLAG = 'Y', and links PS.CUSTOMER_TRX_ID to CT.PREVIOUS_CUSTOMER_TRX_ID — meaning the payment schedule belongs to the transaction that the current transaction references as its predecessor, typically the original invoice when the current row is a credit or adjustment. The receivable application is then matched on RA.CUSTOMER_TRX_ID = CT.CUSTOMER_TRX_ID and RA.APPLIED_PAYMENT_SCHEDULE_ID = PS.PAYMENT_SCHEDULE_ID, and finally filtered by NVL(RA.DISPLAY, 'Y') = 'Y' so that only applications flagged for display are returned.

Key Columns

The view exposes identity, date, monetary, and audit columns:

• ROW_ID — the rowid of the underlying payment schedule row, useful for direct reference back to AR_PAYMENT_SCHEDULES.
• PAYMENT_SCHEDULE_ID and CUSTOMER_TRX_ID — the primary schedule identifier and the related transaction identifier, forming the key linkage for joins.
• DUE_DATE — the due date of the payment schedule installment.
• AMOUNT_DUE_ORIGINAL / AMOUNT_DUE_REMAINING — the original and outstanding amounts due on the schedule. Note that the metadata column listing renders the second as "LINE_REMAINING", which appears to be a documentation typographical truncation of AMOUNT_DUE_REMAINING.
• AMOUNT_LINE_ITEMS_ORIGINAL / AMOUNT_LINE_ITEMS_REMAINING, TAX_ORIGINAL / TAX_REMAINING, FREIGHT_ORIGINAL / FREIGHT_REMAINING — line, tax, and freight components in original and remaining terms.
• Applied amount columns derived from AR_RECEIVABLE_APPLICATIONS and negated by -1: a combined line-and-charges column (sum of LINE_APPLIED and RECEIVABLES_CHARGES_APPLIED), RA_TAX_APPLIED, RA_FREIGHT_APPLIED, RA_LINE_APPLIED, and RA_CHARGES_APPLIED. The negation aligns applied amounts with credit-style sign conventions.
• Audit columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

Typical uses include reconciling applied amounts against remaining balances on cross-referenced transactions, building aging-style extracts that combine schedule balances with application detail, and providing integration payloads where the applied-versus-original split is required.

A simple retrieval of schedule balances for a transaction family can be written as:

• SELECT customer_trx_id, payment_schedule_id, due_date, amount_due_original, amount_due_remaining, tax_original, tax_remaining FROM ar_payment_schedules_trx_v WHERE customer_trx_id = :trx_id;

To inspect applied amounts and their sign convention:

• SELECT payment_schedule_id, ra_line_applied, ra_tax_applied, ra_freight_applied, ra_charges_applied FROM ar_payment_schedules_trx_v WHERE due_date BETWEEN :from_date AND :to_date;

Because the view is filtered to COMPLETE_FLAG = 'Y' and DISPLAY = 'Y', callers should not treat it as a full replacement for querying AR_PAYMENT_SCHEDULES directly. Where incomplete transactions or hidden applications must be included, the base tables should be queried instead. All monetary columns are returned in the functional currency established on the underlying transaction and payment schedule records.