Search Results g_collection_program

Overview

MSC_CL_PRE_PROCESS is an internal PL/SQL package in the APPS schema that forms part of the Oracle Advanced Supply Chain Planning (ASCP) collection architecture within Oracle E-Business Suite 12.1.1 and 12.2.2. The package name reflects its role in the "pre-process" phase of the collections cycle: after raw source data has been pulled from a source ERP instance into the planning staging tables, this package performs the preparatory transformation and validation steps that make that data usable by the planning engine. It is registered in the ETRM repository with an API classification of OTHER, indicating it is a private, implementation-internal component rather than a published PL/SQL API intended for direct customer invocation.

The package specification declares AUTHID CURRENT_USER and contains a substantial set of global variables and constants. Notably, it defines SYS_YES (constant 1) and SYS_NO (constant 2) and initializes the global flag v_flag to SYS_NO. These binary constants are used throughout the package to represent boolean-like state in NUMBER columns, which is a common convention in the MSC (Advanced Planning) schema. The package also declares workload constants such as G_COLLECTION_PROGRAM and G_PULL_PROGRAM, instance type constants (G_INS_DISCRETE, G_INS_PROCESS, G_INS_OTHER, G_INS_MIXED), instance state constants (G_ST_EMPTY, G_ST_PULLING, G_ST_READY, G_ST_COLLECTING, G_ST_PURGING, G_ST_PRE_PROCESSING), calendar type constants, and calling module identifiers for APS and DP.

Key Procedures and Functions

The ETRM repository documents two procedures for this package:

• LAUNCH_MONITOR — the supervisory entry point. It is expected to evaluate the state of a collection or pre-processing run and coordinate monitoring activity, using the instance state constants (G_ST_*) to determine whether a refresh is pulling, ready, collecting, purging, or pre-processing. It typically drives progress reporting and error escalation against the collection and refresh status tables.
• LAUNCH_WORKER — the worker procedure that performs the actual pre-processing workload. It is invoked, directly or indirectly, under the control of LAUNCH_MONITOR and executes the row-level transformations and validations associated with the current instance and refresh.

Because ETRM classifies the package as OTHER and documents no external API entry points, parameter lists are intentionally not treated as public interface; callers should rely on the internal invocation paths rather than constructing direct calls.

Tables Accessed

The package operates against a set of tables via APPS synonyms, all residing in the MSC planning schema:

• MSC_APPS_INSTANCES, MSC_CL_REFRESH_S, and MSC_COLLECTION_S — the instance, refresh, and collection control tables that define the run context and status; the package reads these to resolve v_refresh_id, v_instance_id, and v_instance_code and to interpret current state.
• MSC_BOMS, MSC_ITEM_SUBSTITUTES, MSC_ITEM_ID_LID, and MSC_LOCAL_ID_DEMAND — planning data entities where item, bill of material, substitute, and demand records are prepared for the planning engine.
• MSC_CALENDAR_MONTHS, MSC_COMPANIES, MSC_GROUPS, and MSC_GROUP_COMPANIES — organizational and calendar dimensions used to validate and align data before the planning run.
• MSC_COLL_PARAMETERS — collection configuration parameters that influence processing scope.
• MSC_ERRORS and MSC_ERRORS_S — the error staging tables where validation failures are logged for review.
• FND_USER — the standard EBS user table, used to resolve the current user identity recorded in v_current_user.

Usage Notes

MSC_CL_PRE_PROCESS is not exposed through a Forms-based user interface, nor is it registered as a standalone concurrent program. It is invoked internally by the ASCP collection framework—specifically from the collection and refresh manager logic—as part of a scheduled planning data collection. The presence of the G_COLLECTION_PROGRAM and G_PULL_PROGRAM constants indicates the package branches based on whether pre-processing runs in the context of a full collection program or a pull-based refresh. ETRM records that the package is referenced by three other packages, confirming it is a subordinate component in the MSC dependency chain. Because the package uses AUTHID CURRENT_USER and a large block of package-level globals, it is stateful within a session and should not be called concurrently for overlapping instances. The G_CONC_ERROR constant and related G_SUCCESS, G_WARNING, and G_ERROR constants indicate that results are returned to the calling concurrent manager as standard request completion statuses, allowing the collection monitor to detect and report partial failures.