Search Results import_data

Overview

APPS.CN_IMPORT_PVT is a private PL/SQL package within the Oracle EBS Incentive Compensation (CN) module. Its primary business function is to orchestrate the transfer of data between external flat files and the Incentive Compensation staging and destination tables. The package serves as the main driver that coordinates the execution of concurrent programs responsible for moving data through the import pipeline — from a datafile into a stage table, and subsequently into the final destination tables. The header comments confirm its dual role: Import_Data transfers data from a datafile to a stage table and then to the destination table, while Export_Data handles the reverse direction, moving data from a destination file to a stage table. The package is declared with AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking user rather than the definer, and it defines custom collection types (CHAR_DATA_SET_TYPE and NUM_DATA_SET_TYPE) to emulate the JTF table types that Rosetta, the underlying bulk data processing engine, does not natively support.

Key Procedures and Functions

• IMPORT_DATA — The principal program that calls all concurrent programs required to transfer data from the datafile into the stage table and then into the destination table. It accepts a standard FND_API parameter set for API versioning, message handling, validation level, and commit control, and additionally receives the import header identifier, session context values (user, responsibility, application, org), and the control file name.
• EXPORT_DATA — The complementary program that invokes concurrent programs to transfer data from the destination file into the stage table, supporting outbound data movement.
• CLIENT_STAGE_DATA — Handles the client-side staging phase of the import/export flow.
• SERVER_STAGE_DATA — Handles the server-side staging phase, complementing the client staging step.
• LOAD_DATA — Loads the staged data into its destination structures once staging is complete.
• UPDATE_IMP_HEADERS — Updates the import header records, tracking the status and results of an import run.
• UPDATE_IMP_LINES — Updates the import line records corresponding to the header, maintaining line-level processing status.
• BUILD_ERROR_REC — Constructs an error record when a processing failure occurs.
• WRITE_ERROR_REC — Persists or outputs the constructed error record for later review.

Tables Accessed

The package operates against a set of staging and configuration tables accessed via APPS synonyms:

• CN_IMPORT_TYPES — Defines the supported import types that govern how incoming data is interpreted.
• CN_IMP_HEADERS — Stores header-level information for each import batch; written and updated by UPDATE_IMP_HEADERS.
• CN_IMP_LINES — Stores line-level import detail; written and updated by UPDATE_IMP_LINES.
• CN_IMP_MAPS and CN_IMP_MAP_FIELDS — Provide the mapping definitions that translate source file columns into destination table columns during the load.
• CN_PROCESS_AUDITS — Records audit information for processing runs, supporting traceability.
• PLITBLM — A standard Oracle Applications table used for storing temporary or interface data during processing.

Usage Notes

CN_IMPORT_PVT is classified as a PVT (private) API, indicating it is intended for internal use by the Incentive Compensation module rather than direct invocation by external custom code. It is referenced by eight other packages, reflecting its role as a shared orchestration layer in the import/export pipeline. In practice, it is most commonly invoked indirectly through Incentive Compensation concurrent programs and forms that manage data import and export operations. The IMPORT_DATA procedure is the typical entry point for inbound data loads, receiving session context identifiers so that the correct user, responsibility, application, and organization context is established before processing. Because the package relies on Rosetta-based bulk processing and calls concurrent programs, it should generally be triggered within a properly initialized EBS session where FND_API conventions for message list and return status are honored. Customizations that require direct calls should follow the documented parameter contract, particularly the FND_API version, commit, and validation-level conventions.