Search Results to_operation

Overview

The WIPFV_WIP_MOVE_TRANSACTIONS view is an APPS-owned, VALID database object in the Oracle E-Business Suite Work in Process (WIP) module. It exposes a denormalized, report-ready projection of shop-floor move transactions recorded against discrete WIP jobs. Where the base table WIP_MOVE_TRANSACTIONS stores raw foreign keys and codes, this view resolves those references into human-readable identifiers — department codes, organization code, WIP entity name, line code, accounting period name, unit-of-measure codes, and reason names — so that operational and analytical reports can be written without repeated multi-table joins.

The view is a "flexfield-friendly" construct. It embeds descriptive-flexfield reference tokens (for example '_KF:INV:MSTK:SY', '_KF:SQLGL:GL#:CO', and '_DF:WIP:WIP_MOVE_TRANSACTIONS:MO'), which signal to Oracle Reports/BI Publisher that key and descriptive flexfields must be expanded at runtime. It also preserves both the from-operation and to-operation attributes, making it directly relevant to the to_operation search that surfaced this object.

Underlying Base Objects

The ETRM metadata documents the view as being defined over thirteen base objects, all referenced through APPS synonyms: WIP_MOVE_TRANSACTIONS (the driving table, alias MO), WIP_ENTITIES, WIP_LINES, BOM_DEPARTMENTS (aliased twice — DE1 for the from-department and DE2 for the to-department), MTL_PARAMETERS, MTL_UNITS_OF_MEASURE (aliased twice — UN1 for transaction UOM, UN2 for primary UOM), MTL_TRANSACTION_REASONS, ORG_ACCT_PERIODS, HR_ALL_ORGANIZATION_UNITS, GL_CODE_COMBINATIONS, QA_PLANS, QA_RESULTS, and MTL_SYSTEM_ITEMS. Joins are performed by ORGANIZATION_ID, WIP_ENTITY_ID, ACCT_PERIOD_ID, DEPARTMENT_ID, UOM_CODE, LINE_ID, REASON_ID, and SCRAP_ACCOUNT_ID. Notably, the joins to WIP_LINES, MTL_TRANSACTION_REASONS, and GL_CODE_COMBINATIONS are outer joins, preserving move rows even when optional references are null.

Several referenced objects in the FROM clause (such as QA_PLANS, QA_RESULTS, and MTL_SYSTEM_ITEMS) do not contribute columns to the SELECT list but exist as legacy Cartesian-era joins in the original view definition.

Key Columns

• TRANSACTION_ID — primary key of the underlying move transaction; the join key back to WIP_MOVE_TRANSACTIONS.
• FM_OPERATION_CODE / TO_OPERATION_CODE — the from and to operation codes; the to-operation is the operation the material is being moved into.
• FM_DEPARTMENT_ID / TO_DEPARTMENT_ID — foreign keys to departments, resolved as two DEPARTMENT_CODE columns via DE1 and DE2.
• FM_OPERATION_SEQ_NUM / TO_OPERATION_SEQ_NUM — operation sequence numbers marking routing steps.
• TRANSACTION_QUANTITY / PRIMARY_QUANTITY — quantity moved in the transaction UOM and in the item's primary UOM.
• OVERCOMPLETION_TRANSACTION_QTY / OVERCOMPLETION_PRIMARY_QTY — quantities beyond the job's planned quantity.
• TRANSACTION_UOM / PRIMARY_UOM — resolved to UNIT_OF_MEASURE values by UN1 and UN2.
• WIP_ENTITY_NAME — the job or repetitive schedule identifier.
• LINE_CODE — the production line, where applicable.
• PERIOD_NAME — the accounting period from ORG_ACCT_PERIODS.
• REASON_NAME — the reason for scrap or rejection, when a reason ID is populated.
• GROUP_ID, REFERENCE, ORGANIZATION_CODE, and audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY).

Common Use Cases and Queries

This view is typically consumed by move-transaction reports, shop-floor "where did this job go next" inquiries, scrap analysis, and to-operation throughput reporting. A query targeting the to-operation focus might read:

SELECT WIP_ENTITY_NAME, FM_OPERATION_CODE, TO_OPERATION_CODE,
       TRANSACTION_QUANTITY, DEPARTMENT_CODE, PERIOD_NAME
FROM   APPS.WIPFV_WIP_MOVE_TRANSACTIONS
WHERE  WIP_ENTITY_NAME = :job
ORDER  BY TRANSACTION_DATE;

Because the view already resolves department, UOM, and reason codes, it is well suited to ad-hoc reporting layers and to report data models that would otherwise require extensive joins to BOM_DEPARTMENTS and MTL_UNITS_OF_MEASURE. Queries should filter by ORGANIZATION_ID to preserve multi-org scoping and by TRANSACTION_DATE or PERIOD_NAME to bound result sets.