Sp_PurpurchaseOrder_CheckUpdate (procedure)

采购订单保存校验

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

Parameters

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

Body

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

Narrative

Business context: 采购管理 / 物料采购流程 → 采购订单 (module 192116810113315217757747140) — pre-save helper that snapshots the original purchase price into dOldMaterialsPrice / dOldMaterialsMoney on every purpurchaseorderslave row of the order being saved, so downstream procs (and the user-visible "原价" column) keep the pre-edit price for audit. Despite the _CheckUpdate suffix and COMMENT '采购订单保存校验', the body is back-write rather than validation.

What it does: UPDATE purpurchaseorderslave SET dOldMaterialsPrice = dMaterialsPrice WHERE sParentId = sGuid, then UPDATE purpurchaseorderslave SET dOldMaterialsMoney = ROUND(dOldMaterialsPrice * dMaterialsQty, 2) WHERE sParentId = sGuid. Further blocks in the body handle approval-flow message dispatch (p_sMsgId, p_sMakePersonGroupName) — see body for the rest.

Invocation: Called by Sp_Check_sPod (the audit check proc bound to the 采购订单 module via gdsmodule.sSaveProName='Sp_Check_sPod', sId 192116810113315217757747140). So this proc fires indirectly during save of a 采购订单 (sFormId matches the order form) via the standard POST-save Check chain dispatched by BusinessBaseServiceImpl. Not present in xly-src 30100101 install scripts — DB-only.