Results for “wms_replenishment_pub”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

APPS.WMS_REPLENISHMENT_PUB is the public PL/SQL API for Warehouse Management System (WMS) replenishment processing in Oracle E-Business Suite. It exposes the replenishment engine that moves material from bulk or reserve locations to primary picking locations, driven either by warehouse rules (dynamic replenishment) or by explicit item, order, and customer attributes (push replenishment). The package is classified as a PUB API, meaning it is intended for client-side invocation by forms, concurrent programs, and custom integration code rather than for internal-only use. The header comment (WMSREPPS.pls 120.8, dated April 2008) confirms the package lineage predates the 12.1.1 and 12.2.2 releases and remains the consolidated entry point for replenishment execution in both releases. The _CP suffixed procedures are concurrent-program wrappers that follow the standard EBS errbuf/retcode signature, while the non-suffixed procedures expose the same logic callable from PL/SQL with the conventional x_return_status, x_msg_count, and x_msg_data out parameters.

Key Procedures and Functions

The package documents six procedures, all of which are replenishment-facing. No public functions are declared in the excerpt.

• DYNAMIC_REPLENISHMENT_CP — Concurrent-program wrapper for rule-driven replenishment. It processes a batch, organization, task scope, and release-sequence rule identifier.
• DYNAMIC_REPLENISHMENT — PL/SQL-callable form of dynamic replenishment. Accepts the same business identifiers plus a replenishment level, and returns standard status, message count, and message data.
• PUSH_REPLENISHMENT_CP — Concurrent-program wrapper for push replenishment, which selects and replenishes items based on item, ABC class, order type, customer, carrier, ship method, and date-range criteria.
• PUSH_REPLENISHMENT — API-callable form of the same push logic, with the same selection criteria plus replenishment level.
• UPDATE_DELIVERY_DETAIL — The procedure matching the user's search. It is the documented entry point for updating delivery-detail records associated with replenishment; it is used to synchronize delivery detail rows after replenishment allocation or movement, typically correcting quantities or references so downstream shipping and inventory views remain consistent.
• ALLOCATE_REPL_MOVE_ORDER_CP — Allocates the move-order lines generated by replenishment, tying the replenished quantity to the destination picking or delivery location.

Tables Accessed

The ETRM metadata for 12.2.2 does not enumerate the underlying tables for this package; the "Tables referenced via APPS synonyms" list is empty in the provided excerpt. Based on the replenishment domain and the presence of UPDATE_DELIVERY_DETAIL, the package operates against the WMS and shipping tables accessed through APPS synonyms — most notably WSH_DELIVERY_DETAILS, the move-order tables (MTL_MATERIAL_TRANSACTIONS and associated move-order headers/lines), the replenishment rule and batch tables, and inventory item/location tables in MTL. Because the specific synonym list is not documented, implementers should query DBA_DEPENDENCIES for WMS_REPLENISHMENT_PUB on a live 12.1.1 or 12.2.2 instance to obtain the authoritative read/write set before extending or wrapping the API.

Usage Notes

The package is invoked from three primary contexts. First, the Oracle Warehouse Management concurrent programs "Replenish" and "Push Replenishment" call the _CP procedures, which is why those wrappers carry the errbuf/retcode signature. Second, WMS setup and execution forms call the non-suffixed procedures directly to trigger on-demand replenishment. Third, custom code should call only the non-suffixed (DYNAMIC_REPLENISHMENT, PUSH_REPLENISHMENT, UPDATE_DELIVERY_DETAIL) procedures, since these include the standard validation and message-stack handling; the _CP variants are reserved for concurrent-program registration. All callers must check x_return_status and drain x_msg_data/x_msg_count using the standard FND_MSG_PUB API. Because the package is referenced by four other packages, changes to its signature or behavior have downstream impact and should be regression-tested across the affected dependency chain. The API is compatible with both EBS 12.1.1 and 12.2.2, though the 12.2.x online-patching AD/TXK architecture does not alter the API contract.