Search Results okc_rule_groups_v




Overview
Explore in AI Chat

Overview

OKC_RULE_GROUPS_V is a seeded, APPS-owned database view in the Oracle E-Business Suite Contracts Core (OKC) module. It is the translation-enabled (MLS) interface for contract rule groups, exposing both the base language-independent attributes and the language-specific descriptive columns in a single read-only projection. The view is defined over the base table OKC_RULE_GROUPS_B and its translation table OKC_RULE_GROUPS_TL, joined on the shared primary key ID and filtered by the session language. In ETRM 12.1.1 and 12.2.2 the object is registered with status VALID, and it serves as the canonical access point for rule group data referenced by contracts, contract terms, and rule evaluation logic.

Because rule groups govern how clauses, standards, and deviations are resolved during contract authoring, this view is frequently touched by reporting, integration, and customization layers that must read rule group definitions without depending directly on the underlying _B/_TL pair.

Underlying Base Objects

The view is constructed from two documented base objects:

  • OKC_RULE_GROUPS_B (referenced through a synonym) — the base table holding the language-independent rule group definition: identity, type, source code, contract identifiers, hierarchy, and the standard WHO columns plus the 15 developer attribute columns.
  • OKC_RULE_GROUPS_TL (referenced through a synonym) — the translation table supplying language-specific content such as COMMENTS and the SFWT_FLAG value.

The defining query joins RGPB.ID = RGPT.ID and restricts the translation row to RGPT.LANGUAGE = USERENV('LANG'), so the projected translation columns always reflect the language of the calling session. The view exposes no DML of its own; all maintenance occurs against the underlying tables through the standard OKC APIs.

Key Columns

  • ROW_ID — the ROWID of the base table row, useful for direct-row addressing in EBS forms and existing customizations.
  • ID — primary key of the rule group and the join key between the base and translation tables.
  • OBJECT_VERSION_NUMBER — optimistic locking column used by the Contracts APIs to detect concurrent updates.
  • RGP_TYPE — classifies the rule group, distinguishing the functional role of the group in rule processing.
  • SFWT_FLAG — flag sourced from the translation table (OKC_RULE_GROUPS_TL).
  • RGD_CODE and SAT_CODE — rule group definition code and associated rule/standard code driving rule resolution.
  • CLE_ID, CHR_ID, DNZ_CHR_ID — identifiers of the contract, contract line, and "don't change" contract relationships the group is attached to.
  • PARENT_RGP_ID — self-referencing parent pointer establishing the rule group hierarchy.
  • COMMENTS — translated descriptive text from OKC_RULE_GROUPS_TL.
  • ATTRIBUTE_CATEGORY through ATTRIBUTE15 — the standard DFF (descriptive flexfield) columns available for customer extension.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO audit columns.

Common Use Cases and Queries

Typical scenarios include diagnosing how a contract's rule groups are wired, exporting rule group definitions for reconciliation, and joining rule groups to their associated contract identifiers for reporting. A representative query retrieves all rule groups for a specific contract:

  • SELECT id, rgp_type, rgd_code, sat_code, comments FROM okc_rule_groups_v WHERE chr_id = :p_chr_id;
  • SELECT id, rgp_type, rgd_code, parent_rgp_id FROM okc_rule_groups_v WHERE cle_id = :p_cle_id ORDER BY parent_rgp_id;
  • SELECT COUNT(*) FROM okc_rule_groups_v WHERE dnz_chr_id = :p_chr_id;

Because the view filters on USERENV('LANG'), results depend on the language of the connected session; customers querying outside a form session should set the environment consistently. For multi-language reporting that must show all translations rather than one language, the base tables OKC_RULE_GROUPS_B and OKC_RULE_GROUPS_TL should be queried directly. As with all seeded Contracts objects, the view definition should be treated as Oracle-owned and not modified; extensions belong in the DFF attribute columns.