# `Sp_Apply_Flow_Work` (procedure)

> 流程启动前调用


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sFormGuid` | `varchar(100)` |
| 2 | IN | `sGuid` | `varchar(100)` |
| 3 | IN | `sSrcNo` | `varchar(100)` |
| 4 | IN | `sLoginId` | `varchar(100)` |
| 5 | OUT | `sTableParams` | `longtext` |
| 6 | OUT | `sSrcReportData` | `longtext` |
| 7 | OUT | `sTableParamsValue` | `longtext` |
| 8 | OUT | `sReturn` | `varchar(4000)` |
| 9 | IN | `sBrId` | `varchar(100)` |
| 10 | IN | `sSuId` | `varchar(100)` |
| 11 | OUT | `sCode` | `int` |

## Body

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

## Narrative

**Business context:** 生产工单 — minimal pre-approval display-data builder. Continues the `Sp_Apply_Flow_*` workflow-apply family but, unlike its sibling Apply procs, only emits the seven work-order header fields (单号 / 品名 / 规格 / 批量 / 单位 / 产品批号 / 生产日期 / 有效期至) without any tier roster.

**What it does:** Reads master `mftworkordermaster` joined to slave `mftworkorderslave` and `eleproduct` for `sGuid` and INTOs eight fields into `sTableParamsValue` as a JSON_OBJECT. `sTableParams` lists the seven Chinese labels for those keys. No tier resolution, no variance flags — pure display payload.

**Invocation:** Dispatched dynamically by Java `CheckExamineFlowDataServiceImpl.doSendCheckFolwData()` via `doProByNameFlow(..., sApplyProName, ...)` from `gdsmoduleflow.sApplyProName` (empty in this DB — workflow configs tenant-provisioned per deployment).

Flag: workflow-apply procs typically populate tier columns; this proc emits only the header fields. Consumer flow definition must reach approvers via `gdsmoduleflow` rows rather than embedded `<Tier>Flow` JSON keys.
