用 AI 做 Odoo 19 迁移验证：物料、BOM、采购、销售四个主题的实测

我的一家客户使用金蝶管理供应链，多年了没有升级；我评估之后建议他们更换开源 ERP，并基于 AI 做深度定制。 为此，我借助 Hermes先做了一个测试——物料信息、BOM 导入、采购流程、销售功能。

效率出奇的快！我用 Hermes AI 把这件事在两周内做完了。

从我的经验看，AI 让测试变得很快、开源工具的分量被低估了、数据迁移可以做到很准、企业的二次开发确实迎来了一个成本拐点。

• 四个主题分别验收：物料主数据、BOM 导入、分包采购、销售出库
• 数据准到什么程度：741 张出库单端到端对账，库存正确扣减
• AI 省掉的是试错与对账的时间，不是业务判断
• 开源 + AI 正在改写二次开发的经济性

总结：AI 正在改写 ERP 的选型与迁移成本

先把结论放在前面：传统的数据迁移与数据测试，本质上是冗长、易错的人工劳动——读两套系统的设计规范、逐字段对表、写一次性脚本、反复核对数量。这套活儿占掉一个 ERP 项目最长的一段工期，而且最危险的不是「跑不通」，是「看起来跑通了」：单据都在、数字不对，要等到几个月后跟财务对不上账才会暴露。

借助 AI 工具，这部分工作的效率变化是量级上的。这次四个主题、1,858 个 SKU、741 张出库单的验证，连同环境部署、模型适配、数据导入与全量对账，两周做完。过去这个量级通常要一个顾问团队干一两个月。

第二个变化更根本：不同的 ERP 工具有完全不同的设计规范。同样是 BOM，金蝶是两张带版本号的表、用量存成分数；Odoo 是 BOM 类型 + 分包 + 路由 + 行序号的组合。这种「设计范式」的差异，过去只能靠资深顾问的多年经验去搭桥——人的经验不可复制，也就成了项目最贵的部分。现在 AI 能快速读懂两边各自的实现、指出差异在哪、直接给出字段映射与踩坑清单，把「专家直觉」变成一条可以被复用、被检验的流程。

落到操作层面，这三点最明显：

• 迁移：从「人工对表」变成「AI 生成映射脚本 + 自动对账」，错了会被校验拦下来
• 适配：从「翻文档猜行为」变成「读源码确认行为」，版本差异一天内做完
• 测试：从「抽样点几下」变成「四个关卡全量跑 + 失败清单」，验收有据可查

也正因为如此，开源的 ERP 很可能会迎来春天。过去选型更像一次「赌」——赌这套系统的设计范式能和你的业务磨合得上，赌不起就只好买最贵的那套。现在试错的成本降下来了，选型可以从「先买再适应」变成「先试再选」；而开源给了你改的余地，AI 让「改」变得便宜——两者叠加，才是春天真正的来源。

一、四个主题，四条验收线

迁移验证最怕的是一句含糊的结论：「系统能跑」。所以我把验证拆成四条互不替代的验收线，每条都要有客观结果：

• 物料信息：编码、名称、分类、单位、条码，1,858 个 SKU 全部落库，且单位换算正确
• BOM 导入：金蝶的层级 BOM 能否搬进 Odoo，并支撑起分包生产
• 采购流程：供应商、采购单、分包 PO、发料单能否形成闭环
• 销售功能：真实出库单能否导入、扣减库存、对上账

这四条线覆盖了 ERP 的骨架：主数据、制造、采购、销售。四条都过，才算「这套系统可以谈替换」；过不了其中任何一条，都只是演示。

二、物料信息：主数据是地基，也是坑最多的地方

我把物料放在第一主题，因为它决定后面三件事的对错。这里有一条必须纠正的常识：主数据的权威源是金蝶的物料表，不是订单系统。

三个必须处理干净的点：

