Search Results map_qualified_segment

Overview

APPS.GL_ACCOUNTS_MAP_GRP is a PL/SQL package in the Oracle E-Business Suite General Ledger module. Its API classification code, "GRP," identifies it as a group-type or utility package rather than a formal public API, meaning it is intended primarily for internal consumption by other Oracle EBS components rather than as a supported extension point for customer code. The package provides the account mapping engine used by General Ledger consolidation and by the Subledger Accounting (XLA) architecture when it must translate, or map, a source chart of accounts combination into a target chart of accounts combination.

Account mapping is central to consolidation processing, where balances from multiple subsidiary ledgers that use differing charts of accounts must be restated into the parent chart of accounts. The package resolves segment-level and flexfield-level mapping rules, evaluates account ranges against those rules, and prepares the temporary staging data used to drive the mapping run. Because the package depends on FND_API, it participates in the standard EBS API error-handling and message conventions.

Key Procedures and Functions

The ETRM documentation lists six procedures within the package body:

• MAP — The principal driver for an account mapping operation. It orchestrates the evaluation of mapping rules against a set of source accounts.
• MAP_ACCOUNT — Maps an individual account combination, applying the applicable chart-of-accounts and segment mapping definitions to derive the corresponding target account.
• MAP_BSVS — Handles mapping for balance sheet and value-set related mapping records, applying the balance sheet/value-set mapping rules stored in GL_ACCTS_MAP_BSV_GT.
• POPULATE_BSV_TARGETS — Populates the target-side records for the balance sheet/value-set mapping structures, preparing the target combinations that the mapping logic resolves against.
• MAP_QUALIFIED_SEGMENT — Maps a qualified segment: a specific qualifying segment value that, when matched, determines the corresponding target segment value.
• POPULATE_QUAL_SEGMENT_TARGETS — Populates the target structures for qualified-segment mapping, staging the qualified-segment target values prior to mapping execution.

Together these procedures distinguish between full-account mapping, balance sheet/value-set mapping, and qualified-segment mapping—the three mapping modalities supported by GL consolidation and cross-ledger conversion.

Tables Accessed

The package reads and writes the following documented tables (accessed through APPS synonyms):

• GL_COA_MAPPINGS — Stores chart-of-accounts mapping definitions, the master rule set this package evaluates.
• GL_CONS_FLEXFIELD_MAP and GL_CONS_SEGMENT_MAP — Hold consolidation flexfield-level and segment-level mapping rules.
• GL_ACCTS_MAP_BSV_GT and GL_ACCTS_MAP_INT_GT — Global temporary tables used to stage balance sheet/value-set mappings and intermediate mapping results during processing.
• FND_FLEX_VALUE_SETS, FND_FLEX_VALIDATION_TABLES, FND_ID_FLEX_SEGMENTS, and FND_SEGMENT_ATTRIBUTE_VALUES — Key Flexfield infrastructure read to resolve value sets, segment definitions, validation tables, and segment attributes.
• PLITBLM — A standard EBS PL/SQL table (index-by table) type reference used for in-memory collections.

Usage Notes

GL_ACCOUNTS_MAP_GRP is referenced by three other packages: itself (internal recursion), XLA_AE_CODE_COMBINATION_PKG, and XLA_HIST_LEDGER_UPG_PKG. Within Subledger Accounting, XLA_AE_CODE_COMBINATION_PKG uses this package to derive account combinations for accounting entries, while XLA_HIST_LEDGER_UPG_PKG invokes it during historical ledger upgrade processing when account mappings must be applied to legacy data.

Typical invocation occurs indirectly through consolidation concurrent programs, the Consolidation Workbench, and Subledger Accounting account-derivation flows, rather than through direct customer calls. Because the package is classified as a GRP utility and depends on FND_API, developers should treat it as an internal implementation component. Custom code that requires account mapping should use supported public APIs, such as those in the GL or XLA account-derivation layer, rather than calling GL_ACCOUNTS_MAP_GRP directly. No formal parameter documentation is published for its procedures, so integrators must not assume a stable signature across releases.