Search Results bsc_tab_view_labels_tl_pk

Overview

BSC_TAB_VIEW_LABELS_TL is a translation (TL) table belonging to the BSC — Balanced Scorecard product family in Oracle E-Business Suite. Per the ETRM documentation, the BSC module is classified as Obsolete, meaning the object is retained for legacy compatibility but is not implemented in current 12.1.1 or 12.2.2 instances. The table stores translated label text and layout attributes associated with tab views used in the Balanced Scorecard user interface, enabling multilingual rendering of scorecard dashboard elements.

Functionally, this is the language-specific counterpart to the base label definition table (typically BSC_TAB_VIEW_LABELS_B). The _TL suffix follows Oracle's standard multilingual translation pattern: one row per (business entity, language) combination, while the corresponding _B table holds language-independent attributes. Translated rows carry textual and positional data such as the display label name, font styling, coordinates, and hyperlink URL.

The ETRM metadata assigns a heuristic Data Vault classification of standalone, indicating that no foreign key relationships were mined from the physical schema. In Data Vault modeling terms, this would suggest treating the table as a self-contained construct rather than a strict hub, link, or satellite, though its four-part primary key structure bears resemblance to a multi-attribute hub combined with language-specific satellite content.

Key Information Stored

The table contains 21 documented columns. The most significant for reporting and integration purposes are catalogued below.

• TAB_ID, TAB_VIEW_ID, LABEL_ID, LANGUAGE — the composite surrogate primary key (BSC_TAB_VIEW_LABELS_TL_PK), which the metadata also flags as the unique business-key index BSC_TAB_VIEW_LABELS_TL_U1. Together these columns identify a specific label on a specific view of a specific tab, in a specific language.
• SOURCE_LANG — the language from which the translation was derived, supporting Oracle's standard translation workflow.
• TEXT_FLAG — a control flag indicating whether the label renders as text versus another display form.
• NAME — the translated label caption displayed to the user.
• LEFT_POSITION, TOP_POSITION, WIDTH, HEIGHT — layout geometry governing label placement and sizing on the rendered tab view.
• FONT_SIZE, FONT_STYLE, FONT_COLOR — presentation attributes controlling typography and colour.
• URL — optional hyperlink target associated with the label.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard Oracle WHO columns auditing row provenance.
• NOTE — free-text annotation attached to the label.

Note that the primary key is entirely a composite natural/surrogate mix, with no single surrogate column such as a generated ID. The unique index duplicates the primary key column set exactly.

Common Use Cases and Queries

Because the BSC module is obsolete, this table is primarily encountered during upgrade assessments, data archival, or historical reporting. Typical query patterns include retrieving all translated labels for a given tab view restricted to a target language:

• Filter by TAB_ID and TAB_VIEW_ID with LANGUAGE = userenv('LANG') to reproduce the runtime label set.
• Join to the _B base table on TAB_ID, TAB_VIEW_ID, and LABEL_ID to compare translated versus base attributes.
• Aggregate by LANGUAGE to audit translation completeness across all configured languages using SOURCE_LANG to identify untranslated rows.
• Extract FONT_* and geometry columns for style-sheet migration projects when retiring the scorecard UI.

Related Objects

• BSC_TAB_VIEW_LABELS_B — the base (language-independent) label definition table; joins on TAB_ID, TAB_VIEW_ID, LABEL_ID.
• BSC_TAB_VIEWS_B and BSC_TAB_VIEWS_TL — parent tab view definitions referenced through TAB_ID and TAB_VIEW_ID.
• BSC_TABS_B and BSC_TABS_TL — tab-level definitions supplying the TAB_ID context.
• FND_LANGUAGES — validation source for the LANGUAGE and SOURCE_LANG columns.
• FND_APPLICATION — identifies the owning BSC application during cross-module analysis.

No foreign keys are documented, so joins should be validated manually against the base tables before use in production queries.