# `PRO_ERPMERGEBASEELECUSTOMER` (procedure)


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

## Parameters

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

## Body

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

## Narrative

**Business context:** 基础资料 / 客户 (Customer base data) — when a customer (`ELECUSTOMER`) is renamed, renumbered, or reclassified in the **客户** maintenance page, this proc pushes the new `sCustomerNo`/`sCustomerName`/`sCustomerClassifyId` to every denormalized history-table row that already references that customer.

**What it does:** `SELECT ... INTO @sCustomerNo, @sCustomerName, @sCustomerClassifyId FROM ELECUSTOMER WHERE sId = sEleCustomerId`, then `UPDATE` three denorm tables in turn: `ERPMERGEWORKORDER`, `ERPMERGEPRODUCTIONREPORT`, `ERPMERGESALSALESORDER` — each scoped by `sCustomerId = sEleCustomerId`. Bug worth flagging: the SET clauses swap `sCustomerName = @sCustomerNo` and `sCustomerNo = @sCustomerName` — the two label columns are written to the wrong fields.

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