Results for “max_step_capacity”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

GMO_BATCH_STEPS_V is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite, defined within the GMO (Manufacturing Execution System for Process Manufacturing) product family. It exposes batch step information for process manufacturing batches, joining step-level data to the parent batch header and to the operation definition that the step performs. The view carries a status of VALID and is available across both EBS 12.1.1 and 12.2.2, with the layout documented in the ETRM 12.2.2 metadata.

The view is the principal denormalized source for batch step inquiry screens, shop-floor reporting, and downstream integration extracts. Because it resolves foreign keys to human-readable operation descriptions while retaining the numeric identifiers, it is suitable both for end-user reporting and for programmatic consumption where descriptions are required alongside codes.

Underlying Base Objects

The view text joins three documented base objects:

• GME_BATCH_STEPS (SYNONYM, alias A) — the driving step table supplying BATCH_ID, BATCHSTEP_ID, quantities, dates, status, charges, and termination flags.
• GMD_OPERATIONS_VL (VIEW, alias B) — the operation definition view supplying OPRN_NO, OPRN_VERS, and OPRN_DESC.
• GME_BATCH_HEADER (SYNONYM, alias C) — the batch header supplying the business-facing BATCH_NO.

The join predicates are A.OPRN_ID = B.OPRN_ID and A.BATCH_ID = C.BATCH_ID. GMD_OPERATIONS_VL is itself a translation-enabled view, which is why the operation description resolves according to the session's language. The concatenation B.OPRN_NO||'-'||B.OPRN_VERS produces the OPERATION column, giving a single display key combining operation number and version.

Key Columns

• BATCH_ID / BATCH_NO — the internal batch identifier and its user-visible batch number.
• BATCHSTEP_ID / BATCHSTEP_NO — the step's internal key and its sequence number within the batch routing.
• OPRN_ID, OPRN_NO, OPRN_VERS, OPRN_DESC, OPERATION — the operation that the step executes. OPRN_DESC is the descriptive text, and OPERATION is the combined number-version string. These columns are the direct answer to searches on "oprn_desc", where the requester is typically looking for the human-readable operation name behind a step.
• PLAN_STEP_QTY / ACTUAL_STEP_QTY / MINIMUM_TRANSFER_QTY — planned and executed step quantities plus the transfer threshold; STEP_QTY_UM provides the corresponding unit of measure.
• PLAN_START_DATE, ACTUAL_START_DATE, DUE_DATE, PLAN_CMPLT_DATE, ACTUAL_CMPLT_DATE, STEP_CLOSE_DATE — the scheduling and execution timeline for the step.
• STEP_STATUS, STEPRELEASE_TYPE, QUALITY_STATUS, TERMINATED_IND — status and disposition indicators controlling step behavior.
• MAX_STEP_CAPACITY / MAX_STEP_CAPACITY_UM — capacity ceiling for the step and its unit of measure.
• PLAN_CHARGES / ACTUAL_CHARGES — planned versus actual charge amounts associated with the step.

Two columns, STEP_QTY_UM and MAX_STEP_CAPACITY_UM, are populated as NULL in the view text, reflecting unit-of-measure values held elsewhere or not exposed in this definition.

Common Use Cases and Queries

Typical scenarios include shop-floor step status dashboards, batch genealogy extracts, and variance analysis comparing planned to actual step quantities and dates. A common query retrieves step detail with the operation description for a given batch:

SELECT batch_no, batchstep_no, oprn_no, oprn_vers, oprn_desc, operation,
  step_status, plan_step_qty, actual_step_qty, actual_start_date, actual_cmplt_date
FROM apps.gmo_batch_steps_v
WHERE batch_no = :p_batch_no
ORDER BY batchstep_no;

Searches on the operation description, matching the reported term "oprn_desc", are frequently expressed as:

SELECT batch_no, batchstep_no, oprn_desc, step_status
FROM apps.gmo_batch_steps_v
WHERE UPPER(oprn_desc) LIKE UPPER('%'||:p_desc||'%');

Because OPERATION concatenates operation number and version, it serves as a convenient grouping key when aggregating steps by operation across batches. Reports should filter on BATCH_ID or BATCH_NO rather than on date columns alone, since the step timeline includes multiple date fields with differing semantics.