Search Results cz_rules_seq




Overview
Explore in AI Chat

Overview

CZ_RULES_SEQ is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM metadata scheme as an "OTHER" API object. It is a component of the Oracle Configurator and Rules Engine infrastructure, which underpins the configuration of complex, made-to-order, and assemble-to-order products. The package provides the core sequencing and effectivity logic for rules stored in the Configurator rule model. Business users define rules — constraints, compatibility checks, and defaulting logic — within the Configurator, and these rules carry both an evaluation order (sequence) and an effectivity range (date-bounded validity). CZ_RULES_SEQ encapsulates the set-based operations that manipulate that ordering and date-effectivity information programmatically, without requiring the user to edit each rule individually through the Configurator UI.

The package is documented as VALID in the ETRM catalog for both 12.1.1 and 12.2.2. It references only the SYS schema and the STANDARD package in its dependency list, confirming it is a self-contained PL/SQL unit whose business dependencies are resolved at runtime through APPS synonyms rather than through compile-time schema links. No other packages depend on CZ_RULES_SEQ, indicating it sits at the top of its own call hierarchy and is primarily invoked by external callers.

Key Procedures and Functions

ETRM documents four procedures or functions within the package:

  • REMOVEFROMSEQUENCE — Removes one or more rules from their current position in the rule evaluation sequence. This is the inverse of insertion and is used when a rule is retired, superseded, or must be excluded from ordered processing.
  • MOVEINSEQUENCE — Repositions a rule within the sequence, allowing rules to be moved earlier or later in the evaluation order. This supports the business requirement to change precedence without deleting and recreating rules.
  • CHANGEEFFECTIVITY — Alters the effectivity dates associated with a rule, controlling the date range over which the rule is considered active during configuration evaluation.
  • PROPAGATEEFFECTIVITYSETCHANGE — Propagates an effectivity-set change across the affected rules, ensuring that rules belonging to an effectivity set remain consistent after a set-level date or status change is applied.

Together these procedures cover the full lifecycle of sequence and effectivity maintenance for Configurator rules. No parameter lists are documented in the ETRM metadata; parameter signatures should be confirmed against the deployed package specification in the target instance.

Tables Accessed

The package operates against five objects, referenced through APPS synonyms:

  • CZ_RULES — the primary rule repository holding rule definitions, sequence values, and effectivity columns. This is the principal read/write target.
  • CZ_EFFECTIVITY_SETS — defines effectivity sets that group rules sharing common date ranges; consulted and updated by PROPAGATEEFFECTIVITYSETCHANGE.
  • CZ_RULE_FOLDERS — provides the folder organization of rules, relevant when sequence changes affect grouping or presentation.
  • CZ_XFR_RUN_INFOS_S — a sequence-backed staging table for run information, supporting bulk transfer or processing of rule metadata changes.
  • DUAL — used for scalar evaluations and date arithmetic within PL/SQL logic.

Usage Notes

CZ_RULES_SEQ is not documented as being referenced by any other package, so it is typically invoked directly — from Configurator-related forms, from concurrent programs that mass-maintain rules, or from custom PL/SQL that automates rule sequencing and effectivity administration. Typical invocation scenarios include bulk reordering after a rules migration, scheduled effectivity refresh, and corrective scripts that reconcile rule ordering after data loads. Because the package writes to core Configurator tables, callers should wrap invocations in an explicit transaction, validate that the rules belong to the intended model, and test in a cloned environment. Direct modifications bypass the Configurator UI validation layer, so sequence and effectivity integrity checks normally enforced by the application must be considered by the caller.