# `Sp_WorkOrder_TechnologicalProcess` (procedure)

> 工序工序流程


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `p_sWorkOrderId` | `varchar(100)` |
| 2 | IN | `sBrId` | `varchar(100)` |
| 3 | IN | `sSuId` | `varchar(100)` |
| 4 | OUT | `sReturn` | `varchar(4000)` |
| 5 | OUT | `sCode` | `int` |

## Body

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

## Narrative

**Business context:** 制造 → 工单 — 工序工序流程 (per `COMMENT`): denormaliser that writes the "→"-separated process chain (e.g. `印刷->过油->模切->贴合`) into `mftworkordercontrol.sTechnologicalProcessMemo` for the given 工单, so the 工单 print/preview and Gantt views can show one-line process flows per control row without re-aggregating live.

**What it does:** Two `UPDATE mftworkordercontrol P INNER JOIN (SELECT GROUP_CONCAT(eleprocess.sProcessName ORDER BY sType, iOrder SEPARATOR '->') ... FROM MftWorkOrderProcess JOIN eleprocess ON sId=sProcessId GROUP BY sControlId)` passes: first pass with `sType <> '3'` populates the base chain; second pass with `sType = '3'` appends the post-process steps, concatenating onto the existing memo with another `->`. Both pass scope is `sParentId=p_sWorkOrderId AND sBrandsId AND sSubsidiaryId`. `sCode` is set to 1 on entry but never changed.

**Invocation:** Status: appears orphaned in the standard DB. No `gdsmodule`/`gdsconfigformmaster` binding, no other live DB routine calls it. Referenced only by xly-src install scripts: `script/标版/30100101/schedule/Sp_WorkOrder_TechnologicalProcess.sql` (install), the 金宣发 customer-override `script/客户/金宣发/Sp_Calc_sWod.sql` calls it inside the audit flow (`CALL Sp_WorkOrder_TechnologicalProcess(sGuid,sBrId,sSuId,sReturn,sCode);`) — but the live `Sp_Calc_sWod` deployed in this DB does not include that line. Customer-specific helper; verify deployment before relying on it.
