# `Sp_work_mftworkorderprocessHour` (procedure)

> 工单工序选择机台后重算时间


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

## Parameters

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

## Body

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

## Narrative

**Business context:** 生产管理 → 工单工序 — one-shot data-repair: "工单工序选择机台后重算时间" (after a machine is selected for a work-order process, recompute its `dHour`). Designed to backfill `mftworkorderprocess.dHour` on historical rows created before the machine-aware capacity formula was wired up — note the hard-coded `tCreateDate < '2020-10-02'` cut-off.

**What it does:** `UPDATE mftworkorderprocess SET dHour=0` for everything, then opens a cursor over `viw_mftworkorderprocess P LEFT JOIN MftWorkOrderMaterials M` filtered to `(sBrId, sSuId)`, `dProductQty>0`, `tCreateDate<'2020-10-02'` and grouped by `sSlaveId`. For each row resolves the per-row context (`sControlId`, `sProcessId`, `sMaterialsId`, `sCustomerId`, `sProductId`) plus `sCapacityFormulaId`/`dCapacityHour` and writes back the recomputed `dHour`. `p_sLossMsg/p_sDetail` are accumulated and returned via `sReturn` for the operator.

**Invocation:** Status: appears orphaned. No caller found in any channel — no form-master, no gdsmodule hook, no other proc, the only xly-src hit is its own install script `script/标版/30100101/Sp_work_mftworkorderprocessHour.sql`. The hard-coded date cut-off and the "selected machine" naming match a one-off DBA helper run manually after a 2020-10-02 schema change. Candidate for maintainer audit.
