Search Results shipped_lines

Overview

WSH_WF is the Shipping Execution workflow integration package in Oracle E-Business Suite. It provides the PL/SQL interface through which shipping transaction data is bound to Oracle Workflow processes, most notably the order fulfillment notification workflow that informs customers when their orders have shipped or been backordered. The package is declared with AUTHID CURRENT_USER and resides in the APPS schema, executing with the privileges of the calling user.

The package serves two complementary roles. First, it assembles and launches workflow processes based on delivery and shipment state, using header, contact, and shipped-line information as input. Second, it supplies the workflow callbacks — standard item type function activities — that the Workflow engine invokes during process execution to evaluate order status, render line detail, and determine whether an order is fully fulfilled. Its dependence on WSH_DELIVERY_DETAILS and WSH_NEW_DELIVERIES confirms that it is tightly coupled to Shipping Execution's delivery model.

Key Procedures and Functions

• START_PROCESS — The principal entry point for initiating a shipping workflow. It accepts delivery header identifiers, recipient contact details, shipped and backordered line sets, and notification dates, and optionally allows the caller to override the workflow process and item type.
• ORDER_STATUS — A workflow function activity that determines the fulfillment status of the order and returns the result to the workflow engine.
• SHIPPED_LINES — A workflow document-display callback that returns the formatted set of shipped lines for presentation within a notification.
• BACKORDERED_LINES — The parallel callback that returns formatted backordered line detail for notification display.
• ORDER_FULFILLED — The workflow function activity that evaluates whether the order has been completely fulfilled, returning the outcome used to branch the process. This is the procedure most commonly associated with the "order_fulfilled" search term.
• UPDATE_WORKFLOW — Synchronizes workflow state for a given delivery, typically invoked when delivery attributes change after the workflow has started.
• CHECK_ITEM_INSTANCE — Determines whether a workflow item instance already exists for a given source header and contact, preventing duplicate notifications.
• START_WORKFLOW — A variant launcher that resolves the appropriate workflow for a source header and contact and reports success through a boolean result.
• GET_WF_USER — Resolves the workflow-assigned user name and last name for a contact type and contact identifier, used when addressing notifications.

Tables Accessed

The package reads customer and contact data from HZ_CUST_ACCOUNTS, HZ_CUST_ACCOUNT_ROLES, HZ_ORG_CONTACTS, and HZ_RELATIONSHIPS to identify notification recipients. MTL_SYSTEM_ITEMS supplies item attributes used in line display and fulfillment evaluation. WSH_DELIVERY_DETAILS and WSH_NEW_DELIVERIES provide the delivery and shipped-line context that drives process initiation and line rendering. WF_ITEM_ACTIVITY_STATUSES is queried to detect existing workflow activity, supporting the duplicate-instance check. PLITBLM is an Oracle Forms PL/SQL table construct referenced by the package.

Usage Notes

WSH_WF is normally invoked indirectly rather than called directly by end users. Shipping Execution triggers process initiation when deliveries are confirmed and shipped notifications are generated, with the workflow process invoking ORDER_STATUS, ORDER_FULFILLED, SHIPPED_LINES, and BACKORDERED_LINES as standard function and document callbacks. The package is also referenced by one other database package, indicating internal reuse within the shipping and order fulfillment stack.

Customizations should avoid direct invocation of START_PROCESS or START_WORKFLOW outside supported integration points, as the procedures assume valid delivery and source header context. Because the package runs as AUTHID CURRENT_USER, custom code calling it requires appropriate execute privileges on the package and select privileges on the underlying WSH, HZ, MTL, and WF objects. The ORDER_FULFILLED callback remains the authoritative runtime test for order completion and should not be replicated or bypassed in custom workflow definitions.