Sp_Calc_sPrw (procedure)

销售机会

• Type: PROCEDURE
• Deterministic: NO
• SQL data access: CONTAINS SQL

Parameters

#	Mode	Name	Type
1	IN	iFlag	int
2	IN	iTmpCheck	int
3	IN	sFormGuid	varchar(100)
4	IN	sGuid	varchar(100)
5	IN	sLoginId	varchar(100)
6	OUT	sReturn	varchar(5000)
7	IN	sBrId	varchar(100)
8	IN	sSuId	varchar(100)
9	OUT	sCode	int

Body

Body is not pre-cached. To inspect: mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURESpCalc_sPrw'._

Narrative

Business context: 生产管理 → 生产单据 → 产量计件 — audit / un-audit of a 产量计件 (piecework production-report wage) bill on mftproductionreportwagemaster. The audit freezes the operator's reported output for payroll/KPI calculation.

What it does: Validates sGuid, refuses when bInvalid=1, then on iFlag=1 guards on bCheck and UPDATE mftproductionreportwagemaster to set bCheck=1, sStatus=1, sCheckPerson, tCheckDate. iFlag=0 reverses the flags. Note: the un-audit "already-unchecked" guard reads from salsalesdevmaster (a 销售开发 table) rather than the production-report table — a copy/paste residue from when this proc was forked from Sp_Calc_sScd/similar.

Invocation: Bound to gdsmodule.sProcName on 产量计件 (sId 101251240115016088043411460) under 生产管理 → 生产单据. Dispatched by Java BusinessBaseServiceImpl.getPrcName(sFormGuid, …) on the audit/un-audit button. Install scripts: script/标版/30100101/Sp_Calc_sPrw.sql.

Caveat: the ROUTINE_COMMENT is stale ('销售机会') and the un-audit guard queries the wrong table (salsalesdevmaster). Header is misleading — the body actually serves piecework production reporting.