# `Sp_BtnEventMaterialsSure_New` (procedure)


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sProInParam` | `longtext` |
| 2 | IN | `sMakePerson` | `varchar(100)` |
| 3 | IN | `sBrId` | `varchar(100)` |
| 4 | IN | `sSuId` | `varchar(100)` |
| 5 | OUT | `sReturn` | `varchar(1000)` |
| 6 | OUT | `sCode` | `int` |

## Body

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

## Narrative

**Business context:** 材料存货核算 — toolbar handler that batch-toggles 确认 on `accmaterialsstore` rows for a given costing period. Period gate: rejects the operation if `sysaccountperiod.bCalMaterials=1` (material cost already closed for that period).

**What it does:** Reads `$.params[0].value[0].sCostPeriod` and the array of `sId`s, then builds a temporary table `Sp_ids_Table` via PREPARE/EXECUTE using `JSON_EXTRACT(p_values, '$[*].sId')` reshaped into `('a'),('b'),...`. Gates: if `sysaccountperiod.bCalMaterials=1` for the chosen period, returns `sCode=-1, sBtnDepartFinished`. Otherwise joins `accmaterialsstore` against the temp table and flips `bConfirm = NOT bConfirm`, then sets `sConfirmMonth = CASE WHEN bConfirm=0 THEN '' ELSE p_sPeriodId END`. Drops the temp table. (The original per-row WHILE loop is left commented out at the end.)

**Invocation:** Dispatched dynamically by `GenericProcedureCallServiceImpl.doGenericProcedureCall()` (POST `/procedureCall/doGenericProcedureCall`) — 材料存货核算 grid's 确认 toolbar button names this proc as its action. Siblings in the cost-confirm family: `Sp_BtnEventDepartSure_New`, `Sp_BtnEventworkcenterSure_New`, `Sp_BtnEventProductInStoreSure_New`, `Sp_BtnEventProductionmaterialSure_New`, `Sp_BtnEventProductSure_New`.

Flag: the bulk `sConfirmMonth` update is computed from the **already-flipped** `bConfirm`, which is correct, but the inner CASE references the table's current `bConfirm` after the first UPDATE — semantically the intended "blank when unconfirming" branch fires correctly only because the first UPDATE has already toggled. Verify expected behaviour after maintainer audit.