Sp_Calc_sRgdApply (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(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 PROCEDURESpCalc_sRgdApply'._

Narrative

Business context: 销售退货申请 — audit / un-audit of a 销售退货申请 (sales-return application / pre-approval) on SalRejectGoodsApplyMaster. Sits upstream of the actual 销售退货 (Sp_Calc_sRgd): the customer files a return request, ops approves it via this proc, and a downstream 销售退货 bill is later created against the approved application.

What it does: Validates sGuid, locks (SysLocking check), refuses when bInvalid=1. Reads the CbxDeliverGoodsNotify system setting to know whether the upstream link is a sales-order or a delivery-note. On iFlag=1 guards on already-checked, then UPDATE SalRejectGoodsApplyMaster to set bCheck=1, stamp sCheckPerson/tCheckDate. iFlag=0 reverses. Compared to Sp_Calc_sRgd this proc does NOT touch inventory, receivables, or delivery-slave qty — it just gates the application's approved status.

Invocation: No gdsmodule.sProcName='Sp_Calc_sRgdApply' binding in this snapshot, no other proc/func references it, no xly-src grep hits. Status: appears orphaned in the standard dispatcher path. Dispatched via a 销售退货申请 module that may live in a customer overlay, or via a separate workflow path not yet surveyed here — candidate for maintainer audit.