# `Sp_Calc_sPpa` (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_sPpa`'`._

## Narrative

**Business context:** 采购管理 → 采购明细 → 采购申请单据 — purchase-application (采购申请, PR) audit on `PurPurchaseApplyMaster`. Also serves 客来料入库通知单据 (customer-supplied-material inbound notify) under 销售单据 (the same approval + rollup mechanics apply because the upstream demand row format is shared). The check opens the application for PO consumption; the uncheck rolls quantities back.

**What it does:** Aggregates `purpurchaseapplyslave` by `sMaterialsId+sMaterialsStyle`, summing `dMaterialsQty`/`dAuxiliaryQty` per material. On `iFlag=1` optionally drives `Sp_System_CheckFlow` per slave when `CkxDefineCheck=1` & `iTmpCheck<>1`; back-stamps the applied quantity into the upstream demand rows (`MftWorkOrderMaterials.dAppliedQty`, `salsalesordermaterials.dAppliedQty`); updates `purpurchaseapplydetail` rollup; flips `bCheck=1, sStatus=1, sCheckPerson, tCheckDate` on `PurPurchaseApplyMaster`. `iFlag=0` calls `Sp_Bill_Used` first to refuse when a PO already references this PR, then reverses.

**Invocation:** Bound to `gdsmodule.sProcName` on 采购申请单据 (sId `192116810113315217105813660`, parent 采购明细) and 客来料入库通知单据 (sId `101251240115016341830790030`, parent 销售单据) — dispatched by `BusinessBaseServiceImpl.getPrcName(sFormGuid, …)` on the audit/un-audit button. xly-src ships `script/标版/30100101/Sp_Calc_sPpa.sql` (install) and a period-validation removal patch.