Search Results bsc_mo_indicator_pkg




Overview
Explore in AI Chat

Overview

BSC_MO_INDICATOR_PKG is a PL/SQL package body owned by the APPS schema within the Oracle E-Business Suite Balanced Scorecard (BSC) module. The BSC module, part of the Oracle Business Intelligence Applications foundation shipped with EBS 12.1.1 and 12.2.2, provides the metadata framework used to define Key Performance Indicators (KPIs), indicators, dimensions, and their underlying data structures. This package operates in the metadata optimization layer, as evidenced by its reference to BSC_METADATA_OPTIMIZER_PKG and BSC_MO_DOC_PKG. Its principal business function is to interrogate and resolve the physical and logical configuration of indicators — specifically the measures, columns, key fields, and dimension relationships that compose a given scorecard indicator — so that downstream components can generate SQL, resolve data source bindings, and construct projection or aggregation expressions. The package has a status of VALID and is classified as OTHER in the API taxonomy, indicating that it is an internal utility rather than a public, externally supported API. According to ETRM documentation, it is not referenced by any database object, yet it references numerous BSC and FND packages, tables, and views, and is noted as being referenced by five other packages. This asymmetry suggests it is an inward-facing helper invoked dynamically or through metadata-driven dispatch.

Key Procedures and Functions

The package body exposes fifteen documented procedures and functions, each supporting indicator metadata resolution:

  • GETSTRCOMBINATIONSMN — derives string combinations, likely for constructing key or dimension concatenations.
  • INDICATORTABLES — returns the set of tables associated with a given indicator.
  • KEYFIELDEXISTS — determines whether a designated key field is present in an indicator's definition.
  • DATAFIELDEXISTS — tests for the existence of a data field.
  • DATAFIELDEXISTSFORSOURCE — tests data field existence restricted to a particular source.
  • INDEXRELATION1N — resolves one-to-many index relationships.
  • GETKEYORIGIN — identifies the origin (source table or view) of a key field.
  • GETCONFIGURATIONSFORINDIC — retrieves configurations applicable to an indicator.
  • GETLEVELCOLLECTION — returns the collection of dimension levels for an indicator.
  • GETFREEDIVZEROEXPRESSION — generates a division-by-zero-safe expression fragment.
  • ISINDICATORPNL — determines whether an indicator is Profit-and-Loss oriented.
  • GETDATAFIELDS — returns the data fields belonging to an indicator.
  • ISINDICATORBALANCEORPNL — classifies an indicator as a balance-sheet or P&L type.
  • GETPROJECTIONTABLENAME — resolves the projection table name for an indicator.
  • GETCOLCONFIGFORINDIC — returns column configuration for an indicator.

Tables Accessed

Through APPS synonyms, the package reads configuration and metadata from BSC_KPI_DATA_TABLES, BSC_KPI_DIM_LEVELS_B, BSC_KPI_PERIODICITIES, BSC_SYS_DIM_LEVELS_B, BSC_SYS_DIM_LEVEL_RELS, BSC_SYS_MEASURES, BSC_INTERNAL_COLUMN_S, and BSC_DB_MEASURE_COLS_TL. These hold indicator-to-table mappings, dimension level hierarchies, periodicity settings, measure definitions, and multilingual column labels. It also queries DUAL, USER_OBJECTS, and PLITBLM, and it employs DBMS_SQL for dynamic SQL construction. Dependent views such as BSC_KPIS_VL, BSC_DB_MEASURE_BY_DIM_SET_V, and BSC_DB_DATASET_DIM_SETS_V supply consolidated KPI and measure-by-dimension information.

Usage Notes

This package is invoked internally by the BSC metadata optimizer and documentation packages rather than directly from Oracle Forms or standard concurrent programs. It is typically triggered during scorecard metadata compilation, KPI generation, and dynamic SQL assembly, where the runtime must confirm field existence, resolve key origins, classify indicator types (balance versus P&L), and obtain projection table names. Because it is an OTHER-classified internal API and is not referenced by any database object per the ETRM metadata, customization should be avoided; integrators requiring similar functionality should call supported BSC APIs or the metadata optimizer instead. Any direct reliance is at the implementer's risk.