Search Results wsm_lot_move_txn_interface




Overview

The WSM_LOT_MOVE_TXN_INTERFACE table is a critical data interface within the Oracle E-Business Suite (EBS) Shop Floor Management (WSM) module for versions 12.1.1 and 12.2.2. It serves as the staging table for importing lot-based job shop floor move transactions into the Oracle Shop Floor Management (OSFM) application. This table is central to the transactional flow for discrete manufacturing jobs that utilize lot control, enabling the bulk or programmatic entry of material movement between operations and departments. Its primary role is to hold transaction data in a pending state before it is validated and processed by the relevant concurrent programs or APIs, which subsequently post the data to core inventory and work-in-process (WIP) tables.

Key Information Stored

The table stores a comprehensive set of attributes required to define a lot move transaction. The primary key is the HEADER_ID, which uniquely identifies each interface record. Essential columns define the transaction's context and specifics, including WIP_ENTITY_ID (identifying the specific manufacturing job or schedule), LINE_ID (the production line), and ORGANIZATION_ID. Transaction movement is captured through FM_DEPARTMENT_ID and TO_DEPARTMENT_ID. Lot-specific details, such as the lot number and quantity to move, are stored alongside transaction dates and reference information. The table also includes columns for handling exceptions, such as REASON_ID for explanatory codes and SCRAP_ACCOUNT_ID for financial posting of scrapped material, ensuring a complete audit trail and integration with financials.

Common Use Cases and Queries

The primary use case is the batch import of move transactions from external manufacturing execution systems (MES), data collection devices, or legacy systems. A common operational pattern involves inserting records into this interface and then running the standard "Import Move Transactions" concurrent request to validate and process them. For troubleshooting, queries often target pending or errored transactions. A sample SQL pattern to identify unprocessed interface records for a specific job would be:

  • SELECT header_id, wip_entity_id, transaction_quantity, transaction_date FROM wsm_lot_move_txn_interface WHERE process_flag = 1 AND organization_id = 123;

Reporting use cases frequently involve analyzing transaction flow by joining to WIP_ENTITIES and BOM_DEPARTMENTS to generate shop floor performance metrics, such as move cycle times between specific departments for lot-controlled jobs.

Related Objects

The table maintains strict referential integrity with several core EBS tables via foreign key constraints, as documented in the ETRM. These relationships are essential for validating interface data before processing.

  • WIP_ENTITIES: Joined via WSM_LOT_MOVE_TXN_INTERFACE.WIP_ENTITY_ID. Validates the existence of the discrete job or repetitive schedule.
  • WIP_LINES: Joined via WSM_LOT_MOVE_TXN_INTERFACE.LINE_ID. Validates the production line assignment.
  • BOM_DEPARTMENTS (two relationships): Joined via FM_DEPARTMENT_ID and TO_DEPARTMENT_ID. Validates the source and destination departments for the move operation.
  • MTL_TRANSACTION_REASONS: Joined via REASON_ID. Validates the user-defined reason code for the transaction.
  • GL_CODE_COMBINATIONS: Joined via SCRAP_ACCOUNT_ID. Validates the general ledger account for scrap accounting.
  • WSM_PARAMETERS: Joined via ORGANIZATION_ID. Validates the organization context against WSM setup.