Results for “pa_fin_plan_types_tl”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PA_FIN_PLAN_TYPES_TL is a translation (TL) table in the Oracle Projects (PA) schema. It stores the language-specific, user-facing text for financial plan types—specifically the plan type NAME and DESCRIPTION presented to end users in their chosen session language. In Oracle EBS 12.1.1 and 12.2.2 the projects module exposes several financial plan structures (for example budgets, forecasts, and resource plans), and each is registered once in a base table and translated across every installed language. This table is the translated half of that pair.

Its defining characteristic is language context: multiple rows may exist for the same FIN_PLAN_TYPE_ID, one per LANGUAGE, plus a ZD_EDITION_NAME qualifier used by the EBS language/edition substrate. The table therefore never defines a plan type on its own; it enriches it with localized strings. The documented foreign key to PA_FIN_PLAN_TYPES_B (on FIN_PLAN_TYPE_ID) establishes the parent-child integrity: every translation row must resolve to a valid base row.

From a heuristic Data Vault modeling perspective, the FK and unique-index structure suggests this object is satellite-leaning: it carries descriptive, language-dependent attributes (NAME, DESCRIPTION) keyed to a parent business entity rather than introducing relationships of its own. It behaves like a descriptive satellite hanging off the plan-type base, with LANGUAGE acting as a natural sub-key.

Key Information Stored

The documented schema exposes eleven columns; the most consequential are:

• FIN_PLAN_TYPE_ID — the surrogate/foreign key linking each translation to its parent plan type in PA_FIN_PLAN_TYPES_B. This is not a standalone primary key; it is the join spine.
• NAME — the translated display name of the financial plan type. NAME is also a business-key candidate, unique per language.
• DESCRIPTION — the translated long description shown in setup and inquiry screens.
• LANGUAGE — the NLS language code identifying which language this row serves.
• SOURCE_LANG — the source language from which the translation was derived, supporting the standard EBS TL seeding model.
• ZD_EDITION_NAME — the edition qualifier used by the EBS translation architecture; it participates in both unique indexes.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard WHO audit columns used for concurrency, audit trails, and OAF/Forms-based change tracking.

Two unique indexes are documented. PA_FIN_PLAN_TYPES_TL_U1 (FIN_PLAN_TYPE_ID, LANGUAGE, ZD_EDITION_NAME) guarantees a single translation row per plan type per language per edition—the true business-key candidate. PA_FIN_PLAN_TYPES_TL_U2 (NAME, LANGUAGE, ZD_EDITION_NAME) enforces that a display name is unique within a language, preventing duplicate labels. There is no independent surrogate primary key beyond these composite unique constraints and the FK.

Common Use Cases and Queries

Reporting on project plan-type configuration frequently requires joining the translated name to transactional or setup data so end users see localized labels. A typical pattern resolves the correct language by joining on both FIN_PLAN_TYPE_ID and a LANGUAGE predicate, or by using the NLS view that filters on SYS_CONTEXT('USERENV','LANG'):

• List plan types in session language: SELECT b.fin_plan_type_id, t.name, t.description FROM pa_fin_plan_types_b b, pa_fin_plan_types_tl t WHERE t.fin_plan_type_id = b.fin_plan_type_id AND t.language = USERENV('LANG');
• Identify missing translations: outer-join TL to B and flag rows where a required language is absent, supporting globalization remediation.
• Duplicate label detection: query against U2 to confirm no two plan types share a name within a language.
• Setup and audit reports: extract NAME/DESCRIPTION alongside WHO columns to document who created or changed a plan-type label and when.

Because the table is small but referenced by setup screens and budget/forecast configuration flows, it is commonly joined in discovery queries and BLT (business language testing) validation for multilingual implementations.

Related Objects

• PA_FIN_PLAN_TYPES_B — the base table; joined on FIN_PLAN_TYPE_ID. This is the direct parent and the required join partner for any meaningful query.
• PA_FIN_PLAN_TYPES_VL / _V — the language views that combine B and TL, resolving LANGUAGE automatically for OAF and Forms.
• PA_FIN_PLAN_VERSIONS / plan-version tables — plan versions reference a financial plan type; reporting joins through the B/TL pair to display the localized plan-type name.
• PA_BUDGET_TYPES / forecast setup objects — configuration screens that present financial plan types rely on this translation for user-facing labels.
• FND_LANGUAGES — provides the valid LANGUAGE codes used in the NLS predicate.

In practice, PA_FIN_PLAN_TYPES_TL should be treated as the localization layer for the financial plan type definition, queried almost exclusively in conjunction with PA_FIN_PLAN_TYPES_B and the associated language views.