# `Sp_AdjustMoney_BtnRepair` (procedure)

> 费用报销单调整金额


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sProInParam` | `varchar(10000)` |
| 2 | IN | `sMakePerson` | `varchar(100)` |
| 3 | IN | `sBrId` | `varchar(100)` |
| 4 | IN | `sSuId` | `varchar(100)` |
| 5 | OUT | `sReturn` | `varchar(1000)` |
| 6 | OUT | `sCode` | `int` |

## Body

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

## Narrative

**Business context:** 报销申请 (expense-reimbursement) module — batch-edit button proc for the general expense reimbursement form. Header says 费用报销单调整金额. When the user multi-selects reimbursement detail rows and clicks the BtnBsOperation.BtnRepair dialog, the proc was expected to apply a single `dAdjustMoney` value (with an `sAdjustMemo` justification) to every selected `expensereimbursementslave` row, recomputing `dMaterialsMoney = dAccountMoney + dAdjustMoney`. Follows the canonical `_BtnRepair` template signature (`sProInParam` JSON + `sMakePerson`/`sBrId`/`sSuId` IN, `sCode`/`sReturn` OUT).

**What it does:** Parses `sProInParam` JSON; reads `$.changeValue.dAdjustMoney` and `$.changeValue.sAdjustMemo`; validates `sAdjustMemo` is non-empty (returns `Fun_Sis_GetConstNew('sAdjReasonCantEmpty')`, `sCode=-1` otherwise); iterates `$.params[*].value[*].sId` and runs `UPDATE expensereimbursementslave SET dAdjustMoney=…, dMaterialsMoney = dAccountMoney + dAdjustMoney, sAdjustMemo=… WHERE sId=…` for each selected id.

**Invocation:** Status: appears orphaned. No caller found in any channel (form-master `sSqlStr`/`sConfigSqlStr`, `gdsmodule` hooks, `gdsconfigformslave.sButtonParam` / `sButtonEnabled`, other routines, xly-src grep) — candidate for maintainer audit. `_BtnRepair` procs are normally dispatched dynamically via `sButtonParam` on a button row, but no row in `gdsconfigformslave` currently references this proc name; either the button was removed during a refactor or the form was decommissioned.

Caveat: validation sets `sCode=-1` but does not `LEAVE top`, so the empty-memo branch still continues and applies the update regardless — bug worth flagging.