Search Results gmd_rout_migration




Overview
Explore in AI Chat

Overview

GMD_ROUT_MIGRATION is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite, documented under the ETRM repository for releases 12.1.1 and 12.2.2 with a status of VALID. It belongs to the Oracle Process Manufacturing (OPM) family of migration utilities and is classified as an OTHER API. Its central business purpose is to support the conversion and migration of routing and recipe data structures that were maintained by earlier OPM forms and legacy tables into the current OPM model. During upgrades and data conversions, routing records must be revalidated, their status values normalized, and their transfer percentages recalculated so that downstream manufacturing execution, costing, and scheduling functions can consume consistent routing and dependency data.

The package body depends on GMD_ROUTINGS_B, the base table that stores OPM routing headers, and on GMD_STATUS, the generic status lookup table used across OPM objects. Its name and procedure inventory indicate that it operates as a targeted migration helper rather than a full public API, and the ETRM metadata confirms that GMD_ROUT_MIGRATION is not referenced by any other database object, meaning it is invoked directly rather than being embedded in a larger PL/SQL call hierarchy.

Key Procedures and Functions

  • INSERT_ROUT_STATUS — Populates the status attribute associated with routing records as part of the migration flow. This procedure ensures that migrated routings carry a valid, recognized status value consistent with OPM status conventions, preventing invalid or null statuses from being carried into the production model.
  • INSERT_TRANSFER_PERCENT — Inserts or derives the transfer percentage for routing and recipe step records during migration. This value governs how quantities are transferred between operations, so accurate population is essential for correct material flow and cost rollups after conversion.

Both procedures are documented in the ETRM repository without parameter metadata. The package body also declares a third element, GMD_ROUT_MIGRATION, which appears as a self-referential entry in the dependency listing; this is a package-level construct rather than a separately documented public procedure.

Tables Accessed

  • GMD_ROUTINGS_B — The primary OPM routing base table. The package reads existing routing rows and updates or inserts status information as part of the conversion.
  • GMD_STATUS — Provides valid status codes and their associated attributes, used by INSERT_ROUT_STATUS to assign legitimate status values to migrated routings.
  • FM_ROUT_DEP — Stores routing dependency information for process manufacturing. Referenced during migration to preserve relationships between routing steps.
  • FM_FORM_EFF_BAK — A backup table for formula effectivity data, accessed to reconcile or restore effectivity information associated with converted formula and routing structures.

The package also relies on standard dependencies including FND_PROFILE for environment and user context, GMDFMVAL_PUB for formula validation, and GMD_RECIPE_MIGRATION for coordination with recipe migration activities. These references reinforce that GMD_ROUT_MIGRATION operates as part of a broader OPM data migration effort.

Usage Notes

GMD_ROUT_MIGRATION is typically invoked during OPM implementation and upgrade projects, most commonly as part of a controlled conversion run rather than during routine transactional processing. Because it is not referenced by any other database object, it is called directly, either from a migration driver script or from custom PL/SQL executed by a conversion team. No standard concurrent program or Oracle Forms module is documented as its caller.

Executing the package requires careful sequencing: routing and recipe migration routines should run after their prerequisite source data has been staged, and status and transfer percentage values should be populated before downstream manufacturing and costing data is loaded. Because the procedures modify routing records and status references, DBAs and functional consultants should run them in a test environment with full backups, validate post-migration routing and dependency data, and confirm profile option settings that influence migration behavior. Custom code referencing this package should treat it as an internal migration utility rather than a supported, long-term integration interface.