# `PRO_ERPMERGEBASESISWORKCENTER` (procedure)


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

## Parameters

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

## Body

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

## Narrative

**Business context:** Manufacturing — Work Center base data. When a
shop-floor work center (a press, a die-cutter, a binding line — a
production resource that owns work orders) is renamed in the
**工作中心** (Work Center) maintenance page, this proc updates the
denormalized work-center name on every historical
`ERPMERGEPRODUCTIONREPORT` row that references it. Without it, the
production reports under
**选择工序(轮转/丝印/胶印/按产品分类)**
(Choose Process — Rotary / Silk-screen / Offset / By-product-classification)
would keep displaying the old name forever.

**What it does:** reads `SISWORKCENTER.sName` for the given id, then
updates every `ERPMERGEPRODUCTIONREPORT` row whose `sWorkCenterId`
matches. One-shot denormalization push.

**Invocation:** the JMS `CHANGE_GDS_MODULE` consumer runs the
`PRO_ERPMERGEBASE*` family 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)
for the dispatch mechanism — this is the JMS path, *not* the Redis
@CacheEvict path.

**Tenant scope:** none — keyed only by globally-unique
`sSisWorkCenterId`. Caller is responsible for passing the right id.
