Search Results start_flow

Overview

OE_ORDER_WF_UTIL is an Oracle Workflow utility package in the APPS schema that provides the shared plumbing used by Oracle Order Management's workflow-enabled transactions. Its role is to bridge the PL/SQL business logic of the order entry and order management APIs with the Oracle Workflow engine (WF). Rather than embedding workflow item-type lookups, user-key derivation, notification approver resolution, and work item creation logic redundantly in each module, the order management development team centralised these mechanics in this utility package. It is classified as a UTIL package precisely for this reason: it is a support library, not a public business API, and is not intended to be called directly by end users or external integration code without understanding its internal contracts.

The package is instrumented for both Oracle E-Business Suite 12.1.1 and 12.2.2. In the 12.2.x Online Patching (adop) architecture, the object remains VALID in the APPS edition, and its dependencies on FND_API, STANDARD, and OE_ORDER_PUB confirm it participates in the standard order flow, not in a standalone utility layer.

Key Procedures and Functions

The documented 29 subprograms fall into several functional clusters:

• Workflow flow initiation — START_FLOW, START_LINEFORK, START_ALL_FLOWS, START_FLOWSTART_GLOBALS (and CLEAR_FLOWSTART_GLOBALS), plus CREATESTART_HDRPROCESS, CREATESTART_LINEPROCESS, CREATESTART_LINEFORK. These create and launch the header- and line-level workflow processes for an order, including the "start" subprocess that hands control from the order transaction to the workflow engine.
• Work item management — CREATE_HDRWORKITEM, CREATE_LINEWORKITEM, CREATE_LINEFORK, and CREATE_WORKITEM_UPGRADE. These instantiate the WF_NOTIFICATIONS/work item records that drive approvals and fulfilment activities.
• Notification and approver resolution — SET_NOTIFICATION_APPROVER. This derives the correct approver for a notification based on the order's approval routing rules.
• Item key and descriptor handling — SET_HEADER_USER_KEY, SET_LINE_USER_KEY, SET_HEADER_DESCRIPTOR, SET_LINE_DESCRIPTOR, GET_WF_ITEM_TYPE. These set the identifying user key for header and line workflow items and retrieve the WF item type, ensuring notifications correlate back to the correct order entity.
• Flow status and cleanup — UPDATE_FLOW_STATUS_CODE, UPDATE_QUOTE_BLANKET, DELETE_ROW. These update the workflow status on the order (e.g. for quotes and blankets) and remove transient rows created during flow transitions.

Tables Accessed

Documented table access is concentrated in the Order Management core and reference tables:

• OE_ORDER_HEADERS_ALL / OE_ORDER_HEADERS and OE_ORDER_LINES_ALL — the primary order and line records whose workflow user keys, statuses, and item types are managed here.
• OE_TRANSACTION_TYPES_TL — used to determine the correct workflow item type and transaction context for the order.
• OE_WORKFLOW_ASSIGNMENTS — the assignment/routing table queried to resolve who receives a given notification, feeding SET_NOTIFICATION_APPROVER.
• OE_BLANKET_HEADERS_ALL / OE_BLANKET_HEADERS_EXT / OE_BLANKET_LINES_ALL — retained because the same workflow machinery services blanket purchase agreements and quote-to-blanket conversions (see UPDATE_QUOTE_BLANKET).
• OE_HOLD_DEFINITIONS / OE_HOLD_SOURCES — hold data consulted when workflow-driven approvals or holds affect the flow.
• Supporting reference tables: FND_USER (user identification), HZ_CUST_SITE_USES_ALL (ship-to/site context), MTL_SYSTEM_ITEMS_KFV (item description), RA_TERMS (payment terms), and OE_XML_MESSAGE_SEQ_S (XML message sequencing for integration).

Usage Notes

OE_ORDER_WF_UTIL is invoked indirectly. It is referenced by 28 other packages, including OE_ORDER_PVT, OE_HEADER_UTIL, OE_LINE_UTIL, OE_APPROVALS_WF, OE_BLANKET_WF_UTIL, OE_RMA_WF, OE_SHIPPING_WF, OE_PAYMENT_ASSURANCE_WF, OE_ORDER_PURGE_PVT, and CTO_WORKFLOW_API_PK. In practice it is triggered when a user books an order, submits an order approval, cancels a line, performs an RMA, or ships and confirms a delivery — each of these user-facing actions causes one of the referencing packages to call the appropriate utility routine. It is therefore not a form-level or concurrent-program-level entry point but a shared internal layer. Developers extending Order Management workflow should call the public API in OE_ORDER_PUB rather than this utility, and should treat changes to this package with caution since its behaviour affects approval, fulfilment, and purge flows across the entire order lifecycle.