# `Sp_WorkOrder_CalcDataPackStdQ` (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)` |
| 6 | OUT | `sCode` | `int` |
| 7 | OUT | `sReturn` | `varchar(5000)` |

## Body

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

## Narrative

**Business context:** 生产管理 / 生产工单 → 计算 (包装工单, Q 变体) — alternate full-bill calc for 包装工单. Signature identical to `Sp_WorkOrder_CalcDataPackStd`; the `Q` suffix marks a variant branch (likely "Q for quote/quick" or a customer-specific code-path) — both procs hit the same staging tables but the Q variant adds an extra working table `p_SlaveMoneyTable` (deletes then re-inserts per call) to track per-slave money separately.

**What it does:** Same shape as `Sp_WorkOrder_CalcDataPackStd` — operates on `mftworkordermaster_Tmp` / `mftworkorderslave_Tmp` / `mftworkordercontrol_tmp` / `mftworkordermaterials_tmp` / `mftworkorderprocess_tmp` keyed by `sGuid`+`sMakePerson`. Reads `SysSystemSettings` constants, runs the Product → Parts → Last pipeline inline, computes paper area / run-counts / loss / capacity / money. Adds a `p_SlaveMoneyTable` working table the standard variant doesn't have, suggesting it was forked for a per-slave-money output requirement.

**Invocation:** Enumerated in `CaclProNameEnum.SP_WORKORDER_CALCDATAPACKSTDQ` for direct Java invocation via `CaclProNameEnum.getNameByKey("Sp_WorkOrder_CalcDataPackStdQ")` — selected when the front-end passes `proName="Sp_WorkOrder_CalcDataPackStdQ"` into `WorkOrderCalcDataPackService`. Not dispatched by `Sp_Calc_sBgd`; appears to be Java-only. No xly-src install script — DB-only deployment, probably a customer-specific build.
