Search Results document_status




Overview
Explore in AI Chat

Overview

JL_BR_AR_COLLECTION_DOCS_ALL is a Latin America Localizations (JL) table owned by the JL schema that stores Brazilian Accounts Receivable collection documents — the transaction records created when receivables are submitted for bank collection, bordero processing, factoring, and related banking activities. The table captures both the lifecycle state of each collection document (status, dates, origin) and the full accounting context, since a single collection document fans out into many General Ledger account assignments.

Its role in Oracle EBS 12.1.1 and 12.2.2 is to act as the operational and accounting bridge between the Receivables subledger (AR_PAYMENT_SCHEDULES_ALL, RA_CUSTOMER_TRX_ALL, AR_RECEIPT_METHODS), the Brazil localization borders (JL_BR_AR_BORDEROS_ALL), and the GL chart of accounts (GL_CODE_COMBINATIONS). The documented FK topology — twenty-plus foreign keys pointing outward to GL_CODE_COMBINATIONS and a minimal set of inbound references — supports a Data Vault modeling suggestion of satellite-leaning: the table's identity and key relationships belong to hubs and links elsewhere, while the bulk of its columns are descriptive attributes, dates, amounts, and CCID references. It is a multi-org table, evidenced by the presence of ORG_ID.

Key Information Stored

The surrogate primary key is DOCUMENT_ID, enforced by JL_BR_AR_COLLEC_DOCS_ALL_PK and reinforced by unique index JL_BR_AR_COLLECT_DOCS_U1. Because the same column carries both the primary key and the unique index, DOCUMENT_ID is the only documented business-key candidate; no alternate natural key (such as a borderô number plus document number combination) is defined at the uniqueness level in this metadata.

The most operationally significant columns include:

The 15 ATTRIBUTE columns plus the standard CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN audit columns complete the 76-column structure.

Common Use Cases and Queries

The most frequent reason this table is queried is precisely the search that surfaced it: resolving the GL account for a Brazilian collection event. A typical pattern joins the document to its account combination:

  • Collection aging and borderô reconciliation — join BORDERO_ID to JL_BR_AR_BORDEROS_ALL and group by DOCUMENT_STATUS to monitor pending versus liquidated documents.
  • Accounting drill-down — SELECT d.document_id, d.our_number, g.concatenated_segments FROM jl_br_ar_collection_docs_all d, gl_code_combinations_kfv g WHERE d.cash_ccid = g.code_combination_id; repeated per CCID column that is populated.
  • Interest and abatement analysis — filtering on the populated interest or abatement CCIDs and the corresponding *_RECTRX_ID columns to trace revenue recognition.
  • Operating unit reporting — constrained by ORG_ID and SELECTION_DATE between ranges.

Because the accounting CCIDs are stored as surrogate IDs, queries almost always require a join to GL_CODE_COMBINATIONS (or its _KFV key-flexfield view) to render a human-readable account.

Related Objects

The most significant dependent and referenced objects are:

  • GL_CODE_COMBINATIONS — referenced by more than a dozen CCID columns, making it the dominant dimension.
  • JL_BR_AR_BORDEROS_ALL via BORDERO_ID — the parent borderô.
  • AR_PAYMENT_SCHEDULES_ALL via PAYMENT_SCHEDULE_ID — the underlying receivable.
  • RA_CUSTOMER_TRX_ALL via CUSTOMER_TRX_ID — the source transaction.
  • AR_RECEIPT_METHODS via RECEIPT_METHOD_ID and AR_RECEIPT_METHOD_ACCOUNTS_ALL via BANK_ACCOUNT_ID.
  • CE_BANK_ACCT_USES_ALL via BANK_ACCT_USE_ID, and HZ_PARTIES via the collector bank and branch party IDs.
  • JL_BR_AR_BANK_RETURNS_ALL and JL_BR_AR_OCCURRENCE_DOCS_ALL — child tables that reference DOCUMENT_ID and hold bank return and occurrence detail.