Search Results oe_agreements_tl_pk

Overview

OE_AGREEMENTS_TL is a translation (TL) table owned by the QP schema in Oracle E-Business Suite, operating within the Advanced Pricing module. Its specific purpose is to store the translatable attributes of an agreement record — principally the agreement name — in every language installed in the database. In Oracle's MLS (Multi-Language Support) architecture, a base table holds language-independent data, while its companion _TL table holds language-dependent text keyed by language code. Here, the base table is OE_AGREEMENTS_B (or its equivalent), and OE_AGREEMENTS_TL supplies the human-readable name for each agreement in each supported language.

The table is documented as VALID in both 12.1.1 and 12.2.2, with an 11-column physical schema. From a heuristic Data Vault perspective, the structure suggests a satellite classification: the table carries a composite key plus descriptive, non-key attributes (NAME, REVISION, AGREEMENT_SOURCE_CODE) and standard audit columns, which is characteristic of a satellite attached to an agreement hub rather than a link or hub itself.

Key Information Stored

• AGREEMENT_ID — surrogate foreign key referencing the parent agreement in the base table; part of the composite primary key.
• LANGUAGE — the language code (e.g., US, FR, DE) in which the NAME is expressed; the second component of the primary key.
• SOURCE_LANG — the source (base) language of the installation, indicating the originating language of the seeded text.
• NAME — the translatable agreement name; the primary business-visible column this table exists to hold.
• REVISION — the revision identifier associated with the named agreement.
• AGREEMENT_SOURCE_CODE — the code denoting the source or origin of the agreement.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard EBS audit columns tracking who created and last modified each translated row and when.

The surrogate primary key is OE_AGREEMENTS_TL_PK on (AGREEMENT_ID, LANGUAGE). Two unique indexes act as business-key candidates: OE_AGREEMENTS_TL_U1 on (AGREEMENT_ID, LANGUAGE) and OE_AGREEMENTS_TL_U2 on (NAME, AGREEMENT_SOURCE_CODE, REVISION, LANGUAGE), which enforces uniqueness of the business identifier per language.

Common Use Cases and Queries

A frequent reporting requirement is retrieving the agreement name for the session's language, joining the translation table to the base agreement table:

• Single-language lookup: SELECT t.name FROM oe_agreements_tl t WHERE t.agreement_id = :id AND t.language = USERENV('LANG');
• Multi-language comparison: selecting NAME across all LANGUAGE values for a given AGREEMENT_ID to audit translations.
• Duplicate/naming checks: querying OE_AGREEMENTS_TL_U2 columns to identify name collisions within a language.
• Audit reporting: filtering on LAST_UPDATE_DATE and LAST_UPDATED_BY to track translation maintenance activity.

These queries support pricing agreement reports, order-to-cash analytics, and localization validation dashboards.

Related Objects

• OE_AGREEMENTS_B / OE_AGREEMENTS — the base agreement tables joined on AGREEMENT_ID.
• OE_AGREEMENTS_TL_PK / U1 / U2 indexes — enforce key and business-key integrity.
• QP pricing entities (e.g., price lists, modifiers) that reference agreements via AGREEMENT_ID.
• FND_LANGUAGES — joined on LANGUAGE to resolve language descriptions.
• FND_USER — joined on LAST_UPDATED_BY/CREATED_BY for audit attribution.

Because the Data Vault classification is standalone, the table depends primarily on its base agreement parent rather than forming direct FK links to other translation entities.