# `Sp_WorkOrder_CalcDataStdBefore` (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_CalcDataStdBefore`'`._

## Narrative

**Business context:** 生产管理 / 生产工单 → 计算 (准备阶段, 旧) — intended pre-flight phase of the default work-order calc: read the staging snapshot, pull `SysSystemSettings` corrugate constants, derive slave/customer/product/delivery context, and prime the per-control combine qty before the main calc walks the rows. Signature with no `sCode`/`sReturn` (`sGuid, bChangeRate, sLoginId, sBrId, sSuId` only) marks it as an early sub-step, not a top-level entry.

**What it does:** Reads `mftworkordermaster_Tmp.sFormId` for the order, four `SysSystemSettings` rows (`CbxCorrugateWidth`/`CbxCorrugateLength`/`NetCorrugateLengthSubtract`/`NetCorrugateWidthSubtract`), the first slave's (`MftWorkOrderSlave_Tmp`) `sCustomerId`/`sProductId`/`tDeliverDate`, then clears stale `sControlId` rows on `MftWorkOrderProcess_Tmp` and `mftworkordermaterials_Tmp` and sets every slave's `dProductQty` from the max combine ratio. Side-effects limited to the staging tables.

**Invocation:** Status: appears orphaned. No `gdsmodule` hook, no `gdsconfigformmaster` binding, no other DB routine references it, no xly-src hit. Same proc-shape and same staging-table reads as the logic inlined at the top of `Sp_WorkOrder_CalcDataStd` / `Sp_WorkOrder_CalcDataPackStd` — suggests it was the pre-fork "before" step that got inlined into each model-specific proc and then never deleted. Candidate for maintainer audit / cleanup.
