# `Sp_productionMainPlan_BtnEventBlockOne` (procedure)

> 主计划：锁定 状态为8  印刷、印后工序被锁定，当机台计划算到该时间点的时候，优先该工序排
				 例如工序锁定时间2022-04-30 18:00 - 20:00
				 机台上一道工序开始时间18：00之前的可以再此之前排，例如 16：00 - 19：00
				 那么该工序就是19：00-21：00
				 之后的要再该工序后面排


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sProInParam` | `varchar(10000)` |
| 2 | IN | `sMakePerson` | `varchar(100)` |
| 3 | IN | `sBrId` | `varchar(100)` |
| 4 | IN | `sSuId` | `varchar(100)` |
| 5 | OUT | `sReturn` | `varchar(1000)` |
| 6 | OUT | `sCode` | `int` |

## Body

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

## Narrative

**Business context:** 生产管理 / 主计划 → 锁定 (单行) — single-row variant of `Sp_productionMainPlan_BtnEventBlock`. Locks one specific `mftproductionplanslave` row (a single process line on the machine timeline) rather than every slave row under a work-order. The state-check, `mftproductionplan` master flip, and `Sp_unifiedPlanning_BtnCalculation_workorder` reschedule are all commented out — current behaviour only stamps the slave row.

**What it does:** Parses `$.params[*].value[*].sId` (interpreted as `mftproductionplanslave.sId`, not the master plan id). For each id, `UPDATE mftproductionplanslave SET bEmploy=1, sEmployPerson=sMakePerson, tEmploytime=NOW() WHERE sId=p_sId`. No state validation, no master update, no recalc — the proc is a stripped-down "soft-pin this one process line" toggle.

**Invocation:** Standard `Sp_<Module>_BtnEvent*` slot — dispatched by `GenericProcedureCallServiceImpl.doGenericProcedureCall()`. No xly-src install script, form-master binding, or gdsmodule hook. Name lives on the 主计划 single-row 锁定 button definition only. The commented-out scheduler-recalc block suggests this was a deliberately-thinned variant of the bulk-lock proc — audit before relying on it as a sufficient lock primitive.
