# `Sp_beforeSaveReturn_sSfu` (procedure)

> 商机跟进存前反写数量


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sGuid` | `longtext` |
| 2 | IN | `sBrId` | `varchar(100)` |
| 3 | IN | `sSuId` | `varchar(100)` |
| 4 | IN | `iTag` | `int` |
| 5 | OUT | `sCode` | `int` |
| 6 | OUT | `sReturn` | `longtext` |

## Body

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

## Narrative

**Business context:** 销售线索 / 商机跟进 — variant-form of the sales-follow-up writeback. Comment header: `商机跟进存前反写数量`. The active save-hook for the 商机跟进 module is `Sp_beforeSave_sSfu` → `Sp_saveReturn_sSfu`; this `*Return` procedure carries a parallel implementation that updates `salsaleschancemaster.sFlow` from the latest `salsalesFollowUpmaster.sFollowUpPhase` directly, branching on `iTag` (1=before-save, 2=after-save).

**What it does:** Parses CSV `sGuid` into temp table `p_t_sId`, joins to `SalSalesCheckingSlave` to populate a `p_sSrcSlaveId_tmp` of upstream slave IDs, then in each `iTag` branch builds `p_MftworkOrderSlave_tmp` from `salsalesFollowUpmaster` and updates `salsaleschancemaster.sFlow` for the matched 商机. Commented-out tail blocks would have written back to `salsalesorderslave` / `developorderslave`.

**Invocation:** Status: appears orphaned. No caller found in any channel (form-master, gdsmodule hooks, other routines, xly-src grep across all extensions) — `Sp_beforeSave_sSfu` calls `Sp_saveReturn_sSfu`, not this proc. Candidate for maintainer audit; likely a forked draft that was never wired in.