• 分类体系：金蝶的业务分组是 117 个（包材、成品、半成品、赠品、原料、费用……），而物料类别表只有 7 个。用错那 7 个，成品会从 346 个变成 4 个——这是最典型的「导进去了但全错」。
• 计量单位：Odoo 19 重构了 UoM，没有 category_id / factor_inv，改用 relative_uom_id + relative_factor。新建单位时若不锚定基础单位，会变成互不相通的独立基准，界面出现「1 小时 = 1 盒 = 1 克」的假等价。
• SKU 归并：渠道版、版本号残留、渠道定制会造成重复编码。按名称规范化后，1,536 个压到 1,359 个，减 11%——这步不做，后面的单据和 BOM 都会错配。

还有两个细节：Odoo 19 的产品名称是翻译字段，数据库里存的是 JSON；条码有唯一性约束，写入前必须先查重。

这一段最能体现 AI 的价值——这些差异不会在启动时报错，只会在你写脚本时一个个冒出来。AI 的做法是：按旧版本写法写最小脚本，看它报什么错，再按报错反查源码，改到通过。整个过程一天。

三、BOM 导入：难点不是导入，是重构

金蝶的 BOM 是 T_ENG_BOM（带版本号）+ T_ENG_BOMCHILD（用量 = FNUMERATOR / FDENOMINATOR）两张表。原始结构是四层：成品 → 半成品 → 包材/原料。

但这家的实际业务是半成品全部外购、加工厂只做组装收加工费，所以正确的做法不是照搬，而是把四层压成两层：成品直接挂采购件与包材，约 40 个 BOM 收敛到 5 个。

分包（Subcontracting）的配置链是这样的：

• 成品：is_storable + 生产/采购/制造路由 + 加工费供应商价目
• 组件：采购 + 制造路由（由平台发料给加工厂）
• BOM：type = subcontract，并指定加工厂（可多家）

跑起来的流程：分包 PO（只付加工费）→ 自动生成分包生产单 → 发料单 → 填实发数量 → validate → 成品入库。

三个坑，都是实测踩出来的：

• BOM 循环误报：先给组件挂制造路由再建 BOM，会报「会在这些产品之间创建一个循环」——实际没有循环。顺序必须是先建 BOM，后挂路由。
• 数量精度归零：极小的组件用量（如 0.0001）会被四舍五入成 0，直接从 BOM 行里消失。
• 发料单零数量：分包发料单 validate 之前必须填 move_line 的实发数量，否则报「调拨问题警报：零数量」。

还有一处业务约定：BOM 行的 sequence 决定了发料单的物料顺序。我按「采购件在前、包材在后」分组编排（面体 10 / 酱包 20 / 油包 30 / 粉包 40，包材从 100 起），让 Odoo 的发料单顺序与金蝶一致——现场人员不会因为换了系统就得重新记顺序。

四、采购流程：分包采购跑通，才算真能用

采购这一环节，供应商主数据先迁：金蝶里 550 家供应商，只同步启用的 481 家（跳过草稿与禁用状态）。映射规则很简单——编码进 ref 字段作对账锚点，名称进 name，电话统一进 phone。

真正的考验是分包采购。

它把采购、制造、库存三块串在一起：一张采购单只买加工费，却要驱动生产单、发料单和成品入库。这条链路通了，说明 Odoo 的采购模块不是「能录入单据」，而是能承载真实业务。

这里也踩到一个 Odoo 19 的特征：consu（Goods）默认不跟踪库存，必须把 is_storable 设为 True，产品才会进 stock.quant。不做这一步，单据全部成功，库存永远是 0。

查单据时也有反直觉的地方：分包发料单不在采购单下面，而在生产单的 picking_ids 里（WH/RES）；采购单按 purchase_id 只能查到收货单。

五、销售功能：741 张出库单，端到端对账

销售侧我直接用真实数据压：测试741 张历史出库单，来源是电商订单中台。导入策略上有一条业务口径必须人来定——只同步稳定态（已确认 / 已发货），跳过待确认与已取消的中间态，否则库存会被反复改动。

客户归属是这里最大的数据坑：89% 的出库单没有收件人姓名。我最初判成「线下客户」，自动生成了占位客户——错的。核对店铺维度后才看清，这些其实是线上渠道单（抖音、拼多多、小红书），收件人信息在别的表里。按店铺名重建客户后，697 张单据归位。

