# `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 PROCEDURE `Sp_AfterPost_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.