Search Results xla_mo_reporting_api




Overview
Explore in AI Chat

Overview

The APPS.XLA_MO_REPORTING_API package body is a public Application Programming Interface (API) shipped with the Oracle E-Business Suite Subledger Accounting (XLA) module. It provides the core supporting logic used to resolve and validate reporting context for Subledger Accounting multi-organizational reporting. In the Subledger Accounting architecture, accounting events and journal entries are attributed to a reporting entity and a reporting level, which together determine how balances, transfers, and drill-down reporting are presented for a legal entity or organization. This package encapsulates the rules that map an internal identifier to a meaningful reporting entity name, map an internal identifier to a reporting level name, and validate that a given reporting entity or reporting level is legitimate for the calling context. A default reporting level of 3000 is declared in the package specification and is visible through the g_reporting_level global, indicating that reporting-level resolution is a first-class concern of this API. The package also provides reusable diagnostic utilities, Generic_Error and App_Error, which standardize error messaging and FND logging for internal SQL and application exceptions.

Key Procedures and Functions

The ETRM metadata documents eight procedures and functions exposed by this package. Their roles are as follows:

  • INITIALIZE — Establishes the package-level session state required before other routines are called, including resetting globals such as the reporting entity identifier and the default reporting level.
  • GET_PREDICATE — Returns the SQL predicate fragment used to constrain queries by reporting level or reporting entity; the internal global g_pred supports this construction.
  • GET_REPORTING_ENTITY_NAME — Resolves a stored reporting entity identifier to its display name, typically derived from organization tables.
  • GET_REPORTING_LEVEL_NAME — Returns the descriptive name associated with a reporting level identifier, allowing users to interpret level codes such as 3000.
  • VALIDATE_REPORTING_ENTITY — Confirms that a supplied reporting entity identifier exists and is valid for the current ledger configuration.
  • VALIDATE_REPORTING_LEVEL — Confirms that a supplied reporting level identifier is recognized and permissible.

Two additional routines are present in the documented count, reflecting the package's internal error-handling surface. The Generic_Error and App_Error procedures set FND messages, apply tokens, and raise exceptions, and they defer to APP_EXCEPTION.RAISE_EXCEPTION when a fatal condition occurs. FND logging is controlled by comparisons against FND_LOG.G_CURRENT_RUNTIME_LEVEL at the LEVEL_UNEXPECTED and LEVEL_ERROR thresholds.

Tables Accessed

The package reads through APPS synonyms for the following tables:

  • FND_PRODUCT_GROUPS — Supplies product-group context, including the application installation and database identification used during initialization and messaging.
  • FND_PROFILE_OPTION_VALUES — Retrieves profile option settings that govern default reporting level and related system behavior.
  • HR_ALL_ORGANIZATION_UNITS — Provides the organization unit record used to resolve and validate reporting entity identifiers and their names.
  • HR_ORGANIZATION_INFORMATION — Supplies descriptive organization attributes, such as the organization name and classification, needed for entity naming.

Usage Notes

XLA_MO_REPORTING_API is a shared utility rather than an end-user-facing program. It is referenced by 24 other packages, indicating that it sits at the base of the Subledger Accounting reporting stack and is called by higher-level accounting and inquiry APIs. Typical invocation patterns include Subledger Accounting concurrent programs that build reporting-entity hierarchies, OAF and Forms-based inquiry pages that display the reporting entity and level in their headers, and custom extensions that need the same predicate or name resolution logic used by standard XLA reporting. Because the package relies on package globals such as g_reporting_level and g_pred, callers should execute INITIALIZE at the beginning of a session before invoking the getter or validator routines, particularly in long-running concurrent requests where more than one reporting context may be processed. Error conditions raised by this package are surfaced through FND message stack entries, so custom callers should inherit standard XLA error-handling conventions when embedding these calls.