Sp_delete_backwriting (procedure)

删除后数据反写

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

Parameters

#	Mode	Name	Type
1	IN	sGuid	longtext
2	IN	sFormGuid	varchar(100)
3	IN	sTableName	varchar(255)
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 PROCEDURESpdelete_backwriting'._

Narrative

Business context: Generic delete-reversal hub — runs the form-specific Sp_beforeSave_* for the bill being deleted, so that any upstream quantity/status reservations the original save wrote out are reversed before the delete itself commits. Per the dispatcher convention (Sp_delete_backwriting → Sp_beforeSave_* on delete), this is the cross-module rollback point for document deletes.

What it does: Cleans the leading comma on sGuid, then dispatches on sFormGuid to call the matching Sp_beforeSave_<Code> proc with the same (sGuid, sBrId, sSuId, sCode, sReturn). Covers 销售订单 (Sp_beforeSave_sSod), 采购订单 (Sp_beforeSave_sPod), 送货通知单 (Sp_beforeSave_sDgn), 送货单 (Sp_beforeSave_sDgd), 销售对账单 (Sp_beforeSave_sSck), and a chain of Sp_beforeSave_t* / Sp_beforeSave_sOpc/sOpn/sOpn1 etc. for outsource and toll-process flows. A handful of customer-side hooks (Sp_elematerials_BeforeUpdate) are left commented as historical.

Invocation: Called from Sp_DelMasterSlave_Pro immediately after the master-table identification block — i.e. on every document delete dispatched through BusinessBaseServiceImpl.delMethodPro (the central delete path). The Java side never references the proc directly; it reaches it via the Sp_DelMasterSlave_Pro chain. Install body: script/标版/30100101/Sp_delete_backwriting.sql.