Search Results set_batches




Overview

IGI_ITR is a server-side PL/SQL package owned by the APPS schema within the Oracle E-Business Suite, most closely associated with the Italy localization (IGI) module and its interface tables for transaction processing. Its header timestamp (2007) and version marker indicate it has remained stable across the 12.1.1 and 12.2.2 releases. The package provides the programmatic engine that moves transaction data from the IGI staging tables into the Oracle General Ledger journal interface, allowing staged transaction records to be validated, grouped into batches, and finally imported into GL as journals.

The business flow supported by IGI_ITR centers on the IGI_ITR_CHARGE_HEADERS and IGI_ITR_CHARGE_LINES staging tables. Users or upstream processes populate these tables, then invoke the package to accept or reject individual lines, assign them to batches, and submit the assembled batch to the GL Interface. The package encapsulates the batch-level routing logic, status tracking, and GL interface population required to complete the transfer without manual journal entry. It is classified as an "OTHER" API rather than a formal OPEN interface, meaning it is intended for controlled internal use rather than as a public integration endpoint.

Key Procedures and Functions

The package exposes eight documented procedures:

  • SUBMIT — Entry point for submitting a transaction identified by its header ID. It performs the submission processing for the given interface header and returns status code and message output parameters.
  • ACTION — Applies a caller-supplied action code to control package behavior during processing.
  • SET_BATCHES — Registers a specific batch ID for processing; typically used to add a batch to the internal batch collection (l_BatchIdTable) before processing.
  • PROCESS_BATCHES — The core routine that iterates over registered batches and performs the batch-level processing (validation, GL interface loading, or journal creation). This is the procedure most commonly referenced when users search for "process_batches".
  • CONTROL — Governs an interface run keyed by interface run ID, group ID, and set of books ID, returning a status code and message. It manages run-level coordination for a batch of interface records.
  • ACCEPT — Marks an individual transaction line as accepted, taking the header ID, line number, encumbrance-allowed flag, and group ID, and returning status information.
  • REJECT — Marks an individual transaction line as rejected, taking header ID, line number, and group ID, and returning status information.
  • STATUS — Reports the status of a specific batch identified by batch ID.

Tables Accessed

IGI_ITR references a combination of IGI staging tables and standard General Ledger interface tables via APPS synonyms. On the IGI side, IGI_ITR_CHARGE_HEADERS and IGI_ITR_CHARGE_LINES hold the transaction charge headers and lines that the package validates and processes. On the GL side, GL_INTERFACE and GL_INTERFACE_CONTROL receive the journal lines and control totals destined for journal import. GL_JE_BATCHES, GL_JE_HEADERS, GL_JE_LINES, GL_JE_CATEGORIES, and GL_JE_SOURCES provide the journal batch, header, line, category, and source reference data necessary to construct valid GL journal entries. GL_JOURNAL_IMPORT_S is used for journal import sequencing and identification. DUAL is referenced for trivial single-row queries. Together, these tables confirm that PROCESS_BATCHES and its supporting routines construct GL journal interface records from IGI charge data.

Usage Notes

IGI_ITR is typically invoked from Oracle Forms or from concurrent programs within the IGI localization module rather than directly by end users. The primary usage pattern is: stage data in the IGI charge tables, use ACCEPT or REJECT to validate individual lines, call SET_BATCHES to register batches, execute CONTROL to coordinate the interface run, and finally invoke PROCESS_BATCHES to push the data into GL_INTERFACE. Journal Import is then run to create the actual GL journals. Because the package is an "OTHER"-classified API, direct custom invocation carries upgrade risk; implementations should prefer the supported concurrent programs and forms. It is referenced by one other package in the ETRM metadata, indicating it participates in a small internal call chain. The l_Action, l_TableRow, and l_BatchIdTable package globals persist state within a session, so callers must respect the intended call sequence.