Search Results fnd_mo_reporting_api




Overview
Explore in AI Chat

Overview

FND_MO_REPORTING_API is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite releases 12.1.1 and 12.2.2. The "MO" prefix designates the Multi-Org architecture introduced with Release 12, under which the Multiple Organizations (MO) feature set governs how operating units, legal entities, and ledgers are resolved at runtime. This package is classified as an API in the ETRM repository and is documented as VALID in the current environment.

The package encapsulates the server-side logic required to identify, resolve, and validate reporting entities and reporting levels within the Multi-Org security model. Its business purpose is to abstract the mapping between a user's session context — as established by profile options such as the operating unit — and the reporting hierarchy used by Multi-Org reporting and security components. By centralizing predicate construction and validation logic, the package allows higher-level reporting frameworks to obtain consistent organization-based filtering without embedding organization hierarchy logic directly in each consumer.

FND_MO_REPORTING_API is referenced by 15 other database objects and does not itself reference any object outside the APPS schemas listed in the dependency chain, indicating it functions as a foundational utility rather than an end-user entry point.

Key Procedures and Functions

The package exposes seven documented procedures and functions. The INITIALIZE routine establishes the working context for subsequent calls, loading session-specific values such as the current operating unit and ledger association. GET_PREDICATE returns a SQL predicate fragment that callers can append to their own queries to restrict data to the reporting entities visible to the current user. GET_REPORTING_ENTITY_NAME resolves an entity identifier to its display name, typically sourced from the organization hierarchy tables.

GET_REPORTING_LEVEL_NAME performs the equivalent resolution for reporting levels, returning a human-readable label for a level identifier. VALIDATE_REPORTING_ENTITY verifies that a supplied reporting entity is legitimate and accessible under the current Multi-Org context, raising an application error through APP_EXCEPTION when the check fails. VALIDATE_REPORTING_LEVEL performs the parallel validation for reporting levels. The seventh documented routine supports the internal resolution and caching behavior required by the preceding calls. All routines are intended to be invoked from server-side PL/SQL, not directly by end users.

Tables Accessed

Documented references include FND_PRODUCT_GROUPS, which identifies the installation and is commonly queried during initialization to establish the application context. FND_PROFILE_OPTION_VALUES and the FND_PROFILE package supply the session-level profile settings — principally the operating unit and related Multi-Org profile options — that determine the user's reporting scope. HR_ALL_ORGANIZATION_UNITS and HR_ORGANIZATION_INFORMATION provide the organization hierarchy data used to resolve entity and level names and to build the predicate returned by GET_PREDICATE. GL_SETS_OF_BOOKS is referenced to associate reporting entities with the appropriate ledger. FND_LOOKUPS and FND_MESSAGE, together with APP_EXCEPTION, supply lookup validation and standardized error messaging. FND_MO_REPORTING_ENTITIES_V is the view through which the package reads the reporting entity definitions, and FND_MO_REPORTING_API references itself for internal recursion or shared logic.

Usage Notes

FND_MO_REPORTING_API is invoked indirectly rather than by end users. Multi-Org reporting components, organization security routines, and concurrent programs that must respect operating unit boundaries typically call GET_PREDICATE to obtain a ready-made WHERE clause or call the VALIDATE_* routines before accepting a user-supplied entity or level value. Custom Oracle Forms and OAF pages that implement organization-aware queries may call the same routines to achieve consistency with standard Multi-Org behavior. Because the package is referenced by 15 other objects, changes to its behavior can propagate widely; extensions and customizations should therefore call the public routines rather than modify the package body. When invoked from forms or concurrent programs, callers should ensure the Multi-Org initialization routine (FND_GLOBAL or equivalent) has already executed, since the package depends on profile values being populated in the session.