Search Results xla_ae_code_combination_pkg




Overview
Explore in AI Chat

Overview

The APPS.XLA_AE_CODE_COMBINATION_PKG package is a supporting utility within the Oracle E-Business Suite Subledger Accounting (SLA) architecture, specifically the Accounting Engine component. Its principal business function is the construction and validation of accounting flexfield code combinations (CCIDs) for subledger journal entries generated by the XLA Accounting Engine. When SLA processes transactions from a source subledger such as Payables, Receivables, or Assets, it must resolve accounting flexfield segment values into a single valid code combination identifier before it can post or store a journal line. This package encapsulates the logic that performs that resolution, including cross-validation against GL chart of accounts mappings, caching of frequently used combinations, and error reporting when a combination cannot be derived. Because it is owned by APPS and classified as OTHER in the ETRM registry, it is an internal engine utility rather than a public application programming interface, and it is invoked implicitly by the higher-level SLA engine packages rather than directly by end users.

Key Procedures and Functions

  • BUILDCCIDS — The primary driver routine that assembles code combination identifiers for a set of accounting entries, typically operating against the XLA global temporary tables used during accounting generation.
  • GETCCID — Returns the code combination identifier for a given set of segment values, serving as the core lookup entry point.
  • REFRESHCCID / REFRESHCCIDCACHE — Refreshes and maintains the in-memory cache of resolved code combinations, ensuring that stale combinations are discarded when the chart of accounts or mapping definitions change during a run.
  • CACHE_COA — Loads chart of accounts structure and segment information into the session cache so that subsequent segment lookups avoid repeated queries against the flexfield definition tables.
  • CACHEGLMAPPING — Caches General Ledger account mapping rules, which define how subledger account derivation rules translate into target GL code combinations.
  • GET_FLEX_SEGMENT_VALUE — Retrieves a flexfield segment value, resolving the value identifier from the underlying value set tables.
  • GET_FLEX_SEGMENT_DESC — Returns the descriptive text associated with a flexfield segment value, drawing on the translated values table.
  • GET_SEGMENT_CODE — Returns the concatenated or individual segment code representation for a combination.
  • GET_CCID_ERRORS — Reports validation errors accumulated when a code combination could not be constructed, supporting diagnostic workflows.

Tables Accessed

The package queries applications-owned synonyms including GL_CODE_COMBINATIONS, the authoritative repository of valid accounting flexfield combinations; FND_ID_FLEX_SEGMENTS and FND_FLEX_VALUES along with FND_FLEX_VALUES_TL for segment definitions and translated value descriptions; and FND_SEGMENT_ATTRIBUTE_VALUES for segment qualifiers. GL_COA_MAPPINGS and the interface tables GL_ACCTS_MAP_BSV_GT and GL_ACCTS_MAP_INT_GT supply the account mapping rules used by CACHEGLMAPPING. The SLA global temporary tables XLA_AE_HEADERS_GT, XLA_AE_LINES_GT, and XLA_TRANSACTION_ACCTS_GT provide the journal entry lines whose account combinations are being built and validated, while DBMS_UTILITY and PLITBLM support internal caching and collection manipulation.

Usage Notes

XLA_AE_CODE_COMBINATION_PKG is not intended to be called from forms or concurrent programs directly. It is referenced by five higher-level packages, most notably XLA_ACCOUNTING_ENGINE_PKG, XLA_AE_JOURNAL_ENTRY_PKG, XLA_AE_LINES_PKG, and XLA_THIRD_PARTY_MERGE. These packages invoke it during the Create Accounting process and related accounting engine operations. Customers writing custom SLA account derivation rules or extending the accounting engine should treat this package as an internal dependency and rely on supported APIs rather than calling it directly, since its interface may change between releases. Both Oracle EBS 12.1.1 and 12.2.2 document the object as VALID in the APPS schema, and its behavior is consistent across both releases.