Search Results min_offset

Overview

APPS.MIGRATE_BATCH is the GME (Oracle Process Manufacturing Process Execution) data migration package body responsible for upgrading batch and material data from 11.5.1H and prior releases to the 11.5.1I model, and it remains catalogued in the 12.1.1 and 12.2.2 ETRM registries as an OTHER-classified API owned by APPS. Its architectural approach is a table-by-table copy implemented through INSERT INTO ... SELECT FROM statements, with inline PL/SQL functions used wherever row-level calculations are required. The header comment ($Header: GMEMIGBB.pls 120.1 2005/06/09) confirms the package's lineage as the GME batch migration utility.

A distinguishing feature of this package is the normalization of legacy PM_OPRN_DTL operation detail rows into the newer batch-step model represented by GME_BATCH_STEP_ACTIVITIES and GME_BATCH_STEP_RESOURCES. Migration proceeds in three batch-by-batch processing sections: CHECK_WIP_BATCHES, SPLIT_TRANS_LINE, and INSERT_BATCH_STEP_DTLS. All diagnostic output is written to GME_TEMP_EXCEPTIONS, with message types 'P' (progress), 'I' (information), 'E' (error), and 'D' (unexpected error arising from a WHEN OTHERS handler).

Key Procedures and Functions

The package exposes 54 documented procedures and functions, which fall into several functional groups. The public entry point is RUN, which drives the migration and is documented to accept a commit flag; called with no parameters or with p_commit => FALSE, the migration rolls back at completion so that data conditions can be validated without changing data; called with p_commit => TRUE, data is committed at each phase.

• Orchestration and setup: INITIALIZE_MIGRATION and RUN.
• Key/identifier resolution: GET_OPRN_ID, GET_BATCHSTEP_ID.
• Attribute derivation: GET_PROCESS_QTY_UOM, GET_REF_UOM, GET_ACTUAL_COST_IND, GET_GL_POSTED_IND, GET_POC_DATA_IND.
• Quantity/usage calculation: GET_WIP_PLANNED_QTY, GET_PLANNED_QTY, GET_ACTUAL_QTY, GET_ACTUAL_ACTIVITY_FACTOR, GET_PLANNED_USAGE, GET_ACTUAL_USAGE.
• Batch processing sections: CHECK_WIP_BATCHES (identifies completed default transactions, reports them, reverses the transaction, and creates a new pending transaction); SPLIT_TRANS_LINE (handles completed default transactions that are plain or non-plain with zero quantity — zero-quantity completed transactions are flipped to pending, while non-zero completed plain transactions receive an inserted zero-quantity pending transaction); and INSERT_BATCH_STEP_DTLS (performs the normalization of PM_OPRN_DTL into the batch-step activity and resource tables).
• Data load workers: INSERT_BATCH_HEADER, INSERT_MATERIAL_DETAILS, and INSERT_BATCH_STEPS.

Tables Accessed

Access is performed through APPS synonyms. Batch and step targets include GME_BATCH_HEADER, GME_BATCH_STEPS, GME_BATCH_STEP_ACTIVITIES, and GME_BATCH_STEP_RESOURCES. Legacy source data is read from PM_BTCH_HDR_BAK, PM_MATL_DTL_BAK, PM_OPRN_DTL, and PM_ROUT_DTL. Master and reference data come from IC_ITEM_MST, FM_OPRN_MST, PS_WHSE_EFF, CR_RSRC_DTL, CM_ACST_LED, and CM_CMPT_DTL. Transactional staging uses IC_TRAN_PND. The sequence GEM5_TRANS_ID_S supplies transaction identifiers. Exception logging targets GME_TEMP_EXCEPTIONS.

Usage Notes

MIGRATE_BATCH is an upgrade-time utility rather than a runtime API; the ETRM registry records zero packages referencing it. It is normally invoked directly in SQL*Plus or through a DBA-driven migration script during the GME upgrade, first with the default rollback behavior to enumerate data conditions in GME_TEMP_EXCEPTIONS, then with p_commit => TRUE once validation is complete. Because each phase commits separately when committing is enabled, failures during a phase leave prior phases persisted and must be handled through re-execution or manual correction. Any WIP default transactions reversed by CHECK_WIP_BATCHES change inventory state and should be reviewed before the final commit.