Sp_Invalid_backwriting (procedure)

作废/取消后数据反写

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

Parameters

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

Body

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

Narrative

Business context: Per-form 作废 / 取消作废 back-write dispatcher. Chained from Sp_Invalidation after the bInvalid flag flip succeeds — translates the generic "void this row" intent into the form-specific upstream/downstream reversal by routing to the right Sp_afterSave_s<Code> / Sp_beforeSave_s<Code> handler based on the form's sFormGuid. Without this hop, a void on a 销售订单 would not roll back the qty written on its source 销售订单需求 (Sod), a void on a 采购订单 would not roll back the qty on purpurchaseplanmaster (Pod), etc.

What it does: Strips a leading comma from sGuid. Then a long if/elseif ladder matches sFormGuid against a dozen-plus form ids (销售订单 family Sod, 采购订单 Pod, 送货通知 Dgn, …). For each match, when bInvalid=0 (取消作废 / unvoid) it call Sp_beforeSave_s<Code>(sGuid, sBrId, sSuId, sCode, sReturn) to re-apply the row's effects upstream; when bInvalid=1 (作废) it call Sp_afterSave_s<Code>(...) to reverse them. The pre/after naming is reversed relative to ordinary save semantics — Sp_afterSave is the "now that the row is gone, undo what it did" handler.

Invocation: Called only by Sp_Invalidation — see that proc's narrative for the Java entry point (CheckmodelServiceImpl.invalidationCheckModel()). The 6-step search finds the install script at script/标版/30100101/Sp_Invalid_backwriting.sql and one DB caller (Sp_Invalidation). Maintenance note: adding a new form that needs void/unvoid back-write requires extending the ladder here as well as supplying the matching Sp_beforeSave_* / Sp_afterSave_* pair.