Search Results optional_yn




Overview
Explore in AI Chat

Overview

OKC_RG_DEF_RULES_V is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the OKC – Contracts Core product. The view presents a denormalized, read-oriented projection of contract rule-group definition data, exposing the columns of the underlying OKC_RG_DEF_RULES entity through a stable, externally addressable interface. Its status is recorded as VALID in both the 12.1.1 and 12.2.2 releases, and it carries no business logic or transformation beyond column aliasing: the view text selects each column of the base table directly and renames the driving table alias RGRB to ROW_ID via ROWID. The object is therefore best understood as a thin, versioned API surface rather than a computational view.

Because the view mirrors the base table one-for-one, it allows external reports, concurrent programs, and integration extracts to reference rule definitions without depending on physical storage details or internal naming conventions. This separation is significant in EBS, where base tables are periodically reorganized and where supported read paths are expected to flow through documented views. The user search term optional_yn corresponds directly to one of the exposed columns, indicating that the view is frequently accessed to determine whether a given rule definition is mandatory or discretionary during contract authoring.

Underlying Base Objects

The view is defined over a single referenced base object, documented as OKC_RG_DEF_RULES, exposed to the APPS schema through a SYNONYM. The view definition uses the alias RGRB for that object and performs no joins, unions, or outer-query aggregation. Consequently, row counts, cardinality, and filtering semantics between the view and the base table are identical. The relationship is strictly one-to-one: every row in OKC_RG_DEF_RULES surfaces as exactly one row in OKC_RG_DEF_RULES_V, and ROW_ID is derived from the physical ROWID of the base row. Because there is no WHERE clause in the documented view text, no rows are suppressed; callers must apply their own filtering for product, application, or rule-group context.

Key Columns

The view exposes sixteen columns. The principal identifiers and attributes are as follows:

  • ROW_ID – the base table ROWID, used as a surrogate unique identifier for the definition row.
  • RGD_CODE – the rule-group definition code, the primary business key identifying the rule group to which the rule belongs.
  • RDF_CODE – the rule definition code identifying the specific rule within the group.
  • OPTIONAL_YN – flag indicating whether the rule is optional (Y) or mandatory (N) for the associated rule group; this is the column most commonly queried by users searching the view.
  • MIN_CARDINALITY and MAX_CARDINALITY – lower and upper bounds governing how many times the rule may be satisfied.
  • PRICING_RELATED_YN – indicates whether the rule participates in pricing behavior.
  • ACCESS_LEVEL – controls the visibility or authorization tier of the rule definition.
  • OBJECT_VERSION_NUMBER – optimistic locking version used by the Contracts framework to detect concurrent updates.
  • APPLICATION_ID – the owning application identifier for multi-application deployments.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – standard EBS WHO-column audit attributes.

Common Use Cases and Queries

The view is typically queried by extensions, custom reports, and diagnostic scripts that must enumerate rule definitions without touching the base table. A representative query retrieves optional rules for a given rule group:

SELECT rgd_code, rdf_code, optional_yn, min_cardinality, max_cardinality
FROM apps.okc_rg_def_rules_v
WHERE optional_yn = 'Y'
ORDER BY rgd_code, rdf_code;

Because OPTIONAL_YN is stored as a single-character flag, predicates should use literal 'Y' or 'N' rather than numeric equivalents. For a complete inventory of a rule group, callers join the view to contract rule-group headers using RGD_CODE, applying the appropriate ACCESS_LEVEL filter to respect security constraints. Reporting on PRICING_RELATED_YN supports pricing-rule audits, while MIN_CARDINALITY and MAX_CARDINALITY drive validation logic in contract templates. Auditors frequently extract CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, and LAST_UPDATE_DATE to reconstruct the change history of rule configuration, and OBJECT_VERSION_NUMBER is read to confirm that a cached rule set remains current before commit.

Oracle Proprietary, Confidential Information.