Results for “primary_component_id”

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

Overview

WIP_REQUIREMENT_OPERATIONS is a core Oracle Work in Process (WIP) table that stores the component (material) requirements attached to discrete jobs and repetitive schedules. Each row represents a single component requirement against a specific operation sequence, capturing what material must be issued, from which supply source, in what quantity, and by what date. In Oracle EBS 12.1.1 and 12.2.2, this table is populated when a job or schedule is created or released, either from the bill of materials (BOM) explosion or through manual entry, and it drives material issue transactions, backflush, pick release, and shop floor material availability reporting.

The 79-column structure carries the full lifecycle of a material requirement: the planned quantity, the issued quantity, costed quantities, relief quantities, and allocation/backorder state. Under a heuristic Data Vault classification derived from its foreign key pattern, WIP_REQUIREMENT_OPERATIONS behaves as a link object — it resolves the association between manufactured entities (jobs or repetitive schedules), operations, and inventory items, with descriptive quantity and scheduling attributes carried alongside. This classification is a modeling suggestion, not a documented Oracle designation.

Key Information Stored

The table's uniqueness is enforced by the primary key WIP_REQUIREMENT_OPERATIONS_PK, defined on the composite of INVENTORY_ITEM_ID, WIP_ENTITY_ID, OPERATION_SEQ_NUM, and REPETITIVE_SCHEDULE_ID. A second unique index, WIP_REQUIREMENT_OPERATIONS_U1, adds ORGANIZATION_ID to that same column set, confirming the natural business key of the record.

• INVENTORY_ITEM_ID — the component being required; foreign key to MTL_SYSTEM_ITEMS_B.
• ORGANIZATION_ID — the inventory organization in which the requirement exists.
• WIP_ENTITY_ID — the discrete job that owns the requirement; foreign key to WIP_DISCRETE_JOBS.
• REPETITIVE_SCHEDULE_ID — the repetitive schedule, when the requirement originates from a schedule rather than a discrete job.
• OPERATION_SEQ_NUM — the operation at which the component is consumed; ties the row to WIP_OPERATIONS.
• COMPONENT_SEQUENCE_ID — the BOM component definition from which the requirement was exploded; foreign key to BOM_COMPONENTS_B.
• DEPARTMENT_ID — the department owning the operation; foreign key to BOM_DEPARTMENTS.
• REQUIRED_QUANTITY and QUANTITY_PER_ASSEMBLY — the total requirement and the per-unit usage rate.
• QUANTITY_ISSUED, QUANTITY_RELIEVED, COSTED_QUANTITY_ISSUED, and COSTED_QUANTITY_RELIEVED — transactional and costed issue/relief accumulators.
• QUANTITY_ALLOCATED and QUANTITY_BACKORDERED — allocation and shortfall tracking for the requirement.
• DATE_REQUIRED — the date the component is needed on the shop floor.
• SUPPLY_SUBINVENTORY and SUPPLY_LOCATOR_ID — the default supply source; foreign keys to MTL_SECONDARY_INVENTORIES and MTL_ITEM_LOCATIONS.
• WIP_SUPPLY_TYPE — indicates push, pull, or operation pull (backflush) behavior.
• AUTO_REQUEST_MATERIAL — flag controlling automatic requisition of the component.

The SEGMENT1–SEGMENT20 and ATTRIBUTE1–ATTRIBUTE15 columns provide the standard Oracle flexfield and descriptive flexfield storage for the requirement row.

Common Use Cases and Queries

Typical reporting and integration scenarios include material availability versus requirement analysis, backflush exception reporting, and material issue reconciliation. A common query joins requirements to jobs and items to identify shortfalls:

• Open component requirements by job: filter on WIP_ENTITY_ID and compare REQUIRED_QUANTITY against QUANTITY_ISSUED.
• Backorder and allocation review: select rows where QUANTITY_BACKORDERED > 0 to drive expediting decisions.
• Supply source validation: join SUPPLY_SUBINVENTORY to MTL_SECONDARY_INVENTORIES to confirm picks route to valid subinventories.
• Cost reconciliation: compare COSTED_QUANTITY_ISSUED with QUANTITY_ISSUED to detect costing discrepancies after period close.
• Repetitive schedule material planning: group by REPETITIVE_SCHEDULE_ID and DATE_REQUIRED to project component demand.

Sample pattern: SELECT w.WIP_ENTITY_ID, w.INVENTORY_ITEM_ID, w.OPERATION_SEQ_NUM, w.REQUIRED_QUANTITY, w.QUANTITY_ISSUED FROM WIP.WIP_REQUIREMENT_OPERATIONS w WHERE w.ORGANIZATION_ID = :org AND w.QUANTITY_ISSUED < w.REQUIRED_QUANTITY;

Related Objects

The table's foreign keys and parent relationships define its most significant dependencies:

• WIP_DISCRETE_JOBS — joined on WIP_ENTITY_ID; the discrete job header owning the requirement.
• WIP_REPETITIVE_SCHEDULES — joined on REPETITIVE_SCHEDULE_ID; the repetitive schedule alternative to a discrete job.
• WIP_OPERATIONS — joined on WIP_ENTITY_ID, OPERATION_SEQ_NUM, and REPETITIVE_SCHEDULE_ID; the routing operation consuming the component.
• MTL_SYSTEM_ITEMS_B — joined on INVENTORY_ITEM_ID and ORGANIZATION_ID; the component item master.
• BOM_COMPONENTS_B — joined on COMPONENT_SEQUENCE_ID; the originating bill of materials component.
• BOM_DEPARTMENTS — joined on DEPARTMENT_ID; the department owning the consuming operation.
• MTL_SECONDARY_INVENTORIES, MTL_ITEM_SUB_INVENTORIES, and MTL_ITEM_LOCATIONS — joined on SUPPLY_SUBINVENTORY, INVENTORY_ITEM_ID, and SUPPLY_LOCATOR_ID; the validated supply sources.
• MTL_SECONDARY_LOCATORS — joined on INVENTORY_ITEM_ID, ORGANIZATION_ID, and SUPPLY_LOCATOR_ID; locator validation.

Downstream, WIP material issue and completion processes consume these rows to generate inventory transactions against MTL_TRANSACTIONS_INTERFACE and MTL_MATERIAL_TRANSACTIONS.