Results for “wms_tasks_v”

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

Overview

WMS_TASKS_V is a reporting view owned by the APPS schema in the Warehouse Management (WMS) module of Oracle E-Business Suite. It presents a consolidated, denormalized picture of warehouse execution tasks by joining temporary material transaction records to their associated dispatched task details. The view is the principal mechanism by which task-level information — the physical movement of goods through the warehouse — becomes queryable without requiring the caller to reconcile the transaction staging tables against the dispatch tables manually. Because material transaction action identifiers such as TRANSACTION_ACTION_ID are exposed through a lookup join (ML1.MEANING), the view is frequently the object behind inquiries into what a transaction actually did, which aligns directly with searches for the MTL_TRANSACTION_ACTION concept. The view is documented as VALID in both 12.1.1 and 12.2.2.

Underlying Base Objects

The view is defined primarily over MTL_MATERIAL_TRANSACTIONS_TEMP (aliased MMTT) with a LEFT OUTER JOIN to WMS_DISPATCHED_TASKS (WDT), which supplies the task-oriented columns; NVL expressions such as NVL(WDT.STATUS, 1) and NVL(WDT.TASK_TYPE, MMTT.WMS_TASK_TYPE) confirm that task rows may be absent and transaction attributes used instead. Supporting lookups and descriptions are sourced from MTL_SYSTEM_ITEMS_KFV, MTL_ITEM_LOCATIONS_KFV, MTL_PARAMETERS, MTL_TRANSACTION_LOTS_TEMP, MTL_TRANSACTION_LOT_NUMBERS, MTL_TRANSACTION_TYPES, MTL_TXN_SOURCE_TYPES, MFG_LOOKUPS (four separate aliases), HR_ALL_ORGANIZATION_UNITS, BOM_STANDARD_OPERATIONS, BOM_RESOURCES, PER_ALL_PEOPLE_F, and WMS_DISPATCHED_TASKS_HISTORY. Notably, the current WMS_TASKS_V definition references MTL_MATERIAL_TRANSACTIONS_TEMP rather than the permanent MTL_MATERIAL_TRANSACTIONS table, so it reflects in-flight or pending transaction context.

Key Columns

• TRANSACTION_TEMP_ID, INVENTORY_ITEM_ID, ORGANIZATION_ID — task and item identity, with item description and concatenated segments from MTL_SYSTEM_ITEMS_KFV.
• TRANSACTION_ACTION_ID and ML1.MEANING — the decoded transaction action (for example, issue, receipt, transfer), which is the attribute users search for when investigating MTL_TRANSACTION_ACTION.
• TRANSACTION_TYPE_ID / MTT.DESCRIPTION — transaction type classification.
• LOCATOR_ID, SUBINVENTORY_CODE, LOT_NUMBER, REVISION — source location detail.
• TRANSFER_ORGANIZATION, TRANSFER_SUBINVENTORY, TRANSFER_TO_LOCATION — destination detail for inter-org and intra-org moves.
• TASK_ID, TASK_TYPE, STATUS, PRIORITY — dispatch-level task attributes from WMS_DISPATCHED_TASKS.
• PERSON_ID / FULL_NAME and EQUIPMENT_ID / EQUIPMENT_INSTANCE — assigned labor and equipment resources, with BOM_RESOURCES codes.
• DISPATCHED_TIME, LOADED_TIME, DROP_OFF_TIME — task execution timestamps.
• TRANSACTION_QUANTITY (DECODE on MTL_TRANSACTION_LOTS_TEMP) — quantity, overridden by lot-level quantity where present.
• ATTRIBUTE1 through ATTRIBUTE15 — extensible descriptive flexfield columns carried from WMS_DISPATCHED_TASKS.

Common Use Cases and Queries

Typical uses include warehouse task dashboards, picking and put-away tracking, labor and equipment utilization reporting, and reconciliation of dispatched tasks against their underlying material transactions.

Listing open tasks with their item and action:

SELECT task_id, organization_code, concatenated_segments,
       meaning, status, dispatched_time
FROM   apps.wms_tasks_v
WHERE  status IN (1,2)
ORDER  BY dispatched_time;

Finding all activity for a specific action (the MTL_TRANSACTION_ACTION lookup):

SELECT task_id, inventory_item_id, transaction_temp_id,
       meaning, transaction_quantity, subinventory_code
FROM   apps.wms_tasks_v
WHERE  transaction_action_id = :action_id;

Joining to the permanent transaction table for history comparison:

SELECT t.task_id, t.meaning, m.transaction_id, m.transaction_date
FROM   apps.wms_tasks_v t,
       apps.mtl_material_transactions m
WHERE  t.inventory_item_id = m.inventory_item_id
AND    t.transaction_temp_id = m.transaction_source_id;

Because the view draws on temporary transaction staging, results should be interpreted as pending or recently dispatched work rather than posted inventory history.