Search Results device_confirmation

Overview

WMS_DEVICE_CONFIRMATION_PUB is a public PL/SQL package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the Warehouse Management System (WMS) module and functions as the device-facing confirmation layer for material handling transactions initiated from radio-frequency (RF) handheld devices, scanners, and automated warehouse control systems. The package translates a device-originated request into the corresponding Oracle Inventory transaction, validates the request against existing master and transactional data, and records the outcome for downstream auditing and integration.

Because the package is classified as a PUB (public) API within the ETRM object inventory and its status is VALID, Oracle supports its invocation from external code. It is a foundational component of the WMS device integration stack, positioned between the raw device request and the underlying inventory transaction APIs.

Key Procedures and Functions

The documented public interface consists of a single procedure.

• DEVICE_CONFIRMATION — The sole documented entry point. This procedure processes a confirmation request originating from a warehouse device. Based on the ETRM metadata and the tables it touches, it validates the device request, resolves the item, revision, subinventory, locator, lot, and serial context supplied by the device, and applies the resulting inventory transaction (move, issue, receipt, or completion) through the Inventory transaction interface. It also writes the request and its result to the device request history, enabling traceability of each device interaction.

No parameter list is documented in the ETRM metadata, and therefore none is asserted here. Callers should obtain the exact signature from the package specification in the target environment before invoking it from custom code.

Tables Accessed

The package reads and writes a broad set of inventory, bill of materials, and WMS device tables through APPS synonyms.

• WMS_DEVICE_REQUESTS / WMS_DEVICE_REQUESTS_HIST — The device request header and its history; used to stage the incoming request and record the confirmation outcome.
• MTL_MATERIAL_TRANSACTIONS_TEMP / MTL_MATERIAL_TRANSACTIONS_S — The Inventory transactions interface and the resulting transaction record created when a device confirmation posts.
• MTL_SYSTEM_ITEMS / MTL_SYSTEM_ITEMS_B — Item master validation for the item referenced by the device request.
• MTL_SECONDARY_INVENTORIES — Subinventory validation and default material account resolution.
• MTL_TRANSACTION_LOTS_TEMP / MTL_SERIAL_NUMBERS / MTL_SERIAL_NUMBERS_TEMP — Lot and serial number capture and validation for lot- and serial-controlled items.
• MTL_TRANSACTION_REASONS — Reason code validation where a device transaction requires a reason.
• MTL_TXN_REQUEST_LINES — Move order line validation when the device confirms a move order operation.
• BOM_RESOURCES / BOM_STD_OP_RESOURCES — Resource and standard operation resource lookups supporting work-in-process completion or resource-driven transactions from the shop floor.
• FND_USER — Resolution of the application user associated with the device session for audit purposes.

Usage Notes

WMS_DEVICE_CONFIRMATION_PUB is not intended for interactive form invocation. It is typically called by WMS integration and device-handling layers, notably WMS_DEVICE_INTEGRATION_PVT and WMS_WCS_DEVICE_GRP, both of which reference it according to the ETRM dependency listing. These callers broker communication between warehouse control systems, RF devices, and the EBS transaction engine.

Customizations and third-party warehouse execution systems that need to post device confirmations should call this package rather than inserting directly into the Inventory transaction interface tables, since the package encapsulates the required validation and history logging. Because the package also depends on the STANDARD package supplied by SYS, it follows standard PL/SQL execution semantics and participates in the calling session's transaction, meaning commit and rollback handling remain the responsibility of the caller. Administrators should verify the package status is VALID after patching, since an invalid state blocks RF device confirmations across the warehouse.