CPT · ODOO TRANSFORMATION REVIEW

先统一产品与报价，再让成交推动交付

本页用于评审改造方向，不代表系统已经改造。计划以四份会议 PDF 原文和 2026-08-13 运行中的本地 Odoo 为证据，区分已有、需配置、需小模块和必须先确认的事项。

V0.1 待 Jack 审核 · 当前禁止实施

核心定位

业务协同中枢

Odoo 管产品主档、套餐、报价、合同索引与交付；U8 暂时继续管采购、发货、付款、收款和财务主账；CRM 主责待确认。

实施原则

  • 不改 Odoo 官方核心源码。
  • 标准配置优先，必要时只扩展可卸载独立模块。
  • 接口不可用时先用可核对的文件交换。
  • 真实、历史、报价参考和沙盒数据强制隔离。

建议顺序

P0基线与数据隔离
2—3 日
P1产品档案与报价
7—10 日
P2合同索引与 U8 并行
5—7 日
P3交付与驾驶舱
7—10 日
P4生产与外围集成
前序验收后估时

当前能力与主要缺口

领域当前已有下一步判断
产品中心64 标准产品、两级分类、生命周期、图片补自研/外采、通用名、供应商商品、贴标合规扩展
智能报价7 类客户、套餐、案例、复制、整包配单补成本快照、服务端权限、两种 Excel扩展
历史资产26 单/175 行历史成交索引、28 个案例补签章合同、标准产品替代关系和证据有效期保留
交付15 天模板和沙盒总控补真实项目主档、健康预测、重点项目驾驶舱扩展
U8/CRM无已验证接口先定主系统和唯一 ID，再做受控交换先确认
验收基线多组旧校验脚本4 项校验与当前数据范围不一致，必须先修P0 门禁

已认可的会议方向

  • 先解决产品名称、型号和报价标准化。
  • 按客户类型推荐套餐与历史场景。
  • 成本仅授权角色可见，客户版不含成本。
  • 实施、维修等服务也要产品化。
  • 交付需要项目主档、负责人、阶段和驾驶舱。

明确拒绝的反模式

  • 删除内部稳定编码，只剩可随意填写的型号。
  • 用单一字段覆盖公司、供应商和客户三种产品身份。
  • 用当前成本覆盖历史报价成本。
  • 把沙盒销售订单当真实成交。
  • 接口没验证就承诺实时双向同步。

请 Jack 优先拍板

  • 内部保留唯一产品编码，客户版默认只展示名称和型号。
  • 外采产品同时保存康比特通用身份和供应商原厂身份。
  • 410/450/460 的对外型号、贴标、合格证与最终拍板人。
  • 采购成本是含税还是未税，运费和实施费是否计入。
  • 普通销售只看毛利达标状态，还是可看精确毛利。
  • 自主实施/维修按零成本还是内部人天成本。
  • 签章合同是否为正式交付立项的必要门禁。
  • 现有 CRM 名称、主责范围、唯一 ID 和接口负责人。
  • 首期交付只管里程碑，还是立即要求每日工时。
  • 指定 2 个真实在途项目作为最终验收样本。

下一步

停止规则：U8/CRM 接口、410/450/460 合规、成本口径、合同门禁或真实/沙盒数据边界没有明确结论时，不得通过猜测补成已批准需求。