Results for “mps_net_quantity”

10 results




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

Overview

WIP_FLOW_SCHEDULES is the Work in Process (WIP) table that stores work order-less flow schedules in Oracle E-Business Suite releases 12.1.1 and 12.2.2. Flow schedules represent a repetitive manufacturing model in which production is executed without discrete work orders, and this table is the master record for each flow schedule, holding the scheduling, routing, BOM, accounting, and demand attributes that govern how the build is performed and costed. The table resides in the WIP schema and is owned by the WIP - Work in Process product.

Each flow schedule is tightly coupled to a row in WIP_ENTITIES; the WIP_ENTITY_ID column is the primary key and the linking attribute to that parent entity. The ETRM relationship data classifies the object as satellite-leaning, meaning it is best modelled as a satellite carrying descriptive and control attributes attached to the WIP entity hub, rather than as an independent hub or link. A composite unique index, WIP_FLOW_SCHEDULES_U1 (WIP_ENTITY_ID, ORGANIZATION_ID), and a business-key unique index, WIP_FLOW_SCHEDULES_U2 (SCHEDULE_NUMBER, ORGANIZATION_ID), enforce uniqueness and support keyed lookups. The physical schema documents 78 columns.

Key Information Stored

The most operationally significant columns fall into four groups.

Common Use Cases and Queries

Flow schedules are queried for production status reporting, costing, and demand pegging. A typical pattern joins WIP_FLOW_SCHEDULES to WIP_ENTITIES and MTL_SYSTEM_ITEMS_B:

  • Open schedules in an org: SELECT schedule_number, primary_item_id, planned_quantity, scheduled_completion_date FROM wip_flow_schedules WHERE organization_id = :org AND status <> 12;
  • Quantity fulfilment: compare PLANNED_QUANTITY against QUANTITY_COMPLETED and QUANTITY_SCRAPPED to measure yield.
  • Cost and variance review: aggregate schedules by MATERIAL_VARIANCE_ACCOUNT or RESOURCE_VARIANCE_ACCOUNT, joining GL_CODE_COMBINATIONS to read the account combination.
  • Kanban-driven replenishment: filter on KANBAN_CARD_ID, AUTO_REPLENISH, or DEMAND_SOURCE_TYPE to trace demand origin back to MTL_KANBAN_CARDS or the demand source header.
  • Transaction reconciliation: join MTL_MATERIAL_TRANSACTIONS.TRANSACTION_SOURCE_ID to WIP_ENTITY_ID (or SCHEDULE_NUMBER) to trace material issues and completions to the schedule.

Related Objects

The most significant related objects, with their join columns, are:

  • WIP_ENTITIES — parent entity; join on WIP_ENTITY_ID (also the primary key).
  • MTL_SYSTEM_ITEMS_B — item definition; join on PRIMARY_ITEM_ID and ORGANIZATION_ID.
  • MTL_ITEM_REVISIONS_B, MTL_RTG_ITEM_REVISIONS, BOM_STRUCTURES_B, and BOM_OPERATIONAL_ROUTINGS — BOM and routing validation using PRIMARY_ITEM_ID, ORGANIZATION_ID, and the revision/alternate columns.
  • GL_CODE_COMBINATIONS — all ten account columns (material, resource, overhead, outside processing, and variance accounts) reference this table.
  • MTL_KANBAN_CARDS — join on KANBAN_CARD_ID for pull-based replenishment.
  • MTL_ITEM_LOCATIONS — join on COMPLETION_LOCATOR_ID for completion location.
  • WIP_PERIOD_BALANCES — references WIP_ENTITY_ID for period cost balances.
  • MTL_MATERIAL_TRANSACTIONS and MTL_TRANSACTIONS_INTERFACE — reference TRANSACTION_SOURCE_ID and SCHEDULE_NUMBER respectively, linking transactions to schedules.
  • WIP_SCHEDULE_GROUPS — join on SCHEDULE_GROUP_ID.