# `PRO_ERPMERGEBASEELETEAM` (procedure)


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

## Parameters

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

## Body

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

## Narrative

**Business context:** Manufacturing — 班组 (Team) base data. When a production team's `sTeamName` or `sTeamNo` is edited on the 班组维护 page, this proc pushes the new name/number onto every historical `ERPMERGEPRODUCTIONREPORT` row that references the team, so production-report queries keep showing the current label.

**What it does:** reads `sTeamName`, `sTeamNo` from `ELETEAM` for the given id, then `UPDATE ERPMERGEPRODUCTIONREPORT SET sTeamName=@..., sTeamNo=@... WHERE sTeamId = sEleTeamId`.

**Invocation:** member of the `PRO_ERPMERGEBASE*` denorm-merge family. Called by `ProDao.proErpMergeBaseEleTeam(map)` via MyBatis CALLABLE mapper `ProMapper.xml`, driven from `ChangeEleTeamServiceImpl.changeTableData()` after the JMS `CHANGE_GDS_MODULE` consumer detects an `ELETEAM` row mutation. See [Cache invalidation on metadata change](../../reference/maintainer/cache-invalidation.md) for the dispatch mechanism.