Search Results resolved_status_reqd_flag

Overview

CSS_DEF_PHASES_VL is a localization (VL) view in the Oracle E-Business Suite CSS — Support product module. It exposes phase definition data used by the Support/Service Request lifecycle, presenting a language-resolved, denormalized projection of the underlying phase definition tables. The view joins a base table (CSS_DEF_PHASES_B) with its translation table (CSS_DEF_PHASES_TL) so that translatable descriptive attributes — the phase NAME and DESCRIPTION — are returned in the session's active language, determined at runtime by USERENV('LANG').

In the 12.1.1 and 12.2.2 EBS releases, the CSS module itself is documented as obsolete ("CSS - Support (obsolete)"). The ETRM metadata explicitly states that the object is Not implemented in this database, meaning that the view is not deployed in every environment and may exist only where legacy Support/Service Request configurations remain. Its intended reporting role, where present, is to provide a stable, translated read interface over the phase definitions that govern the ordered stages of a service request or support workflow. Integration consumers and custom reports can query the view without needing to resolve the B/TL join or the language WHERE clause themselves.

Underlying Base Objects

The view is defined over exactly two documented base tables:

• CSS_DEF_PHASES_B — the base (non-translatable) phase definition table. It carries the surrogate key PHASE_ID, ordering, flags, date-effectivity, WHO audit columns, the fifteen descriptive flexfield (DFF) attribute columns, the DFF CONTEXT, and PHASE_STATUS_OPTION_CODE. It is aliased as B in the view text.
• CSS_DEF_PHASES_TL — the translation table holding the language-specific NAME and DESCRIPTION. It is aliased as T.

The two are joined on the shared key PHASE_ID, with the additional predicate T.LANGUAGE = USERENV('LANG') restricting the translation row to the caller's session language. Because the view is an inner join, a base phase row is returned only when a matching translation row exists for the active language. The view's ROW_ID is derived from B.ROWID, exposing the physical row identifier of the base table row rather than a synthesized key.

Key Columns

• PHASE_ID — primary surrogate key linking the base and translation tables; the identifier used by foreign keys elsewhere in the CSS schema.
• NAME / DESCRIPTION — translated text sourced from CSS_DEF_PHASES_TL in the session language.
• SORT_ORDER — determines the display sequence of phases within a lifecycle.
• OBJECT_VERSION_NUMBER — optimistic locking / concurrency control token.
• CUSTOMER_VIEWABLE_FLAG — indicates whether the phase is visible to external customers (for example in iSupport).
• CLOSED_STATUS_REQD_FLAG / RESOLVED_STATUS_REQD_FLAG — control whether a status transition to Closed or Resolved is mandatory at this phase.
• START_DATE_ACTIVE / END_DATE_ACTIVE — date-effectivity window for the phase definition.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO audit columns.
• PHASE_STATUS_OPTION_CODE — code identifying the status option associated with the phase.
• CONTEXT and ATTRIBUTE1–ATTRIBUTE15 — descriptive flexfield context and segment columns for customer-defined extensions.
• ROW_ID — the base table's ROWID.

Common Use Cases and Queries

Typical uses include building ordered phase listings for support workflow documentation, validating DFF configuration, and joining phase data to service request status history. A representative query lists active phases in session-language order:

• SELECT phase_id, name, sort_order, phase_status_option_code FROM css_def_phases_vl ORDER BY sort_order;
• SELECT phase_id, name FROM css_def_phases_vl WHERE customer_viewable_flag = 'Y' AND SYSDATE BETWEEN start_date_active AND NVL(end_date_active, SYSDATE + 1);
• SELECT phase_id, name, description, attribute1, attribute2 FROM css_def_phases_vl WHERE context = :ctx;

Because the view is documented as not implemented in the reference database and the CSS module is obsolete, developers should verify object existence (for example via ALL_VIEWS) before relying on it, and prefer supported Service/Service Request views in current 12.2.2 environments.