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 PROCEDUREPROERPMERGEBASEELECUSTOMER'._
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.