# `PRO_ERPMERGEBASEELEPRODUCT` (procedure)


- **Type:** PROCEDURE
- **Deterministic:** NO
- **SQL data access:** CONTAINS SQL

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sEleProductId` | `varchar(100)` |

## Body

_Body is not pre-cached. To inspect: `mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURE `PRO_ERPMERGEBASEELEPRODUCT`'`._

## Narrative

**Business context:** 基础资料 / 产品 (Product base data) — when a product (`ELEPRODUCT`) is renamed, renumbered, its style/unit changed, has its customer-product-no updated, or is moved to a different product classification in the **产品** maintenance page, this proc pushes the new `sProductNo`/`sProductName`/`sProductStyle`/`sProductUnit`/`sCustomerProductNo`/`sProductClassifyId` (= `ELEPRODUCT.sParentId`) to every history-table row that already references that product.

**What it does:** `SELECT ... INTO @...` from `ELEPRODUCT WHERE sId = sEleProductId`, then `UPDATE` three denorm tables in turn: `ERPMERGEWORKORDER`, `ERPMERGEPRODUCTIONREPORT`, `ERPMERGESALSALESORDER` — each scoped by `sProductId = sEleProductId`.

**Invocation:** Reached via `ProDao.proErpMergeBaseEleProduct(map)` → MyBatis `ProMapper.proErpMergeBaseEleProduct` (`CALL PRO_ERPMERGEBASEELEPRODUCT(#{sEleProductId})`). Fired by the entity-change service for `eleproduct` (JMS `CHANGE_GDS_MODULE` consumer) after a base-data row mutates, keeping denormalized reporting tables in sync without a full rebuild. See [Cache invalidation on metadata change](../../reference/maintainer/cache-invalidation.md).
