# `Sp_quoquotation_customeragreeWithdraw` (procedure)

> @author:zhucx 
		     @date: 
				 @describe:


- **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_quoquotation_customeragreeWithdraw`'`._

## Narrative

**Business context:** 销售管理 → 报价&估计管理 → 报价单 (quoquotationmaster) — toolbar button "撤销客户已同意" that rolls a `sStatus='4'` (customer agreed, set by `Sp_quoquotation_customeragree`) back to `sStatus='1'`. Body is identical to `Sp_quoquotation_CustomerAgreeAgain`; the two names exist to give the UI distinct labels for "withdraw agreement" vs "re-agree after rejection" while sharing the underlying transition.

**What it does:** Validates `sProInParam` length, then iterates `$.params[*].value[*].sId` and runs `UPDATE quoquotationmaster SET sStatus='1', tStatus=SYSDATE() WHERE sId=p_sId AND sBrandsId=sBrId AND sSubsidiaryId=sSuId`. No further side-effects.

**Invocation:** Standard generic-dispatch button handler dispatched by `GenericProcedureCallServiceImpl.doGenericProcedureCall()` (POST `/procedureCall/doGenericProcedureCall`) when the 报价单 grid's 撤销客户已同意 button is clicked. No `gdsmodule` hook or DB-side binding.