# `Sp_Calc_sPpn` (procedure)

> 生产计划


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `iFlag` | `int` |
| 2 | IN | `iTmpCheck` | `int` |
| 3 | IN | `sFormGuid` | `varchar(100)` |
| 4 | IN | `sGuid` | `varchar(100)` |
| 5 | IN | `sLoginId` | `varchar(100)` |
| 6 | OUT | `sReturn` | `varchar(4000)` |
| 7 | IN | `sBrId` | `varchar(100)` |
| 8 | IN | `sSuId` | `varchar(100)` |
| 9 | OUT | `sCode` | `int` |

## Body

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

## Narrative

**Business context:** Production planning — 生产计划 audit on `MftProductionPlanMaster`. The check freezes a plan header and propagates the planned-status onto the matching `MftWorkOrderProcess` rows so downstream production reports can recognise the plan as active.

**What it does:** Guards on `sGuid`/`SysLocking`/`bInvalid`/`CkxIntervalMonthModifyBill` period-frozen check against `MftProductionPlanMaster`. When `CkxDefineCheck=1` & `iTmpCheck<>1` runs `Sp_System_CheckFlow` per slave for multi-step approval. On `iFlag=1` flips `bCheck=1, sStatus=1, sCheckPerson, tCheckDate` on `MftProductionPlanMaster` and stamps the plan-status into `MftWorkOrderProcess`; `iFlag=0` clears them.

**Invocation:** Status: appears orphaned in the live database. No `gdsmodule.sProcName` binding, no `gdsconfigformmaster` reference, no callers in `information_schema.ROUTINES`. xly-src ships only an install script (`script/标版/30100101/Sp_Calc_sPpn.sql`) — no Java/XML wiring. The 生产计划 module in production may instead use the family member `Sp_Calc_sPpr` (产量上报) or the planning logic may have moved into `MftProductionPlan*` MyBatis services; candidate for maintainer audit.