Results for “jl_br_ar_payment_sch_iob_v”

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

Overview

JL_BR_AR_PAYMENT_SCH_IOB_V is a read-only view owned by the APPS schema within the JL – Latin America Localizations product, specifically targeting the Brazilian receivables localization. It is documented in the ETRM as a VALID database object. The view consolidates payment schedule information with the Brazilian borderô (bank collection remittance) framework, exposing installment-level receivable data alongside the corresponding bordero record, customer party, and bank account usage.

Its principal role is to support reporting and integration scenarios in which a payment schedule line must be examined together with the collection or factoring bordero that submitted it to a bank. Because the view joins payables flow documents to the borderô tables, it is used by localization reports and interfaces that require a trade-note reference in the format TRX_NUMBER-TERMS_SEQUENCE_NUMBER and related attributes, without requiring the consumer to manually reproduce the joins across the underlying AR and JL tables.

Underlying Base Objects

The view is defined over the following documented objects: AR_PAYMENT_SCHEDULES_ALL, JL_BR_AR_COLLECTION_DOCS_ALL, JL_BR_AR_BORDEROS, RA_CUSTOMER_TRX_ALL, HZ_CUST_ACCOUNTS, HZ_PARTIES, and CE_BANK_ACCT_USES_ALL. All are referenced through synonyms in the APPS schema.

• AR_PAYMENT_SCHEDULES_ALL — the primary driver of the view, supplying payment schedule identifiers, due dates, remaining amounts due, and transaction numbers.
• JL_BR_AR_COLLECTION_DOCS_ALL — links each payment schedule to its borderô collection document.
• JL_BR_AR_BORDEROS — the borderô header, filtered by BORDERO_TYPE IN ('COLLECTION','FACTORING'), and the source of ORG_ID and bank account usage.
• RA_CUSTOMER_TRX_ALL — supplies the transaction number and bill-to customer identifier.
• HZ_CUST_ACCOUNTS and HZ_PARTIES — provide the customer account and the customer name (PARTY_NAME).
• CE_BANK_ACCT_USES_ALL — validates the bank account use associated with the collection document.

The join is a conjunction of schedule, collection document, bordero, transaction, account, party, and bank account use, all restricted to the borderô type COLLECTION or FACTORING, and constrained throughout on ORG_ID.

Key Columns

• ROW_ID — the ROWID of the underlying payment schedule row, used as the distinct key.
• PAYMENT_SCHEDULE_ID — the installment identifier from AR_PAYMENT_SCHEDULES_ALL.
• DUE_DATE — the installment due date.
• AMOUNT_DUE_REMAINING — the open amount still outstanding on the installment.
• CUSTOMER_ID — the bill-to customer account identifier.
• CUSTOMER_TRX_ID and TRX_NUMBER — the transaction identifier and number of the originating invoice.
• GLOBAL_ATTRIBUTE10 and GLOBAL_ATTRIBUTE11 — the descriptive flexfield attributes used by the Brazilian localization.
• CUSTOMER_NAME — the customer party name.
• ORG_ID — the operating unit identifier (multi-org security key).
• TRADE_NOTE_NUMBER — concatenation of TRX_NUMBER and TERMS_SEQUENCE_NUMBER, formatted with a hyphen; the trade-note reference.

Common Use Cases and Queries

The view is typically queried to list bordero-submitted installments with their remaining balance and customer details for a given operating unit. A minimal query follows:

SELECT TRADE_NOTE_NUMBER, TRX_NUMBER, CUSTOMER_NAME,
       DUE_DATE, AMOUNT_DUE_REMAINING, GLOBAL_ATTRIBUTE10
  FROM APPS.JL_BR_AR_PAYMENT_SCH_IOB_V
 WHERE ORG_ID = :org_id
   AND TRUNC(DUE_DATE) BETWEEN :start_date AND :end_date
 ORDER BY DUE_DATE;

Typical scenarios include reconciliation of borderô submissions against outstanding receivables, aging and collection reporting for Brazilian legal entities, factoring analysis, and reconciliation of bank account usage against collection documents. Because the view filters to COLLECTION and FACTORING borderô types, results exclude borderôs of other categories, and the DISTINCT clause eliminates duplicates arising from the multi-table join. Queries should be scoped by ORG_ID to respect operating unit security.