Sp_Calc_sFksq1 (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_sFksq1'._

Narrative

Business context: 财务管理 → 财务单据 — payment-request audit on paymentRequest (COMMENT '付款申请'). The _1 suffix marks this as the newer 付款申请 variant: same Sp_Calc_sFksq shape rewritten against a dedicated paymentRequest table instead of reusing expensereimbursementmaster.

What it does: Validates sGuid, refuses when bInvalid=1, checks sysaccountperiod.bFrozen per SysSystemSettings.CkxIntervalMonthModifyBill. With iFlag=1: guards on bCheck=1 then Update paymentRequest to set bCheck=1, sStatus=1, sCheckPerson, tCheckDate. With iFlag<>1: symmetric uncheck. The version-1 body drops the advanceCostCheckMaster back-write loop that Sp_Calc_sFksq carried — pure master flip.

Invocation: Status: appears orphaned. No live gdsmodule.sProcName binding, no sSaveProName hook, no other-routine CALLs, no xly-src reference — candidate for maintainer audit. Likely bound only in customer-specific overrides for tenants on the newer paymentRequest schema.