Results for “so_agreements_tl”

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

Overview

SO_AGREEMENTS_TL is the translation (language) table for the Oracle Order Entry agreements base table, SO_AGREEMENTS_B. In Oracle EBS 12.1.1 and 12.2.2, Order Entry stores user-facing, translatable text such as agreement names in dedicated _TL tables that are keyed by the base table's primary key plus a LANGUAGE column. The base table SO_AGREEMENTS_B holds the language-independent attributes, while SO_AGREEMENTS_TL stores the translated NAME value for each installed or defined language. This separation supports Oracle's Multilingual Support (MLS) architecture, allowing each user to view agreement descriptions in their own session language without duplicating the transactional agreement record.

The table resides in the OE (Order Entry) schema with a status of VALID. From a data-modeling perspective, the mined relationship metadata classifies this object heuristically as a standalone entity, meaning the foreign key structure does not place it rigidly inside a hub/link/satellite chain. Where a Data Vault style model is desired, it is perhaps most naturally modeled as a satellite of the SO_AGREEMENTS_B hub, since it stores descriptive, language-dependent attributes that are functionally dependent on the agreement identifier.

Key Information Stored

The table contains nine documented columns. The most important are:

• AGREEMENT_ID — Surrogate identifier linking the translation row to its parent agreement in SO_AGREEMENTS_B; part of the composite primary key.
• LANGUAGE — The language code for the translation; the second component of the primary key.
• NAME — The translated agreement name. This is the principal translatable business attribute and forms the unique business key in combination with LANGUAGE.
• SOURCE_LANG — Indicates the source language from which the translation originated, used by the MLS framework to track translation provenance.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — Standard Oracle audit columns recording who created and last modified the row and when.

The primary key is SO_AGREEMENTS_TL_PK (AGREEMENT_ID, LANGUAGE), while SO_AGREEMENTS_TL_UK1 (NAME, LANGUAGE) enforces uniqueness of the translated name within a language. The distinction is significant: AGREEMENT_ID plus LANGUAGE is the surrogate/technical identity, whereas NAME plus LANGUAGE is the business-key candidate used to prevent duplicate agreement names in the same language.

Common Use Cases and Queries

Typical uses include building multilingual agreement listings, ensuring that name uniqueness is enforced per language, and joining translated content to base agreement records for reporting. Retrieving a translated agreement name for a specific agreement and session language follows a standard pattern:

• SELECT t.name, b.agreement_id FROM oe.so_agreements_tl t, oe.so_agreements_b b WHERE t.agreement_id = b.agreement_id AND t.language = USERENV('LANG') AND b.agreement_id = :agreement_id; — resolves the display name for a single agreement.
• SELECT agreement_id, language, name FROM oe.so_agreements_tl WHERE language = 'US' ORDER BY name; — reports all agreement names in a specific language.
• SELECT name, COUNT(*) FROM oe.so_agreements_tl GROUP BY name, language HAVING COUNT(*) > 1; — a data-quality check against the SO_AGREEMENTS_TL_UK1 uniqueness rule.

Because the table is a translation table, reporting queries should always filter on LANGUAGE; omitting it returns one row per installed language and can inflate row counts in aggregations.

Related Objects

The most significant related objects are:

• SO_AGREEMENTS_B — The base table; joined on AGREEMENT_ID. It is the parent of every translation row.
• SO_AGREEMENTS_TL_PK — The primary key constraint (AGREEMENT_ID, LANGUAGE) enforcing row identity.
• SO_AGREEMENTS_TL_UK1 — The unique index (NAME, LANGUAGE) enforcing per-language name uniqueness.
• SO_AGREEMENTS_VL — The MLS view that joins base and translation tables to present the session-language view of agreements.
• Order Entry agreement APIs and forms — User interfaces and programmatic interfaces that read and write agreement names, relying on this table for translated display text.

Maintenance should be performed through the supported Order Entry forms or APIs rather than direct DML, since the MLS framework maintains the base and translation rows in tandem.