实施策略
采取对账引擎优先、渐进式替代策略：
- 先验证核心能力：优先完成认证框架和对账引擎，在 2 周内验证售中/售后对账的可行性
- 逐模块上线：每阶段完成独立可交付的模块，业务可提前使用增量功能
- 零中断迁移：新旧系统并行运行，基础配置数据从原系统 MySQL 迁移，报表从 WDT 重新同步
- 最后切换：全部功能验收完成后，统一切换到新系统
战略选择：完全替代原 Java 系统，不维护两套并行对账逻辑。仅基础配置数据（店铺、分销商、用户）从 MySQL 做一次性迁移，报表数据从 WDT 同步引擎重新生成。
Phase 1：认证框架 + 对账引擎核心
周期：第 1-2 周 | 优先级：⭐ 最高
目标
搭建多租户认证体系，构建 SQL 模板驱动的对账引擎，完成售中对账和售后对账两个核心场景的完整验证。
里程碑
| # | 里程碑 | 交付物 | 验收标准 |
|---|---|---|---|
| 1.1 | 多租户认证上线 | JWT 登录/登出、用户 CRUD、bcrypt 密码管理 | 管理员可创建用户并分配角色权限 |
| 1.2 | Recon Schema 就绪 | 认证表 + 对账核心表 migration | Schema 迁移脚本可重复执行 |
| 1.3 | 对账引擎核心完成 | SQL 模板引擎 + 公式配置 CRUD | 可通过 API 配置对账公式 |
| 1.4 | 售中对账验证通过 | 支付宝账单 ↔ 销售出库单自动匹配 | 对账执行完成后，on_sale_results 表有正确匹配结果 |
| 1.5 | 售后对账验证通过 | 退款账单 ↔ 退货退款单自动匹配 | 对账执行完成后，after_sale_results 表有正确匹配结果 |
| 1.6 | 前端框架就绪 | ReconLayout + 对账执行页面 + NavMenu | 登录后可进入对账模块，查看执行结果 |
业务验证
登录 → 创建用户 → 分配权限 → 配置对账公式 → 执行售中对账 → 查看匹配结果 → 验证数据准确性
Phase 2：对账报表 + 基础设置
周期：第 3-5 周 | 优先级：高
目标
构建统一报表框架（ReportTable 通用组件 + 统一报表 Handler），完成售中/售后对账的全部报表（汇总、明细、中间表、遗留数据），上线基础设置管理模块。
里程碑
| # | 里程碑 | 交付物 | 验收标准 |
|---|---|---|---|
| 2.1 | 通用报表组件完成 | ReportTable（分页/筛选/排序/导出） | 一个组件可驱动任意报表类型的展示 |
| 2.2 | 统一报表 Handler 上线 | GET /api/recon/reports/{type} | 通过 URL 参数指定报表类型即可查询 |
| 2.3 | 售中对账报表全量上线 | 汇总/主表/明细/中间表/遗留/备份 | 10+ 张售中报表可正常查询和导出 |
| 2.4 | 售后对账报表全量上线 | 汇总/主表/明细/中间表/遗留/备份 | 10+ 张售后报表可正常查询和导出 |
| 2.5 | 邮费对账模块上线 | 邮费汇总/对比/差异分析 | 邮费差异数据可追溯 |
| 2.6 | 基础设置管理上线 | 店铺/分销商/TP/结算配置/自定义属性 | 店铺和结算配置从 MySQL 迁移并验证 |
| 2.7 | 用户权限管理 UI 上线 | 用户管理 + 7 大权限分配 | 管理员可通过 UI 完整管理用户和权限 |
业务验证
创建店铺 → 配置结算规则 → 选择期间 → 查看售中对账汇总 → 下钻到明细 → 导出 Excel → 查看未关联数据
Phase 3：发货/退款/退货/预入库报表
周期：第 6-8 周 | 优先级：高
目标
完成全部业务操作类报表（发货、退款、退货、预入库），上线对账状态管理和数据中心模块。
里程碑
| # | 里程碑 | 交付物 | 验收标准 |
|---|---|---|---|
| 3.1 | 发货报表全量上线 | 发货汇总/主表/明细/多物流 | 10+ 张发货报表可正常查询 |
| 3.2 | 退款报表全量上线 | 退款汇总/主表/明细 | 8+ 张退款报表可正常查询 |
| 3.3 | 退货入库报表全量上线 | 退货入库汇总/明细 | 6+ 张退货报表可正常查询 |
| 3.4 | 预入库报表全量上线 | 已关联/未关联 汇总+明细 | 4+ 张预入库报表可正常查询 |
| 3.5 | 各类遗留表 + 备份表 | 按类型的遗留数据管理和备份 | 遗留数据可正常标记和处理 |
| 3.6 | 对账状态管理上线 | cfg_sap_normal 状态配置 | 运营人员可自定义对账状态 |
| 3.7 | 数据中心：支付宝透视上线 | 账务类型字典/支付宝汇总/明细 | 支付宝数据可在数据中心统一查询 |
业务验证
选择期间 → 查看发货汇总 → 筛选特定店铺 → 导出明细 → 查看退款遗留数据 → 查看支付宝收支汇总
Phase 4：物流资费 + 结算 + 发票
周期：第 9-11 周 | 优先级：中
目标
完成物流资费对账、结算管理和发票管理三大模块，实现从对账到结算的完整业务闭环。
里程碑
| # | 里程碑 | 交付物 | 验收标准 |
|---|---|---|---|
| 4.1 | 物流资费对账模块上线 | 汇总/中间表/状态管理/报价管理 | 物流费用对比结果准确可追溯 |
| 4.2 | 物流资费账单管理上线 | 账单导入/查看/异常处理 | 物流公司账单可导入并对账 |
| 4.3 | 金额调整审批流上线 | 提交→审批→通过/驳回→重新计算 | 调整单完整流转，审批记录可查 |
| 4.4 | 结算生成与确认上线 | 选择周期→生成预结算→确认→锁定 | 结算单可生成、调整、确认和导出 |
| 4.5 | 发票管理上线 | 发票汇总/明细/红冲统计 | 发票数据可正常查询和统计 |
| 4.6 | 天猫损益表上线 | 天猫旗舰店收入/成本/费用/利润汇总 | 损益数据可与平台账单核对 |
| 4.7 | 平台账单 + 销售汇总上线 | 平台账单原始数据 + 跨店铺销售 GMV | 平台账单数据在大盘视图正确呈现 |
业务验证
配置物流报价 → 执行物流对账 → 查看差异 → 生成结算 → 提交金额调整 → 审批通过 → 确认结算 → 导出结算报告
Phase 5：定制表 + 数据迁移 + 收尾
周期：第 12-14 周 | 优先级：中低
目标
完成剩余 30+ 定制报表，将原系统基础配置数据从 Java MySQL 迁移至 PostgreSQL，进行性能优化和压力测试，正式切换上线。
里程碑
| # | 里程碑 | 交付物 | 验收标准 |
|---|---|---|---|
| 5.1 | 定制报表全量上线 | 30+ 配置驱动的定制报表 | 所有报表通过统一网关正常查询 |
| 5.2 | 对账公式编辑器 UI | 可视化的公式配置界面 | 运营人员可自行调整对账规则 |
| 5.3 | Dashboard KPI 增强 | KPI 卡片/趋势图表/待办列表 | 首页展示核心对账指标 |
| 5.4 | 历史数据迁移完成 | 店铺/分销商/用户/结算配置迁移 | 迁移数据与原系统数据一致 |
| 5.5 | 性能优化 | 索引调优、查询缓存、批量查询 | 大数据量报表查询 < 3 秒 |
| 5.6 | 端到端测试 + 压力测试 | 完整业务流程测试 + 并发压力测试 | 所有测试用例通过，并发支持 50+ 用户 |
| 5.7 | 正式切换上线 | 新系统替代旧系统 | 原慧策系统下线，全部业务切换到新系统 |
业务验证
WDT 同步 → 对账执行 → 报表查看 → 结算确认 → 备份 → 全流程端到端验证通过
整体时间线
| 阶段 | 周期 | 核心交付 | 业务可感知成果 |
|---|---|---|---|
| Phase 1 | 第 1-2 周 | 认证 + 对账引擎 | 登录系统和售中/售后对账可用 |
| Phase 2 | 第 3-5 周 | 报表框架 + 基础设置 | 报表查询和店铺管理可用 |
| Phase 3 | 第 6-8 周 | 全量业务报表 | 发货/退款/退货全量报表可用 |
| Phase 4 | 第 9-11 周 | 物流 + 结算 + 发票 | 完整对账→结算业务闭环 |
| Phase 5 | 第 12-14 周 | 定制 + 迁移 + 收尾 | 正式切换上线 |
风险缓冲：每阶段预留 1 周的缓冲时间应对不确定性。如果某个 Phase 延期，优先保障核心对账功能和报表中心上线，非关键模块可在上线后进行补丁式迭代。