Search Results operation_plan_instance

Overview

WMS_WP_TASKS_GTMP_V is a reporting view owned by the APPS schema in Oracle E-Business Suite (documented for 12.2.2, applicable to 12.1.1). It is a thin projection over the Warehouse Management work-plan task staging object WMS_WP_TASKS_GTMP, exposing task-level detail for warehouse execution and mobile (RF) processing. The view presents task identity, transaction context, personnel, status, item, LPN, and operation-plan attributes in a single flattened structure, which makes it convenient for reporting, interfaces, and integration extracts without the caller needing to join the underlying task tables directly. Because the base object is referenced as a synonym, the view inherits whatever privileges are granted on that synonym within the APPS schema.

The view is not a business-transaction master; it is a staging/working projection. Records typically represent tasks in flight, including planned and modified tasks, and carry both original and current values for mutable attributes (for example PERSON_ID versus PERSON_ID_ORIGINAL, STATUS_ID versus STATUS_ID_ORIGINAL, PRIORITY versus PRIORITY_ORIGINAL). This aligns with Warehouse Management task generation and re-planning, where the system records what was originally requested and what the task currently holds.

Underlying Base Objects

The ETRM metadata documents exactly one referenced base object: WMS_WP_TASKS_GTMP, exposed through a synonym. The view is defined as a straightforward SELECT of named columns from that object, with no aggregation, filtering, or joins. Consequently, row cardinality and grain match the base object: one row per task record in the staging table. Any duplicate or transient staging rows appear in the view unchanged.

Because the view performs no join to inventory, order, or personnel tables, it does not resolve foreign-key descriptions beyond those already denormalized into the base object (for example ORGANIZATION_CODE, PERSON, TASK_TYPE, OPERATION_PLAN). Consumers requiring authoritative master data should join to the corresponding base tables.

Key Columns

• Task identity and lineage: TASK_ID, PARENT_LINE_ID, MOVE_ORDER_LINE_ID, CHILD_TASKS, and NUM_OF_CHILD_TASKS identify the task and its position in a task hierarchy.
• Transaction context: TRANSACTION_TEMP_ID, TRANSACTION_TYPE_ID, TRANSACTION_ACTION_ID, TRANSACTION_SOURCE_TYPE_ID, TRANSACTION_SOURCE_ID, and TRANSACTION_SOURCE_LINE_ID describe the originating transaction.
• Organization and location: ORGANIZATION_ID/ORGANIZATION_CODE, TO_ORGANIZATION_ID/TO_ORGANIZATION_CODE, TO_SUBINVENTORY, TO_LOCATOR_ID/TO_LOCATOR, SUBINVENTORY, and LOCATOR define source and destination.
• Personnel: PERSON_ID, PERSON_ID_ORIGINAL, PERSON, PERSON_RESOURCE_ID, and PERSON_RESOURCE_CODE identify the assigned resource.
• Status and priority: STATUS_ID, STATUS_ID_ORIGINAL, STATUS, PRIORITY, PRIORITY_ORIGINAL, TASK_TYPE_ID, and TASK_TYPE track execution state.
• Item and quantity: ITEM, ITEM_DESCRIPTION, REVISION, TRANSACTION_QUANTITY, TRANSACTION_UOM, SECONDARY_QUANTITY, and SECONDARY_UOM.
• Operation plan (relevant to the search term): OPERATION_PLAN_ID, OPERATION_PLAN, OPERATION_SEQUENCE, and OPERATION_PLAN_INSTANCE tie a task to its operation plan and specific plan instance.
• LPN and shipping: FROM_LPN, TO_LPN, TO_LPN_ID, ALLOCATED_LPN, CARTONIZED_LPN, PICKED_LPN, CONTENT_LPN, CONTAINER_ITEM, SHIP_METHOD, SHIPMENT_DATE, SHIPMENT_PRIORITY, and DISPATCHED_TIME.
• Audit/processing flags: MMTT_LAST_UPDATE_DATE, WDT_LAST_UPDATE_DATE, IS_MODIFIED, PLAN_TASK, RESULT, and ERROR.

Common Use Cases and Queries

Typical uses include monitoring open warehouse tasks by status or assignee, analyzing operation-plan execution per plan instance, extracting task data for external systems, and diagnosing processing results (RESULT/ERROR). A representative query filtering by operation plan instance:

SELECT task_id, organization_code, item, operation_plan, operation_plan_instance, operation_sequence, status, priority, person FROM apps.wms_wp_tasks_gtmp_v WHERE operation_plan_instance = :plan_instance ORDER BY operation_sequence, task_id;

Tasks by status and organization:

SELECT organization_code, status, task_type, COUNT(*) task_count FROM apps.wms_wp_tasks_gtmp_v GROUP BY organization_code, status, task_type;

Error and modification review:

SELECT task_id, result, error, is_modified, mmtt_last_update_date, wdt_last_update_date FROM apps.wms_wp_tasks_gtmp_v WHERE result IS NOT NULL OR error IS NOT NULL;

Assignments by person with original-versus-current comparison:

SELECT task_id, person, person_id, person_id_original, status, status_id, status_id_original, priority, priority_original FROM apps.wms_wp_tasks_gtmp_v WHERE person_resource_code = :resource_code;

Because the view is a direct projection, filters on indexed base columns (for example TASK_ID, ORGANIZATION_ID, or OPERATION_PLAN_INSTANCE where indexed on the base object) push down efficiently. Given the staging nature of the underlying object, queries should generally bound results by organization, status, or date to avoid scanning transient task rows.