Results for “wip_operations”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

WIP_OPERATIONS is the core transactional table within the Oracle Work in Process (WIP) module that stores the routing operations associated with discrete jobs and repetitive schedules. Each row represents a single operation step on the manufacturing floor, capturing the sequence position, department assignment, quantity flow, and scheduling dates required to move material through production. In Oracle EBS 12.1.1 and 12.2.2 the table resides in the WIP schema and is classified as VALID in the ETRM repository.

Because the table anchors a wide fan-out of dependent child records — resources, requirement operations, sub-operation resources, and move transaction interfaces — a Data Vault modeling heuristic suggests treating WIP_OPERATIONS as a hub. It holds the durable business key of a manufactured operation, while the descriptive quantity and status columns behave in a satellite-like manner, and the adjacency columns (previous/next operation sequence) introduce recursive link characteristics.

Key Information Stored

The primary key, WIP_OPERATIONS_PK, is composed of WIP_ENTITY_ID, OPERATION_SEQ_NUM, and REPETITIVE_SCHEDULE_ID. A second unique index, WIP_OPERATIONS_U1, adds ORGANIZATION_ID to that key set, making it the stronger business-key candidate. Notable columns include:

• WIP_ENTITY_ID — identifies the discrete job or repetitive schedule the operation belongs to.
• OPERATION_SEQ_NUM — the sequence number positioning the operation on the routing.
• REPETITIVE_SCHEDULE_ID — links the operation to a repetitive schedule when applicable.
• ORGANIZATION_ID — the inventory organization in which the operation executes.
• OPERATION_SEQUENCE_ID / STANDARD_OPERATION_ID — pointers to the BOM routing and standard operation definitions.
• DEPARTMENT_ID — the department responsible for the operation, referencing BOM_DEPARTMENTS.
• SCHEDULED_QUANTITY — the planned quantity to be processed.
• Quantity buckets: QUANTITY_IN_QUEUE, QUANTITY_RUNNING, QUANTITY_WAITING_TO_MOVE, QUANTITY_REJECTED, QUANTITY_SCRAPPED, QUANTITY_COMPLETED.
• Date columns: FIRST_UNIT_START_DATE, FIRST_UNIT_COMPLETION_DATE, LAST_UNIT_START_DATE, LAST_UNIT_COMPLETION_DATE, DATE_LAST_MOVED.
• PREVIOUS_OPERATION_SEQ_NUM / NEXT_OPERATION_SEQ_NUM — self-referencing navigation of the routing chain.
• COUNT_POINT_TYPE / BACKFLUSH_FLAG / MINIMUM_TRANSFER_QUANTITY — shop-floor control attributes governing moves and backflush behavior.
• OPERATION_YIELD, OPERATION_YIELD_ENABLED, LOWEST_ACCEPTABLE_YIELD — quality and yield thresholds.
• SKIP_FLAG, OPERATION_COMPLETED, PROGRESS_PERCENTAGE — status and completion tracking.
• Standard 15 ATTRIBUTE columns plus WF_ITEMTYPE/WF_ITEMKEY for workflow integration.

The table carries 76 columns in total, including audit columns (LAST_UPDATE_DATE, CREATED_BY) and WSM-related columns supporting shop-floor execution.

Common Use Cases and Queries

WIP_OPERATIONS is queried for shop-floor status reporting, move transaction processing, WIP valuation, and routing analysis. A typical pattern retrieves open operations for a job with remaining work:

• SELECT operation_seq_num, department_id, scheduled_quantity, quantity_completed FROM wip_operations WHERE wip_entity_id = :p_entity_id ORDER BY operation_seq_num;
• Bottleneck identification across departments joins to BOM_DEPARTMENTS: SELECT d.department_code, SUM(o.quantity_running) FROM wip_operations o, bom_departments d WHERE o.department_id = d.department_id GROUP BY d.department_code;
• Move interface validation joins WIP_MOVE_TXN_INTERFACE on WIP_ENTITY_ID and TO_OPERATION_SEQ_NUM to confirm a target operation exists before processing.
• Yield variance reporting leverages OPERATION_YIELD against SCHEDULED_QUANTITY versus QUANTITY_COMPLETED.
• Completion dashboards filter on OPERATION_COMPLETED = 'Y' and DATE_LAST_MOVED range for period close reporting.

Because the table is transactional and high-volume, queries should always predicate on WIP_ENTITY_ID or ORGANIZATION_ID to exploit the unique index and avoid full scans.

Related Objects

The table participates in an extensive referential network:

• WIP_DISCRETE_JOBS — parent job header, joined on WIP_ENTITY_ID.
• WIP_REPETITIVE_SCHEDULES — parent schedule, joined on REPETITIVE_SCHEDULE_ID.
• BOM_DEPARTMENTS — provides department details via DEPARTMENT_ID.
• BOM_OPERATION_SEQUENCES — source routing definition via OPERATION_SEQUENCE_ID.
• WIP_OPERATION_RESOURCES — child records of resources consumed, joined on WIP_ENTITY_ID, OPERATION_SEQ_NUM, REPETITIVE_SCHEDULE_ID.
• WIP_REQUIREMENT_OPERATIONS — component demand per operation, using the same three-column join.
• WIP_SUB_OPERATION_RESOURCES — sub-operation resource detail.
• WIP_MOVE_TXN_INTERFACE — staging table for move transactions, referencing FROM and TO operation sequence numbers.
• JAI_PO_OSP_LINES — outside processing lines tied to WIP entities and operations.
• WSM_OPERATION_DETAILS — referenced through STANDARD_OPERATION_ID for shop-floor execution data.

Together these relationships position WIP_OPERATIONS as the operational hub through which discrete and repetitive manufacturing execution data flows in Oracle EBS.