Search Results gl_iea_import_registry




Overview
Explore in AI Chat

Overview

The GL_IEA_IMPORT_REGISTRY table is a General Ledger (GL) module object within the Oracle E-Business Suite 12.1.1 and 12.2.2 environments. It resides in the GL schema and is classified as a control table for the Global Intercompany System (GIS), formally referred to as the Intercompany Enterprise Application (IEA). Its specific function is to govern and record the execution of intercompany import processes. When intercompany transactions are interfaced into the GIS from external sources or subsidiary ledgers, the import program requires a mechanism to track which batches of transactions have been processed for specific intercompany transaction types. This table serves as that execution control registry, ensuring that import logic is applied correctly and consistently to defined groups of transactions. The table is defined with a status of VALID and is catalogued as part of the standard ETRM documentation for EBS 12.2.2, with applicability to 12.1.1 maintaining consistent behaviour.

From a data-modelling perspective, the metadata heuristic suggests a Data Vault classification of link. This classification is appropriate because the table does not store descriptive attributes about a single business entity; rather, it associates two independent entities—a group identifier and a transaction type—and optionally links them to a concurrent request. It serves as an associative structure resolving a many-to-many-style relationship between transaction groups and transaction types, while also recording the specific execution instance via the request identifier.

Key Information Stored

The documented physical schema contains three columns, and the table is deliberately narrow, reflecting its role as a lightweight control and association registry:

  • GROUP_ID — A numeric identifier representing a logical grouping of intercompany transactions. Together with TRANSACTION_TYPE_ID, it forms the composite primary key. It identifies the batch or set of intercompany lines being imported and is the primary partitioning key for import control.
  • TRANSACTION_TYPE_ID — A foreign key to GL_IEA_TRANSACTION_TYPES. This identifies the specific intercompany transaction type (for example, a recurring or one-time intercompany transaction definition) that governs the rules under which the import group is processed. It is also part of the composite primary key.
  • REQUEST_ID — A foreign key to FND_CONCURRENT_REQUESTS. This column records the specific concurrent program request that executed the import for the given group and transaction type. It provides the audit linkage to the concurrent manager job, enabling traceability of execution status, timing, and output.

The surrogate primary key is defined as GL_IEA_IMPORT_REGISTRY_PK on (GROUP_ID, TRANSACTION_TYPE_ID). A unique index, GL_IEA_IMPORT_REGISTRY_U1, exists on the same column pair, confirming that this combination is the business key candidate. No other descriptive columns are documented, so the table is entirely composed of key and relationship attributes.

Common Use Cases and Queries

The primary use case is the monitoring and troubleshooting of Global Intercompany System imports. DBAs and financial systems administrators frequently query this table to determine whether a specific intercompany group has been imported and by which concurrent request. A typical query joins to FND_CONCURRENT_REQUESTS to retrieve the phase and status of the import:

  • Import status audit: SELECT r.group_id, r.transaction_type_id, r.request_id, c.phase_code, c.status_code FROM gl_iea_import_registry r, fnd_concurrent_requests c WHERE r.request_id = c.request_id AND r.group_id = :group_id;
  • Transaction type analysis: Joining to GL_IEA_TRANSACTION_TYPES reveals which transaction types are most frequently associated with import executions, useful for capacity planning and process tuning.
  • Reconciliation and control: Comparing registry entries against the actual intercompany transaction tables verifies that all registered imports completed successfully and that no orphaned control records remain.
  • Concurrent request traceability: Filtering by REQUEST_ID allows administrators to isolate the registry entries created by a specific concurrent program run, supporting post-incident analysis.

Related Objects

The table participates in a small but well-defined set of relationships, as documented by its foreign keys and primary key structure:

  • GL_IEA_TRANSACTION_TYPES — Referenced via TRANSACTION_TYPE_ID. This is the master definition of intercompany transaction types and must be joined to obtain descriptive and rule information for each registry entry.
  • FND_CONCURRENT_REQUESTS — Referenced via REQUEST_ID. Provides the concurrent execution context, including request phase, status, and run timestamps for the import job.
  • GL_IEA_TRANSACTIONS — The actual intercompany transaction interface table populated by the import process; the registry controls which groups are eligible for import into this structure.
  • GL_IEA_INTERFACE — The interface staging structure for intercompany data, logically related through the import execution controlled by the registry.
  • GL_IEA_GROUPS — Where defined, the group identifiers referenced in the registry correspond to logical groups used elsewhere in the intercompany subsystem.
  • FND_CONCURRENT_PROGRAMS / FND_CONCURRENT_PROGRAM_SERIAL — Indirectly related through the concurrent request, useful for identifying the specific import program that generated the registry entry.

No public APIs are documented for direct manipulation; the table is normally maintained exclusively by the Global Intercompany System import concurrent program.