Sp_AfterPost_sAcc (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 PROCEDURESpAfterPost_sAcc'._
Narrative
Business context: 质量事故报告 (quality-accident report) — the Sp_AfterPost_* family is the canonical post-审核 (post-approval) calc-proc tier in xly's bill lifecycle (alongside Sp_beforeSave_*, Sp_afterSave_*, Sp_Calc_*, Sp_Check_*, Sp_saveReturn_*). The _sAcc variant is meant to fire after a quality-accident bill's approval to refresh the master row's "has attachment" flag.
What it does: Validates sData is JSON (else returns sCode=1); runs a single UPDATE mftqualityaccidentMaster A LEFT JOIN (SELECT COUNT(sId) iCount, sParentId FROM eleproductfile GROUP BY sParentId) B ON A.sId=B.sParentId SET A.bFile = IF(IFNULL(B.iCount,0)>0,1,0) WHERE sId=sGuid so the accident row reflects whether any eleproductfile attachments exist for it.
Invocation: Status: appears orphaned. No caller found in any channel (form-master, gdsmodule hooks, other routines, xly-src grep, schema *Post* columns) — candidate for maintainer audit. The lifecycle slot the proc was designed for (Sp_AfterPost_*) is not wired in the current Java Bill flow; the attachment-flag refresh has either been moved into a different calc-proc or dropped.