# `Sp_WorkOrder_CalcDataStdBeforeAfter` (procedure)


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sGuid` | `varchar(100)` |
| 2 | IN | `bChangeRate` | `int` |
| 3 | IN | `sLoginId` | `varchar(100)` |
| 4 | IN | `sBrId` | `varchar(100)` |
| 5 | IN | `sSuId` | `varchar(100)` |

## Body

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

## Narrative

**Business context:** 生产管理 / 生产工单 → 计算 (准备阶段+收尾, 旧) — intended composite "before-and-after" wrapper of the default work-order calc: same staging reads as `Sp_WorkOrder_CalcDataStdBefore` plus the post-walk updates that finalise `MftWorkOrderMaterials_Tmp` and `mftworkordermaster_tmp`. Signature without `sCode`/`sReturn` (`sGuid, bChangeRate, sLoginId, sBrId, sSuId`) — designed to be wedged into the calc pipeline, not invoked directly by users.

**What it does:** Mirrors `Sp_WorkOrder_CalcDataStdBefore`'s setup (reads `mftworkordermaster_Tmp.sFormId`, four `SysSystemSettings` rows, first slave context) and then performs the after-phase updates: `UPDATE mftworkordermaster_tmp` totals, `Insert INTO MftWorkOrderMaterials_Tmp` for derived materials lines, `Update MftWorkOrderMaterials_Tmp` /`MftWorkOrderControl_Tmp` /`MftWorkOrderProcess_Tmp` /`MftWorkOrderSlave_Tmp` to consolidate the calc.

**Invocation:** Status: appears orphaned. No `gdsmodule` hook, no `gdsconfigformmaster` binding, no other DB routine references it, no xly-src hit. Almost certainly a dead twin of `Sp_WorkOrder_CalcDataStdBefore` retained from a pre-fork era when the calc was split into discrete before/before-after/after sub-procs — the current generation inlines all phases into `Sp_WorkOrder_CalcData{Pack,Book,Set,Flex,Std}`. Candidate for maintainer audit / cleanup.
