Results for “priority_name”

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

Overview

OKE_PRIORITY_CODES_TL is the multi-lingual (translation) table for contract priority rating codes in the Oracle E-Business Suite Project Contracts (OKE) module. Priority codes assign a ranking or urgency classification to contracts, and this table stores the language-specific descriptive text — the priority name and an extended description — associated with each priority code. It is a child of the base OKE_PRIORITY_CODES_B table (which holds the language-independent attributes) and is organized under the Oracle Projects/Contracts translation pattern common throughout EBS.

The parent-child relationship ensures the priority code itself remains a stable, language-neutral identifier while the display text varies by installed language. Oracle EBS ships seeded priority codes (for example, a standard set of rating values), and customers may add their own using the Contracts setup user interface.

Under the heuristic Data Vault classification mined from the FK structure, this object is classified as standalone. A Data Vault modeler would typically suggest treating it as a satellite attached to the base priority code hub, since it carries descriptive, language-dependent attributes keyed by the business identifier. Note this classification is heuristic and not a definitive design directive.

Key Information Stored

All ten documented columns are identified below.

• PRIORITY_CODE — the business code identifying the priority rating. Part of the composite primary key and the unique index on the base table relationship.
• LANGUAGE — the language code indicating which translated row applies. It is the second component of the primary key and of both unique indexes.
• PRIORITY_NAME — the translated, user-visible name of the priority code. This is the most frequently queried column on this table and is a business-key candidate (see unique index below).
• DESCRIPTION — a translated longer description providing supplemental detail about the priority rating.
• SOURCE_LANG — the source language of the translation, used to identify the original text when multiple installations are present.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard EBS WHO (audit) columns capturing row creation and modification metadata.

The surrogate/technical primary key is OKE_PRIORITY_CODES_TL_PK (PRIORITY_CODE, LANGUAGE). Unique index candidates for the business key are OKE_PRIORITY_CODES_TL_U1 (PRIORITY_CODE, LANGUAGE) and OKE_PRIORITY_CODES_TL_U2 (PRIORITY_NAME, LANGUAGE). The latter guarantees that a priority name is unique within a given language, which is a meaningful business constraint on the priority name.

Common Use Cases and Queries

Typical uses include LOV and list-of-values population for contract entry forms, priority lookup in contract reporting, and multilingual display. A translation-aware query in the current session language:

• SELECT priority_code, priority_name, description
• FROM oke_priority_codes_tl
• WHERE language = USERENV('LANG')
• ORDER BY priority_name;

Searching by name (the term priority_name was your search) uses the unique index U2 to resolve a name back to its code:

• SELECT priority_code FROM oke_priority_codes_tl WHERE priority_name = :name AND language = :lang;

Joining to the base table returns the untranslated attributes alongside the localized text, enabling priority-based sorting and filtering in contract reports.

Related Objects

• OKE_PRIORITY_CODES_B — base table joined on PRIORITY_CODE, holds language-independent attributes.
• OKE_CONTRACTS / OKE_CONTRACTS_ALL — contracts referencing a priority code, joined on the priority code column.
• OKE_PRIORITY_CODES_VL — the translation-view object if defined, surfaced for form runtime access.
• OKE_PRIORITY_CODES_TL_PK / U1 / U2 — PK and unique indexes enforcing code/name uniqueness.
• FND_LANGUAGES — provides valid LANGUAGE values.
• OKE_SETUP — the contracts setup form that maintains priority codes and their translations.

Because the object is standalone by Data Vault heuristic, no other hub or link relationships are documented beyond the base/translation pairing.