Search Results as_issues_tl




Overview

AS_ISSUES_TL is the translation (TL) table for the Issues entity within the AS – Sales Foundation product of Oracle E-Business Suite. In Oracle EBS, tables suffixed with _TL exist specifically to support Multi-Language Support (MLS). They store the language-dependent, translatable attributes of a base (non-translated) entity, allowing the same logical record to present different text to users operating under different language settings. The base record itself is held in a corresponding _B or base table (typically AS_ISSUES_B), while AS_ISSUES_TL holds the translated NAME and DESCRIPTION for each supported language.

From a data-vault modeling perspective, the metadata classifies this object heuristically as standalone. This reflects the absence of outbound foreign keys beyond the security group reference and the fact that a translated table is essentially a dependent satellite of its base entity; it carries descriptive, language-scoped context keyed by the parent issue. It should not be treated as an independent hub or link when designing integration or reporting layers.

Key Information Stored

The table is owned by the OSM schema and contains 11 documented columns in the 12.2.2 physical schema. The most significant are:

  • ISSUE_ID – The surrogate/foreign key linking each translation row to its parent issue record in the base table. It forms part of the composite primary key.
  • LANGUAGE – The EBS language code (e.g., US, FR, DE) identifying which translated row applies. It is the second component of the primary key AS_ISSUES_TL_PK (ISSUE_ID, LANGUAGE).
  • NAME – The translated, user-facing name/description of the issue, the primary business-meaningful text attribute.
  • DESCRIPTION – Free-form translated description text associated with the issue.
  • SOURCE_LANG – Indicates the source language of the record, used by MLS tooling to track translation origin.
  • SECURITY_GROUP_ID – Foreign key referencing FND_SECURITY_GROUPS. It enforces multi-tenant security group filtering so that translated rows are visible only to authorized operating units or organizations.
  • Audit columnsLAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, and LAST_UPDATE_LOGIN standardize change tracking and user accountability.

The composite surrogate unique index AS_ISSUES_TL_U1 (ISSUE_ID, LANGUAGE) is the business-key candidate, assuring one translation row per issue per language.

Common Use Cases and Queries

Typical uses include multilingual reporting, integration extracts, and debugging translation gaps where an issue lacks a row for a given language. A join between the base table and its translation is standard:

  • Retrieve translated names for a specific language:
    SELECT b.issue_id, t.name, t.description
    FROM   as_issues_b b
           JOIN as_issues_tl t
             ON t.issue_id = b.issue_id
            AND t.language = USERENV('LANG')
    WHERE  b.security_group_id = :sg_id;
    
  • Find missing translations:
    SELECT b.issue_id
    FROM   as_issues_b b
    WHERE  NOT EXISTS (SELECT 1 FROM as_issues_tl t
                       WHERE t.issue_id = b.issue_id
                       AND t.language = 'FR');
    
  • Reporting: joining to FND_SECURITY_GROUPS to scope output to an organization.
  • Data audit: comparing SOURCE_LANG against LANGUAGE to identify untranslated or inherited rows.

Related Objects

The most significant related objects include:

  • AS_ISSUES_B – The base Issues table holding language-independent columns; joined on ISSUE_ID.
  • FND_SECURITY_GROUPS – Referenced by AS_ISSUES_TL.SECURITY_GROUP_ID; provides security group definitions for row-level access control.
  • FND_LANGUAGES – Supplies language metadata matching the LANGUAGE column values.
  • AS_ISSUES_TL_PK / AS_ISSUES_TL_U1 – Primary and unique indexes enforcing one translation row per issue/language.
  • FND_APPLICATION and MLS-related FND views – Support language resolution and translation utilities.

Because AS_ISSUES_TL is standalone with a single outbound security FK, downstream dependencies are primarily through the parent issue entity rather than direct references.