交付出件箱

批 A（价格管理）开发内容梳理 · 待长官确认

2026-08-14 · dev2 云机 · 依据 = 方案正本 1017 行（门店签约并行化方案v2-微信支付版-20260813.md）+ 效果图 ③ 节
本文每条都标了方案出处行号，不是凭交接件摘要写的。确认后我才落第一行代码。

一、这批做什么（一句话）

PC 管理台新增一个「价格管理」页,把"单价"这个能力从无到有建起来 —— 因为现在全系统没有定价能力，金额和席位数全靠门店手填，这是接微信支付的前置条件。

批 A 不碰支付，零依赖，做完可独立上线。

二、范围清单（做什么）

2.1 数据层 · 新增 2 张表（方案 §三 line 95-103、§五AA line 692-701）

service_prices（价格表）

字段	说明
`id`	主键
`name`	服务项目名，默认「赵阳智脑」
`unit_price`	单价（元 / 席 · 365 天）
`default_quantity`	默认数量，默认 1
`is_active`	上架 / 下架
`updated_at` / `updated_by`	最后修改（`updated_by` = `Integer FK users.id`）

service_price_changes（改价历史 · 🔴 必须独立成表）

字段	说明
`id` / `price_id`	主键 / 关联价格表
`old_price` / `new_price`	改价前后
`changed_by` / `changed_at`	谁改的、什么时候（`Integer FK users.id`）
`remark`	可空

🔴 一改一行，永不覆盖。理由：service_prices.updated_by/at 是覆盖式的只留最后一次，而效果图的「改价记录」弹窗要列历次改价；且订单按 price_snapshot 结算，事后对账要能追溯"某笔订单成交时单价多少、谁改的"。

2.2 后端 API（新建模块 `settlement/backend/app/api/settlement/service_prices.py`）

端点	用途
列表	价格管理页表格数据（服务项目 / 单价 / 默认数量 / 状态 / 最近改价）
改价	写 `service_prices.unit_price` + 同时 insert 一行 `service_price_changes` + 同时写 `AuditLog`
上下架	切 `is_active` + 写 `AuditLog`
改价记录	读 `service_price_changes`，倒序

2.3 前端 · PC 管理台（`settlement/web/app/platform/minicup/`）

左侧菜单新增「价格管理」入口
列表页：服务项目 / 单价 / 默认数量 / 状态 / 最近改价 / 操作
操作列只有「编辑」一个按钮 —— 方案明确：叫「改价」会让人以为只能改价，不知道里面还有记录；「编辑」涵盖改价 + 上下架 + 查看改价记录，全在同一个弹窗
编辑弹窗：当前单价（只读）· 默认数量 · 新单价输入 · 说明文案「改价只影响改价后新建的订单；已支付订单按下单时的单价快照结算，不受影响」· 保存 · 下方「改价记录」表（时间 / 原价 / 改后价 / 操作人）

三、明确不做的（防止范围膨胀）

项	为什么不做	归属
「新增服务项目」按钮	方案原话：当前仅赵阳智脑一个商品，等真有第二个再加	后议
`payment_orders` 表、下单/回调/查单	微信支付	批 B
机构列表「付款」独立列、筛选改造	列表改造	批 D
门店端支付页、增购弹层	页面改造	批 C / E
原价划线视觉（§五T.2）	见下方待确认 ①	批 C / E

四、🔴 我发现的问题 / 需要长官拍板的（5 条）

① 方案导读有一处指错（我判定不做，请确认）

导读 line 16 写「做批 A 价格管理 → 看 五 N（数据模型）· 五 T.2（原价样式）」，但实查：

数据模型在 §三（line 93），不在 §五N（§五N line 713 是"微信支付接入"）
§五T.2 原价划线，方案 line 1016 明写应用处是「门店端支付页、增购弹层」→ 那是批 C / E，不在批 A

⇒ 我的判定：批 A 不含 T.2 原价样式。 若您认为要一起做，请说。

② 单价填多少？效果图那 ¥2,380 是真实价格吗？

效果图里显示：当前单价 ¥2,380.00 / 席 · 年，且带了 3 条历史（05-12 初始 ¥1,980 → 07-01 ¥2,180 → 08-13 ¥2,380）。

我不会把效果图的示意数字当真实价格写进初始化数据。
需要您给准信：上线时初始单价定多少？
历史那 3 条是画图用的示意，我只写 1 行"初始"记录，不伪造历史

③ 「下架」要不要保护？（方案没写）

当前只有一个商品。如果平台把它下架了，门店端就无商品可下单 → 签约流程直接断。

我的建议：加一道「最后一个上架商品不允许下架」的服务端校验
方案里没这条，属我自检发现，要您点头才加（不擅自加功能）

④ 谁能改价？（权限口径）

改价是危险操作（方案 §五AA 明确要留痕）。现网平台侧有没有细分角色、哪些角色可以改价，我还没查。

选项 a：我先去查现网 platform 侧权限模型，查完给您方案
选项 b：您直接指定（如"只有超管能改"）

⑤ 页面路由命名

建议 settlement/web/app/platform/minicup/prices/（与现有 channels / stores / payment-confirm 同级）。菜单放在哪一项之后，您有偏好就说，没有我放在末尾。

五、实施纪律（我自己会守的，先交底）

代码只落 settlement/，不落核心 app/（方案实施红线 1）
🔴 alembic migration 手写，绝不跑 autogenerate —— 记忆里记着"结算侧 autogenerate 对同库会生成 DROP 45 张核心表"的高危；虽然近期主仓有「autogenerate 守门三连」的修复提交，但我动手前会先复验一遍，不凭记忆也不凭提交标题
命名跟现网对齐：迁移文件走 phaseNN_NNN_xxx.py 格式（现有 14 个都是这个格式）
updated_by / changed_by 一律 Integer FK users.id，与现网 6 处 *_by 同构；危险操作同时写 AuditLog（方案 §五AA line 710）
测试 禁 mock，e2e 真打；完工前跑 8 维物理 verify，每维贴终端输出

六、已完成的动手前 verify（证据）

维度	命令	结果
现状复验	`grep -rn "unit_price\\|service_prices\\|service_price_changes" app/ settlement/`	0 命中 ✅ 证实"系统当前无定价能力"属实，无冲突、无重复造轮子
落点确认	`ls settlement/backend/app/api/settlement/`	15 个模块，无价格相关 → 需新建
前端落点	`find settlement/web/app/platform -type d`	现有 stores / channels / finance / payment-confirm / revenue-ledger / settlements / share-records → 价格页需新建
迁移链	`ls settlement/backend/migrations/versions/`	14 个，最新 `phase66_000_zero_guarantee.py`

七、请您回我三件

① 的判定（批 A 不含原价样式）对不对？
② 初始单价填多少？
③ 下架保护 加不加？④ 改价权限 走 a 还是 b？

这四条定了我就开工。⑤ 路由命名您不表态我就按建议来。