# `Sp_SortReportProcess` (procedure)

> 判断工单是否完工并修改


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sGuid` | `varchar(50)` |
| 2 | IN | `sBrId` | `varchar(50)` |
| 3 | IN | `sSuId` | `varchar(50)` |

## Body

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

## Narrative

**Business context:** 生产管理 → 生产报工 — assigns/refreshes the `iGroupOrder` ranking on work-order processes (`mftworkorderprocess`) and production-plan slaves (`mftproductionplanslave`) so report-quantity validation can compare against the previous process in the same group. Despite the page subtitle ("判断工单是否完工并修改"), the body is purely an ordering rebuild used by report-quantity guards.

**What it does:** Drops/creates `SortTmp` temp table; selects every `mftproductionplanslave` row for the scoped work-order (`sWorkOrderId = sGuid`, or all when `sGuid=''`) joined to `mftworkordercontrol` (excluding `bOutside=1`, `dProcessQty>0`), groups by `(sWorkOrderId || sId)` and assigns a 1..N rank via the classic MySQL `@rank` session-variable trick ordered by `iOrder` of the work-order-process. Then UPDATEs `mftproductionplanslave.iGroupOrder` from `SortTmp` and propagates the same rank up to `mftworkorderprocess.iGroupOrder` for the processes that back those plans.

**Invocation:** Called by `Sp_CheckExceedReport` (`p_sReportType='2'`) before it queries the previous-process report quantity — so the rank reflects today's plan topology when the operator submits 报工. Install script: `script/标版/30100101/Sp_SortReportProcess.sql`. No xly-src Java caller.
