Search Results get_conc_segments

Overview

XLA_REPORT_UTILITY_PKG is a shared PL/SQL utility package owned by the APPS schema in Oracle E-Business Suite. It belongs to the Subledger Accounting (XLA) product family and is declared with AUTHID CURRENT_USER, meaning that its unqualified references execute under the privileges of the calling schema. As indicated by its package header comments, it provides routines that support accounting reports and diagnostic queries rather than performing transactional accounting itself.

The package first shipped in April 2005 and was extended over subsequent releases. The function get_transaction_id was added in December 2005, get_conc_segments in June 2006, and in February 2009 get_transaction_id was overloaded to support more than fifty event classes per application, a requirement introduced for the Financial Services Accounting Hub (FSAH). These additions reflect the package's central role in dynamically assembling SQL for XLA reporting views, where the set of entity identifiers and event classes varies substantially between source applications such as Payables, Receivables, Assets, and Inventory.

Because transaction identifiers and event attributes differ per application and per event class, XLA reporting cannot rely on a single static view. This package resolves those differences at runtime, producing SQL fragments or descriptive values that reporting code can concatenate into executable statements.

Key Procedures and Functions

• GET_TRANSACTION_ID — The most commonly referenced routine, added in 2005 and overloaded in 2009. It builds the SELECT, FROM, and WHERE fragments required to resolve a transaction identifier for a given application, entity code, event class, and reporting view. This is the procedure users typically seek when searching for "get_transaction_id."
• GET_ACCT_QUALIFIER_SEGS — Returns account qualifier segment names from the chart of accounts, including balancing, account, cost center, management, and intercompany segments.
• GET_CCID_DESC — Returns a descriptive string for a given combination identifier within a specified chart of accounts.
• GET_SEGMENT_INFO — Retrieves segment and alias segment information for a chart of accounts, supporting display of accounting flexfield structure in reports.
• GET_CONC_SEGMENTS — Provides concatenated segment values, added in 2006.
• GET_LEDGER_ID, GET_LEDGER_OBJECT_TYPE, IS_PRIMARY_LEDGER — Resolve ledger context: the ledger identifier in effect, its object type, and whether it is a primary ledger.
• GET_ANC_FILTER — Returns filter criteria related to account assignment.
• CLOB_TO_FILE — Writes CLOB content out to a file, typically for large report output.

Tables Accessed

The package reads configuration and definition data rather than posting accounting entries. Flexfield metadata comes from FND_FLEX_VALUE_SETS, FND_ID_FLEX_SEGMENTS, FND_ID_FLEX_STRUCTURES, and FND_SEGMENT_ATTRIBUTE_VALUES, which together supply chart of accounts structure used by GET_ACCT_QUALIFIER_SEGS, GET_CCID_DESC, and GET_SEGMENT_INFO. Ledger context is drawn from GL_LEDGERS and GL_LEDGER_SET_ASSIGNMENTS. Subledger definition data comes from XLA_ENTITY_ID_MAPPINGS, XLA_EVENT_CLASS_ATTRS, XLA_EVENT_TYPES_B, and XLA_ANALYTICAL_DTLS_B, which drive the dynamic SQL construction in GET_TRANSACTION_ID. The package also inspects DBA_TAB_COLUMNS, USER_OBJECTS, and USER_SYNONYMS to validate the existence and shape of reporting view columns at runtime, and uses DBMS_LOB and PLITBLM for large object handling and string parsing.

Usage Notes

XLA_REPORT_UTILITY_PKG is an internal utility layer. It is referenced by eleven other APPS packages and is invoked by XLA accounting reports, diagnostic concurrent programs, and custom extensions that must render subledger transaction identifiers or chart of accounts descriptions. Because GET_TRANSACTION_ID outputs SQL text through its OUT parameters, callers are responsible for concatenating and executing the returned fragments. The 2009 overload exists specifically because a single application can define more than fifty event classes, so callers targeting FSAH environments should ensure the appropriate signature is resolved by argument type. Customizations should treat the package as a supported internal API, avoid direct modifications, and rely on the documented signatures only.