Search Results pay_payment_types_tl_n2

Overview

HR.PAY_PAYMENT_TYPES_TL is the translated (TL) companion table to HR.PAY_PAYMENT_TYPES in Oracle E-Business Suite. It stores the language-specific presentation layer for payment type definitions — the descriptive name and description text that users see when the application renders a payment type in a given language. Because payment types are seeded reference data consumed across Payroll, Payments, and HR self-service flows, the TL table exists so that the same underlying PAYMENT_TYPE_ID can be surfaced with locale-appropriate wording without duplicating the base definition.

In Oracle EBS 12.1.1 and 12.2.2, the table resides in the APPS_TS_SEED tablespace, consistent with its role as seed/reference data rather than transactional data. The ETRM metadata classifies the object heuristically as standalone in Data Vault terms — that is, it does not behave as a classic hub, link, or satellite because it carries no foreign-key dependencies outward to other business entities. In a Data Vault model, the base PAY_PAYMENT_TYPES table would typically be treated as a hub (keyed by PAYMENT_TYPE_ID), and this TL table would function as a multi-active satellite keyed by PAYMENT_TYPE_ID and LANGUAGE. Treat this as a modeling suggestion rather than a documented constraint, since the ETRM dependency section explicitly states the table does not reference other database objects.

Key Information Stored

The table has eleven documented columns. The most operationally significant are the following.

• PAYMENT_TYPE_ID (NUMBER) — System-generated primary key inherited from PAY_PAYMENT_TYPES. It is the join spine back to the base definition.
• LANGUAGE (VARCHAR2) — The language of the translated row. Together with PAYMENT_TYPE_ID it forms the composite surrogate key.
• PAYMENT_TYPE_NAME (VARCHAR2, 80) — The translated display name of the payment type.
• DESCRIPTION (VARCHAR2, 80) — The translated description shown to end users.
• SOURCE_LANG (VARCHAR2) — The source language from which the translation was derived.
• ZD_EDITION_NAME — Editioning column used in 12.2.x for online patching and edition-based redefinition.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE — Standard WHO audit columns tracking creation and modification of each translated row.

The documented unique index PAY_PAYMENT_TYPES_TL_PK enforces uniqueness across PAYMENT_TYPE_ID, LANGUAGE, and (in the 12.2.2 physical schema) ZD_EDITION_NAME. A secondary non-unique index, PAY_PAYMENT_TYPES_TL_N2, covers LANGUAGE and PAYMENT_TYPE_NAME, supporting language-filtered name searches. No other business-key candidate is documented beyond the primary key.

Common Use Cases and Queries

The most common access pattern is a join from the base table to this TL table filtered by the session or reporting language, so that payment type names appear in the correct locale. A typical reporting query is:

SELECT p.payment_type_id, t.payment_type_name, t.description
FROM hr.pay_payment_types p, hr.pay_payment_types_tl t
WHERE p.payment_type_id = t.payment_type_id
AND t.language = USERENV('LANG');

Other practical scenarios include: auditing which languages a given payment type has been translated into; detecting missing translations by comparing the base table against the TL table for a target language; and building bilingual lookup extracts for interfaces or conversions. The truncated query text supplied with the ETRM documentation supports straightforward full-table reads by PAYMENT_TYPE_ID, name, description, language, and the WHO columns. Because the table lives in a seed tablespace, it is generally read-only at runtime and should not be written to outside of supported patching or translation-loading processes.

Related Objects

• HR.PAY_PAYMENT_TYPES — The base (non-translated) payment type definition table. Joined on PAYMENT_TYPE_ID; supplies the language-independent attributes and is the parent of the TL row.
• APPS.PAY_PAYMENT_TYPES_TL — The APPS-layer synonym/view over the HR-owned table, used by application code and reports.
• PAY_PAYMENT_TYPES_TL041450_WHO — A WHO (audit) trigger object in the APPS layer that populates the standard WHO columns on insert and update.
• PUBLIC.PAY_PAYMENT_TYPES_TL — Public synonym exposing the object to non-APPS schemas.
• FND_USER — Referenced by LAST_UPDATED_BY and CREATED_BY for user attribution.
• FND_LOGINS — Referenced by LAST_UPDATE_LOGIN for session-level audit tracing.

Collectively these dependencies confirm the table is a leaf-level translation store: it consumes the base payment type key and is consumed by application synonyms, triggers, and reporting joins, but defines no outgoing foreign keys of its own.