# `Sp_Apply_Flow_OpsCheck` (procedure)

> 流程启动前调用-发外对账修改单价
					对账改了单价总价也会变，发票也涉及到改价格。
					这个到时候需要增加审批流程，比如说超过100元的，
					二级部门、一级部门，财务审核，
					超过2万的总经理审核


- **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_OpsCheck`'`._

## Narrative

**Business context:** 发外对账 → 发外加工流程 → KPI流程操作菜单 (catalog header: "流程启动前调用-发外对账修改单价 — 对账改了单价总价也会变，发票也涉及到改价格 / 二级部门、一级部门，财务审核, 超过2万的总经理审核"). Per-form workflow-apply data builder for the subcontracted-process reconciliation (`opsoutsidecheckingmaster`) when reconciliation changes the unit price.

**What it does:** Resolves six approver tiers: 二级部门 (制单人's department head), 一级部门 (制单人's grandparent department head), 财务 (`iPosition=11`), 总经理 (`iPosition=1`), 副董执行董事 (`iPosition=38`), 国内事业副总 (`iPosition=34`). Computes 是否烟包 (`p_iOut`) by joining `opsoutsidecheckingslave` → `salsalesordermaster` → `elecustomer` → `siscustomerproperty.sName='烟包'`. Aggregates `p_dChangeMoney` = `SUM(dMaterialsMoney) - SUM(dMaterialsPrice*dMaterialsQty)` across slave rows where the current price differs from the source-工序发外 row's price, *excluding* a hardcoded list of 7 工序 sIds (模切版/菲林/etc) that are exempt from price-change approval. Builds `p_sProcessMemo` / `p_sProductName` summaries grouped by the source form (`opsoutsideprocessmaster.sFormId='101801153119616594919790770'` for 工序发外 vs `'192116810113315234963208090'` for 整单发外). Emits `sTableParams` (发外对账单号/供应商名称/差异金额/对账信息/对账备注) and `sTableParamsValue` (master values + `iOut` + the six approver name lists `OneFlow`/`TwoFlow`/`ThreeFlow`/`FourFlow`/`NineFlow`/`TenFlow`).

**Invocation:** Dispatched dynamically by Java `CheckExamineFlowDataServiceImpl.doSendCheckFolwData()` via `doProByNameFlow(..., sApplyProName, ...)` where `sApplyProName` is read from `gdsmoduleflow.sApplyProName` on the 发外对账 workflow config row. `gdsmoduleflow` is empty in this database — workflow configs are tenant-provisioned per deployment.

Flags: the exempt-工序 list (7 hardcoded process sIds: `1691254111216986535514710` etc, including `17024524340001397977945229603600`, `17050515990006986455489932151000`, `17054858080003494616334115346000`) and the source-form sIds are tenant-specific — cloning to a different deployment loses the price-change-exemption rule. Approver-tier numbering uses `NineFlow`/`TenFlow` slots (gaps at FiveFlow/SixFlow/SevenFlow/EightFlow), aligning with the family-wide convention where tier numbering reserves slots for related procs.
