本文内容
SAP Business One 迁移 Odoo：历史数据要搬多少？
“把全部历史都搬过去”，听起来比决定留下什么更稳妥。但它仍未回答一个问题：已付款发票应该成为活跃会计记录、客服参考，还是一份可以从档案中找到的原文档？
迁移继续执行获批业务所需的记录，将未结项与商定的期初财务状态协调起来，其余历史通过经过验证的查询路径保留。 每类数据都应按它要支持的工作来选择。年数只是筛选条件，不是完整迁移范围。
资料核查日期：2026年11月5日。 产品边界依据 Odoo 20 官方文档、SAP Business One 公开归档指南及 SAP 知识库公开预览。下文表格和金额均为虚构。我们没有访问企业数据库，也没有执行 SAP 到 Odoo 的迁移。
哪些记录需要在 Odoo 中继续参与业务？
从切换后第一项必须完成的工作开始。列出它依赖的记录及关系，再定义目标系统允许产生的效果。活跃客户、未完成订单和已结清发票可能属于同一段历史，却需要不同的目标位置和验收证据。
| 用途 | 示例 | 允许效果 | 需要的证明 |
|---|---|---|---|
| 继续工作 | 活跃客户和剩余订单明细。 | 支持获批的下一项业务操作。 | 用户能完成该操作，不重复已完成工作。 |
| 建立期初状态 | 未结发票和获批期初余额。 | 将商定财务状态表示一次。 | 财务接受对账结果及目标处理方式。 |
| 查询选定历史 | 某个在用序列号所需的服务记录。 | 提供上下文，不产生未经批准的移动或义务。 | 正确用户能检索关联证据。 |
| 保留旧证据 | 已关闭发票及附件。 | 允许获授权的历史查询。 | 查询演练返回所需原件和上下文。 |
例如，一张未完成订单已有部分明细交付。迁移需要保留剩余工作和足够的解释信息。如果只导入原订单总量，却没有决定已完成部分如何表示，用户可能收到错误的下一步任务。工程师设计导入前，流程负责人应先批准继续处理的行为。
各类去向都应保留来源身份。建议引用可包含源公司、记录类型和源标识。不要假定可见单据号在所有公司数据库中都唯一。明确在哪里维护源记录与目标记录或档案位置的对应关系。
记录实际 SAP Business One 版本、数据库平台、目标 Odoo 版本、已安装应用及相关自定义字段。其他 SAP 产品或其他 Odoo 配置的步骤需要单独核实。本文不证明存在通用转换器，也不确认某个连接器版本兼容。
未结项与期初余额如何协调？
未结项解释尚未完成的财务义务，期初状态描述财务起点。两种表示必须在目标系统中相互协调。加载任一数据集前，应由财务批准处理与对账方式，包括如何识别重复和截点后的变化。导入成功本身不是充分证据。
Odoo 20 期初分录指南提醒，未结单据和期初余额若组合处理不当，可能导致数值重复。
下面是一个虚构控制总额示例，说明迁移范围需要保留什么应收金额。它不规定会计分录、过渡科目、税务处理或过账顺序。
| 源项目 | 剩余金额 | 范围要求 |
|---|---|---|
| INV-A | 15,000 欧元 | 保留客户身份、来源引用和剩余金额。 |
| INV-B | 8,000 欧元 | 为这笔独立项目保留相同类型的证据。 |
| 未结项合计 | 23,000 欧元 | 与财务批准的期初表示对账。 |
| 应拒绝的重复表示 | 23,000 欧元 + 23,000 欧元 = 46,000 欧元 | 同一应收金额不能贡献两次。 |
后续收款可能需要这两张发票。但这不表示可以在没有获批会计处理的情况下，再增加独立的 23,000 欧元。反过来，只有一个汇总金额，也可能让用户无法知道哪张客户单据仍未付款。财务合计和用户任务都需要各自证据。
SAP 的期初余额知识库公开预览也指出，已有过账本身不会阻止继续添加期初余额；已锁定过账期间会形成限制。这是 SAP 行为边界，不能证明 Odoo 具备对应保护。
明确截点。如果获批导出之后 INV-A 发生变化，旧金额就不能证明最终范围。记录更正，并让财务确定要更新哪些证据。不要悄悄修改表格，却继续附上旧版本的批准。
哪些已关闭历史值得放进 Odoo？
只有明确工作需要在 Odoo 内使用历史，且选定表示能够满足需求、不产生意外业务效果时，才将其迁入。要求负责人说明查询或报表任务。保持选择范围有限，并在扩大历史期间之前验证所选表示的实际行为。
支持团队可能要查询与在用序列号关联的服务干预记录；销售可能要在续约前查看旧协议。这些需求值得讨论具体字段和关系，却不能自动证明有必要重新创建所有底层财务交易。
明确历史是作为附件、专用参考记录、报表数据集，还是外部档案链接保存。这些是待评估的设计选项，不是本文承诺可相互替代的原生导入能力。不同选项会影响搜索、权限和维护。
对已付款发票，一个有效验收问题是：授权用户能否找回所需原件和结清背景，又不产生新的应收金额？对已完成交付，则应检查历史查询是否保持当前库存与待交付工作不变。必须在实际配置中观察结果。
如果只需要历史月度趋势，应单独定义报表数据集及对账。此类需求可能无需重放每笔业务单据。若报表还需下钻到原件，范围就必须包含对应查询路径。
可用的历史档案需要什么？
档案需要商定的查询任务、受控访问，以及持续维护该能力的负责人。明确用户如何找到记录、应附带哪些证据，以及访问和恢复如何维持。一个导出文件夹只是候选方案，必须先演示它满足这些要求。
本文的“归档”指项目商定的历史保存去向，并不是要求运行 SAP Data Archive Wizard。SAP Business One 10.0 归档指南描述了该向导不可逆的数据移除，并明确它不支持 Browser Access 和 SAP HANA。
写出另一位人员能够执行的查询任务。例如：“针对公司 A 的发票 PAID-17，找回原件、必需附件，以及说明结清情况的引用。”商定什么算正确结果，并记录各部分所在位置。这只是示例规范，没有实际执行过档案测试。
再用一个可见发票号相同的公司测试。结果必须保持在请求公司的范围内。还应加入附件缺失和用户权限不足的情况。搜索很快，并不代表证据完整，也不保证没有返回另一公司的记录。
明确迁移团队离场后谁维护查询服务，包括访问交接、必要时受支持的运行环境，以及保留材料的恢复演练。取得所选路径所需的合同和许可确认。不能假定旧系统访问会自动延续或免费提供。
实际记录和司法辖区的保留、删除及证据保存义务，应由相应负责人确定。本文不提供统一保留年限。技术查询证据可以支持这一决定，但单凭它不能证明法律合规。
迁移范围登记表应包含什么？
为每个数据集记录业务用途、准确纳入边界、目标去向、允许效果和责任人。补充能证明验收的证据。让排除项足够明确，并对登记表进行版本管理，避免新截点或新增历史期间继承另一范围的批准。
| 字段 | 回答的问题 | 示例内容 |
|---|---|---|
| 数据集与边界 | 包括哪些记录？ | 公司 A，在获批截点仍未结清的客户发票。 |
| 用途与去向 | 用户要用它做什么？ | 使用获批 Odoo 表示继续收款工作。 |
| 允许效果 | 哪些变化获准发生？ | 按获批期初方法，将剩余应收表示一次。 |
| 身份与证据 | 审核人如何追溯记录？ | 公司、源标识、目标引用和对账证据。 |
| 责任与验收 | 谁批准结果？ | 财务批准金额；业务人员演示下一项工作。 |
| 版本与排除项 | 正在接受哪项决定？ | 范围版本、截点及明确排除的已关闭记录。 |
下载建议的历史范围验收登记表。12 个用例涵盖业务延续、两张未结发票、期初协调、选定参考历史及档案查询，还包括截点变化和未经授权重放历史过账的情况。
每行均标为 NOT_RUN。将虚构记录替换为获批测试数据，并附上实际证据后，才能把用例视为已验收。文件是一份初始规范，不是兼容性证明，也不是已经完成的对账。
整体核验可参考Odoo 迁移验收与对账指南。映射建议的验证由AI 数据映射审查另行讨论。范围登记表负责决定这些检查应覆盖哪些记录和业务效果。
范围变化应该如何验收？
把范围变化作为关于依赖记录和目标效果的新决定。说明新增工作、哪些证据已经失效，并在完成修订检查后由相关负责人批准。即使导出查询只改了一点，增加历史年份也可能改变关系及财务行为。
假设有人要求加入较早年份的所有已付款发票。先问用途是客服、报表，还是活跃财务流程，再选择表示方式并检查效果。未结发票测试成功，并不能证明已付款历史可以经同一路径安全重放。
如果无法访问所需来源，应先解决，再承诺历史完整。旧 ERP 访问路径指南讨论这一集成选择。缺少访问应成为有责任人的明确范围依赖，而不是对未来导出内容的隐含假设。
构建导入前应先批准什么？
先批准一份小范围登记表，覆盖首批业务任务、财务认可的期初状态，以及经过演示的历史查询路径。每部分都指定负责人。按该约定构建和评估导入；只有新增用户工作能够证明额外记录与证据的必要性时，再扩大范围。
建议从一条有代表性的未结单据链和一项已关闭历史查询任务开始。它们能尽早区分继续工作、保留财务含义和找回证据这三类验收任务。旧系统现代化评估可把这些决定转为明确的迁移工作包。选择历史保存实现时，可参考标准软件与定制开发决策指南。