Search Results gme_batch_history




Overview
Explore in AI Chat

Overview

GME_BATCH_HISTORY is the production history table within the Oracle EBS Process Manufacturing Process Execution module (GME). It functions as an append-oriented audit ledger for production events that carry financial implications. Each row captures a discreet moment in the lifecycle of a batch, such as a change in batch status or a shift in the Work-In-Process (WIP) warehouse assignment. Because these events drive inventory valuation and cost accounting, the table is maintained as a durable historical record rather than a current-state snapshot.

The table is owned by the GME schema and is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2. The ETRM documentation classifies GME_BATCH_HISTORY with a heuristic Data Vault designation of standalone, meaning the mined foreign-key structure does not reveal a strong parent-child dependency. This should be treated as a modeling suggestion rather than a definitive assertion; the table behaves more like a satellite attached to a batch hub (GME_BATCH_HEADER) when its event semantics are considered, since it records descriptive event context around the batch business key. The primary key GME_BATCH_HISTORY_PK is defined on the single column EVENT_ID.

Key Information Stored

The physical schema documented in ETRM 12.2.2 comprises 16 columns. The most operationally significant are:

  • EVENT_ID — the surrogate primary key and sole member of the unique index GME_BATCH_HISTORY_PK. It uniquely identifies each production event record.
  • BATCH_ID — the identifier of the batch whose event is being logged; this is the effective business-key link to the batch master.
  • ORIG_STATUS and NEW_STATUS — the batch status before and after the event, capturing transitions such as release, completion, or cancellation.
  • ORIG_WIP_WHSE and NEW_WIP_WHSE — the WIP warehouse before and after the event, enabling tracking of physical location changes with inventory valuation impact.
  • GL_POSTED_IND — a flag indicating whether the event has been posted to the General Ledger, which is critical for reconciliation and period-close activities.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — standard Oracle WHO columns for audit and row-version tracking.
  • PROGRAM_APPLICATION_ID, PROGRAM_ID, REQUEST_ID, PROGRAM_UPDATE_DATE — concurrent program context, identifying the job that generated the event.

Unlike a pure surrogate hub, the only unique index documented is the primary key; no additional business-key candidate is published in the metadata.

Common Use Cases and Queries

The most frequent reporting use case is reconstructing the status and WIP history of a specific batch. A typical query joins the history to the batch master and orders events chronologically:

  • Batch lifecycle audit: SELECT BATCH_ID, ORIG_STATUS, NEW_STATUS, ORIG_WIP_WHSE, NEW_WIP_WHSE, CREATION_DATE FROM GME_BATCH_HISTORY WHERE BATCH_ID = :batch_id ORDER BY CREATION_DATE;
  • Unposted GL event reconciliation: SELECT BATCH_ID, EVENT_ID, NEW_STATUS, CREATION_DATE FROM GME_BATCH_HISTORY WHERE GL_POSTED_IND = 'N';
  • Warehouse move analysis: filter on ORIG_WIP_WHSE != NEW_WIP_WHSE to report physical relocations affecting WIP valuation.
  • Concurrent program traceability: group by PROGRAM_ID or REQUEST_ID to determine which processes generate the most financially sensitive events.

Related Objects

The metadata documents no explicit foreign-key dependencies, consistent with its standalone classification. The most significant related objects are:

Together these objects allow practitioners to trace a batch from execution through financial posting using EVENT_ID and BATCH_ID as the principal linking keys.