Search Results start_work_flow

Overview

CTO_CHANGE_ORDER_PK is the primary PL/SQL package body within Oracle E-Business Suite that supports the Configure-to-Order (CTO) change order notification process. Its stated purpose, per the source header, is to "get the Change order information from the Order Management and start the workflow to send notification." It therefore acts as the bridge between configuration change events captured in Order Management data and the Oracle Workflow engine that delivers notifications to the appropriate parties.

The package is owned by APPS and is classified as an OTHER API in ETRM. The source history shows it was originally created in August 2000 and evolved through a series of enhancements addressing ATO items, ML/MO cases, PTO-ATO configuration changes, cancellation handling, and default administrator role resolution. The package is referenced by two other packages, confirming it is a reusable internal component rather than an isolated utility.

Key Procedures and Functions

• START_WORK_FLOW — The procedure that initiates the notification workflow for a change order. This is the entry point most frequently sought by users searching on "start_work_flow," as it is responsible for launching the workflow process that dispatches change-order notifications.
• CHANGE_NOTIFY — Handles the change notification logic, assembling the change-order information retrieved from Order Management and preparing it for the workflow notification.
• RESERVATION_EXISTS — Checks whether a reservation exists for the relevant item or order line, used to determine appropriate processing paths during a configuration change.
• IS_ITEM_ML_OR_MO — Determines whether an item is a model (ML) or an option (MO) class item. The source history notes that this procedure calls the Get_model_sourcing_org API and initially compared its boolean return against 'Y'/'N', an issue corrected during patch set certification.
• DELETE_FROM_REQ_INTERFACE — Removes records from the requisition interface, supporting cleanup associated with the change-order process.
• GET_USER_NAME — Retrieves a user's name, used when populating notification content with the identity of the responsible or affected user.

Addressing a documented fact: the package supports cancellation cases and resolves the default administrator role from a Workflow attribute, and an additional workflow attribute was introduced to clarify cancellation notification messages (bug 1656334).

Tables Accessed

The package operates against several EBS schemas through APPS synonyms. Order Management and configuration data are read from OE_ORDER_LINES, MTL_SYSTEM_ITEMS, MTL_SYSTEM_ITEMS_KFV, and BOM_PARAMETERS. Reservation and sourcing logic draws on MTL_RESERVATIONS, MTL_SALES_ORDERS, MTL_UNITS_OF_MEASURE, and MTL_PLANNERS. Supply-chain scheduling information comes from MRP_SR_ASSIGNMENTS, MRP_SR_RECEIPT_ORG, and MRP_SR_SOURCE_ORG. Customer identity for notifications is resolved through HZ_CUST_ACCOUNTS and HZ_PARTIES, while FND_USER and FND_LANGUAGES supply user and language context. These reads support the retrieval of change-order details and the population of notification attributes.

Usage Notes

CTO_CHANGE_ORDER_PK is invoked when a configuration change on a CTO/ATO/PTO sales order must trigger notification. Typical callers include Oracle Order Management processing logic and other APPS packages (two documented referrers). Customizations should call the documented procedures rather than duplicate the logic, and developers should note the internal dependencies on Workflow attributes for administrative role resolution and notification text. Because the package is an internal-support API, customers should avoid modifying it directly and instead extend behavior through supported hooks or custom wrappers.