Search Results fii_ap_drill_across




Overview

FII_AP_DRILL_ACROSS is an Oracle Applications (APPS) PL/SQL package that belongs to the Oracle Financial Intelligence / Financials Intelligence (FII) product family, specifically the Accounts Payable (AP) analytical and reporting layer. Its business purpose is to support "drill across" functionality within the Payables intelligence reporting framework. In Oracle EBS terminology, "drill across" describes the ability for a user to navigate from a summary-level figure in one analytical report or dashboard directly into a lower level of detail, or into a related reporting context, without losing the dimensional context of the original analysis.

The package is classified in the ETRM metadata with an API classification of OTHER, indicating that it is not published as a standard open interface or public application programming interface, but rather is an internal component used by the FII reporting infrastructure. It is owned by the APPS schema, consistent with most EBS PL/SQL packages delivered under the shared APPS database account.

This package addresses the Accounts Payable domain, using parameters that reflect core Payables analysis dimensions: operating unit, supplier, currency, accounting period, and an as-of date. These dimensions correspond directly to the common filters applied in Payables period-close, liability, and payment analysis reporting.

Key Procedures and Functions

The documented metadata identifies a single public procedure within the package:

  • DRILL_ACROSS — The sole documented procedure. Its name and the package's surrounding design indicate that it acts as the entry point for executing a drill-across navigation in the Accounts Payable analytical context. It accepts the contextual filter values required to define the scope of the analysis, including the source, operating unit, supplier, currency, as-of date, period, and an internal parameter identifier. The parameter identifier (a "pParamIds" style argument) typically carries serialized or encoded context passed from the calling FII report or form, allowing the procedure to resolve which underlying query or report should be launched for the selected drill target.

No other procedures or functions are documented for this package. The header comment in the package specification carries a source control identifier with a date of 2005, reflecting the long-standing stability of this component across EBS releases.

Tables Accessed

The ETRM metadata does not enumerate specific tables referenced by this package through APPS synonyms. This is consistent with the package operating primarily as a navigation and context-resolution component rather than as a direct data-manipulation unit. Where database access occurs, it would be expected to read from Accounts Payable analytical and reporting objects — for example the FII AP summary or fact tables and their supporting AP base tables — in order to resolve drill targets and validate the incoming contextual parameters. However, because the documented metadata lists no referenced tables, no specific table names should be assumed. Implementers should treat the package as context-driven and rely on runtime tracing should a precise dependency list be required.

Usage Notes

FII_AP_DRILL_ACROSS is typically invoked indirectly by the Financials Intelligence reporting framework rather than being called directly from a form trigger or standard concurrent program. The drill-across event is normally initiated when a user selects a hyperlinked analysis value in an FII dashboard or analytical report and requests a cross-navigation to related Payables detail. The calling layer passes the required contextual arguments — source, operating unit, supplier, currency, as-of date, period, and parameter identifiers — into the procedure.

The package is documented as referenced by zero other packages, indicating that it sits at or near the top of the call hierarchy for this particular drill-across path and is not reused as a shared utility. Because it is classified as OTHER and is not a published API, custom code should not depend on it; any direct invocation risks breakage on patching or upgrade. In Oracle EBS 12.1.1 and 12.2.2, this object should be regarded as an internal component maintained by Oracle, and integrations should be built against supported open interfaces instead.