Search Results wma_move




Overview
Explore in AI Chat

Overview

WMA_MOVE is a PL/SQL package in the APPS schema that supports shop floor move transactions within Oracle Work in Process. It operates primarily in the Oracle EBS 12.1.1 and 12.2.2 releases as part of the Warehouse Management and WIP transaction processing infrastructure. The package handles the movement of assemblies, components, and serialized items through manufacturing operations, both for discrete and repetitive work orders, and provides supporting logic for backflush processing. Its documented references to WIP_MOVE_TXN_INTERFACE and WIP_SERIAL_MOVE_INTERFACE confirm that it participates in the flow of move data through the WIP transaction interfaces, while its dependency on WMA_COMMON indicates shared utility routines for shop floor moves. The package is classified as OTHER in the ETRM metadata, meaning it is a supporting internal package rather than a formally published public API, though it is invoked by several other WIP private and processing packages.

Key Procedures and Functions

Eight documented procedures and functions make up the package's surface:

  • PROCESS — The primary driver routine that orchestrates a move transaction through the package's internal logic.
  • BACKFLUSH — Performs backflush processing for a move transaction, issuing components based on the bill of material requirements.
  • BF_REQUIRE — Determines backflush requirements, identifying the components that must be issued during the move.
  • ASSY_PULL_BF — Handles assembly pull-style backflush logic for components defined with pull sequences or related supply models.
  • VALIDATE — Validates move transaction input, ensuring the operation, quantities, and related attributes are consistent before processing.
  • DERIVE — Derives transaction attributes such as default operations or quantities from the supplied input.
  • PUT — Places or writes the resulting transaction data, typically into interface or base WIP tables.
  • INSERTSERIAL — Inserts serial number information for serialized items involved in the move.

Together, these routines separate validation, derivation, processing, and serial handling into distinct steps, allowing callers to drive move transactions with consistent sequencing.

Tables Accessed

The package references several WIP tables through public synonyms:

  • WIP_MOVE_TXN_INTERFACE — The move transaction interface table where move transactions are staged and processed.
  • WIP_OPERATIONS — Provides operation-level information for the work order being moved.
  • WIP_PARAMETERS — Supplies WIP system parameters and defaults that govern move and backflush behaviour.
  • WIP_SERIAL_MOVE_INTERFACE — Holds serial number move data for serialized transactions, populated by INSERTSERIAL and related logic.
  • WIP_SHOP_FLOOR_STATUSES and WIP_SHOP_FLOOR_STATUS_CODES — Provide the shop floor status definitions and valid status codes applied to moves and related operations.

WIP_LOT_SERIAL_OBJ_T appears in the dependency metadata as the object type used for lot and serial processing.

Usage Notes

WMA_MOVE is typically invoked indirectly rather than called directly by end users or custom code. The documented dependency list shows it is referenced by WIP_BATCH_MOVE, WIP_BFLPROC_PRIV, WIP_DISCRETE_WS_MOVE, and WIP_MOVPROC_PRIV, which correspond to batch move, backflush, discrete shop floor move, and move processing routines. These callers represent the standard WIP move and backflush paths, including those used by manufacturing forms and concurrent move processing. Because the package is classified as OTHER and is not a public API, extensions and customizations should generally call the documented public move APIs or use the move transaction interface rather than invoking WMA_MOVE procedures directly. Custom code that does call it should be aware that the package depends on WMA_COMMON and on the WIP interface and operations tables, so move transactions must be staged and validated consistently with the standard processing flow. No parameter lists or procedural signatures are documented in the ETRM metadata, so integrators should inspect the package specification in the target instance before use.