Search Results gme_batch_step_activ_mig




Overview
Explore in AI Chat

Overview

GME_BATCH_STEP_ACTIV_MIG is a table in the GME schema belonging to the Oracle Process Manufacturing Process Execution module. It stores migrated or interface-stage data for batch step activities, mirroring the structure of the operational GME_BATCH_STEP_ACTIVITIES table with an _MIG suffix that conventionally denotes data staged for conversion, migration, or bulk load into the production Process Execution model. The object's ETRM status is VALID, and the documented physical schema at 12.2.2 contains 54 columns.

Under a heuristic Data Vault classification mined from its foreign key structure, this table is modeled as standalone. In Data Vault terms, it does not function as a true hub, link, or satellite relative to its FK target; instead it behaves as a self-contained staging entity whose single documented foreign key (BATCHSTEP_ACTIVITY_ID → GME_BATCH_STEP_ACTIVITIES) points back into the source-of-truth activity table. This classification suggests modeling the table as a staging or transient load set rather than as a durable integrated warehouse object. The table exists in both Oracle EBS 12.1.1 and 12.2.2, though column inventory and constraints should always be verified against the specific patch level in use.

Key Information Stored

The primary structural identifier is BATCHSTEP_ACTIVITY_ID, the documented foreign key and the logical surrogate key linking each row to its parent activity definition in GME_BATCH_STEP_ACTIVITIES. Business-key candidates for a batch step activity include the combination of BATCH_ID, BATCHSTEP_ID, and ACTIVITY, which together identify the batch, the step within the batch, and the specific activity performed.

Processing context is captured through OPRN_LINE_ID (the operation line reference), MATERIAL_IND (whether the activity is material-related), BREAK_IND and MAX_BREAK (break behavior for scheduling), and SEQUENCE_DEPENDENT_IND (whether the activity's timing depends on preceding activities). Scheduling data is held in OFFSET_INTERVAL, PLAN_START_DATE, ACTUAL_START_DATE, PLAN_CMPLT_DATE, and ACTUAL_CMPLT_DATE. Performance is captured by PLAN_ACTIVITY_FACTOR and ACTUAL_ACTIVITY_FACTOR.

Standard EBS concurrency and audit columns are present: DELETE_MARK, CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN, along with a flexible ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE30 descriptor set, and a TEXT_CODE column. The extensive ATTRIBUTE array indicates the operational table is flexfield-enabled, and migrated rows carry those descriptor values through.

Common Use Cases and Queries

The principal use case is batch conversion and data load validation. Migration teams reconcile staged rows in GME_BATCH_STEP_ACTIV_MIG against target rows in GME_BATCH_STEP_ACTIVITIES to confirm that every batch step activity transferred with the correct schedule and factor values.

  • Unmatched activity detection: select rows in the _MIG table whose BATCHSTEP_ACTIVITY_ID has no corresponding production row, revealing failed or skipped conversions.
  • Schedule variance reporting: compare PLAN_START_DATE, PLAN_CMPLT_DATE, ACTUAL_START_DATE, and ACTUAL_CMPLT_DATE to quantify planned-versus-actual activity duration during migration cutover.
  • Factor reconciliation: join on BATCHSTEP_ACTIVITY_ID to compare PLAN_ACTIVITY_FACTOR and ACTUAL_ACTIVITY_FACTOR between staging and production.
  • Batch-level rollups: aggregate activities by BATCH_ID and BATCHSTEP_ID to validate step completion counts.
  • Orphan identification: left-join to GME_BATCH_STEP_ACTIVITIES and filter for NULL parents, detecting referential integrity risk before promotion. Reports should consistently filter DELETE_MARK = 0 where the logical delete convention applies.

Related Objects

  • GME_BATCH_STEP_ACTIVITIES — the documented parent and operational source; joined on BATCHSTEP_ACTIVITY_ID. This is the primary target of migration promotion.
  • GME_BATCH_STEPS — referenced through BATCHSTEP_ID, supplying step-level context for each activity.
  • GME_BATCH_HEADERS — joined via BATCH_ID, providing batch-level identity and status.
  • GME_OPERATION_NETWORKS — related through OPRN_LINE_ID to the operation line definition on which the activity executes.
  • GME_BATCH_STEP_ACTIVITY_RESOURCES — child resource assignments that depend on the activity record identified by BATCHSTEP_ACTIVITY_ID.
  • GME_BATCH_STEP_ACTIVITY_RESOURCES_MIG — the parallel migration staging table for activity resource rows.
  • GME_BATCH_STEP_DEPENDENCIES — holds sequence relationships governed by SEQUENCE_DEPENDENT_IND and break attributes.
  • GME_API_BATCH_STEP_ACTIVITIES — the public API package used to create, update, or delete activities programmatically.

Any promotion or purge operation against this table should validate foreign key integrity to GME_BATCH_STEP_ACTIVITIES before commit, since the table is classified as standalone and is not itself the system of record.