Search Results struct_num

Overview

GL_GLXRLFBL_XMLP_PKG is the generated PL/SQL package body that backs an Oracle E-Business Suite (EBS) XML Publisher (BI Publisher) concurrent report. The package name follows the standard _XMLP_PKG convention applied to Oracle Reports-to-XML conversions, and the base report identifier GLXRLFBL belongs to the Oracle General Ledger product. In EBS 12.1.1 and 12.2.2 this construct provides the report's before- and after-report logic, its lexical parameter accessors, and the flexfield resolution hooks the report layout calls at runtime. Its primary business function is to support a General Ledger reporting process that must be constrained by a user-selected data access set and ledger, and that must dynamically resolve the Accounting Key Flexfield (GL#) against the correct chart of accounts.

Key Procedures and Functions

• BEFOREREPORT — Executes prior to the report run. It resolves the user-supplied access set identifier into an access set name and the associated chart of accounts identifier (the structure number), and resolves the ledger identifier into a ledger name. It raises an application error on failure, terminating the concurrent request.
• AFTERREPORT — Executes after the report completes. In this package it is effectively a stub returning TRUE, retained for XML Publisher invocation symmetry.
• FLEX_FIELD_ALL_LOWFORMULA — Formula column used to derive the low value of the all-segment flexfield range, bound to the structure number at runtime.
• FLEX_FIELD_ALL_HIGHFORMULA — Formula column used to derive the high value of the all-segment flexfield range, also bound to the structure number.
• STRUCT_NUM_P — Lexical parameter accessor that exposes the resolved chart of accounts structure number (STRUCT_NUM) to the report query.
• LEDGER_NAME_P — Lexical parameter accessor exposing the resolved ledger name.
• FLEX_SELECT_ALL_LOW_P — Lexical parameter accessor supplying the low flexfield selection string used in the report's WHERE clause.
• FLEX_SELECT_ALL_HIGH_P — Lexical parameter accessor supplying the corresponding high flexfield selection string.
• ACCESS_SET_NAME_P — Lexical parameter accessor exposing the resolved data access set name.

These _P functions follow the standard XML Publisher pattern: each returns the value of a package-level variable populated in BEFOREREPORT, allowing the report's data model to reference it as a lexical or bind parameter.

Tables Accessed

The package reads two documented base tables through APPS synonyms:

• GL_ACCESS_SETS — queried in BEFOREREPORT by access_set_id to return the access set name and chart_of_accounts_id. This determines the set of ledgers, and the accounting structure, that the report is permitted to display.
• GL_LEDGERS — queried by ledger_id to return the ledger name displayed in report headers and used for ledger-scoped filtering.

No inserts, updates, or deletes are performed; the package is strictly a read-only reporting aid. The Accounting Key Flexfield definitions are resolved indirectly through the FND FLEXRSQL and FND FLEXRIDVAL user exits referenced in the original Oracle Reports source, passing GL# as the flexfield code and STRUCT_NUM as the structure number.

Usage Notes

This package is not intended to be called directly from forms or custom code. It is invoked automatically by the XML Publisher concurrent program engine when the associated GL report is submitted. Oracle Reports generates a call to BEFOREREPORT before executing the query, and to AFTERREPORT on completion; the flexfield formula functions and _P accessors are called by the report layout itself.

The user search term "struct_num" maps directly to the package variable STRUCT_NUM, which is populated in BEFOREREPORT from GL_ACCESS_SETS.CHART_OF_ACCOUNTS_ID and subsequently passed to the flexfield user exits. This mechanism ensures the report resolves the accounting flexfield against the chart of accounts attached to the selected data access set rather than a hard-coded structure, a critical requirement when multiple charts of accounts coexist in one EBS instance. Because the package is regenerated from the report definition, customizations should be applied through the report or its data model rather than by editing the package body directly.