Search Results wsm_starting_jobs_interface




Overview
Explore in AI Chat

Overview

The WSM_STARTING_JOBS_INTERFACE table is a critical interface object within the Oracle E-Business Suite Shop Floor Management (WSM) module, specifically for versions 12.1.1 and 12.2.2. It functions as a staging table designed to import data for Work in Process (WIP) lot transaction operations, with a primary focus on capturing details for the starting lots involved in a transaction. As documented, it is explicitly defined as a child table to WSM_SPLIT_MERGE_TXN_INTERFACE. Its role is to serve as a temporary data repository where external systems or custom programs can insert records. These records are subsequently processed by Oracle's standard interface programs to execute and validate complex shop floor transactions, such as lot splits and merges, before the data is transferred to the core transactional tables.

Key Information Stored

While the provided metadata does not list specific columns beyond the key fields, the structure is defined by its primary and foreign key relationships. The primary key, HEADER_ID, uniquely identifies a set of starting lot records belonging to a single parent transaction header in the WSM_SPLIT_MERGE_TXN_INTERFACE table. The WIP_ENTITY_ID column is a foreign key that links each starting lot record to a specific WIP job or schedule (lot) defined in the WIP_ENTITIES table. This establishes the fundamental link between the interface data and the manufacturing entity being acted upon. Other typical columns in such an interface table would include attributes for the starting lot quantity, transaction date, and reference information, which collectively define the pre-transaction state of the manufacturing lot.

Common Use Cases and Queries

The primary use case for this table is the batch import of lot split and merge transactions. A common operational pattern involves populating the parent WSM_SPLIT_MERGE_TXN_INTERFACE header, then inserting corresponding child records into WSM_STARTING_JOBS_INTERFACE for each originating lot. After data insertion, a concurrent request (e.g., WSM Lot Split/Merge Transaction Import) is submitted to validate and process the records. For troubleshooting, analysts often query for unprocessed or error records. A sample query to examine pending interface records for a specific transaction header would be:

  • SELECT sj.wip_entity_id, we.wip_entity_name FROM wsm_starting_jobs_interface sj, wip_entities we WHERE sj.header_id = :p_header_id AND sj.wip_entity_id = we.wip_entity_id AND sj.process_flag IS NULL;

This helps verify the data before submission or diagnose import failures by checking the PROCESS_FLAG and ERROR_CODE columns, which are standard in Oracle interface tables.

Related Objects

The table maintains strict relational integrity with other core EBS objects, as defined by its foreign keys. The documented relationships are:

  • Parent Table (Header): WSM_SPLIT_MERGE_TXN_INTERFACE. Joined via HEADER_ID. This is the primary parent-child relationship where the header defines the transaction type and the child holds the specific starting lots.
  • Reference Table (Master Data): WIP_ENTITIES. Joined via WIP_ENTITY_ID. This ensures that every starting lot referenced in the interface corresponds to a valid, existing WIP job or repetitive schedule in the system.

Successful processing of records in this interface table will ultimately result in updates to core transactional tables such as WIP_TRANSACTIONS and WIP_LOT_MOVEMENTS, though these are not direct foreign key relationships from the interface itself.