Sp_Qualityaccident_CheckUpdate (procedure)
质量事故报告
- Type: PROCEDURE
- Deterministic: NO
- SQL data access: CONTAINS SQL
Parameters
| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | sGuid |
varchar(100) |
| 2 | IN | sData |
longtext |
| 3 | IN | sAllData |
longtext |
| 4 | IN | sFormGuid |
varchar(100) |
| 5 | IN | sLoginId |
varchar(100) |
| 6 | IN | sBrId |
varchar(100) |
| 7 | IN | sSuId |
varchar(100) |
| 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 PROCEDURESpQualityaccident_CheckUpdate'._
Narrative
Business context: 制造管理 → 质量事故报告 (mftqualityaccidentMaster). Pre-check / pre-save recompute that reconciles dMaterialsLossMoney, dLoseMoney, dReplenishmentQty and per-责任人 dResponsibleMoney on the master + slave rows before the bill is committed. The DB COMMENT just reads "质量事故报告".
What it does: Validates sData as JSON; pulls sWorkOrderId from mftqualityaccidentMaster for sGuid. Then: (1) where dMaterialsLossMoney=0, computes it from mftworkordermaterials ÷ mftworkordercontrol.dSumMachineAllQty × this slave's dReplenishmentQty/dPartsQty/1.13; (2) recomputes dLoseMoney = dMaterialsLossMoney + dPrintLossMoney + dOtherMoney; (3) syncs master dReplenishmentQty from SUM(slave.dReplenishmentQty) if they disagree; (4) prorates each slave's dResponsibleMoney against dLoseMoney. Master+slave updates are scoped by sBrandsId/sSubsidiaryId.
Invocation: No gdsmodule.sSaveProName/sSaveProNameBefore/sCalcProName binding, no other routine references it, and grep -rln on xly-src returns one hit — script/标版/30100101/Sp_Qualityaccident_CheckUpdate.sql (the install script). Signature (sGuid, sData, sAllData, sFormGuid, sLoginId, sBrId, sSuId, OUT sCode, OUT sReturn) matches the Sp_Check_s<Code> POST-save validator slot dispatched via gdsmodule.sSaveProName. Status: appears orphaned in the live config; candidate for maintainer audit — likely the binding was dropped while the proc body stayed.