Odoo 迁移验收：逐条核对业务记录与余额

返回

Kevin Riedl

13 分钟 阅读 · 2026年11月5日
最近审核 2026年11月5日

下一篇

来源端有五张订单，目标端也有五张，各公司的合计金额一致。但在我们的本地测试数据中，两张订单的金额仍然错误。迁移可以通过汇总检查，却给实际使用这些记录的人留下错误结果。

验收 Odoo 迁移，应先将约定的来源快照与预期目标记录逐项核对，再运行依赖这些记录的业务流程。除了金额与状态，还要检查身份标识和关联关系。每项差异都应有负责人及复测证据，并由相应业务负责人批准，才能认定迁移完成。

资料核查日期：2026 年 11 月 5 日。产品事实依据 Odoo 官方文档。我们使用 Python 标准库运行了九个合成 JSON 核对案例，没有迁移 Odoo 数据库、检查客户记录或验证会计报表。下载的 CSV 是验收建议模板，检查状态均为 NOT_RUN。

成功的 Odoo 迁移需要证明什么？

成功迁移必须交付约定范围内的业务记录和可用流程。数据库能够启动、导入显示成功，只能证明其中一部分。应明确哪些人员必须完成哪些操作、操作后应产生什么记录，以及哪些历史信息需要继续可查。

先说明迁移路径。Odoo 版本升级与导入其他 ERP 的历史数据是不同任务。后者可能需要新映射和明确排除的历史范围；升级则可能改变应用行为或自定义模块兼容性。验收记录应写出实际路径，不能把所有“迁移”都视为同一种程序。

Odoo 的升级指南建议在生产切换前，使用升级后的数据库测试业务流程和外部集成。需要把这项要求转化为自身业务的证据：部分履约订单与刚录入的联系人，所需检查并不相同。

技术执行与业务批准应分开。工程人员可以证明比较器在既定规则下没有发现差异；财务负责人仍需判断选定的余额控制和已记录调整是否支持会计结果。仓库负责人则需要判断剩余数量是否真实代表团队还能继续完成的工作。

比较数据前，需要固定哪些基准？

计算差异前，先固定基准。来源快照和比较范围都要明确。记录纳入的公司、单据状态及截止时点，同时保存目标端获批的转换规则。缺少这些边界，差异可能只是统计对象不同；看似一致也可能是筛选条件排除了本应检查的记录。

保留原始导出文件或其他获批的来源证据，以及对应提取参数，并记录目标构建标识和映射修订号。若快照之后来源端继续产生交易，应提前约定最后一批增量如何进入切换、如何核对。昨天获准的导出不会自动覆盖今天的新收货记录。

即使目标数据库 ID 变化，也要保留稳定业务引用。Odoo 文档说明了通过外部 ID 重建导入关系的方法。核对应能追踪每条来源记录对应哪个目标，包括获准的拆分或合并。

检查逻辑应独立于被检查的转换。如果期望值计算复用了导入程序里错误的单位换算，两边可能错得一致。应从获批业务规则或原始单据直接推导部分基准案例，再与导入结果比较。

为什么记录数和总额都一致，仍然可能有错误？

汇总一致仍不够。汇总控制丢弃了单条记录的身份信息。缺失记录可能被另一条意外记录替代，方向相反的金额错误也可能互相抵消。我们实际运行的模型保留五条记录及全部公司、币种分组总额，但两张订单金额不同。保留汇总检查的同时，还需要核对组成这些合计的记录。

测试数据包含公司 A、B 的订单，EUR 和 USD 分组统计。A 的两张欧元订单应为 100.00 欧元和 200.00 欧元，错误目标却保存了 110.00 欧元和 190.00 欧元：

来源公司 A / EUR：100.00 + 200.00 = 300.00
目标公司 A / EUR：110.00 + 190.00 = 300.00
单条记录差异：      +10.00 和 -10.00

汇总差异为零，并不代表两张单据可以通过验收。这些是合成订单金额控制，并非试算平衡表。我们按示例中的零容差规则进行精确十进制比较，没有运行税额、汇率或存货估值计算。

九项预期观察均与本地运行一致。下载可运行的核对模型和已记录的模型结果，保存 Python 文件后执行：

python3 reconcile-model.py

模型只比较 JSON 记录中指定的字段，并未操作 Odoo 销售明细、日记账分录或附件存储。附件值是用于代表示例内容检查的身份标签，不是真实文件验证结果。未改变的对照案例，只证明比较器接受了自身明确规定的基准。

迁移核对应覆盖哪些业务记录？

