Search Results gme_batch_step_dependencies




Overview
Explore in AI Chat

Overview

GME_BATCH_STEP_DEPENDENCIES is a Process Manufacturing Process Execution (GME) table in the Oracle E-Business Suite that stores the sequencing and dependency relationships between steps within a batch. In process manufacturing, a batch is not a single undifferentiated transaction — it is composed of many discrete steps (charging, mixing, reacting, transferring, sampling, and so on), and the order in which those steps may begin is frequently constrained. This table captures those constraints, expressing rules such as "the start of step B depends on the completion of step A," along with the optional delays, quantities, and rework behavior that govern the handoff.

The ETRM metadata classifies this object, using a heuristic derived from its foreign-key structure, as standalone. In Data Vault modeling terms this suggests the table is best understood as a link-style association resolving a many-to-many relationship between a batch and its constituent steps, rather than a simple hub of independent business entities or a descriptive satellite. It has no documented foreign-key dependencies to other tables in the mined relationship data, so its identity is carried entirely by its own composite primary key.

Key Information Stored

The table is physically documented with 49 columns in the 12.2.2 schema under the GME owner. Its primary key, GME_BATCH_STEP_DEPENDENCIES_PK, is a composite of three columns: BATCH_ID, BATCHSTEP_ID, and DEP_STEP_ID. This triple is both the surrogate primary key and the sole documented unique index, meaning it also serves as the business-key candidate for the row.

  • BATCH_ID — identifies the batch to which the dependency belongs.
  • BATCHSTEP_ID — the dependent step, i.e., the step whose execution is constrained.
  • DEP_STEP_ID — the predecessor step upon which the dependent step relies.
  • DEP_TYPE — the nature of the dependency between the two steps, distinguishing completion-based, start-based, or similar sequencing rules.
  • REWORK_CODE — indicates how the dependency behaves when a step is reworked or repeated.
  • STANDARD_DELAY, MIN_DELAY, MAX_DELAY — the expected, minimum, and maximum time delays permitted before the dependent step may proceed.
  • TRANSFER_QTY, TRANSFER_UM, TRANSFER_PERCENT — the quantity, unit of measure, and percentage that must be transferred before the dependency is satisfied.
  • TEXT_CODE — a coded reference providing additional descriptive context for the dependency.
  • CHARGEABLE_IND — flag indicating whether the dependent step is chargeable.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE30 — the standard Oracle extensibility block for customer-defined descriptive flexfield data.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard Oracle who-audit columns tracking row creation and modification.

Common Use Cases and Queries

The most frequent use of this table is in batch scheduling and shop-floor execution logic, where the application must determine which steps are eligible to start. A typical query retrieves all predecessors of a given step within a batch:

SELECT dep_step_id, dep_type, standard_delay, min_delay, max_delay
FROM gme_batch_step_dependencies
WHERE batch_id = :p_batch_id AND batchstep_id = :p_step_id;

A reverse query lists everything that depends upon a given step, useful for impact analysis when a step is delayed. Reporting use cases include dependency-network documentation for regulated batches, validation of delay and transfer rules, and audit extracts of rework behavior. Because the table is standalone with no documented foreign keys, joins to batch and step master data are performed explicitly on BATCH_ID, BATCHSTEP_ID, and DEP_STEP_ID rather than through declared constraints.

Related Objects

No foreign keys are documented for this object, so the following relationships are expressed through shared key columns rather than enforced constraints. The most significant related objects are those keyed on the same batch and step identifiers:

  • GME_BATCH_HEADERS — joins on BATCH_ID to retrieve batch-level context.
  • GME_BATCH_STEPS — joins on BATCHSTEP_ID and DEP_STEP_ID to resolve step details and descriptions.
  • GME_BATCH_STEP_ACTIVITIES — joins on BATCHSTEP_ID to link dependency rules to executed activities.
  • GME_BATCH_STEP_RESOURCES — joins on BATCHSTEP_ID for resource assignments tied to dependent steps.
  • GME_BATCH_STEP_ITEMS — joins on BATCHSTEP_ID for material movements governed by dependency rules.
  • GME_BATCH_STEP_DEPENDENCIES_PK — the primary key index enforcing uniqueness across BATCH_ID, BATCHSTEP_ID, and DEP_STEP_ID.

Because the object is standalone, integrators should treat BATCH_ID, BATCHSTEP_ID, and DEP_STEP_ID as the authoritative linking keys when constructing queries or data extracts.