Search Results wip_mtl_allocations_temp




Overview
Explore in AI Chat

Overview

WIP_MTL_ALLOCATIONS_TEMP is a transient staging table owned by the WIP (Work in Process) schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It holds temporary repetitive schedule allocation data generated during completion transactions. Specifically, the table is populated as part of the processing logic that determines the available-to-complete quantity across competing repetitive schedules, allowing the completion transaction to allocate material against one or more eligible schedules before the final transaction records are written.

From a heuristic Data Vault modeling perspective, the mined FK structure classifies this object as standalone, which suggests it is best treated as a hub-like or transient staging structure rather than a classic link or satellite. Its lifecycle is short-lived: rows are inserted, consumed, and purged as part of a single completion transaction processing cycle, so it should not be modeled as a durable historical entity.

Key Information Stored

The table's documented physical schema contains 16 columns. The most operationally significant are:

The surrogate primary key is WIP_MTL_ALLOCATIONS_TEMP_PK, defined on (ORGANIZATION_ID, TRANSACTION_TEMP_ID, REPETITIVE_SCHEDULE_ID). A separate unique index, WIP_MTL_ALLOCATIONS_TEMP_U1, enforces the same business key in a different column order (TRANSACTION_TEMP_ID, REPETITIVE_SCHEDULE_ID, ORGANIZATION_ID); the two together confirm that the natural business key is the combination of allocation context, schedule, and organization.

Common Use Cases and Queries

Because the table is a working area, its primary use cases are diagnostic and debugging rather than reporting. Typical scenarios include investigating why a repetitive completion allocated quantity to a particular schedule, auditing available-to-complete calculations, and tracing allocations back to a concurrent request. A representative query retrieving allocations for a given temporary transaction is:

  • SELECT repetitive_schedule_id, organization_id, primary_quantity, transaction_quantity, transaction_date FROM wip.wip_mtl_allocations_temp WHERE transaction_temp_id = :temp_id;
  • SELECT * FROM wip.wip_mtl_allocations_temp WHERE completion_transaction_id = :txn_id;
  • SELECT request_id, program_id, COUNT(*) FROM wip.wip_mtl_allocations_temp GROUP BY request_id, program_id;

Reports should treat the table as volatile and never assume row persistence across processing cycles.

Related Objects

Although the metadata classifies this table as standalone, its columns reference the surrounding repetitive manufacturing model:

These relationships are logical rather than enforced by foreign keys; the table is populated and cleared entirely within the WIP completion transaction flow.