Results for “gl_iea_autogen_map”

26 results




AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The GL.GL_IEA_AUTOGEN_MAP table is a General Ledger (GL) module object within Oracle EBS 12.1.1 and 12.2.2 that stores the automatic account generation mapping rules used by the Global Intercompany System (GIS). Intercompany transactions require accounts to be derived automatically on both the sending and receiving sides of a transaction, and this table holds the configuration that governs how that derivation is performed based on the interplay between a sender ledger's chart of accounts and a receiver ledger's chart of accounts. The table is owned by the GL schema, is documented with 26 columns in the ETRM 12.2.2 physical schema, and carries a status of VALID.

From a Data Vault modeling perspective, the mined FK structure carries a heuristic classification of standalone. Because the documented primary key is composite — comprising only RECEIVER_CHART_OF_ACCT_ID and SENDER_CHART_OF_ACCT_ID — the table behaves like a configuration or cross-reference hub for the chart-of-accounts pairing rather than a transactional satellite. Each row represents one unique sender/receiver chart-of-accounts combination and the automatic generation behavior applied to it. There is also a documented unique index, GL_IEA_AUTOGEN_MAP_U1, on the same two columns in reverse order, reinforcing that the pair constitutes the natural business key.

Key Information Stored

The most important columns in GL_IEA_AUTOGEN_MAP are:

  • SENDER_CHART_OF_ACCT_ID — identifies the chart of accounts of the sending (initiating) ledger. Part of the composite primary key and the unique index.
  • RECEIVER_CHART_OF_ACCT_ID — identifies the chart of accounts of the receiving (recipient) ledger. Part of the composite primary key and the unique index.
  • USE_SENDER_CLEAR_RULES_FLAG — indicates whether the sender's clearing account rules apply when generating accounts for this pairing.
  • USE_RECEIVER_CLEAR_RULES_FLAG — indicates whether the receiver's clearing account rules apply.
  • USE_RECEIVER_DIST_RULES_FLAG — indicates whether the receiver's distribution rules apply to the automatic account generation.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard EBS WHO columns recording audit and concurrency information.
  • ATTRIBUTE1 through ATTRIBUTE15 — the standard flexible descriptive attribute columns available for customer-specific extensions.
  • CONTEXT — the descriptive flexfield context column that qualifies the attribute segments.

The surrogate key is represented by the GL_IEA_AUTOGEN_MAP_PK constraint over the sender and receiver chart-of-accounts identifiers, and GL_IEA_AUTOGEN_MAP_U1 serves as the business-key candidate unique index. The three USE_*_RULES_FLAG columns encode the core business logic of the table, determining whose clearing and distribution rules drive account generation for a given ledger pair.

Common Use Cases and Queries

Typical uses of this table include troubleshooting intercompany account generation, auditing the rule precedence between sender and receiver ledgers, and reporting the configuration state of the Global Intercompany System.

To retrieve the rules for a specific ledger pair:

  • SELECT sender_chart_of_acct_id, receiver_chart_of_acct_id, use_sender_clear_rules_flag, use_receiver_clear_rules_flag, use_receiver_dist_rules_flag FROM gl.gl_iea_autogen_map WHERE sender_chart_of_acct_id = :p_sender AND receiver_chart_of_acct_id = :p_receiver;

To list all pairings that defer to receiver rules:

  • SELECT * FROM gl.gl_iea_autogen_map WHERE use_receiver_dist_rules_flag = 'Y';

Because the table is small and configuration-oriented, it is commonly joined to chart-of-accounts definitions in reporting queries and used to validate why a particular intercompany journal derived accounts differently than expected.

Related Objects

The table participates in the Global Intercompany System and relates most directly to:

These relationships should be confirmed against the actual foreign-key constraints in the target instance, as the documented metadata classifies this object as standalone.