design.md 4.3 KB
Context
Monorepo 已包含 CRM（crm/ Java + Vue）、地磅（dibang-xiaoshou/）、报销 BX（bx/，本次不联动）、以及待扩展的 mobile-frontend（uni-app）。plan/计划需求.md 定义了计划域七步业务流程、与 CRM 合同/产品、地磅单据的深度耦合，以及统一账号与菜单权限的长期目标。SQL 参考要求指向 plan/sx.sql，表名 pl_ 前缀；车辆字段可参考 plan/vehicle_management.sql。
Goals / Non-Goals
Goals:
- 用分阶段里程碑（M0→Mn）交付：先对齐制品与路线图，再数据模型与 API，再 CRM/地磅改造与计划前端，最后运输结算与盘存深化。
- 建立 Python 计划域后端 与工作流能力，承载审核类状态机（运输结算等），并与 CRM 用户体系集成（复用或联邦，见 Decisions）。
- 保持历史 SQL 尽量少改；新增以
pl_为主，CRM/地磅侧以增量列/关联表为主。 - 文档与阶段总结统一落在
docs/系统文档/下，便于检索与审计。
Non-Goals:
- 本次不实现与 BX 报销 的接口或数据联动。
- 不在本阶段一次性完成全部业务代码合并或生产切换。
- 不强制在本设计阶段选定移动端视觉规范（仅约束技术栈为 uni-app 扩展）。
Decisions
- 流程模式：按《项目任务全流程助手》采用 Complex Mode；本 change 对应 M0：对齐与路线图，实现编码从 M1 起分里程碑门禁。
- OpenSpec 与能力拆分：按
proposal.md中八个 capability 分别建 spec，任务与测试用例映射到 capability，避免单文件不可维护。 - 编号规则：计划订单编号
SXDDH+YYYYMMDD+ 6 位序列；运输编号SXYS+ 序列（需求为 7 位可变长度时以实现为准，M1 锁定格式与并发分配策略）。 - 待入库 / 待出库判定：与需求文档一致——目的地为「安庆市山峡化工有限公司」或「安徽云栋化工有限公司」→ 待入库；供应商为上述二者之一 → 待出库（实现时以主数据或配置表承载公司全称，避免硬编码散落）。
- Web UI：新计划管理端采用 art-design-pro（与地磅现有
dibang-xiaoshou/art-design-pro对齐技术选型，复用组件与学习成本）。 - 工作流引擎：Python 生态选型在 M1 前完成 PoC（候选：Temporal、Prefect、或轻量自研状态机 + DB；不以 Java Flowable 为运行时，仅保留概念类比）。本设计不提前锁定许可证与运维成本，Open Questions 跟踪。
- CRM 用户/角色复用：优先 SSO 或网关统一鉴权 + CRM 为身份源之一；计划服务校验 token 或 session 委托；菜单分 Web / 移动端 维度建模（需求已声明）。
Risks / Trade-offs
plan/sx.sql缺失 → 无法对齐财务/CRM 基线模型；缓解：在 M0 末从现有环境导出补齐至plan/sx.sql，并在风险清单登记。- 跨三系统并行改造 → 集成回归成本高；缓解：契约优先（OpenAPI/事件主题表）、每里程碑最小竖切（合同发起 → 单行计划 → 模拟地磅回调）。
- 框架合同调价版本 → 与历史合同数据不一致风险；缓解：调价函附件 + 版本表 + 计划行冻结引用价格版本 ID。
- 公司名规则硬编码 → 更名或子公司扩展困难；缓解：配置化「本企业实体」主数据，规则引擎读配置。
- 工作流引擎过重 → 运维与集群成本；缓解：M1 PoC 对比后选最简满足「结算审核 + 通知」路径的方案。
Migration Plan
- M0：制品 +
pl_草案 DDL（仅新表）+ 环境基线 SQL 归档。 - M1：计划只读/草稿 API + CRM 合同发起 API 联调；无生产切换。
- M2+：分模块打开写权限、地磅双向同步、移动端只读看板→全功能。
- 回滚：以功能开关与 DB migration 向下兼容为主；计划域表可空库回滚脚本保留。
Open Questions
- 工作流引擎最终选型与部署拓扑（单机 vs 集群）。
crm/py-backend是否作为计划域宿主，或独立plan-backend/服务目录（待 M1 仓库布局决策）。- 与 CRM 的菜单同步：推送到 CRM 菜单表还是计划网关聚合菜单（影响改造面）。