Sp_Calc_sFksq (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_sFksq'._

Narrative

Business context: 财务管理 → 财务单据 — payment-request audit (COMMENT '付款申请'). Despite the 付款申请 (payment-request) label and sFksq (付款申请) name, the body operates on expensereimbursementmaster / expensereimbursementslave — byte-identical to Sp_Calc_sFybx (费用报销). The two siblings appear to be split for module-naming convenience even though they audit the same table.

What it does: Validates sGuid, refuses when bInvalid=1, checks sysaccountperiod.bFrozen per SysSystemSettings.CkxIntervalMonthModifyBill. With iFlag=1: guards on bCheck=1, Update expensereimbursementmaster to set the audit flags, Update expensereimbursementslave to flip slave bCheck=1, and Update advanceCostCheckMaster to write back the reimbursed amount against the prior advance-cost record. Uncheck reverses the master/slave flags but does not unwind the advanceCostCheckMaster back-write — flag for maintainer audit if reversibility matters.

Invocation: Status: appears orphaned. No live gdsmodule.sProcName binding, no sSaveProName hook, no other-routine CALLs, no xly-src reference — candidate for maintainer audit. The active 付款申请 form in production is likely Sp_Calc_sFksq1 (which operates on the newer paymentRequest table), with sFksq left as a legacy duplicate of the 费用报销 (Sp_Calc_sFybx) flow.