Search Results process_data




Overview

GCS_DP_DYNAMIC_PKG is an Oracle EBS Applications (APPS) PL/SQL package that forms part of the Global Consolidation System (GCS) Data Preparation Engine. The package header is defined with AUTHID CURRENT_USER, meaning that all SQL executed within its procedures runs under the privileges of the invoking schema rather than the package owner. As stated in the embedded header comments, the package was created on 08-Dec-03 by Ying Liu and its stated purpose is to provide "package procedures for the Data Preparation Engine Program." In practical terms, the Data Preparation Engine is responsible for gathering, transforming, and staging financial balances and related dimensional data so that the consolidation engine can produce consolidated entries. This package therefore sits on the boundary between raw financial data collection (via dynamic SQL) and the consolidation entry structures that downstream consolidation processing consumes.

Key Procedures and Functions

The package exposes two documented procedures. Both follow the standard concurrent-program call signature, accepting an OUT NOCOPY errbuf and retcode for concurrent manager error reporting.

  • PROCESS_DATA — Performs the core data preparation step. Its documented purpose is to "process all the data collected by the dynamic sql statement and insert the data into GCS_ENTRY_LINES/HEADERS." Its parameters indicate that it receives source currency, target calendar period, maximum period, currency type, hierarchy, entity, source ledger, a year-end values match flag, a calendar period record (of type gcs_utility_pkg.r_cal_period_info), balance type, owner percentage, run detail identifier, and source dataset code. It is the primary routine for full data preparation runs.
  • PROCESS_INC_DATA — Handles incremental data processing. It shares much of the same parameter profile as PROCESS_DATA (source currency, target calendar period, currency type, hierarchy, entity, source ledger, balance type, owner percentage, source dataset code) but adds a run name and returns four OUT parameters: x_entry_id, x_stat_entry_id, x_prop_entry_id, and x_stat_prop_entry_id. These outputs correspond to the entry identifiers created for standard, statistical, proportional, and statistical-proportional entry lines, indicating that incremental processing creates discrete entry records rather than a bulk refresh.

Tables Accessed

The package operates across a broad set of Enterprise Performance Foundation (FEM) and GCS tables, accessed through APPS synonyms. The FEM tables — FEM_BALANCES, FEM_CAL_PERIODS_ATTR, FEM_DIM_ATTRIBUTES_B, FEM_DIM_ATTR_VERSIONS_B, FEM_EXT_ACCT_TYPES_ATTR, FEM_GLOBAL_VS_COMBO_DEFS, FEM_LEDGERS_ATTR, FEM_LN_ITEMS_ATTR, FEM_OBJECT_DEFINITION_B, and FEM_XDIM_DIMENSIONS — supply the balance data, calendar period attributes, dimensional metadata, ledger attributes, line item attributes, and account type definitions required to interpret and transform source balances. FND_CURRENCIES provides currency validation and conversion metadata. GCS_CAL_PERIOD_MAPS_GT is a global temporary table used to map source calendar periods to target periods. GCS_CONS_ENG_RUNS and GCS_CONS_ENG_RUN_DTLS store the consolidation engine run header and detail records that track execution of the data preparation process. GCS_CONS_IMPACT_ANALYSES supports impact analysis of consolidation changes. The write targets referenced in the procedure documentation are GCS_ENTRY_LINES and GCS_ENTRY_HEADERS, which hold the prepared entry data.

Usage Notes

This package is designed to be invoked from the Data Preparation Engine concurrent program, which explains the AUTHID CURRENT_USER declaration and the errbuf/retcode OUT parameters. It may also be called directly from custom PL/SQL code that needs to invoke data preparation programmatically; because the package is not marked as an approved public API (API classification: OTHER), direct calls should be treated with caution and validated against the installed patch level. The package is referenced by one other package, so dependent code must be considered when applying patches. Given the header revision ($Header: gcsdpdyns.pls 120.2 2006/02/04), the code has remained stable since the 11i-era codebase and is carried forward into 12.1.1 and 12.2.2 without functional change to the documented interface.