Search Results gcs_lex_map_rule_stages_u1

Overview

The GCS_LEX_MAP_RULE_STAGES table is a core data structure within the Oracle E-Business Suite (EBS) General Ledger Consolidation System (GCS), specifically for the Financial Consolidation Hub. Its primary role is to define and manage the sequential processing stages within a Transformation Rule Set. In the context of financial consolidation and translation, these rule sets are critical for automating data transformations, such as currency conversion or intercompany eliminations, during the consolidation process. The table enables the logical grouping and ordering of individual transformation rules, ensuring they are executed in a controlled, staged sequence as defined by the STAGE_NUMBER. This staged execution is fundamental to maintaining data integrity and achieving correct financial results in multi-currency, multi-entity consolidation environments in releases 12.1.1 and 12.2.2.

Key Information Stored

The table stores metadata that defines each stage within a rule set. The key columns are:

• RULE_STAGE_ID: The unique primary key identifier (PK) for a specific rule stage record. This is the column referenced by the user's search.
• RULE_SET_ID: A foreign key (FK) linking the stage to its parent Transformation Rule Set in the GCS_LEX_MAP_RULE_SETS table.
• STAGE_NUMBER: Defines the execution order of the stage within its rule set. This sequence dictates the procedural flow of data transformation.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN: Standard Oracle EBS "Who" columns for auditing record creation and modifications.

The table's physical storage is managed in the APPS_TS_TX_DATA tablespace, with a PCTFREE of 10 to optimize for transactional updates.

Common Use Cases and Queries

This table is primarily accessed for configuration, troubleshooting, and reporting on consolidation rule set structures. A common operational query involves listing all stages for a specific rule set to understand or validate the transformation workflow. For example, to audit the staging sequence for a known RULE_SET_ID (e.g., 1001):

SELECT RULE_STAGE_ID, STAGE_NUMBER, CREATED_BY, CREATION_DATE
FROM GCS.GCS_LEX_MAP_RULE_STAGES
WHERE RULE_SET_ID = 1001
ORDER BY STAGE_NUMBER;

Another critical use case is identifying orphaned stages or validating data integrity by joining to the parent rule sets table:
SELECT stg.RULE_STAGE_ID, stg.RULE_SET_ID, stg.STAGE_NUMBER
FROM GCS.GCS_LEX_MAP_RULE_STAGES stg
LEFT JOIN GCS.GCS_LEX_MAP_RULE_SETS rs ON stg.RULE_SET_ID = rs.RULE_SET_ID
WHERE rs.RULE_SET_ID IS NULL;
This query helps ensure all stages have a valid parent rule set, which is essential for system stability.

Related Objects

The GCS_LEX_MAP_RULE_STAGES table sits at the center of a key relationship hierarchy within the GCS module:

• Parent Reference (Foreign Key): The RULE_SET_ID column references the primary key of GCS_LEX_MAP_RULE_SETS. This defines the many-to-one relationship where multiple stages belong to a single rule set.
• Child Reference (Referenced by Foreign Key): The table's primary key, RULE_STAGE_ID, is referenced by the GCS_LEX_MAP_RULES table. This establishes a one-to-many relationship where a single rule stage can contain multiple individual transformation rules.

These documented relationships create the logical chain: Rule Set → Rule Stage → Rule. The table is also indexed for performance: a unique index (GCS_LEX_MAP_RULE_STAGES_U1) on RULE_STAGE_ID and a non-unique index (GCS_LEX_MAP_RULE_STAGES_N1) on the combination of RULE_SET_ID and STAGE_NUMBER to support efficient lookups and ordering.