--- title: "Odoo 迁移验收：业务记录与余额核对" canonical: https://wavect.io/zh/blog/odoo-migration-acceptance-reconciliation/ language: zh description: "用记录与余额核对验收 Odoo 迁移，识别总额一致掩盖的明细错误。九个已运行的合成案例附验收模板；真实环境检查仍待执行，技术通过不能替代业务签字。" image: "https://wavect.io/img/blog/headers/header_odoo-migration-acceptance-reconciliation.png" author: ["Kevin Riedl"] published: "2026-11-05" updated: "2026-11-05" reviewed: "2026-11-05" --- # Odoo 迁移验收：逐条核对业务记录与余额 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-n8n-idempotency-recovery/) 要点速览 先固定来源快照和目标范围，逐条核对身份、数值与关联，再演练迁移后的业务流程。九个本地模型案例包含相互抵消、总额仍一致的金额错误。下载的 CSV 初始为 NOT_RUN，批准待定；技术比较通过不能替代财务对余额的审查与批准。 来源端有五张订单，目标端也有五张，各公司的合计金额一致。但在我们的本地测试数据中，两张订单的金额仍然错误。迁移可以通过汇总检查，却给实际使用这些记录的人留下错误结果。 **验收 Odoo 迁移，应先将约定的来源快照与预期目标记录逐项核对，再运行依赖这些记录的业务流程。**除了金额与状态，还要检查身份标识和关联关系。每项差异都应有负责人及复测证据，并由相应业务负责人批准，才能认定迁移完成。 **资料核查日期：2026 年 11 月 5 日。**产品事实依据 Odoo 官方文档。我们使用 Python 标准库运行了九个合成 JSON 核对案例，没有迁移 Odoo 数据库、检查客户记录或验证会计报表。下载的 CSV 是验收建议模板，检查状态均为 `NOT_RUN`。 ## 成功的 Odoo 迁移需要证明什么？ 成功迁移必须交付约定范围内的业务记录和可用流程。数据库能够启动、导入显示成功，只能证明其中一部分。应明确哪些人员必须完成哪些操作、操作后应产生什么记录，以及哪些历史信息需要继续可查。 先说明迁移路径。Odoo 版本升级与导入其他 ERP 的历史数据是不同任务。后者可能需要新映射和明确排除的历史范围；升级则可能改变应用行为或自定义模块兼容性。验收记录应写出实际路径，不能把所有“迁移”都视为同一种程序。 Odoo 的 [升级指南](https://github.com/odoo/documentation/blob/20.0/content/administration/upgrade.rst) 建议在生产切换前，使用升级后的数据库测试业务流程和外部集成。需要把这项要求转化为自身业务的证据：部分履约订单与刚录入的联系人，所需检查并不相同。 技术执行与业务批准应分开。工程人员可以证明比较器在既定规则下没有发现差异；财务负责人仍需判断选定的余额控制和已记录调整是否支持会计结果。仓库负责人则需要判断剩余数量是否真实代表团队还能继续完成的工作。 ## 比较数据前，需要固定哪些基准？ 计算差异前，先固定基准。来源快照和比较范围都要明确。记录纳入的公司、单据状态及截止时点，同时保存目标端获批的转换规则。缺少这些边界，差异可能只是统计对象不同；看似一致也可能是筛选条件排除了本应检查的记录。 保留原始导出文件或其他获批的来源证据，以及对应提取参数，并记录目标构建标识和映射修订号。若快照之后来源端继续产生交易，应提前约定最后一批增量如何进入切换、如何核对。昨天获准的导出不会自动覆盖今天的新收货记录。 | 边界 | 测试前记录 | 要避免的错误结论 | | --- | --- | --- | | 数据范围 | 公司、对象类型、状态筛选和明确排除项。 | 归档记录或草稿只在一侧被排除。 | | 时间 | 快照时间、报告期间和时区解释。 | 后续交易被当作迁移错误，或掩盖更早缺失的记录。 | | 金额与数量 | 币种、金额口径、计量单位和获批舍入规则。 | 不同单位或币种被相加，得到误导性合计。 | | 身份 | 稳定来源键及其与目标记录的对应关系。 | 名称相似的两个客户被当作同一账户。 | | 预期变化 | 获批转换及批准人。 | 测试失败后，无法解释的差异被改称为预期变化。 | 即使目标数据库 ID 变化，也要保留稳定业务引用。Odoo 文档说明了 [通过外部 ID 重建导入关系](https://github.com/odoo/documentation/blob/20.0/content/applications/essentials/export_import_data.rst) 的方法。核对应能追踪每条来源记录对应哪个目标，包括获准的拆分或合并。 检查逻辑应独立于被检查的转换。如果期望值计算复用了导入程序里错误的单位换算，两边可能错得一致。应从获批业务规则或原始单据直接推导部分基准案例，再与导入结果比较。 ## 为什么记录数和总额都一致，仍然可能有错误？ 汇总一致仍不够。汇总控制丢弃了单条记录的身份信息。缺失记录可能被另一条意外记录替代，方向相反的金额错误也可能互相抵消。我们实际运行的模型保留五条记录及全部公司、币种分组总额，但两张订单金额不同。保留汇总检查的同时，还需要核对组成这些合计的记录。 测试数据包含公司 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 ``` 汇总差异为零，并不代表两张单据可以通过验收。这些是合成订单金额控制，并非试算平衡表。我们按示例中的零容差规则进行精确十进制比较，没有运行税额、汇率或存货估值计算。 | 测试数据变化 | 汇总控制 | 实际发现的明细问题 | | --- | --- | --- | | 基准保持不变 | 五行；公司与币种分组总额一致。 | 按模型比较规则未发现差异。 | | 相互抵消的金额错误 | 记录数与总额仍一致。 | 两项金额差异：+10.00 欧元和 -10.00 欧元。 | | 已交付数量从 6 变为 10 | 记录数与金额汇总仍一致。 | 一项数量字段差异。 | | 客户引用及该客户所属公司发生变化 | 记录数与金额汇总仍一致。 | 两项关联字段差异。 | | 附件身份发生变化 | 记录数与金额汇总仍一致。 | 一项内容身份差异。 | | 草稿变成模型自身的 sale 状态 | 记录数与金额汇总仍一致。 | 一项状态差异。 | | 某个来源订单引用被替换 | 记录数与金额汇总仍一致。 | 一个来源身份缺失，另有一个意外身份。 | | 两条记录使用同一复合键 | 记录数与金额汇总仍一致。 | 重复键、缺失身份及六项字段差异。 | | 目标快照使用不同截止时点 | 接受汇总结果前先拒绝比较。 | 比较范围不一致。 | 九项预期观察均与本地运行一致。下载 [可运行的核对模型](/downloads/odoo-migration-acceptance-reconciliation/reconcile-model.py) 和 [已记录的模型结果](/downloads/odoo-migration-acceptance-reconciliation/model-results.json) ，保存 Python 文件后执行： ``` python3 reconcile-model.py ``` 模型只比较 JSON 记录中指定的字段，并未操作 Odoo 销售明细、日记账分录或附件存储。附件值是用于代表示例内容检查的身份标签，不是真实文件验证结果。未改变的对照案例，只证明比较器接受了自身明确规定的基准。 ## 迁移核对应覆盖哪些业务记录？ 应覆盖迁移范围内承载未完成业务承诺的记录。先检查身份与关联，再信任汇总值；随后按公司和币种核对金额、剩余数量及状态。还要证明文档可以访问，依赖这些记录的人员能够继续约定的工作。 | 领域 | 需要比较的证据 | 由谁批准业务结果？ | | --- | --- | --- | | 客户与产品 | 稳定身份、必需属性和预期关联。 | 客户或产品数据负责人。 | | 未结订单 | 表头和明细引用、金额、当前状态及剩余工作。 | 销售或采购流程负责人。 | | 部分履约 | 按获批单位表示的订购、完成和未完成数量。 | 仓库或服务交付负责人。 | | 应收与应付 | 财务定义的账户、公司、币种和期间余额，以及单据级例外。 | 获授权的财务负责人。 | | 库存 | 数量控制与估值证据分开，并纳入相关库位或批次。 | 库存负责人；估值另需财务批准。 | | 发票与贷项单据 | 单据身份、状态、金额，以及与结算或更正之间获批的关联。 | 获授权的财务负责人。 | | 附件 | 正确文档关联到正确记录，且预期角色能够取回。 | 依赖该文档的流程负责人。 | | 访问与集成 | 获准和被拒绝的操作，以及受控传输后的最终记录。 | 应用负责人及集成负责人。 | 财务控制必须采用约定的会计口径。不能把不同币种相加，不能用发票数量代替余额，也不能认为导入草稿就已经完成记账。应将技术比较与会计审查分开，并保存财务负责人接受的报表和调整。 部分订单要看剩余义务。按模型的简单规则，订购十件、交付六件，还剩四件待完成。如果迁移后的表头显示已经交付十件，即使订单金额不变，这四件工作也可能从操作队列中消失。 权限检查可使用单独的 [Odoo 20 多公司访问测试矩阵](/zh/blog/odoo-20-company-access-migration-tests/) 。生成目标数据的映射则参考 [AI 辅助 Odoo 映射的独立验证](/zh/blog/odoo-ai-data-mapping-validation/) 。验收记录应链接这些专项证据，不要把每项专业检查压缩成一个百分比。 ## 迁移验收 CSV 应记录哪些内容？ CSV 应把每个预期结果与实际结果、证据关联起来，并单独记录负责审查和批准的人。纳入基准范围和目标构建，才能让后来接手的人复现比较。未解决差异必须保留缺陷引用及复测状态；实际值为空绝不能表示差异为零。 下载 [建议的迁移验收模板](/downloads/odoo-migration-acceptance-reconciliation/acceptance-template.csv) 。业务基准初始为 `TO_DEFINE`，实际值留空，执行状态为 `NOT_RUN`，批准状态为 `PENDING`。其中没有默认财务批准，也没有真实迁移结果。 | 字段组 | 填写内容 | 规则 | | --- | --- | --- | | 基准 | 快照、筛选条件、公司与币种范围、目标构建。 | 比较对象不同，必须先记录相应调整。 | | 控制 | 比较方法、预期值、单位和容差。 | 看到结果之前先批准容差。 | | 执行 | 实际值、差异、证据引用和执行状态。 | NOT_RUN 必须与比较通过区分。 | | 解决 | 缺陷、复测证据和技术负责人。 | 修复导入后，应重新比较受影响记录。 | | 批准 | 业务负责人、批准决定和日期。 | 技术通过不能自动填写批准人。 | 在模型的公司 A/EUR 金额控制中，预期值和实际值都是 300.00。该行可以报告汇总一致，但两张单据的明细比较仍然失败，相关缺陷必须保留。不能用汇总差异零覆盖它们各自的偏差。 若转换是有意安排的，应记录预期影响及批准依据。“已接受差异”必须指向获批规则或例外，不能成为关闭无人能够解释的问题的办法。 ## 如何测试迁移后的流程，而不只检查导出文件？ 从已知的迁移记录开始，使用预期角色执行操作，再检查产生的业务记录。环境应受到保护，外部服务应可控，并包含操作人员需要处理的例外。导出比较证明存储值，演练则证明团队是否能在新配置下继续工作。 以部分履约订单为例，先找到已迁移记录及其支持文档，确认获授权的操作人员看到正确的未完成数量。在受控环境中执行约定的下一步，再将新增记录与剩余义务同预期比较。还应保留另一角色被拒绝执行该动作的证据。 Odoo 的 [数据库中和文档](https://github.com/odoo/documentation/blob/20.0/content/administration/neutralized_database.rst) 列出了测试数据库中会停用的自动化和外部功能。自定义集成进程需要另行检查。即使数据库被标记为测试用途，演练目标端仍必须受控。 [自定义数据库升级流程](https://github.com/odoo/documentation/blob/20.0/content/developer/howtos/upgrade_custom_db.rst) 将空库模块检查、升级后数据测试和演练分开。应保留各自证据。模块能在空库安装，不代表它已经证明能够正确处理历史部分订单。 如果传输依赖文件而非 API， [旧 ERP 集成指南](/zh/blog/legacy-erp-integration-without-api/) 讨论了交付边界。演练应包含实际导入及恢复路径，并通过引用把来源文件与目标业务记录连接起来。 ## 临时变更和未解决差异应怎样影响上线？ 上线批准必须绑定已测试的构建和数据范围。最后阶段修改映射或新增来源增量，可能使部分证据失效。应找出受影响控制，并在上线前重跑。每项未解决差异都需要明确决策人；是否阻断切换，应由业务影响决定，而非工单存在多久或显示什么状态。 在演练之前定义最终增量流程：基准何时截止、谁控制之后的来源写入、怎样识别截止后的变化。最终核对应明确解释这些新增数据，不能把所有新增目标记录都当作无法说明的异常。 对每个遗留缺陷，记录受影响流程和可能的业务后果。获授权的负责人可以按约定规则接受例外，但决定及附带条件必须保留。笼统地表示“看起来没问题”，无法让后续操作人员知道某个缺失附件或错误待交数量是否曾被有意识地接受。 切换后，还应对生产结果重跑约定控制，并观察下一个相关业务步骤。定时导入或后续履约可能暴露即时登录检查发现不了的问题。 [软件上线前 QA 清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 提供了更完整的发布证据框架。 ## 签署验收前，我们会要求什么？ 我们会要求一条可追溯的证据链：从约定基准，经明细比较和流程演练，连接到相应业务批准。先从关键流程开始，公开每项未解决差异，再把方法扩展到批准范围。签署后的验收记录应让接手人员看清：证明了什么、对应哪个构建、还有哪些附带条件。 Wavect 的 [软件质量保障服务](/zh/services/software-quality-assurance/) 承接独立验收工作。沟通时可带上迁移范围及一个有争议的结果。首项有用的审查，是判断现有证据能否区分正确业务结果与仅仅没有报错的迁移过程。 ## Odoo 迁移验收常见问题 ### Odoo 版本升级和导入其他 ERP 历史数据，验收方式完全相同吗？ 两者都要证明约定的目标业务结果，但转换规则不同。外部导入可能拆分记录、映射编号，或将获准的历史留在档案中；Odoo 升级可能改变视图和自定义模块行为。先写明实际路径，再定义预期差异，不能假定所有来源字段都必须原样保留。验收应依据获批目标，而非只追求表面一致。 ### 记录数量能否用来批准期初余额？ 不能。数量只说明有多少记录满足筛选条件，无法证明金额、会计口径或关联关系正确。财务负责人需要定义相关账户、币种、期间和单据状态，检查核对证据并批准调整。这项批准必须与工程人员的计数结果分开，也不能由导入成功消息代替；数量一致不构成会计验收。 ### 所有金额差异都必须为零吗？ 执行前先确定精度及获批转换。有些比较必须精确一致，有些需要明确合理的容差或核对调整。每项差异及原因都应保留，不能把相反方向的单据错误抵消成总额零，也不能在发现失败后才设定容差。采用什么规则，需要由负责该业务的人员批准，而非比较程序自行决定。 ### 有意留在档案系统中的历史数据如何验收？ 记录排除的数据范围及其留在操作数据库之外的原因，明确谁能取回，以及历史文档如何关联到已迁移记录。使用预期角色测试访问。验收应保留获批历史方案，不能自行决定法律保留期限，也不能让仍需使用的记录失去访问入口。排除数据需要可审查的安排，不能只是未导入。 ### 附件是按计划重新生成的，应如何比较？ 先约定文件身份判断规则。未改变的原件可以比较内容身份；重新生成的文档可能需要核对必要字段及其所属记录。记录转换和预期差异。如果重新生成已经获批，字节哈希不同本身不能证明文件损坏。验收仍需确认正确文档能够由预期角色获取，并关联到正确业务记录。 ### 检查仍为 NOT_RUN 时，可以批准模板吗？ NOT_RUN 表示该检查尚未记录执行证据，不能当作比较通过。如果上线规则允许某个具体例外，应单独保存授权决定及其影响。不能因为项目需要签字或已有计划日期，就把执行结果改成 PASS。模板格式获得认可，与其中每项控制实际执行并通过，是不同的决定。 ### 运行示例能验证我的 Odoo 数据库吗？ 不能。示例只比较自己的合成 JSON 记录，复现九个指定案例，不连接你的数据库，也不检查会计报表、真实权限或业务流程。可以用它检验验收方案的思路，再调整建议 CSV，并在实际来源快照和目标构建上执行必要检查。模型通过不能替代真实迁移证据或业务批准。 QA 与生产就绪 ## 接下来读什么 可靠生产软件所需的测试、审计、维护与加固。 [从这里开始**AI 生成代码的 QA**](/zh/blog/qa-for-ai-generated-code/) - [README ZIP 恶意软件：审查 AI 工具的实际安装内容](/zh/blog/readme-zip-malware-install-review/) - [AI 生成的 Odoo 模块：先审业务规则，再谈上线](/zh/blog/ai-generated-odoo-module-audit/) - [Odoo AI 智能体测试：验收实际保存的活动记录](/zh/blog/odoo-ai-agent-business-state-tests/) - [Odoo 20 权限迁移：如何验收多公司隔离？](/zh/blog/odoo-20-company-access-migration-tests/) - [Odoo 19 升级 20：AI 工作流要重新验收什么？](/zh/blog/odoo-19-20-ai-upgrade-readiness/) [上一篇文章**AI 生成的 Odoo 模块：先审业务规则，再谈上线**](/zh/blog/ai-generated-odoo-module-audit/) [下一篇文章**Odoo AI 智能体测试：验收实际保存的活动记录**](/zh/blog/odoo-ai-agent-business-state-tests/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-n8n-idempotency-recovery/)