Search Results gml_batch_tmp




Overview

GML_BATCH_TMP is a temporary table owned by the GML schema within Oracle E-Business Suite, serving the Process Manufacturing Logistics (GML) product family. Its documented purpose is to hold transient data used during batch reservation processing. In Oracle Process Manufacturing (OPM) and discrete distribution flows, reservation logic must evaluate large volumes of on-hand batch inventory, allocate quantity against sales order or delivery demand lines, and then reconcile the results back into permanent reservation and delivery structures. GML_BATCH_TMP provides the staging ground for that intermediate working set, keyed by a SESSION_ID so that concurrent users and concurrent processes do not collide within the shared table.

Because the table is populated and consumed within a single logical operation, it is not intended as a system of record. Rows are typically inserted by a reservation or pick-release process, read for validation and allocation decisions, and then either transferred to persistent reservation tables or purged. Administrators and developers should treat this object as implementation detail rather than reporting infrastructure.

From a Data Vault modeling perspective, the ETRM metadata classifies GML_BATCH_TMP heuristically as standalone. This is a modeling suggestion: the table sits largely outside the core hub-and-link network of permanent master and transactional data, with only one documented foreign key relationship. It behaves more like a transient staging satellite than a business hub or link.

Key Information Stored

The documented physical schema contains 20 columns. The most significant include:

No unique index is documented in the metadata, and the table is explicitly classified as standalone, so no surrogate primary key is asserted. BATCH_RES_ID functions as the principal business reference back to the permanent reservation entity.

Common Use Cases and Queries

Because GML_BATCH_TMP is session-scoped, diagnostics revolve around identifying active sessions and inspecting the allocation they produced. A typical inspection query retrieves all working rows for a session, joined to the persistent reservation for correlation:

  • Session audit: SELECT * FROM GML.GML_BATCH_TMP WHERE SESSION_ID = :session_id;
  • Reservation correlation: SELECT t.ITEM_ID, t.BATCH_NO, t.RESERVED_QTY, r.* FROM GML.GML_BATCH_TMP t JOIN GML.GML_BATCH_SO_RESERVATIONS r ON r.BATCH_RES_ID = t.BATCH_RES_ID WHERE t.SESSION_ID = :session_id;
  • Allocation variance: compare PLANNED_QTY against RESERVED_QTY to detect shortfalls in batch availability during pick or ship confirmation.
  • Leak detection: rows that persist after a process completes indicate an unclean termination and can be purged by SESSION_ID.

Reporting use cases are limited to process diagnostics and troubleshooting rather than recurring analytics, given the table's transient nature.

Related Objects

The documented relationship data identifies one foreign key. Significant related objects include:

  • GML_BATCH_SO_RESERVATIONS — referenced through GML_BATCH_TMP.BATCH_RES_ID; the persistent sales order batch reservation record.
  • Sales order and delivery detail tables referenced by DOC_ID, LINE_ID, and DELIVERY_DETAIL_ID.
  • Inventory item and warehouse definitions referenced by ITEM_ID and WHSE_CODE.
  • Batch master and batch line tables referenced by BATCH_ID and BATCH_LINE_ID.

Together these objects supply the demand, supply, and batch context consumed by the reservation process that GML_BATCH_TMP temporarily materializes.