Search Results wms_wp_tasks_gtmp

Overview

WMS.WMS_WP_TASKS_GTMP is a transient staging and interface table in the Warehouse Management (WMS) module of Oracle E-Business Suite, present and valid in both 12.1.1 and 12.2.2. It is physically owned by the WMS schema and exposes 72 documented columns. The suffix _GTMP indicates a global temporary table, meaning rows are session-scoped and typically purged on commit or session termination. The table serves as a pre-processing buffer for warehouse task records generated by the Warehouse Control System (WCS) or warehouse device interface before those tasks are validated and posted into the persistent WMS task structure.

Under the heuristic Data Vault classification mined from its foreign key structure, WMS_WP_TASKS_GTMP is characterized as standalone. No hub, link, or satellite designation is asserted by the source metadata. This classification is a modeling suggestion only; the table's own foreign keys indicate that it behaves as a staging surface whose rows are later reconciled against master transaction source and operation plan records rather than as a durable integration hub.

Key Information Stored

The table's surrogate identifier is TASK_ID, which uniquely identifies each staged task row prior to durable insertion. TRANSACTION_TEMP_ID and LINE_NUMBER function as business-key candidates for correlating staged rows back to upstream feeder records. Notable columns include:

• TASK_ID — surrogate primary key for the staged task.
• TRANSACTION_TEMP_ID — temporary identifier linking the row to its source transaction.
• TRANSACTION_TYPE_ID, TRANSACTION_ACTION_ID, TRANSACTION_SOURCE_TYPE_ID, TRANSACTION_SOURCE_ID — classify the nature and origin of the movement.
• ORGANIZATION_ID / ORGANIZATION_CODE — warehouse context for the task.
• TO_LPN, TO_LPN_ID, FROM_LPN, ALLOCATED_LPN, PICKED_LPN, CARTONIZED_LPN, CONTENT_LPN — license plate numbers associated with source, destination, and container handling.
• ITEM, ITEM_DESCRIPTION, REVISION, SUBINVENTORY, LOCATOR — inventory attributes of the item being moved.
• TRANSACTION_QUANTITY and TRANSACTION_UOM — primary quantity and unit of measure; SECONDARY_QUANTITY / SECONDARY_UOM carry dual-UOM values.
• STATUS_ID, PERSON_ID, PRIORITY — task execution state, assigned resource, and priority.
• OPERATION_PLAN_ID, OPERATION_SEQUENCE, OPERATION_PLAN_INSTANCE — linkage to the operation plan governing the task.
• PICK_SLIP_NUMBER, MOVE_ORDER_LINE_ID, SHIP_METHOD, SHIPMENT_DATE — outbound logistics context.
• RESULT, ERROR — outcome of staging validation.

Common Use Cases and Queries

Because the table is a temporary staging surface, typical consumption occurs within the same session that populated it. Common patterns include pre-validation of inbound tasks before posting, diagnosing task-generation failures, and reconciliation reporting against the persistent WMS task tables.

• Rejected-task diagnostics: SELECT TASK_ID, ITEM, ERROR FROM WMS.WMS_WP_TASKS_GTMP WHERE ERROR IS NOT NULL;
• Task throughput by status: SELECT STATUS, COUNT(*) FROM WMS.WMS_WP_TASKS_GTMP GROUP BY STATUS;
• High-priority picks: SELECT TASK_ID, PICK_SLIP_NUMBER, ITEM, PRIORITY FROM WMS.WMS_WP_TASKS_GTMP WHERE PRIORITY = 1 ORDER BY PICK_SLIP_NUMBER;
• Correlating staged tasks to operation plans: SELECT g.TASK_ID, p.OPERATION_PLAN FROM WMS.WMS_WP_TASKS_GTMP g JOIN WMS.WMS_OP_PLANS_B p ON g.OPERATION_PLAN_ID = p.OPERATION_PLAN_ID;

Related Objects

Two foreign keys are explicitly documented for this table, anchoring it to master and plan data:

• WMS_OP_PLANS_B via OPERATION_PLAN_ID — the parent operation plan governing the task.
• MTL_TXN_SOURCE_TYPES via TRANSACTION_SOURCE_TYPE_ID — the transaction source classification.

Because the table is classified as standalone with no dependent (child) tables, no other objects reference it via foreign key. Downstream processing typically routes staged rows into the persistent warehouse execution tables within the WMS_WP_TASKS family, and inventory-side reconciliation touches MTL_MATERIAL_TRANSACTIONS. WMS transaction-mapping and posting logic in the Warehouse Management module consumes the staging rows to generate confirmed warehouse execution records.