# `Sp_UnConfirm_Zg` (procedure)

> 主管确认:通过


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sProInParam` | `varchar(10000)` |
| 2 | IN | `sMakePerson` | `varchar(100)` |
| 3 | IN | `sBrId` | `varchar(100)` |
| 4 | IN | `sSuId` | `varchar(100)` |
| 5 | OUT | `sReturn` | `varchar(1000)` |
| 6 | OUT | `sCode` | `int` |

## Body

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

## Narrative

**Business context:** 销售订单跟进 — 主管确认:不通过 button (despite the COMMENT saying "通过"). Used when a 主管 (supervisor) rejects a salesperson's 跟进完成 declaration on a 销售订单 slave row: clears the per-line "follow-up confirmed" flag and pushes a `sysmsg` back to the order's 制单人 explaining the rejection.

**What it does:** Validates `sProInParam`, parses `$.params[0].value[i].sSlaveId` JSON, and for each id: looks up the matching `salsalesorderslave` → `salsalesordermaster`, finds the original `sMakePerson`'s login id via `Fun_GetLoginUser(...)`, inserts a row into `sysmsg` (title "跟进完成发送通知", content "…跟进完成主管确认不通过", `sFormId='101251240115016285600841620'`) and a corresponding `sysmsguser` row addressed to that user, then `update salsalesorderslave set iConfirmPersonSate=1 where sId=p_sId`.

**Invocation:** Dispatched dynamically by `GenericProcedureCallServiceImpl.doGenericProcedureCall()` (the POST `/procedureCall/doGenericProcedureCall` channel) — bound to the 主管确认:不通过 toolbar button on the 销售订单跟进 grid. Install script `script/标版/30100101/Sp_UnConfirm_Zg.sql`. The COMMENT label is misleading (says 通过, body messages "不通过") — flag for review.