Search Results epoch_end

Overview

APPS.CZ_RULES_SEQ is a server-side PL/SQL package body belonging to the Oracle E-Business Suite Configuration Management (CZ) schema family, which underpins the Enterprise Technical Reference Model (ETRM) and related configuration rule infrastructure in release 12.1.1 and 12.2.2. Its primary business function is to maintain the ordering, sequence, and effective dating of configuration rules and rule folders stored in the CZ schema. The package provides controlled operations for removing a rule from a sequence, moving a rule within a sequence, and altering the effectivity window of rules and effectivity sets, including the propagation of effectivity changes across dependent rule definitions.

The package header declares package-level globals including GLOBAL_RUN_ID, EPOCH_BEGIN, and EPOCH_END. The EPOCH_END literal is initialized from CZ_UTILS.EPOCH_END_, which is the canonical sentinel date used throughout the CZ schema to represent an open-ended or "infinite" effectivity range. An epoch end of the sentinel value (typically 31-DEC-4712 or an equivalent CZ_UTILS constant) indicates that the rule or effectivity set has no defined expiration and remains active indefinitely. Utility routines such as LOG_REPORT and overloaded FND_REPORT procedures in the body wrap CZ_UTILS.LOG_REPORT and CZ_UTILS.GET_TEXT to emit standardized diagnostic messages and translated report text to the concurrent manager log or to the caller's run context.

Key Procedures and Functions

• REMOVEFROMSEQUENCE — Removes a specified rule from its parent sequence within a rule folder, renumbering the remaining members so that ordering remains contiguous. This supports configuration edits that delete or deactivate a rule without leaving gaps in the evaluation order.
• MOVEINSEQUENCE — Repositions a rule within its sequence, typically moving it earlier or later relative to sibling rules. Because ETRM evaluates rules in sequence order, this procedure is central to controlling precedence and conflict resolution between competing configuration rules.
• CHANGEEFFECTIVITY — Modifies the effective start and/or end dates of an individual rule or effectivity set. The procedure handles the boundary conditions associated with EPOCH_BEGIN and EPOCH_END, setting or clearing the open-ended sentinel as required.
• PROPAGATEEFFECTIVITYSETCHANGE — Cascades effectivity changes made at the effectivity-set level down to the rules and rule members that reference that set. This ensures that a change to a shared effectivity definition is reflected consistently across all dependent rules.

Tables Accessed

• CZ_EFFECTIVITY_SETS — Stores effectivity set definitions. Read and updated when computing or propagating date ranges across member rules.
• CZ_RULES — The core rule repository. Updated to reflect new sequence positions and changed effectivity dates.
• CZ_RULE_FOLDERS — Organizes rules into logical folders. Referenced to resolve the sequence context in which a rule resides.
• CZ_XFR_RUN_INFOS_S — Transfer/run information, used to record or associate processing runs with sequence and effectivity operations.
• DUAL — Used for single-row computations, sentinel date evaluation, and PL/SQL expression evaluation.

Usage Notes

CZ_RULES_SEQ is an internal package invoked primarily from Oracle Forms and concurrent programs within the ETRM and configuration management modules, rather than being called directly by end users. Because it is referenced by no other documented packages in the ETRM metadata set, its public procedures are effectively private implementation entry points consumed by the CZ forms layer and by administrative concurrent requests that maintain rule sequencing and effectivity. Custom code should treat the package as unsupported and instead use the supported CZ_UTILS and public CZ APIs where available.

When classifying effectivity, callers should be aware that any date compared against EPOCH_END (derived from CZ_UTILS.EPOCH_END_) represents an unbounded or open-ended range. Reporting and validation logic that searches on "epoch_end" is therefore effectively testing whether a rule or effectivity set is indefinitely active. Debugging typically relies on concurrent manager log output generated through the FND_REPORT and LOG_REPORT helpers, which use message names and token/value pairs resolved by CZ_UTILS.GET_TEXT. The package should only be exercised within a maintained CZ schema, and any direct invocation must supply a valid run identifier to ensure diagnostics are correctly attributed.