Search Results fm_operation_code

Overview

WIP_MOVE_TXN_INTERFACE_V is an APPS-owned database view in the Work in Process (WIP) module of Oracle E-Business Suite, valid in both release 12.1.1 and 12.2.2. It presents foreign-key data for the move transaction interface, resolving the various coded identifiers stored in the interface table into descriptive values that are meaningful to users and downstream integrations. In the WIP transaction flow, move transactions record the movement of assemblies from one operation to the next within a discrete job or repetitive schedule. The interface table WIP_MOVE_TXN_INTERFACE is the staging area into which external systems—such as manufacturing execution systems (MES), shop-floor data collection devices, or custom concurrent programs—insert move transaction records before the Move Transaction Manager processes them. The view layers decoded meanings over the raw interface rows so that reports and diagnostic queries can display readable operation, department, status, and transaction-type descriptions without joining MFG_LOOKUPS repeatedly.

The view is read-oriented and inherits the transactional and audit columns of the underlying interface table. It does not perform validation, defaulting, or processing; it exists purely as a convenience presentation layer for foreign-key resolution and reporting.

Underlying Base Objects

The documented base objects are MFG_LOOKUPS (VIEW) and WIP_MOVE_TXN_INTERFACE (SYNONYM). The view text confirms this: the driving table is WIP_MOVE_TXN_INTERFACE aliased WMTI, and five aliases of MFG_LOOKUPS (ML, ML2, ML3, ML4, ML5) provide lookup meanings. Each lookup join decodes a specific LOOKUP_TYPE: transaction type, process phase, process status, and the from/to intraoperation step types. Because the underlying interface object is exposed to the view as a synonym, the view reads the same physical table regardless of the schema from which it is queried, while the joins to MFG_LOOKUPS translate the stored codes into their MEANING values. The ROWID of the interface row is preserved as ROW_ID, allowing the view to remain updatable for simple columns under standard Oracle rules.

Key Columns

The view exposes the full column set of WIP_MOVE_TXN_INTERFACE plus five joined meaning columns. Columns relevant to the user's search for FM_OPERATION_CODE include:

• FM_OPERATION_CODE and FM_OPERATION_SEQ_NUM — the "from" operation code and sequence number from which the assembly is being moved.
• TO_OPERATION_CODE and TO_OPERATION_SEQ_NUM — the destination operation code and sequence number.
• FM_DEPARTMENT_ID/FM_DEPARTMENT_CODE and TO_DEPARTMENT_ID/TO_DEPARTMENT_CODE — the source and destination departments.
• FM_INTRAOPERATION_STEP_TYPE and TO_INTRAOPERATION_STEP_TYPE — the within-operation step (Queue, Run, To Move, Reject, Scrap), decoded into FM_INTRAOPERATION_STEP_MEANING and TO_INTRAOPERATION_STEP_MEANING.
• PROCESS_PHASE and PROCESS_STATUS — processing state of the interface row, with meanings PROCESS_PHASE_MEANING and PROCESS_STATUS_MEANING.
• TRANSACTION_TYPE with TRANSACTION_TYPE_MEANING, and TRANSACTION_QUANTITY, PRIMARY_QUANTITY, and their UOMs.
• Identity and context columns: TRANSACTION_ID, GROUP_ID, SOURCE_CODE, SOURCE_LINE_ID, ORGANIZATION_ID, WIP_ENTITY_ID, WIP_ENTITY_NAME, TRANSACTION_DATE, ACCT_PERIOD_ID, and the ATTRIBUTE1–ATTRIBUTE15 descriptive flexfield columns.

Common Use Cases and Queries

Typical scenarios include auditing staged move transactions prior to processing, troubleshooting rows that failed the Move Transaction Manager, and producing shop-floor or integration reports. A query keyed on the from-operation code is the most direct application of the searched column:

• SELECT transaction_id, wip_entity_name, fm_operation_seq_num, fm_operation_code, to_operation_code, transaction_type_meaning, process_status_meaning FROM wip_move_txn_interface_v WHERE fm_operation_code = :p_code AND organization_id = :p_org;
• Identifying unprocessed rows: filter on PROCESS_STATUS (for example, pending or error) and order by CREATION_DATE to isolate recent batches, using GROUP_ID to group a single load.
• Cross-checking scrap or rejection steps by selecting rows where FM_INTRAOPERATION_STEP_MEANING or TO_INTRAOPERATION_STEP_MEANING equals a scrap or reject value.
• Joining back to WIP_ENTITIES or BOM_OPERATION_SEQUENCES through WIP_ENTITY_ID and the operation sequence for enriched reporting.

Because the view reflects the staging table directly, queries return exactly what was inserted, with no additional validation. Corrections must be made in WIP_MOVE_TXN_INTERFACE itself or through the supported move transaction interfaces.