2026-07-31-pl-plan-follow-status-redesign.md 3.0 KB

运输计划跟进状态重构设计

日期: 2026-07-31
范围: pl_plan.follow_status 枚举与流转;web-admin 运输计划列表/归档筛选与按钮;数据迁移。

背景

当前跟进状态为 draft / processing / completed / cancelled,其中 processing 无写入路径;安排运输只改 transport_status,跟进状态长期停在「草稿」,语义与操作脱节。

目标

跟进状态改为五档,并与业务动作绑定:

展示 存库值 说明
等通知 wait_notice 仅可从「待安排」手动进入
待安排 pending_arrange 新建默认
已安排 arranged 安排运输成功后
已完成 completed 首次归档成功后
已取消 cancelled 作废后(文案由「已作废」改为「已取消」)

transport_status(pending / arranged)保持独立,不合并。

流转规则

自动

  1. 创建(含从合同创建、create-full)→ pending_arrange
  2. 安排运输成功 → arranged(含当前为 wait_notice)
  3. 首次归档成功 → completed(archive_status=archived 同步)
  4. 作废 → cancelled

手动

  1. 等客户通知:仅当 follow_status=pending_arrange 且未归档、未取消 → wait_notice
  2. 取消等通知:仅当 follow_status=wait_notice → pending_arrange

「等通知」允许安排运输;安排成功后直接变为「已安排」。

API(方案 A)

  • POST /api/transport/plan/{id}/wait-notice — 设为等通知
  • POST /api/transport/plan/{id}/cancel-wait-notice — 取消等通知,回到待安排

安排、归档、作废接口内更新 follow_status,不依赖客户端传入。

PlanUpdate 若仍含 followStatus,服务端 SHALL 忽略或拒绝随意改写,避免绕过流转(推荐:更新接口不应用客户端提交的 follow_status)。

删除规则

允许删除当且仅当:

  • follow_status ∈ {pending_arrange, wait_notice}
  • transport_status = pending
  • archive_status ≠ archived

前端

  • 筛选与 Tag 文案对齐新五档;统一走 pl-display.ts(列表页去掉重复 map)
  • 运输计划列表工具栏 / 查看弹窗:
    • 「等客户通知」(pending_arrange)
    • 「取消等通知」(wait_notice)
  • 操作按钮文案「作废」可保留;状态展示为「已取消」

旧数据迁移

-- draft → pending_arrange
-- processing + transport arranged → arranged
-- processing + else → pending_arrange
-- completed / cancelled 不变

同步更新 docs/sql/shanxia2.0.sql 中列注释与默认值说明(若有 DEFAULT)。

非目标

  • 不改造 transport_status 枚举
  • 不恢复早期 OpenSpec 细粒度跟进链路(待采购/待发货等)
  • 不改归档页核心流程(仅筛选/展示文案)

自检

  • 无占位符
  • 与「等通知可安排」「仅待安排可进等通知」「可取消等通知」决策一致
  • 范围限于跟进状态,不扩运费/证件