# `sp_mitproductionapply_calculate` (procedure)

> 领料申请单据计算过程split，前台传入数据源，经过运算处理后返回前台渲染


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sDropTableSql` | `longtext` |
| 2 | IN | `sCreateTableSql` | `longtext` |
| 3 | IN | `insertSql` | `longtext` |
| 4 | IN | `selectSql` | `longtext` |
| 5 | IN | `sFormGuid` | `varchar(100)` |
| 6 | IN | `sLoginId` | `varchar(100)` |
| 7 | IN | `sBrId` | `varchar(100)` |
| 8 | IN | `sSuId` | `varchar(100)` |
| 9 | OUT | `sCode` | `int` |
| 10 | OUT | `sReturn` | `longtext` |

## Body

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

## Narrative

**Business context:** 生产管理 → 领料申请单据 — front-end-driven calculation pass for the 领料申请 (materials-requisition) form. The browser hands in lifecycle SQL (drop tmp / create tmp / insert / select) and a business hook fires in between to back-fill on-hand stock figures into the requisition's slave rows. The standard pattern lets a form's "calc" button reuse the same proc shell while the body section is module-specific.

**What it does:** Returns codes per the header comment (`-1` failure / `1` success / `2` confirm-needed / `-7` continue-prompt / `-8` failure-with-confirm). Runs `sDropTableSql`, `sCreateTableSql`, `insertSql` each as `;`-split prepared statements. Then the inline business pass: creates a temporary `A1` keyed by `(sMaterialsId, sMaterialsStyle)` containing `SUM(dAuxiliaryQty), SUM(dMaterialsQty)` from `elematerialsstock` joined to `siswarehouse` where `bLine=0` (i.e. only physical, not online/transit warehouses); `UPDATE mitproductionapplyslave_calc_tmp a JOIN A1 b ON a.sMaterialsId=b.sMaterialsId AND b.sMaterialsStyle=IFNULL(a.sMaterialsStyle,'') SET a.dAuxiliaryQty1 = b.dAuxiliaryQty, a.handleType = IF(IFNULL(a.handleType,'')='','update',a.handleType)`. Then runs the front-end `selectSql` and the cleanup `sDropTableSql`.

**Invocation:** Status: appears orphaned by name. No caller found in any channel (form-master `sSqlStr`/`sConfigSqlStr`/`sSqlCondition`, gdsmodule hooks, other routines, xly-src grep across all extensions). The proc body matches the standard `BusinessCalculateServiceImpl` calc-split contract — Java code passes the four SQL chunks plus a `_calc_tmp` table name. Likely dispatched dynamically by class name and form metadata rather than by hard-coded references; candidate for maintainer audit.
