# `PRO_ERPMERGEBASESISTAX` (procedure)


- **Type:** PROCEDURE
- **Deterministic:** NO
- **SQL data access:** CONTAINS SQL

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sSisTaxId` | `varchar(100)` |

## Body

_Body is not pre-cached. To inspect: `mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURE `PRO_ERPMERGEBASESISTAX`'`._

## Narrative

**Business context:** Base data — 税率 (Tax). When a tax row in `SISTAX` is edited (name or rate), this proc pushes both `sTaxName` and `dTaxRate` onto every historical row of the work-order and sales-order merge-reporting tables that references the tax id.

**What it does:** reads `sName`, `dRate` from `SISTAX` for the given id, then `UPDATE`s `sTaxName` and `dTaxRate` on `ERPMERGEWORKORDER` and `ERPMERGESALSALESORDER` rows whose `sTaxId = sSisTaxId`.

**Invocation:** member of the `PRO_ERPMERGEBASE*` denorm-merge family. Called by `ProDao.proErpMergeBaseSisTax(map)` via MyBatis CALLABLE mapper `ProMapper.xml`, driven from `ChangeSisTaxServiceImpl.changeTableData()` after the JMS `CHANGE_GDS_MODULE` consumer detects a `SISTAX` row mutation. See [Cache invalidation on metadata change](../../reference/maintainer/cache-invalidation.md).

Caveat: pushes the new `dTaxRate` onto historical rows that were originally booked at the old rate — tax-rate retroactivity is a business decision, not a bug, but worth flagging.