Sp_update_BusineesVoucherBillNo (procedure)

业务单据删除前校验 -1 回滚

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

Parameters

#	Mode	Name	Type
1	IN	sFormGuid	varchar(100)
2	IN	iFlag	int
3	IN	sGuid	varchar(100)
4	IN	sTableName	varchar(100)
5	IN	sLoginId	varchar(100)
6	OUT	sReturn	varchar(4000)
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 PROCEDURESpupdate_BusineesVoucherBillNo'._

Narrative

Business context: 财务 → 凭证 — pre-delete validator for udfVoucherMaster (业务单据删除前校验 -1 回滚). When a user requests to delete a voucher that was generated from a business document, this proc decides whether the delete is safe and, when not, returns sCode=-1 to roll back.

What it does: Looks up udfVoucherMaster (sId=sGuid) for sMastertbName (comma-separated list of source master tables) and bMinus (是否红冲). If bMinus=1 the proc immediately blocks with the localised sBusineesVoucherBillNoHcCantDel message ("红冲凭证不能直接删除，可删除相应的蓝字单据"). Otherwise it iterates the comma-separated sMastertbName list, splitting each token to find a candidate update column — the disabled inner branches show the original intent was to NULL out sVoucherBillId on every source master row, but the executable path now just walks the list. Returns sCode/sReturn.

Invocation: Status: appears orphaned. No caller found in any channel — not bound to a form-master, no gdsmodule hook, no other routine references it, and the only xly-src hit is its own install script script/标版/30100101/Sp_update_BusineesVoucherBillNo.sql. The name suggests it was meant to be wired as a sDeleteProName hook on a voucher form but never was. Candidate for maintainer audit.