Results for “date_active”

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

Overview

OKS_EVENTS_V is a reporting and integration view owned by the APPS schema within the Service Contracts (OKS) module of Oracle E-Business Suite 12.1.1 and 12.2.2. Despite its name, which suggests a transactional events entity, the view is defined over the condition header tables that store the definitions of Service Contracts conditions — the configurable rules and event triggers that drive contract behavior such as billing schedules, renewal logic, and entitlement evaluation. The view therefore presents a denormalized, language-resolved list of condition headers rather than individual runtime event occurrences.

OKS_EVENTS_V serves as a stable read-only interface for forms, concurrent programs, and external integrations that need to enumerate condition definitions without joining the base and translation tables directly. Because it resolves the multilingual translation through USERENV('LANG'), it returns names and descriptions in the session's current language, which simplifies localization of reports and interfaces.

Underlying Base Objects

The view is documented in ETRM 12.2.2 as being defined over two synonyms, OKC_CONDITION_HEADERS_B and OKC_CONDITION_HEADERS_TL, both resolving to the corresponding APPS base tables:

• OKC_CONDITION_HEADERS_B — the base (non-translated) table holding the primary key, counter group reference, effective dates, condition header type, and the one-time and template flags.
• OKC_CONDITION_HEADERS_TL — the translation table holding NAME and DESCRIPTION keyed by ID and LANGUAGE.

The two are joined on ID, with the translation restricted to the session language via CNHT.LANGUAGE = USERENV('LANG'). The view is a simple inner join, so a condition header without a translation row in the current language will not appear in the result set. No WHERE clause beyond the language predicate is applied, and no DISTINCT or aggregation is performed.

Key Columns

• ID — Primary key of the condition header; the join key between the base and translation tables and the identifier referenced by child condition lines and contract condition assignments.
• COUNTER_GROUP_ID — Identifier of the counter group to which the condition belongs, grouping related condition headers for numbering or sequencing purposes.
• NAME — Translated condition name, sourced from OKC_CONDITION_HEADERS_TL in the session language.
• DESCRIPTION — Translated long description of the condition.
• ONE_TIME_YN — Flag indicating whether the condition is applied only once rather than repeatedly over the contract life.
• DATE_ACTIVE / DATE_INACTIVE — Effective date range governing when the condition definition is valid.
• CNH_TYPE — Condition header type, classifying the condition (for example, by the kind of rule or event it represents).
• TEMPLATE_YN — Flag identifying whether the record is a reusable template rather than a concrete condition.

Common Use Cases and Queries

Typical scenarios include populating LOVs in custom forms for condition selection, extracting condition definitions for data warehousing, and filtering active templates for contract authoring. A representative query listing all active, non-template conditions in the current language follows:

• SELECT id, name, description, cnh_type, date_active, date_inactive
• FROM apps.oks_events_v
• WHERE template_yn = 'N'
• AND SYSDATE BETWEEN date_active AND NVL(date_inactive, SYSDATE);

To retrieve only reusable templates, filter on template_yn = 'Y'. To locate the condition associated with a known counter group, add WHERE counter_group_id = :group_id. Because the view performs no filtering of obsolete rows, consumers should always apply date-range or flag predicates appropriate to their requirement. Note that records lacking a translation row in USERENV('LANG') are silently excluded, so integrations requiring all conditions regardless of language should query OKC_CONDITION_HEADERS_B directly.