Search Results ff_formulas_f_tl_pk




Overview
Explore in AI Chat

Overview

FF_FORMULAS_F_TL is the translation (TL) table for Oracle Fast Formula definitions in Oracle E-Business Suite 12.1.1 and 12.2.2. It is owned by the HR schema and belongs to the PAY (Payroll) product family. As a translated table, it stores the language-dependent attributes of a formula — specifically the formula name and its descriptive text — for each installed language, while the language-independent structural attributes of the formula reside in the corresponding base table, FF_FORMULAS_F. This separation follows the standard Oracle EBS MLS (Multi-Lingual Support) design pattern, in which a base table holds the primary record and one or more "_TL" tables hold translatable text keyed by language.

In data-vault terms, the heuristic classification mined from the foreign-key structure is standalone, with no dependent relationships captured. A reasonable modeling suggestion is to treat FF_FORMULAS_F_TL as a satellite of the formula hub represented by FF_FORMULAS_F, where the hub key is FORMULA_ID and the satellite carries language-qualified descriptive attributes. Because it holds no downstream references itself, it should generally be loaded and joined last.

Key Information Stored

The documented physical schema in ETRM 12.2.2 shows eleven columns. The most significant are:

  • FORMULA_ID — the surrogate identifier linking each translation row back to the owning formula record in the base table. This is the principal join key.
  • LANGUAGE — the language code identifying which locale the translated text applies to.
  • SOURCE_LANG — the language from which the translated text was derived, used by the MLS translation framework.
  • FORMULA_NAME — the translated, user-facing name of the formula as displayed in the relevant language.
  • DESCRIPTION — the translated long description of the formula's purpose and behavior.
  • ZD_EDITION_NAME — the editioning column introduced by the Online Patching (ADOP) architecture in 12.2, used to isolate rows by patch edition.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE — standard WHO audit columns recording row creation and last modification.

Two key definitions are documented. The primary key constraint FF_FORMULAS_F_TL_PK is listed in one place as (FORMULA_ID, FORMULA_NAME) and, in the documented physical schema, as the unique index (FORMULA_ID, LANGUAGE, ZD_EDITION_NAME). The latter represents the true business-key candidate: a formula identifier combined with a language and, under 12.2 editioning, an edition marker. Any query intending to return a single translated row should therefore constrain FORMULA_ID and LANGUAGE together.

Common Use Cases and Queries

Typical usage centers on resolving a formula's display name and description in a specific language for reporting, data extraction, or troubleshooting. A representative pattern joins the translation table to the base table on FORMULA_ID while filtering by LANGUAGE:

  • Listing all formula names in a chosen language for a payroll configuration report.
  • Verifying that a translation exists for every formula, exposing missing-language gaps for localization projects.
  • Comparing SOURCE_LANG against LANGUAGE to identify rows pending retranslation after a base-text change.
  • Auditing formula descriptions before a patch or upgrade, using the audit columns to determine recency.

A common SQL shape is a join between FF_FORMULAS_F and FF_FORMULAS_F_TL on FORMULA_ID, with a WHERE clause such as LANGUAGE = 'US' (or the relevant NLS language code) to return the translated FORMULA_NAME and DESCRIPTION. Under 12.2, reporting queries should be aware of ZD_EDITION_NAME so that rows from a non-run edition are not inadvertently returned.

Related Objects

The most significant related objects, based on documented join keys and the Fast Formula data model, include:

  • FF_FORMULAS_F — the base, language-independent formula table; joined on FORMULA_ID. This is the primary parent of the TL row.
  • FF_FORMULAS_VL — the MLS view that joins FF_FORMULAS_F to FF_FORMULAS_F_TL and presents the translated name and description transparently; it is the preferred access path for most queries.
  • FF_FORMULAS_B — the base view counterpart used in the MLS stack.
  • FF_FORMULA_TYPES — classifies formulas referenced through FORMULA_ID.
  • FF_FORMULA_FUNCTIONS and FF_FORMULA_CONTEXTS — define callable functions and context dependencies of the formula identified by FORMULA_ID.
  • FF_COMPILED_FORMULAS — stores compiled formula text associated with the same FORMULA_ID.
  • FF_ROUTES and FF_ROUTE_ROUTING_RULES — reference formulas through the same identifier in payroll processing configurations.

Because FF_FORMULAS_F_TL carries no outgoing foreign keys, all of these objects relate through the shared FORMULA_ID, making it a straightforward descriptive satellite within the Fast Formula model.