Search Results update_shp_qty

Overview

WSH_SC_DEL_LINES is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM metadata as an "OTHER" API type. Its header comment dates from 1999, indicating it belongs to the original Shipping Execution (WSH) module lineage and has remained structurally stable across releases 12.1.1 and 12.2.2. The package provides server-side logic that supports delivery-line processing within Oracle Shipping Execution, the module responsible for managing deliveries, pick releases, packing, and shipping confirmation.

The package operates on delivery records keyed by delivery identifier (DEL_ID) and performs quantity reconciliation and line release operations against the Sales Order and picking schemas. Functionally it complements the shipping confirmation and delivery management flows by recalculating shipped quantities and re-evaluating unreleased delivery lines after transactional changes. It is a low-level utility package rather than a public API intended for direct customer extension; nevertheless, because it is invoked by other packages and possibly by forms and concurrent programs, customizations occasionally call it directly with a DEL_ID.

Key Procedures and Functions

Two procedures are documented in the package specification:

• update_shp_qty — Accepts a delivery identifier and an action code, and updates shipped quantity information for the delivery's lines. The action code parameter allows the caller to communicate the context of the update so that the procedure can apply the appropriate recalculation or adjustment logic when quantities change as the result of shipping or delivery modification activity.
• update_unrel_lines — Accepts a delivery identifier and processes the delivery's unreleased lines. This is the procedure most commonly associated with the search term "update_unrel_lines." It is used when delivery lines have been created or modified but not yet released to picking, and the unreleased line state must be re-evaluated so that shipping quantities, release status, and related detail rows remain consistent with the sales order demand.

No parameter lists beyond those shown in the ETRM excerpt should be assumed; the documented signatures are exactly update_shp_qty(del_id, action_code) and update_unrel_lines(del_id).

Tables Accessed

ETRM documentation identifies the following base tables, referenced through APPS synonyms:

• SO_LINES_ALL — The sales order lines table, providing the ordered quantity and demand context against which shipping quantities are reconciled.
• SO_LINE_DETAILS — Order line detail attributes (including shipping-relevant flags and reference information) used to resolve how lines should be processed.
• SO_PICKING_LINES_ALL — The picking line table where released line quantities are stored and updated as a result of the package's logic.
• SO_PICKING_LINE_DETAILS — Picking line detail rows that carry additional attributes needed to keep detail data synchronized with the header-level picking line updates.

Together these tables support the two core responsibilities: adjusting shipped quantity on existing picking/delivery lines and grooming unreleased lines so that they can be picked or shipped correctly.

Usage Notes

WSH_SC_DEL_LINES is an internal Shipping Execution package. ETRM records that it is referenced by one other package, confirming that it is called from within the shipping application's own PL/SQL stack rather than being a public, supported extension point. In 12.1.1 and 12.2.2, delivery and shipping confirmation flows perform quantity updates and release-line processing through this and related packages; 12.2.x retains the same logical structure, with data model changes (such as the move to the common Oracle Fusion-style schema in some areas) not altering the documented procedure signatures.

Custom code should treat this package as unsupported and use it only when no public API exists for the required reconciliation, invoking it with a valid DEL_ID and the correct action code for update_shp_qty. Because it writes directly to picking and order tables, callers must commit appropriately, avoid calling it concurrently for the same delivery, and validate that the delivery is in a state where shipped-quantity or unreleased-line updates are legal. Errors raised by the package should be handled and rolled back rather than ignored, since partial updates can leave delivery lines inconsistent with sales order demand.