# `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 PROCEDURE `PRO_ERPMERGESALSALESORDER`'`._

## 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 `DELETE`s any existing `ERPMERGESALSALESORDER` row keyed on `sSlaveId` and `INSERT`s 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](../../reference/maintainer/cache-invalidation.md).

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.