应覆盖迁移范围内承载未完成业务承诺的记录。先检查身份与关联，再信任汇总值；随后按公司和币种核对金额、剩余数量及状态。还要证明文档可以访问，依赖这些记录的人员能够继续约定的工作。

财务控制必须采用约定的会计口径。不能把不同币种相加，不能用发票数量代替余额，也不能认为导入草稿就已经完成记账。应将技术比较与会计审查分开，并保存财务负责人接受的报表和调整。

部分订单要看剩余义务。按模型的简单规则，订购十件、交付六件，还剩四件待完成。如果迁移后的表头显示已经交付十件，即使订单金额不变，这四件工作也可能从操作队列中消失。

权限检查可使用单独的 Odoo 20 多公司访问测试矩阵。生成目标数据的映射则参考 AI 辅助 Odoo 映射的独立验证。验收记录应链接这些专项证据，不要把每项专业检查压缩成一个百分比。

迁移验收 CSV 应记录哪些内容？

CSV 应把每个预期结果与实际结果、证据关联起来，并单独记录负责审查和批准的人。纳入基准范围和目标构建，才能让后来接手的人复现比较。未解决差异必须保留缺陷引用及复测状态；实际值为空绝不能表示差异为零。

下载建议的迁移验收模板。业务基准初始为 TO_DEFINE，实际值留空，执行状态为 NOT_RUN，批准状态为 PENDING。其中没有默认财务批准，也没有真实迁移结果。

在模型的公司 A/EUR 金额控制中，预期值和实际值都是 300.00。该行可以报告汇总一致，但两张单据的明细比较仍然失败，相关缺陷必须保留。不能用汇总差异零覆盖它们各自的偏差。

若转换是有意安排的，应记录预期影响及批准依据。“已接受差异”必须指向获批规则或例外，不能成为关闭无人能够解释的问题的办法。

如何测试迁移后的流程，而不只检查导出文件？

从已知的迁移记录开始，使用预期角色执行操作，再检查产生的业务记录。环境应受到保护，外部服务应可控，并包含操作人员需要处理的例外。导出比较证明存储值，演练则证明团队是否能在新配置下继续工作。

以部分履约订单为例，先找到已迁移记录及其支持文档，确认获授权的操作人员看到正确的未完成数量。在受控环境中执行约定的下一步，再将新增记录与剩余义务同预期比较。还应保留另一角色被拒绝执行该动作的证据。

Odoo 的数据库中和文档列出了测试数据库中会停用的自动化和外部功能。自定义集成进程需要另行检查。即使数据库被标记为测试用途，演练目标端仍必须受控。

自定义数据库升级流程将空库模块检查、升级后数据测试和演练分开。应保留各自证据。模块能在空库安装，不代表它已经证明能够正确处理历史部分订单。

如果传输依赖文件而非 API，旧 ERP 集成指南讨论了交付边界。演练应包含实际导入及恢复路径，并通过引用把来源文件与目标业务记录连接起来。

临时变更和未解决差异应怎样影响上线？

上线批准必须绑定已测试的构建和数据范围。最后阶段修改映射或新增来源增量，可能使部分证据失效。应找出受影响控制，并在上线前重跑。每项未解决差异都需要明确决策人；是否阻断切换，应由业务影响决定，而非工单存在多久或显示什么状态。

在演练之前定义最终增量流程：基准何时截止、谁控制之后的来源写入、怎样识别截止后的变化。最终核对应明确解释这些新增数据，不能把所有新增目标记录都当作无法说明的异常。

对每个遗留缺陷，记录受影响流程和可能的业务后果。获授权的负责人可以按约定规则接受例外，但决定及附带条件必须保留。笼统地表示“看起来没问题”，无法让后续操作人员知道某个缺失附件或错误待交数量是否曾被有意识地接受。

切换后，还应对生产结果重跑约定控制，并观察下一个相关业务步骤。定时导入或后续履约可能暴露即时登录检查发现不了的问题。软件上线前 QA 清单提供了更完整的发布证据框架。

签署验收前，我们会要求什么？

我们会要求一条可追溯的证据链：从约定基准，经明细比较和流程演练，连接到相应业务批准。先从关键流程开始，公开每项未解决差异，再把方法扩展到批准范围。签署后的验收记录应让接手人员看清：证明了什么、对应哪个构建、还有哪些附带条件。

Wavect 的软件质量保障服务承接独立验收工作。沟通时可带上迁移范围及一个有争议的结果。首项有用的审查，是判断现有证据能否区分正确业务结果与仅仅没有报错的迁移过程。