Search Results cp_flow

Overview

APPS.MSC_X_CP_FLOW is a PL/SQL package body within the Oracle Advanced Supply Chain Planning (ASCP) and Supply Chain Event Management (SCEM) module. Its primary business function is to orchestrate the flow of collaborative planning and supplier collaboration information across the supply chain. Specifically, the package provides the programmatic bridge between Oracle E-Business Suite and the SCEM/ASCP engine infrastructure, enabling the launch of planning engine concurrent requests, the initiation of Oracle Workflow processes for supplier capacity and forecast interactions, and the publication of supply commits and order forecasts to trading partners. The package is classified under the OTHER API category in ETRM documentation and, as of the source header shown, carries a version reference to 2005, indicating that it is a long-standing component of the supply chain planning architecture reused across 12.1.1 and 12.2.2.

Key Procedures and Functions

The package exposes 15 documented procedures and functions, grouped into logical families:

• SCEM engine orchestration: START_SCEM_ENGINE_WF creates and starts a workflow process of type MSCXSCEM with process name START_SCEM_ENGINE, using a sequence-generated item key prefixed with "CP_FLOW-". LAUNCH_SCEM_ENGINE is the workflow callback that submits the SCEM concurrent program (short name MSCXNETG) in trigger mode via FND_REQUEST.SET_MODE and FND_REQUEST.SUBMIT_REQUEST, then commits. AUTO_SCEM_MODE returns or sets the automatic SCEM execution mode.
• Forecast and capacity workflows: START_DP_RECEIVE_FORECAST_WF, DP_RECEIVE_FORECAST, RECEIVE_SUPPLIER_CAPACITY_WF, and RECEIVE_SUPPLIER_CAPACITY initiate and process inbound demand planning forecasts and supplier capacity responses exchanged with trading partners.
• ASCP engine orchestration: START_ASCP_ENGINE_WF and LAUNCH_ASCP_ENGINE launch the Advanced Supply Chain Planning engine by submitting the relevant concurrent request, mirroring the SCEM launch pattern.
• Outbound publication: PUBLISH_SUPPLY_COMMITS_WF, PUBLISH_SUPPLY_COMMITS, PUBLISH_ORDER_FORECAST_WF, and PUBLISH_ORDER_FORECAST push supply commit and order forecast data to trading partners via workflow-driven messages.
• Diagnostics: PRINT_DEBUG_INFO and PRINT_USER_INFO emit diagnostic and user-facing messages to the concurrent program log, replacing or complementing FND_FILE.PUT_LINE calls.

Tables Accessed

The package reads and writes several core planning and workflow tables through APPS synonyms:

• MSC_SUP_DEM_ENTRIES_S: sequence source for workflow item keys in START_SCEM_ENGINE_WF.
• MSC_PLANS: used to resolve the active plan context for engine launches.
• MSC_COMPANY_RELATIONSHIPS, MSC_COMPANY_USERS, MSC_DESIGNATORS, MSC_TRADING_PARTNERS, MSC_TRADING_PARTNER_MAPS: define the supply chain network, user-to-company mappings, and trading partner associations needed to route forecast, capacity, and commit messages to the correct recipients.
• FND_USER, FND_RESPONSIBILITY, WF_LOCAL_ROLES: supply Oracle Applications identity and responsibility data used when addressing workflow notifications and resolving approver or recipient roles.
• DUAL: used for simple SELECT expressions such as workflow key construction.

Usage Notes

MSC_X_CP_FLOW is not invoked directly from EBS forms. Instead, it is called programmatically by five other packages and by Oracle Workflow activities. In practice, the workflow routines (START_*_WF) create workflow items, while the corresponding callback procedures (LAUNCH_*, RECEIVE_*, PUBLISH_*) execute inside the workflow engine to submit concurrent requests or post messages. The use of FND_REQUEST.SET_MODE(TRUE) in LAUNCH_SCEM_ENGINE is significant: it forces trigger mode so that any SAVEPOINT and ROLLBACK commands within the workflow activity are bypassed, allowing the concurrent request submission to commit immediately. Because PRINT_USER_INFO is referenced directly in the source, the note that this procedure replaces traditional log-message calls is relevant to anyone tracing concurrent request output. Developers integrating with the SCEM or ASCP flow should call the workflow starters rather than the callback procedures directly, and should ensure the associated concurrent programs (for example MSCXNETG) remain enabled and properly assigned to the requesting responsibility.