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 PROCEDUREPROERPMERGEMFTWORKORDER'._
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 DELETEs any existing ERPMERGEWORKORDER row by sSlaveId and INSERTs 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.
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.