# `Sp_afterSave_sAcc` (procedure)

> 质量事故报告存后反写数量


- **Type:** PROCEDURE
- **Deterministic:** NO
- **SQL data access:** CONTAINS SQL

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sGuid` | `varchar(2000)` |
| 2 | IN | `sBrId` | `varchar(100)` |
| 3 | IN | `sSuId` | `varchar(100)` |
| 4 | OUT | `sCode` | `int` |
| 5 | OUT | `sReturn` | `varchar(4000)` |

## Body

_Body is not pre-cached. To inspect: `mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURE `Sp_afterSave_sAcc`'`._

## Narrative

**Business context:** 质量事故报告 (quality-accident report) — thin save-phase wrapper. The `Sp_afterSave_s<Code>` family is the historic post-save hook tier: each is a 1-line delegator to `Sp_saveReturn_s<Code>(..., iFlag=2, ...)` (the `iFlag=2` phase code signals "after save" for the saveReturn worker, distinguishing it from the audit/反审 paths that pass `iFlag=1`/`0`). For `_sAcc` the worker is `Sp_saveReturn_sAcc` — meant to re-write quantities on related rows after the accident report is saved.

**What it does:** Wraps `sGuid` in double-quotes if not already quoted (the worker expects a JSON-array-style id list) and, when `sGuid` is non-empty, runs `CALL Sp_saveReturn_sAcc(sGuid, sBrId, sSuId, 2, @sCode, @sReturn)`. Does not propagate `@sCode`/`@sReturn` back to its own OUT params (unlike the `_sGYKK` sibling which does).

**Invocation:** Status: appears orphaned. No caller found in any channel — no `gdsmodule` row sets `sSaveProName` / `sCalcProName` / `sProcName` to this name, no form-master `sSqlStr` references it, no other routine calls it, and `grep` across xly-src finds no hits. Java `BusinessBaseServiceImpl.addUpdateDelBusinessData()` dispatches the post-save hook via the form/module's `sSaveProName` column, but in production that column holds the corresponding `Sp_Check_s<Code>` name, never `Sp_afterSave_s<Code>` — candidate for maintainer audit. The wrapper-plus-worker pair is decommissioned legacy.