# `PRO_ERPMERGEMFTWORKORDER` (procedure) - **Type:** PROCEDURE - **Deterministic:** NO - **SQL data access:** CONTAINS SQL ## Parameters | # | Mode | Name | Type | |---|---|---|---| | 1 | IN | `sSlaveId` | `varchar(100)` | | 2 | OUT | `sErrorMsg` | `varchar(100)` | ## Body _Body is not pre-cached. To inspect: `mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURE `PRO_ERPMERGEMFTWORKORDER`'`._ ## Narrative **Business context:** Manufacturing — 生产施工单 (Work Order) reporting-row builder. Whenever a `MFTWORKORDERSLAVE` row is saved/checked, this proc rebuilds the corresponding fully-denormalized row in `ERPMERGEWORKORDER` — joining in customer, product, form, classification, tax, salesman, payment, and deliver labels — so downstream BI/reporting queries can scan a single wide table without re-joining the operational schema. **What it does:** loads the slave row by `sSlaveId` into session variables, fetches its master via `@sParentId`, then conditionally fetches name labels from `ELECUSTOMER`, `ELEPRODUCT`, `GDSMODULE`, `SISCUSTOMERCLASSIFY`, `SISTAX`, `SISPRODUCTCLASSIFY`, `SISSALESMAN`, `SISPAYMENT`, `SISDELIVER`. Inside a transaction it `DELETE`s any existing `ERPMERGEWORKORDER` row by `sSlaveId` and `INSERT`s the freshly composed denormalized row. **Invocation:** Called by `ProDao.proErpMergeMftWorkOrder(map)` via MyBatis CALLABLE mapper `ProMapper.xml`, driven from `MegerWorkOrderServiceImpl` after a `MFTWORKORDERSLAVE` mutation event. Companion to `PRO_ERPMERGEPRODUCTIONREPORT` (production-report variant) and `PRO_ERPMERGESALSALESORDER` (sales-order variant). See [Cache invalidation on metadata change](../../reference/maintainer/cache-invalidation.md). Caveat: `DELETE FROM ERPMERGEWORKORDER WHERE sSlaveId = sSlaveId` — the parameter name shadows the column name, so the predicate `sSlaveId = sSlaveId` is always true (or always-NULL-safe-true depending on optimizer). The DELETE deletes the whole table in each invocation. The INSERT then re-inserts only the current row — net behaviour is correct for a single-row rebuild, but the table gets rewritten on every call, which is destructive if any other live row exists. Worth a maintainer audit.