# `Sp_PlanListtDeliverDate_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_PlanListtDeliverDate_BtnRepair`'`._

## Narrative

**Business context:** 生产管理 → 生产计划 → 主计划 — bulk delivery-date adjust handler (proc COMMENT: "调整交期，主计划页面调用"). Operator picks rows in the 主计划 (`mftproductionplan`) grid, types a new `tDeliverDate`, and this proc cascades that date through every downstream entity tied to the work-order so the new commitment is visible across sales/work-order/plan/notify chains.

**What it does:** Parses `$.params[*].value[*].sId` and `$.changeValue.tDeliverDate` from `sProInParam`. For each `sId` it cursors `mftproductionplan` (filtered by `sBrandsId/sSubsidiaryId`) to fetch the `sWorkOrderId` plus the old delivery date, then runs five updates: `salsalesorderslave`, `mftworkorderslave` (slave on `sParentId`), `mftproductionplanslave`, `mftproductionplan` (also sets `sMaterialsCheckResult = '偏离交期'/'满足交期'` by comparing `tLastDeliverDate` vs new date), and `saldelivernotifyslave`. Finally inserts a `syslog` row tagged `sOperationType='调整交期'`, `sFormId='19211681019715708440774010'`, with the old/new dates in `sLog`.

**Invocation:** Dispatched dynamically by `GenericProcedureCallServiceImpl.doGenericProcedureCall()` — the 主计划 grid's 调整交期 toolbar button names this proc. Install script `xly-src/script/标版/30100101/schedule/Sp_PlanListtDeliverDate_BtnRepair.sql` is the source of truth. Twin `Sp_PlanListtDeliverDate_BtnRepair_memo` is an identical-body memo/snapshot copy.
