Search Results css_def_statuses_tl_pk

Overview

CSS_DEF_STATUSES_TL is the translation table for Reasons (Phase Statuses) within the Oracle E-Business Suite CSS (Support) product family. In the EBS data model, a base table such as CSS_DEF_STATUSES stores the language-independent definition of status codes used to describe reason or phase-status values, while the corresponding _TL table stores the language-dependent, translatable text associated with each of those records. This separation allows the same underlying status identifier to carry a different display name or description in each installed language, which is the standard multi-language pattern used throughout EBS for reference and lookup data.

The ETRM metadata classifies this object's data vault role heuristically as standalone. In modeling terms, this suggests the table functions as an independent reference or lookup structure rather than participating as a transactional hub or a junction link. It carries its own composite primary key and does not appear, in the documented relationship data, to be the child side of foreign key relationships. That classification is a heuristic derived from foreign key structure and should be treated as a modeling suggestion rather than a definitive architectural statement.

An important qualification from the ETRM metadata is that CSS_DEF_STATUSES_TL is not implemented in this database. The product is also flagged as CSS - Support (Obsolete). These two facts mean the table may exist only in certain historical or partially installed environments, and its presence should be verified against the actual database before any development or reporting work depends on it.

Key Information Stored

The documented metadata identifies the primary key and the minimum set of identifying columns. The most significant columns are:

• STATUS_ID — The surrogate identifier for the status or reason record. In the base table this value is unique; in the translation table it repeats once for each language, and it is the join column back to the base definition table.
• LANGUAGE — The NLS language code identifying which translation row is being stored. Combined with STATUS_ID, it forms the composite primary key and is the discriminator that makes the _TL table language-dependent.

Because the documented metadata does not enumerate additional columns, the exact translatable attributes (for example a NAME or DESCRIPTION column) are not confirmed here and should be confirmed by describing the table in an environment where it is implemented. The primary key CSS_DEF_STATUSES_TL_PK (STATUS_ID, LANGUAGE) is the surrogate/technical key for this table; the underlying STATUS_ID is the business-identifying candidate inherited from the base definition table. LANGUAGE itself is not a business key but a technical discriminator required for the multilingual design.

Common Use Cases and Queries

The primary use case is retrieving the translated display text for a status identifier in a specific language, typically so that forms, reports, or interfaces present users with the correct localized value. A typical query joins the translation table to its base table and filters on the current session language.

• Look up the translated name for a single status: SELECT status_id, language FROM css_def_statuses_tl WHERE status_id = :p_id AND language = USERENV('LANG');
• List all available translations for a status to support multi-language reporting or translation maintenance.
• Validate that a status has a translation in every installed language, which is a common data-quality check for multilingual reference data.
• Join to the base table to produce lookup views that expose the code alongside its translated description.

Because the table is documented as not implemented and its product is obsolete, any query should be preceded by an existence check, and it should not be treated as a dependable source for new development.

Related Objects

The documented relationship data classifies this object as standalone, so no foreign key relationships are confirmed. The significant related objects, based on the standard EBS translation pattern, are:

• CSS_DEF_STATUSES — the base (language-independent) definition table, joined on STATUS_ID = STATUS_ID; this is the primary parent object.
• CSS_DEF_STATUSES_TL primary key constraint CSS_DEF_STATUSES_TL_PK, which enforces uniqueness on (STATUS_ID, LANGUAGE).

Additional dependent views, lookup APIs, or reporting objects may exist in environments where the CSS Support product is installed, but none are documented in the ETRM metadata provided; these should be identified through the data dictionary. Because no foreign key relationships are documented and the product is obsolete, downstream dependencies are expected to be minimal and should be verified locally.