退货要分两种处理：实物退货走 stock.return.picking，仅退款走 account.move。Odoo 社区版没有 RMA（售后单）模块，那是企业版能力——这一点在做方案时必须提前讲清。

验收结果：741 张全部导入成功，stock.quant 库存正确扣减。这就是「销售功能测试」该有的样子。

六、AI 让测试「快」在哪

把时间摊开看，这次验证的真实分布是：

「快」不是因为 AI 打字快，而是三件具体的事：它不怕重复（同一个报错试二十遍不烦）、它能读源码反查（文档没有的就去看实现）、它能一次写完对账脚本（把「看起来对了」变成「数字上对了」）。

但边界要说清楚：AI 加速的是验证，不是决策。哪些单据算稳定态、退货走哪条流程、财务怎么合规——这些仍然要人来定。

七、数据迁移为什么能「准」

「准」不是天然属性，是被三个机制逼出来的：

• 幂等键用业务主键（订单号 + 映射表），不用字符串形态猜
• 创建后必须对账：拿源数据主键清单比对目标系统编码，差一条都不算完
• 逐单容错 + 失败清单：任何一单失败不影响整批，但必须留下可追的清单

为什么我把这三条写死？因为踩过两个「静默错误」：

① 批量 create 静默丢单——脚本报告创建 1,852 条，实际入库 1,675 条，177 条凭空消失，没有异常也没有日志。不做对账，这批数据会永远错下去。

② 纯数字单号被误判——我用 isdigit() 判断「是不是内部 ID 需要跳过」，结果把真实业务单号也跳过了，同一批数据重复导入 959 单。

这两件事说明一个朴素的道理：AI 能让你跑得很快，但只有对账能让你跑得准。

八、开源工具的分量：Odoo 19 能覆盖到哪

这次验证让我对开源 ERP 的评估变了。过去常见的说法是「开源能省授权费，但功能不够」。实际下来，社区版已经覆盖了采购、库存、制造、销售、会计的主干——四道验收线全部走通就是证据。

它的缺口也很明确，必须提前讲：

• RMA / 售后单：企业版功能，社区版要用调拨 + 凭证组合替代
• 中国化财务：金税四期、专票、进项抵扣没有原生支持，本地化交给会计线下处理
• 第三方模块生态：Odoo 19 太新，Odoo20已有，第三方模块兼容性未知

但这些缺口改变了性质：它们从「不能做」变成「需要定制」。而「需要定制」这件事，成本正在被 AI 改写。

九、企业二次开发，确实迎来了春天

二次开发贵，从来不贵在写代码，贵在三件事：读懂别人的代码、试错到能跑、把业务口径翻译成数据模型。

这三件事恰好是 AI 最能压缩的：

• 读代码：从「翻文档猜行为」变成「直接看实现 + 提问」
• 试错：从「一天调一个错」变成「一次跑十个假设」
• 翻译：从「会议纪要 → 需求文档 → 开发」变成「需求文档 → 可直接审阅的模型草案」

结果是：过去只有大企业付得起的定制，中小企业开始付得起；过去「买标准品、忍着不适配」的选择，变成「买开源、改到贴合」。开源 ERP 的生态，会被这个变化重新激活。

但春天不等于没有门槛。业务口径、财务合规、上线验收这三件事 AI 替不了你——脚本可以签字，但上线不能由脚本签字。

结语

四道关都过了：物料 1858 个 SKU 落库且换算正确，BOM 从四层重构为两层并支撑分包，分包采购闭环跑通，741 张出库单端到端对账无误。

AI 让测试变快，是因为它把「试错」变成了廉价的动作；数据迁移能准，是因为把「对账」变成了硬性关卡；开源工具值得认真对待，是因为它给了你改的余地；而二次开发的春天，来自「改」的成本终于降下来了。

如果只留一句给同样在做迁移的人：先把验收拆成可判定的关卡，再让 AI 去跑。关卡不清晰，AI 只会更快地给你一堆「看起来跑通了」的假象。