Search Results wip_job_schedule_interface

Overview

The WIP_JOB_SCHEDULE_INTERFACE table is a critical staging table within the Oracle E-Business Suite Work in Process (WIP) module. Its primary role is to serve as the data interface for programmatically creating, updating, and scheduling discrete jobs and repetitive schedules. This table acts as the intermediary between external systems, custom programs, or data loads and the core WIP transactional tables. Data is inserted into this interface table, and then a standard concurrent request, typically the "Move Transaction Manager" or "WIP Mass Load" programs, processes the rows, validates the data against business rules, and creates the corresponding records in the definitive WIP_DISCRETE_JOBS or WIP_REPETITIVE_SCHEDULES tables. This design ensures data integrity and leverages Oracle's built-in validation logic for all job and schedule transactions.

Key Information Stored

The table holds a comprehensive set of attributes required to define a manufacturing job or schedule. Key columns include identifiers such as GROUP_ID and REQUEST_ID for grouping and tracking interface submissions, and PROCESS_PHASE and PROCESS_STATUS to control the interface processing workflow. Essential job definition columns are WIP_ENTITY_ID (for updates), PRIMARY_ITEM_ID, CLASS_CODE, QUANTITY, and START_QUANTITY. Scheduling is controlled by columns like FIRST_UNIT_START_DATE, FIRST_UNIT_COMPLETION_DATE, LAST_UNIT_START_DATE, and LAST_UNIT_COMPLETION_DATE. The table also stores references to associated manufacturing data, including ORGANIZATION_ID, LINE_ID, ALTERNATE_BOM_DESIGNATOR, and ALTERNATE_ROUTING_DESIGNATOR. The END_ITEM_UNIT_NUMBER column supports project manufacturing (PJM) integrations.

Common Use Cases and Queries

The primary use case is the bulk creation or modification of jobs from external planning systems (like ASCP), custom manufacturing execution systems (MES), or legacy data migrations. A typical implementation involves a custom PL/SQL procedure that populates the interface table and then submits the standard concurrent request to process it. Common diagnostic queries include checking for rows in error to facilitate troubleshooting. For example:

• Identifying pending interface rows: SELECT group_id, wip_entity_name, process_status FROM wip_job_schedule_interface WHERE process_phase = 1 AND process_status in (1,3);
• Reviewing error details for failed rows: SELECT error_message FROM wip_job_schedule_interface WHERE process_status = 3;

Reporting directly from this table is uncommon, as successful transactions are moved to the main WIP tables.

Related Objects

As documented in the ETRM, WIP_JOB_SCHEDULE_INTERFACE has extensive foreign key relationships, underscoring its role as a central interface. Key related transactional tables include:

• WIP_DISCRETE_JOBS and WIP_REPETITIVE_SCHEDULES: The ultimate destination tables for processed interface rows, joined via WIP_ENTITY_ID and REPETITIVE_SCHEDULE_ID, respectively.
• BOM_STRUCTURES_B and BOM_OPERATIONAL_ROUTINGS: Validate the PRIMARY_ITEM_ID, ORGANIZATION_ID, and alternate designators for the bill of material and routing.
• WIP_ACCOUNTING_CLASSES: Validates the CLASS_CODE and ORGANIZATION_ID.
• WIP_PARAMETERS: Validates the ORGANIZATION_ID for WIP setup.
• WIP_LINES: Validates the LINE_ID for line scheduling.
• MTL_KANBAN_CARDS and PJM_UNIT_NUMBERS: Support kanban and project manufacturing integrations via KANBAN_CARD_ID and END_ITEM_UNIT_NUMBER.