Sp_System_MaterialsAllReSure (procedure)
- Type: PROCEDURE
- Deterministic: NO
- SQL data access: CONTAINS SQL
Parameters
| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | sProInParam |
varchar(10000) |
| 2 | IN | sMakePerson |
varchar(100) |
| 3 | IN | sBrId |
varchar(100) |
| 4 | IN | sSuId |
varchar(100) |
| 5 | OUT | sReturn |
varchar(4000) |
| 6 | OUT | sCode |
int |
Body
Body is not pre-cached. To inspect: mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURESpSystem_MaterialsAllReSure'._
Narrative
Business context: 成本核算 / 期间材料价格批量反确认 — inverse of Sp_System_MaterialsAllSure. Bulk-clears the 材料分摊价格 confirmation flag for selected periods on the 月度成本 module so the period can be recomputed. Refuses to run while downstream 成本核算 (accordercostanalysis iType=1 直接材料 or accproductionmaterialsslave 非工单领用) already holds bConfirm=1 data, to prevent ledger drift.
What it does: Validates sProInParam (JSON $.params[*].value[*].sId) hits sysaccountperiod; for each sId it reads sPeriodId / bCalMaterials, checks for any bConfirm=1 row in accordercostanalysis (iType=1) or accproductionmaterialsslave against that period — if found returns sCode=-1 with sCbhsHaveConfirmData. Otherwise refuses periods already bCalMaterials=1 ("数据已核算不能批量操作"). When clean, sets sysaccountperiod.bCalMaterials=0 for the listed periods and zeros related material-cost confirmation columns across accmaterialsstore / mitmaterialsstoreadjustmoney*.
Invocation: Status: appears orphaned at the procedure-call level (no other proc, form-master, or gdsmodule hook references it; no xly-src caller outside its own script/标版/30100101/cost/Sp_System_MaterialsAllReSure.sql install). Signature (sProInParam JSON, sMakePerson, sBrId, sSuId, sReturn, sCode) is the canonical Sp_BtnEvent_* dispatch shape — so it likely lands via GenericProcedureCallServiceImpl.doGenericProcedureCall() from a toolbar button on the 月度成本 grid; verify by searching for the literal Sp_System_MaterialsAllReSure in front-end button configs.