Search Results jl_br_ar_borderos




Overview
Explore in AI Chat

Overview

The APPS.JL_BR_AR_PAYMENT_SCH_IOB_V view is a Brazilian localization (JL_BR) reporting object within Oracle E-Business Suite Receivables. It exposes Accounts Receivable payment schedule data that has been associated with a bordero — a Brazilian banking collection instrument used for cobrança (collection) and factoring arrangements. The view flattens the relationship between open receivable installments, their corresponding bordero registrations, customer identity, and the bank account used for collection, producing a single row per qualifying payment schedule.

The naming convention reflects its scope: JL_BR denotes the Brazil localization, AR denotes Receivables, PAYMENT_SCH denotes the payment schedule basis, and IOB refers to the banking interface context through which collection documents are transmitted to financial institutions. The view therefore supports reporting and integration scenarios where users must identify which customer installments (trade notes) have been placed into borderos for bank collection or factoring, and which remain outstanding.

Underlying Base Objects

The view is defined over seven documented base objects, all referenced through APPS synonyms:

  • AR_PAYMENT_SCHEDULES_ALL — the primary driver, supplying the transaction installments, due dates, remaining amounts, TRX numbers and terms sequence.
  • JL_BR_AR_COLLECTION_DOCS_ALL — the Brazil localization collection-document table linking each payment schedule to a bordero.
  • JL_BR_AR_BORDEROS — the bordero header, providing organization context and bordero type (restricted to COLLECTION and FACTORING).
  • RA_CUSTOMER_TRX_ALL — the AR transaction, supplying the transaction number and bill-to customer linkage.
  • HZ_CUST_ACCOUNTS and HZ_PARTIES — the TCA trading community tables resolving customer account to the party name.
  • CE_BANK_ACCT_USES_ALL — the bank account usage, ensuring only schedules tied to a valid collection bank account usage are returned.

All joins are correlated on ORG_ID across the schedule, bordero, transaction, and account-usage records, enforcing multi-org isolation. The DISTINCT keyword eliminates duplicates arising from multiple matching collection-document rows.

Key Columns

Common Use Cases and Queries

Typical reporting scenarios include reconciling collections transmitted to banks against open AR balances, auditing which installments are included in factoring borderos, and building bordero remittance extracts. A representative query listing outstanding factored installments by customer:

  • SELECT trade_note_number, customer_name, trx_number, due_date, amount_due_remaining FROM apps.jl_br_ar_payment_sch_iob_v WHERE org_id = :org_id AND amount_due_remaining > 0 ORDER BY due_date;
  • SELECT customer_name, SUM(amount_due_remaining) total_due FROM apps.jl_br_ar_payment_sch_iob_v WHERE org_id = :org_id GROUP BY customer_name;
  • SELECT trade_note_number, global_attribute10, global_attribute11 FROM apps.jl_br_ar_payment_sch_iob_v WHERE trx_number = :trx_number;

Because the view exposes only schedules already linked to collection or factoring borderos, it should not be used as a general open-receivables ledger; for complete aging, base AR reporting views remain the appropriate source.