Results for “interest_writeoff_ccid”

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

Overview

The view APPS.JL_BR_AR_COLL_DOCS_SAB_V belongs to the JL - Latin America Localizations product family, specifically the Brazilian Accounts Receivable localization. It exposes collection document data used by the Brazilian bank collection (bordero) and portfolio process, presenting rows sourced from the underlying collection document table JL_BR_AR_COLLECTION_DOCS enriched with descriptive attributes resolved from parties, banks, receipt methods, batch sources, and lookup tables. In Oracle EBS 12.1.1 and 12.2.2 environments, the view is registered as VALID in the APPS schema and is consumed by concurrent programs, report definitions, and integration extracts that must render collection documents with human-readable descriptions rather than raw identifiers.

The view is not a transactional entry point. Its role is presentation and enrichment: it joins a wide set of reference objects so that each collection document row carries not only its operational identifiers (bordero, payment schedule, customer transaction) but also contextual detail such as collector bank and branch names, portfolio codes, and lookup-derived status meanings.

Underlying Base Objects

The documented base objects referenced by JL_BR_AR_COLL_DOCS_SAB_V include JL_BR_AR_COLLECTION_DOCS (the primary driving table), JL_BR_AR_BANK_INSTRUCTIONS, AR_BATCH_SOURCES, AR_PAYMENT_SCHEDULES_ALL, AR_RECEIPT_METHODS, RA_CUSTOMER_TRX_ALL, CE_BANK_ACCOUNTS, and CE_BANK_ACCT_USES_ALL. Party and relationship resolution is achieved through HZ_PARTIES, HZ_ORGANIZATION_PROFILES, HZ_RELATIONSHIPS, and HZ_CODE_ASSIGNMENTS. Status and code meanings are resolved through the FND_LOOKUPS view and the FND_GLOBAL package, the latter typically supplying ORG_ID and user context for multi-org security.

The view therefore acts as a denormalized projection: the CD alias columns correspond to JL_BR_AR_COLLECTION_DOCS, while customer, bank, receipt method, and lookup joins supply the descriptive columns. The "_SAB_V" naming convention aligns with Brazilian subledger reporting views that pair raw IDs with names for downstream reports.

Key Columns

• ORIGIN_TYPE — Classifies how the collection document was created, for example generated by the bank collection/bordero process versus other origination paths. This is the column most frequently searched for in collection reconciliation and extract logic.
• DOCUMENT_ID / BORDERO_ID / PAYMENT_SCHEDULE_ID — Core operational keys linking the document to its bordero, its AR payment schedule, and the associated portfolio.
• DOCUMENT_STATUS / PREVIOUS_DOC_STATUS — Current and prior status of the document (e.g., selected, sent to bank, settled, cancelled).
• DOCUMENT_TYPE / PORTFOLIO_CODE / OUR_NUMBER — Brazilian collection identifiers: instrument type, portfolio, and "nosso número" assigned by the bank.
• CUSTOMER_TRX_ID / TERMS_SEQUENCE_NUMBER — Link back to the originating AR invoice and installment.
• BANK_ACCT_USE_ID / RECEIPT_METHOD_ID / BATCH_SOURCE_ID — Bank account use, receipt method, and batch source driving the collection.
• Factor/interest columns — FACTORING_RATE, FACTORING_AMOUNT, INTEREST_*_CCID, and related receipt IDs support interest, abatement, and factoring accounting.
• COLLECTOR_BANK_PARTY_ID / COLLECTOR_BRANCH_PARTY_ID — Collector bank and branch resolved via HZ tables.

Common Use Cases and Queries

Typical scenarios include reconciling bordero documents to AR receipts, analyzing documents by origination path, and generating bank-specific collection extracts.

SELECT document_id,
       bordero_id,
       origin_type,
       document_status,
       our_number,
       due_date
FROM   apps.jl_br_ar_coll_docs_sab_v
WHERE  origin_type = :p_origin_type
AND    document_status = :p_status;

Grouping by portfolio and origin supports volume reporting:

SELECT portfolio_code,
       origin_type,
       COUNT(*) doc_count,
       SUM(factoring_amount) total_factoring
FROM   apps.jl_br_ar_coll_docs_sab_v
GROUP  BY portfolio_code, origin_type
ORDER  BY portfolio_code;

Because the view resolves statuses through FND_LOOKUPS, reports can present lookup meanings directly. Multi-org security is enforced via the FND_GLOBAL package, so queries should always be executed with proper ORG_ID context.