Sp_Check_sOiv (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_sOiv'._
Narrative
Business context: KPI流程操作菜单 → 发外加工流程 → 发外发票 — thin post-save wrapper that delegates to Sp_afterSave_sOiv. No validation rules of its own; exists so the save dispatcher can hit the Sp_Check_* slot while the actual side-effects live in the Sp_afterSave_* peer.
What it does: Initialises sCode=1, iFlag=IFNULL(iFlag,0), sReturn='', then immediately calls Sp_afterSave_sOiv(sGuid, sBrId, sSuId, sCode, sReturn) inside the top: block; relies on that peer to populate sReturn/sCode.
Invocation: Bound to gdsmodule.sSaveProName (post-save) on 发外发票 (101251168116315832142387420, under KPI流程操作菜单 → 发外加工流程). Dispatched by BusinessBaseServiceImpl.checkUpdate(..., "sSaveProName") after the save batch commits. No xly-src install script ships for this name — body is database-resident only.