# `Sp_afterSave_sMpt` (procedure)

> 产品工艺卡保存后反写状态


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sGuid` | `varchar(2000)` |
| 2 | IN | `sBrId` | `varchar(100)` |
| 3 | IN | `sSuId` | `varchar(100)` |
| 4 | OUT | `sCode` | `int` |
| 5 | OUT | `sReturn` | `varchar(4000)` |

## Body

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

## Narrative

**Business context:** 产品工艺卡 → 产品档案及SOP → 产品管理 — header says 产品工艺卡保存后反写状态. Unlike the rest of the `Sp_afterSave_s<Code>` family this member does its work inline rather than delegating to `Sp_saveReturn_sMpt`: when a 产品工艺卡 is saved, copy the technology-card id back onto every linked 销售机会产品 and 销售开发计划 row so downstream reports/quotes see the latest 工艺 head.

**What it does:** When `sGuid` is non-empty, dynamically PREPAREs and EXECUTEs two `UPDATE` statements against `salsaleschanceproduct` and `salsalesdevplanmaster`. Each update joins through `mftproductslave` (where `sSrcSlaveId` traces upward to the just-saved 工艺卡 row) up to `mftproductmaster` and writes `sProductTechnologyId = M.sId`. Tenant-scoped by `sBrId` / `sSuId`. Splits the concatenated SQL string on `;`, runs each fragment via PREPARE/EXECUTE/DEALLOCATE.

**Invocation:** Reached on two paths. (1) `Sp_Check_sMpt` (save-commit dispatch) calls this proc near the tail of a successful save. (2) `Sp_Invalid_backwriting` dispatches to this proc on 作废/取消作废 of form `101251240115016082594412050` (产品工艺卡), itself triggered by Java `CheckmodelServiceImpl` via `Sp_Invalidation`.

Caveat: `Sp_Check_sMpt` is not currently bound to any `gdsmodule.sSaveProName`/`sSaveProNameBefore` slot — the save-commit dispatch path may only fire when forms are wired manually. The Invalid path is the more reliable trigger.