Results for “request_error_code”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

GCS_CONS_ENG_RUN_DTLS is a detail-level table within the GCS – Financial Consolidation Hub product in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores row-level information generated by the consolidation engine, capturing the outcome, status, and relationships for individual consolidation steps executed against entities within a consolidation hierarchy. The table acts as the granular counterpart to the consolidation run header, allowing the engine to persist per-entry, per-rule, and per-relationship results for troubleshooting, audit, and reconciliation of consolidation activity.

The product owner is GCS, and the table is documented with 19 columns in the ETRM 12.1.1 schema. Note that the metadata explicitly records the module as obsolete, and the object is flagged as "Not implemented in this database" — meaning the physical table may not exist in every EBS instance. Where present, it is referenced primarily by the consolidation engine and related diagnostic views rather than by standard end-user forms.

Based on the foreign key topology — multiple optional references to GCS_ENTRY_HEADERS plus references to categories and consolidation relationships — the heuristic Data Vault classification of this table is a link. This classification is offered as a modeling suggestion: the table behaves as an associative construct that ties together consolidation runs, journal entries, and structural relationships rather than functioning as a standalone hub or a descriptive satellite.

Key Information Stored

The surrogate primary key is RUN_DETAIL_ID, enforced through the GCS_CONS_ENG_RUN_DTLS_PK constraint. A second unique index, GCS_CONS_ENG_RUN_DTLS_U1, is also documented on RUN_DETAIL_ID, confirming it as the sole business-key candidate for row-level identification. Beyond that key, the following columns carry the substantive information:

• RUN_NAME — identifier linking the detail row back to a consolidation execution.
• CONSOLIDATION_ENTITY_ID and CHILD_ENTITY_ID — the parent and child entities participating in the consolidation step.
• CONTRA_CHILD_ENTITY_ID — the contra entity used when elimination logic applies.
• RULE_ID and CONS_RELATIONSHIP_ID — the consolidation rule and the relationship definition that drove the step.
• ENTRY_ID and STAT_ENTRY_ID — references to the resulting (and statistical) journal entry headers.
• PRE_PROP_ENTRY_ID and PRE_PROP_STAT_ENTRY_ID — pre-propagation entry references used in multi-pass processing.
• REQUEST_ERROR_CODE and BP_REQUEST_ERROR_CODE — error/status indicators for the request and its business-process stage.
• CATEGORY_CODE — the consolidation category context.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard EBS audit columns.

Common Use Cases and Queries

Typical reporting centers on diagnosing why a consolidation produced an unexpected balance or failed to complete. Analysts join the detail rows to the entry headers to trace which journal entry was created for a given entity and rule, and to correlate error codes with the underlying request. A representative pattern is:

• Filter by RUN_NAME to retrieve all detail rows for one consolidation execution.
• Join ENTRY_ID to GCS_ENTRY_HEADERS to inspect the resulting entry lines.
• Join CATEGORY_CODE to GCS_CATEGORIES_B to resolve the category description.
• Aggregate by CHILD_ENTITY_ID and RULE_ID to profile consolidation activity.

Sample SQL: SELECT d.run_detail_id, d.run_name, d.child_entity_id, d.rule_id, d.entry_id, d.request_error_code FROM gcs_cons_eng_run_dtls d WHERE d.run_name = :run_name ORDER BY d.child_entity_id;

Related Objects

The documented foreign keys establish the primary join paths for this table, all resolving through RUN_DETAIL_ID or its entry references:

• GCS_ENTRY_HEADERS — referenced four times, via ENTRY_ID, STAT_ENTRY_ID, PRE_PROP_ENTRY_ID, and PRE_PROP_STAT_ENTRY_ID.
• GCS_CATEGORIES_B — referenced through CATEGORY_CODE.
• Self-referencing relationships via RULE_ID and CONS_RELATIONSHIP_ID, which point to consolidation rule and relationship definitions.

Because the module is obsolete, no supported public API depends on this table in current releases; external integrations should treat it as read-only diagnostic metadata.