# `Sp_productionplan_ControlProcessTrack` (procedure)

> @author:钱豹
							@date:20210711 封存
							@describe: 生成计划:加载从表数据(加号点击)，主要功能：
							1、根据工单，装配单 取工艺路线
							2、根据机台计划 更新 工序状态
							3、按机器中的排程规格，更新每个机台的IORDER
							4、按工艺路线，更改机台的开始时间，推算交期


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sLoginId` | `varchar(100)` |
| 2 | IN | `sBrId` | `varchar(100)` |
| 3 | IN | `sSuId` | `varchar(100)` |
| 4 | IN | `p_sProductionPlanId` | `varchar(255)` |

## Body

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

## Narrative

**Business context:** 生产计划管理 → 生管主计划 — 跟踪 (track) variant of `Sp_productionplan_ControlProcessNew`. Same COMMENT header (`@author:钱豹 @date:20210711 封存`) and same purpose — load the process-flow tree for an expanded plan row — but resolves `sWorkOrderId` indirectly through `mftworkorderslave` so the call site can hand it a slave/部件 `sId` instead of a 生产主计划 master `sId`.

**What it does:** Same `SysSystemSettings.CkxXd` read; differs from ControlProcessNew at the top: `SELECT m.sWorkOrderId INTO p_sWorkOrderId FROM mftproductionplan m JOIN mftworkorderslave B ON M.sWorkOrderId = B.sParentId WHERE B.sId = p_sProductionPlanId` (i.e., treats the incoming id as a 工单从表 row). From there it builds the wide `Productionplan_ControlProcess_Tmp` and runs the same multi-pass enrichment as ControlProcessNew — loading process rows, layering machine-plan state, refreshing per-machine `iOrder`, propagating timeline.

**Invocation:** No xly-src grep hit and no live dispatcher binding found — Status: appears orphaned. Sibling `Sp_productionplan_ControlProcessNew` is the active variant called by `WorkOrderPlanServiceImpl.getControlProcessList(...)`. Likely a deprecated tracking-view spike. Candidate for maintainer audit.
