PRO_ERPMERGESALSALESORDER (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 PROCEDUREPROERPMERGESALSALESORDER'._
Narrative
Business context: Sales — 销售订单 (Sales Order) reporting-row builder. Rebuilds the denormalized ERPMERGESALSALESORDER row for one SALSALESORDERSLAVE whenever the sales-order is saved/checked, joining in customer, product, form, classification, tax, salesman, payment, and deliver labels so sales-analytics queries can scan a single wide table.
What it does: loads the slave row from SALSALESORDERSLAVE by sSlaveId and its master from SALSALESORDERMASTER via @sParentId, then conditionally pulls name labels from related base tables. Inside a transaction it DELETEs any existing ERPMERGESALSALESORDER row keyed on sSlaveId and INSERTs the freshly composed denormalized row.
Invocation: Called by ProDao.proErpMergeSalSalesOrder(map) via MyBatis CALLABLE mapper ProMapper.xml, driven from MegerSaleOrderServiceImpl after a SALSALESORDERSLAVE mutation event. Sibling of PRO_ERPMERGEMFTWORKORDER and PRO_ERPMERGEPRODUCTIONREPORT. See Cache invalidation on metadata change.
Caveat: the DELETE predicate is WHERE sSlaveId = sSlaveId — same shadowed-name bug as the sibling procs; MySQL binds both sides to the IN parameter so the WHERE is effectively a tautology, wiping the whole table on each invocation before the single-row INSERT. Flag for maintainer audit.