Search Results jl_br_eilog




Overview
Explore in AI Chat

Overview

JL_BR_EILOG is an audit trail (log) table owned by the JL schema within the Oracle E-Business Suite Latin America Localizations module (JL). Its purpose is to track the communication between partner software and the Brazilian tax authority (SEFAZ) — and the reverse direction — as it relates to the submission of electronic invoices (Nota Fiscal Eletrônica, or NF-e) and their subsequent status transition changes. In practice, the table acts as a chronological journal of every meaningful event exchanged during the NF-e lifecycle, providing the traceability that Brazilian fiscal compliance regulations require.

The object is classified heuristically as standalone under the Data Vault modeling convention. This classification derives from its foreign key structure, which contains a single outbound reference and no inbound references from other tables in the documented metadata. As a modeling suggestion, the table behaves most like a satellite attached to the electronic invoice occurrence record — it stores descriptive, time-stamped, and historically versioned attributes rather than defining new business entities or relationships. The single FK to JL_BR_AR_OCCURRENCE_DOCS_ALL serves as the parent link tying each log entry back to the underlying fiscal occurrence document.

Key Information Stored

The table contains 10 documented columns in the ETRM 12.2.2 physical schema. The most significant are:

  • OCCURRENCE_ID — Foreign key referencing JL_BR_AR_OCCURRENCE_DOCS_ALL. This is the business key candidate that links each log entry to the specific electronic invoice occurrence being tracked.
  • OCCURRENCE_DATE — The date the logged occurrence took place, used to sequence events chronologically.
  • CUSTOMER_TRX_ID — References the receivables transaction (invoice) associated with the electronic invoice submission.
  • ELECTRONIC_INV_STATUS — The status of the electronic invoice at the time of the logged event, capturing status transition changes over time.
  • MESSAGE_TXT — The actual message payload exchanged with the tax authority or partner software, including return codes, rejection reasons, or authorization confirmations.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, CREATED_BY — Standard Oracle EBS audit columns recording who created and last modified each row and when.

Because the documented schema does not expose an explicit surrogate primary key column, OCCURRENCE_ID combined with OCCURRENCE_DATE is the most plausible natural key candidate for uniquely identifying an event; if a system-generated row identifier exists in the underlying physical table, it functions as the surrogate key.

Common Use Cases and Queries

Typical usage centers on fiscal audit and troubleshooting. Common scenarios include reviewing the complete message history for a specific invoice, identifying invoices stuck in a rejected status, and analyzing submission timing against SEFAZ response windows.

  • Tracing all events for one occurrence: SELECT * FROM JL_BR_EILOG WHERE OCCURRENCE_ID = :id ORDER BY OCCURRENCE_DATE;
  • Listing rejected or pending electronic invoices: SELECT CUSTOMER_TRX_ID, ELECTRONIC_INV_STATUS, MESSAGE_TXT FROM JL_BR_EILOG WHERE ELECTRONIC_INV_STATUS = :status;
  • Audit reporting by date range: SELECT OCCURRENCE_DATE, CUSTOMER_TRX_ID, ELECTRONIC_INV_STATUS FROM JL_BR_EILOG WHERE OCCURRENCE_DATE BETWEEN :from_date AND :to_date;

These queries support compliance reporting, dispute resolution with tax authorities, and operational monitoring of partner software integrations.

Related Objects

The only documented foreign key relationship is:

  • JL_BR_AR_OCCURRENCE_DOCS_ALL — joined on JL_BR_EILOG.OCCURRENCE_ID = JL_BR_AR_OCCURRENCE_DOCS_ALL.OCCURRENCE_ID. This parent table holds the occurrence documents that this log table annotates.

Additional related objects typically referenced during analysis include the Receivables transaction tables (RA_CUSTOMER_TRX_ALL, keyed by CUSTOMER_TRX_ID) and the JL Brazil electronic invoice processing programs that write to this audit table. Because the documented relationship data identifies JL_BR_EILOG as standalone with no inbound references, it functions primarily as a dependent child of the occurrence document rather than a parent referenced by other objects.