Files
baiyue-firstleg/lastleg-service/docs/procurement-table-cleanup.md
T
2026-10-27 18:27:56 +08:00

5.3 KiB
Raw Blame History

海外采购旧流程表退役

2026-10-27 已完成代码分离。只处理海外采购专属模型和业务表,不删除或更新共用财务、资金、File、仓储库存或其他海外业务表。尚未执行目标数据库,也未部署运行服务。

采购专属表从 27 张收敛为 6 张;21 张旧表已从生产 Java 和两份初始化基线解除引用。原只读核查发现的阻塞现已在本次修改中处理,不能在旧版服务上直接执行删表脚本。

保留六表

表 用途
ll_overseas_procurement_order 采购主单、方向、审核仓库与当前状态
ll_overseas_procurement_status_history 创建、审核及备注修改流水
ll_overseas_procurement_file 收货、签收附件归属
ll_procurement_workflow_receipt 分批实收及照片
ll_procurement_workflow_outbound 分批出库、物流和签收
ll_procurement_workflow_command 批次操作幂等及审计

精确退役清单(21 张)

  • ll_overseas_procurement_fee
  • ll_procurement_wallet_attempt
  • ll_procurement_flow
  • ll_procurement_command
  • ll_procurement_budget_authorization
  • ll_procurement_receipt
  • ll_procurement_disposition
  • ll_procurement_manifest
  • ll_procurement_carton
  • ll_procurement_carton_source
  • ll_procurement_shipment
  • ll_procurement_shipment_item
  • ll_procurement_label_set
  • ll_procurement_label_item
  • ll_procurement_estimate_review
  • ll_procurement_repack
  • ll_procurement_fee_correction
  • ll_procurement_fee_correction_item
  • ll_procurement_control_note
  • ll_procurement_closure
  • ll_procurement_closure_item

代码分离

  • ProcurementQueryService 只读取主单、附件、审核流水及共用人工海外费用,不再执行旧预算、装箱、面单、运输、异常和采购费用查询。客户投影仍过滤客户、主单、业务类型和应收方向,内部说明不公开。
  • 创建、审核、编辑响应不再访问旧采购费用表;仓库直接取审核主单。原响应中的旧区块保留空容器,避免当前前端适配器访问缺失数组,背后没有旧业务表依赖。
  • 旧购买、预算核验、物理装箱、运输面单、费用核定及异常处置 Controller/Service/DTO 已删除。新批次接口和独立上传、客户确认、文件权限保持不变。
  • 旧采购专属 WalletResultHandler、费用 Mapper/Entity、方向事实 Mapper 和专属退款编号 Repository 已移除;共用资金消费者、Outbox/Inbox 和共用海外费用审核链不修改。
  • 共用费用业务白名单仅移除已退役 PROCUREMENT_FEE 子业务实体查表项,OVERSEAS_PROCUREMENT 主单继续沿原共用应收、冻结、审核和实扣链。
  • 旧履约 OpenAPI 仅保留当前文件接口与详情投影;七状态流程独立契约继续保留。旧实现测试随旧功能退役;现行分批数量、库存、客户隔离、幂等、费用门禁与权限测试保留,并新增仅六表可运行的真实 Mapper 详情/审核测试和退役范围合同。

脚本与执行顺序

  1. 只读核查 SQL:查看 27 张表存在状态及行数估算,支持重复执行,不需要业务写权限。
  2. 完成快照/备份,停止旧服务写入并部署本次 Lastleg 分离版本;在维护窗口验证现行主流程。必须先部署、再删除旧表。不能把脚本存在视为已发布。
  3. 审阅 精确删表 SQL。在指定 MySQL 8.0+ 实例的同一连接设置脚本声明的发布确认变量,然后整份执行,禁止遇错继续。脚本只对 baiyue_lastleg 的 21 张清单表执行一条 DROP TABLE IF EXISTS;DDL 隐式提交,不承诺事务回滚。
  4. 脚本先验证六张当前表存在、无旧状态采购、旧资金表无任何记录,并只读检查共用资金 Outbox/Inbox 中是否仍有 PROCUREMENT_FEE 证据。有旧资金记录就停止,不自动删除、迁移或伪造结清,也不修改共用表。非空旧物理/运输/异常表会随 DROP 永久删除,须在执行前核对备份及范围。
  5. 前置检查在首个业务 DROP 前完成;不关闭外键校验,有外部引用则失败。完整成功后可重复执行,已删除表按 IF EXISTS 跳过。失败时停止、保留原错误并核查现状;最终剩余旧表数应为 0,同时确认客户端退出码为 0。

只读脚本不证明数据为空,删除脚本也不能自动识别运行中的二进制版本。V14—V21 旧采购迁移仅用于历史追溯,不得在本次退役后重放;当前 Lastleg 基线与海外空库基线已删除这 21 张定义。不得用本脚本删除六张现用表或任何共用费用、余额、文件对象及库存数据。

本次验证

  • 后端现行采购及退役契约 55 项、管理端相关 67 项、Gateway 路由 5 项和脚本文档契约 4 项通过;Mapper 扫描通过。
  • 两份初始化 SQL 与修改前逐表比较:均只移除这 21 张表,其余表定义完全一致;生产 Java 中没有这 21 张旧表名引用。
  • Lastleg 架构检查 15 项中 14 项通过,无新增跨业务依赖;车队检查仍因 dispatch 访问 fleet 持久化 Mapper 失败,该问题不在本次采购修改范围。
  • 未执行目标 MySQL、未部署、未进行线上页面验收;SQL 仅完成静态范围及防护契约检查。