Search Results associated_request_id

Overview

The GCS_DATA_SUB_DTLS table is a core data object within the Oracle E-Business Suite General Ledger Consolidation System (GCS) in releases 12.1.1 and 12.2.2. It functions as a control table, storing header-level metadata for user-submitted data loads that directly impact pristine financial data within the FEM_BALANCES table. Its primary role is to track the submission, parameters, and status of data loads and consolidation hierarchy change transactions, such as acquisitions and disposals. Each record represents a distinct load job, providing an audit trail and context for the detailed transaction data stored in related tables like GCS_AD_TRIAL_BALANCES.

Key Information Stored

The table's columns define the critical dimensions and status of a data load operation. The mandatory LOAD_ID column is the primary key, uniquely identifying each submission. Key defining parameters include ENTITY_ID, CAL_PERIOD_ID, CURRENCY_CODE, BALANCE_TYPE_CODE, and RULE_SET_ID, which collectively specify the target scope and transformation rules for the loaded data. Operational metadata is captured in columns such as STATUS_CODE, START_TIME, END_TIME, and the standard WHO columns (CREATED_BY, CREATION_DATE, etc.). Crucially, the ASSOCIATED_REQUEST_ID column establishes a foreign key relationship to FND_CONCURRENT_REQUESTS, linking the data load to its corresponding concurrent request in the EBS framework for status monitoring and logging. The NOTIFICATION_TEXT column, of CLOB datatype, stores detailed messages related to the load process.

Common Use Cases and Queries

A primary use case is monitoring the status and history of data load submissions for troubleshooting or audit purposes. The ASSOCIATED_REQUEST_ID is frequently used to join with FND_CONCURRENT_REQUESTS to retrieve the concurrent program's phase and status. Common reporting queries include identifying failed or long-running loads, summarizing loads by entity or period, and reviewing notification details. For example, to find details for a load linked to a specific concurrent request, a developer might use:

• SELECT g.load_name, g.status_code, g.start_time, g.end_time, f.request_id, f.phase_code, f.status_code AS conc_status FROM gcs.gcs_data_sub_dtls g, fnd_concurrent_requests f WHERE g.associated_request_id = f.request_id AND f.request_id = :req_id;

Another common pattern is querying loads submitted within a date range for a particular entity to analyze submission frequency or performance.

Related Objects

GCS_DATA_SUB_DTLS is central to the GCS data submission architecture, with documented relationships to several key objects. Its primary key (LOAD_ID) is referenced by the GCS_CONS_IMPACT_ANALYSES table, linking load headers to their downstream impact analyses. The table itself references several master and control tables via foreign keys:

• FND_CONCURRENT_REQUESTS: Via ASSOCIATED_REQUEST_ID, linking to the EBS concurrent manager.
• FND_CURRENCIES: Via CURRENCY_CODE, validating the currency.
• GCS_LEX_MAP_RULE_SETS: Via RULE_SET_ID (for data transformation) and VALIDATION_RULE_SET_ID.

These relationships enforce data integrity and enable comprehensive joins for reporting on the complete lifecycle of a consolidation data load, from the initial concurrent request through to the impacted balances.