Search Results register_i015




Overview
Explore in AI Chat

Overview

JL_BR_SPED_DATA_EXTRACT_PUB is a public PL/SQL package in the APPS schema that supports the Brazilian SPED (Sistema Público de Escrituração Digital) statutory reporting obligations within Oracle E-Business Suite. SPED requires Brazilian legal entities to file standardized electronic accounting and fiscal records with tax authorities. This package serves as the data extraction registration layer for specific SPED record blocks, accepting the reporting context (ledger, legal entity, establishment, period, and segment mappings) that the extraction process requires in order to assemble the mandated bookkeeping and fiscal registers.

In the documented release, the package body contains only stub implementations. Both procedures compile successfully but execute a NULL statement, meaning the deployed code does not yet perform extraction logic. This indicates the package is either a placeholder reserved for future localization delivery or a wrapper point intentionally left empty, with actual SPED processing handled elsewhere in the Brazilian localization module. The API classification is PUB, confirming that it is exposed as a supported entry point intended for invocation by other code rather than being an internal helper.

Key Procedures and Functions

The package exposes two documented procedures. Both share an identical parameter interface, accepting the ledger identifier, legal entity identifier, establishment identifier, period set name, start and end dates, balancing, account, and cost center segment values, bookkeeping type, and the concurrent request identifier, along with the standard errbuf and retcode out parameters used by concurrent-program-friendly PL/SQL APIs.

  • register_I015 — Intended to register the extraction context for SPED record I015, which relates to the identification of the bookkeeping accounts associated with the reporting period. The user search term "register_i015" maps directly to this procedure. In the documented body it contains no executable logic.
  • register_I200_I250 — Intended to register the extraction context for SPED records I200 through I250, which comprise the bookkeeping ledger entries and their supporting detail for the accounting period. As delivered, its body also contains no executable logic.

Tables Accessed

The documented metadata identifies three tables referenced through APPS synonyms. Although the stub bodies contain no active SQL statements, these tables define the expected resolution context for the referenced parameters.

  • GL_LEDGERS — The General Ledger ledger definition, supplying the ledger identifier, accounting period set name, and chart of accounts context for the reporting entity.
  • XLE_ENTITY_PROFILES — The legal entity profile, used to identify the registered legal entity to which the SPED filing applies.
  • XLE_ETB_PROFILES — The establishment profile, distinguishing the specific tax establishment within the legal entity for which records must be extracted.

These three tables together establish the statutory reporting hierarchy of ledger, legal entity, and establishment that governs Brazilian fiscal localization.

Usage Notes

Because this is a PUB API with the conventional concurrent-program parameter signature (errbuf, retcode, and concurrent_request_id), it is designed to be invoked from Oracle EBS concurrent programs, typically the Brazilian SPED data extraction or generation concurrent program. It may also be called from the Oracle Forms interface or from custom localization code that orchestrates SPED submission. The metadata records that the package is referenced by one other package, indicating that at least one dependent module calls these procedures as part of a larger extraction workflow.

Implementers working on Oracle EBS 12.1.1 or 12.2.2 should note that the delivered body performs no work. Any functional SPED extraction logic must reside in the referencing package or be supplied through localization patches. Developers extending this API should preserve the documented public signatures to avoid breaking dependent callers, and should route all error signaling through the errbuf and retcode parameters so the calling framework can correctly record request completion status.