Search Results populate_lot_migration

Overview

GMA_MIGRATION_PUB is a public PL/SQL package in the Oracle E-Business Suite Applications (APPS) schema that supports the migration of legacy process manufacturing data into the Oracle EBS data model. The package is declared with AUTHID CURRENT_USER, meaning its SQL statements execute with the privileges of the invoking user rather than the package owner. Its source header ($Header: GMAPMIGS.pls 120.1 2006/04/10) and the presence of tables such as IC_LOTS_MST_MIG and GMI_MIGRATION_PARAMETERS indicate it belongs to the legacy GMA/GMI (Oracle Process Manufacturing) migration framework used to convert historical item, lot, organization, and recipe information into the standardized Oracle tables.

The package is classified as a PUB (public) API and is referenced by zero other packages according to the ETRM 12.2.2 metadata, which confirms its role as a top-level utility invoked directly by migration routines, concurrent programs, or conversion scripts rather than as a low-level building block.

Key Procedures and Functions

The package exposes five documented program units:

• CHECK_ORGANIZATION_DEPENDENTS — A procedure that verifies whether a given organization (identified by an organization code) has dependent records that would affect migration or deletion. It returns an active indicator to signal whether dependents exist.
• POPULATE_LOT_MIGRATION — A procedure that populates the lot migration staging area (IC_LOTS_MST_MIG) with the lot records to be converted, forming the core of the lot data migration process.
• GET_ITEM_NO — A function that accepts an item identifier and returns the corresponding item number as a VARCHAR2. This is a lookup utility used to resolve internal item IDs to their user-facing numbers during migration.
• GET_LOT_NO — A function that accepts a lot identifier and returns the corresponding lot number as a VARCHAR2. This is the object targeted by the search term "get_lot_no" and is used to translate internal lot IDs into their display lot numbers, typically during data conversion or validation.
• GET_ORGN_CODE — A function that accepts a warehouse code and returns the associated organization code, providing a mapping between warehouse and organization identifiers.

These units follow a consistent pattern: small, focused lookups and a single large migration driver procedure. No parameter lists are invented here; only the documented signatures and purposes are described.

Tables Accessed

The package reads and writes a range of APPS synonyms covering process manufacturing and inventory data. Key tables include:

• IC_LOTS_MST_MIG — The lot migration staging table populated by POPULATE_LOT_MIGRATION.
• IC_LOTS_MST — The master lot table, the source of lot numbers resolved by GET_LOT_NO.
• IC_ITEM_MST and IC_ITEM_MST_B — Item master tables used by GET_ITEM_NO.
• IC_WHSE_MST and SY_ORGN_MST — Warehouse and organization masters used by GET_ORGN_CODE and CHECK_ORGANIZATION_DEPENDENTS.
• GMI_MIGRATION_PARAMETERS — Stores migration control parameters.
• GMD_RECIPES_B, GMD_RECIPE_VALIDITY_RULES, FM_FORM_MST_B, PM_BTCH_HDR, LM_TECH_HDR — Process manufacturing recipe, formula, batch, and technical header tables relevant to migration dependencies.
• GL_ITEM_CST, IC_LOCT_INV, MTL_PARAMETERS — Costing, location inventory, and inventory parameter tables that support validation and dependent checks.

These tables are accessed to read legacy values, validate dependencies, and write migrated lot and item data into the target model.

Usage Notes

GMA_MIGRATION_PUB is typically invoked from the Oracle Process Manufacturing migration concurrent programs, conversion scripts, or custom PL/SQL that prepares legacy data for the EBS 12.1.1 / 12.2.2 environment. The GET_LOT_NO and GET_ITEM_NO functions are commonly called as inline lookups when building migration extracts or reconciliation reports, while POPULATE_LOT_MIGRATION and CHECK_ORGANIZATION_DEPENDENTS are run as part of the batch migration sequence. Because the package is PUBLIC and referenced by no other package, it is safe to call directly, but its AUTHID CURRENT_USER setting means the calling user must have the necessary privileges on the underlying tables.