# `Sp_Calc_sSodbecome` (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(5000)` |
| 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_sSodbecome`'`._

## Narrative

**Business context:** 销售管理 → 销售订单变更审核 (sales-order change-request audit — `SalSalesOrderbecomeMaster`). When a 销售订单 is changed (qty / spec / delivery date) after audit, the variance is recorded on a 变更 bill; auditing that 变更 propagates the new values back into the live 销售订单, work-order, delivery-notify and delivery-goods slaves.

**What it does:** Validates `sGuid`/`bInvalid`/`SysLocking`/`sysaccountperiod`, then on `iFlag=1` sets `bCheck=1`, `sCheckPerson`, `tCheckDate` on `SalSalesOrderbecomeMaster`; propagates the changed fields into `salsalesordermaster`/`salsalesorderslave` and synchronises downstream rows: `Update mftworkordermaster`/`mftworkorderslave` (work-order specs), `Update saldelivernotifyslave` and `Update saldelivergoodsslave` (open delivery-notify and delivery lines). `iFlag=0` rolls back to the pre-change values.

**Invocation:** Status: not bound to any current `gdsmodule.sProcName`, form-master `sSqlStr` ref, or other-routine caller; no xly-src grep hit. Despite the rich change-propagation body, this audit slot for `SalSalesOrderbecomeMaster` is not wired into the live metadata in this database — candidate for maintainer audit. Likely either superseded by a sibling proc / btn-event handler or pending re-wiring after a recent change. Verify deployment.