# `Sp_Calc_sRgdApply` (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_sRgdApply`'`._

## Narrative

**Business context:** 销售退货申请 — audit / un-audit of a 销售退货申请 (sales-return application / pre-approval) on `SalRejectGoodsApplyMaster`. Sits upstream of the actual 销售退货 (`Sp_Calc_sRgd`): the customer files a return request, ops approves it via this proc, and a downstream 销售退货 bill is later created against the approved application.

**What it does:** Validates `sGuid`, locks (`SysLocking` check), refuses when `bInvalid=1`. Reads the `CbxDeliverGoodsNotify` system setting to know whether the upstream link is a sales-order or a delivery-note. On `iFlag=1` guards on already-checked, then `UPDATE SalRejectGoodsApplyMaster` to set `bCheck=1`, stamp `sCheckPerson`/`tCheckDate`. `iFlag=0` reverses. Compared to `Sp_Calc_sRgd` this proc does NOT touch inventory, receivables, or delivery-slave qty — it just gates the application's approved status.

**Invocation:** No `gdsmodule.sProcName='Sp_Calc_sRgdApply'` binding in this snapshot, no other proc/func references it, no xly-src grep hits. **Status: appears orphaned in the standard dispatcher path.** Dispatched via a 销售退货申请 module that may live in a customer overlay, or via a separate workflow path not yet surveyed here — candidate for maintainer audit.