Sp_Check_sFksq (procedure)
付款申请保存之前数据校验
- Type: PROCEDURE
- Deterministic: NO
- SQL data access: CONTAINS SQL
Parameters
| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | sTableName |
varchar(100) |
| 2 | IN | sGuid |
varchar(100) |
| 3 | IN | sFormGuid |
varchar(100) |
| 4 | IN | sLoginId |
varchar(100) |
| 5 | IN | sBrId |
varchar(100) |
| 6 | IN | sSuId |
varchar(100) |
| 7 | IN | iFlag |
int |
| 8 | OUT | sCode |
int |
| 9 | OUT | sReturn |
varchar(4000) |
Body
Body is not pre-cached. To inspect: mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURESpCheck_sFksq'._
Narrative
Business context: 财务管理 → 付款申请单 (sFksq = 付款申请,on expensereimbursementmaster/advanceCostCheckMaster) — post-save validator that guards the link between a 付款申请 and the 预支单 it draws against, and back-fills the bank-account fields from the matching 费用细项 + 部门 line.
What it does: Reads sAdvanceOrderCodeId from expensereimbursementmaster for sId=sGuid. Joins advanceCostCheckMaster + the saved 报销单 + grouped advancecostcheckslave (by sExpenseDetailId/sParentId) to check that the requested dMaterialsMoney does not exceed the 预支单's remaining 金额; if it does, aborts with sPayUpPrePay ("付款申请金额大于预支单金额,请重新填写付款申请单"). Then updates expensereimbursementmaster.sAccountNo/sAccountId from descriptionoffeesslave joined on (sMExpenseDetailId, sMasterDepartId) so the bank account reflects the chosen expense item / department.
Invocation: Status: appears orphaned. No gdsmodule.sSaveProName/sSaveProNameBefore binding, no other routine references the name, no xly-src hit. The peer Sp_Calc_sFksq exists but is also not module-bound; both look like a half-wired feature for the 付款申请 form — candidate for maintainer audit.