--- title: "Odoo 对接 BMD：月度导出核对与导入确认" canonical: https://wavect.io/zh/blog/odoo-bmd-export-reconciliation/ language: zh description: "Odoo 导出总额相符，并不证明 BMD 接收了正确单据。用十三个可运行案例核对身份、金额、贷项、公司和回执，附待执行验收表，明确部分导入后的恢复与财务批准。" image: "https://wavect.io/img/blog/headers/header_odoo-bmd-export-reconciliation.png" author: ["Kevin Riedl"] published: "2026-11-05" updated: "2026-11-05" reviewed: "2026-11-05" --- # Odoo 对接 BMD：月度交接前如何核对导出批次 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-migration-acceptance-reconciliation/) 要点速览 把已批准的 Odoo 源单据与具体导出文件、接收方单据证据对应起来。先比较身份与逐项金额，再看合计；保留贷项和公司边界，部分导入查清后再决定重做什么。可运行模型展示十三个合成案例，另一份验收表中的真实连接器检查尚未执行。 一个虚构导出批次的总额是 300.00 欧元，其中两张单据的金额仍然有错。下面的示例说明：文件已生成、总额也相符，并不能证明交接正确。 **核对 Odoo 到 BMD 的交接，应同时依据已批准的源单据、具体导出配置和接收方的接收证据。**先比较单据身份与逐项金额，再查看汇总值。保留贷项、公司边界和版本变更记录，确认接收方接受了哪些单据之后再关闭交接任务。 **资料核查日期：2026 年 11 月 5 日。**本文参考 Odoo 官方文档、BMD 公开的标准接口课程大纲及针对具体版本的供应商资料。我们运行了十三个合成 Python 比较案例，没有执行真实的 Odoo 导出、BMD 导入、客户账务核查或财务审批。可下载模型使用规范化示例数据，并非 BMD 文件格式实现。 ## Odoo 到 BMD 的交接需要证明什么？ 交接需要分别证明三件事：选中了正确的源数据范围，导出保留了已批准的业务含义，目标系统接受了预定单据。为每个阶段保留标识与证据。下载完成只能说明文件存在；接收方的实际记录才能说明文件到达后发生了什么。不要把这些不同结论压缩成一个含义不明的成功状态。 先请接收团队定义“已接受批次”。它是指单据已准备好等待审核，还是分录已导入指定工作区？记录双方同意的结果。如果双方对“已导入”的理解不同，共用这个状态也无法形成明确交接。 | 边界 | 需要保留的证据 | 回答的问题 | | --- | --- | --- | | 已批准的源数据 | 快照、公司、期间、单据状态与排除项。 | 哪些业务单据应该转移？ | | 生成的批次 | 连接器和配置版本、确切文件标识、逐单据比较。 | 这份导出携带了什么业务含义？ | | 目标结果 | 导入报告、已接受和已拒绝的单据引用、未决项目。 | 接收方接受了哪些预定记录？ | 批次可以通过导出核对，但目标接收情况仍然未知。应明确保留这一状态，并提供双方都能查阅的证据。 ## 你正在验证哪一个连接器和导入配置？ 验证时要明确 Odoo 的版本与版本类型、已安装连接器的具体修订，以及 BMD 接收配置。请负责人用这套组合演示一张有代表性的单据。产品名称本身无法证明目标会如何解释你的记录。保留实际采用的配置和演示结果，后续变更才有可比较的依据。 [MPI 的 BMD 模块页面针对 Odoo 19](https://www.mpi-erp.at/bmd) ，列出了 Enterprise 会计、奥地利本地化和可配置导出列。这是特定版本的供应商说明。如果目标是 Odoo 20，需要另行确认支持情况。 [Odoo 20.0 奥地利本地化文档](https://github.com/odoo/documentation/blob/20.0/content/applications/finance/fiscal_localizations/austria.rst) 介绍会计与报表模块，以及 SAF-T XML 导出。这些功能并不能确定所选 BMD 导入配置要求的文件格式。 [BMD 标准接口课程大纲](https://www.bmd.com/at/akademie/akademieshop/seminar/d/fibu-standardschnittstellen-10943/52) 区分主数据、余额和记账文件导入，并涉及导入错误与提示。大纲不是完整字段规范。实现文件布局前，应向接收方取得适用配置及映射要求。 演示范围应包括需要支持的贷项和更正单据，必要时带上附件。普通发票并不会验证这些路径。记录为使示例成功而在目标端进行的任何人工准备。 如果托管方式或 API 访问决定集成路径，可参考已有的 [Odoo 集成架构指南](/zh/blog/odoo-erp-api-integration-limits-2026/) 。无论由人传递已批准文件，还是由自动流程传输，本文的验收约定都可以保留。 ## 月度导出约定应包含哪些内容？ 导出约定需要固定预定单据范围、已批准的转换规则和目标端所需证据，并明确谁有权修改这些决定。审批应绑定源快照和批次版本。源数据或映射后续发生变化，就要重新审查。这样，批准的是哪份文件、哪些业务含义，才能在交接之后继续查清。 | 决定 | 导出前明确 | 应检查的证据 | | --- | --- | --- | | 数据范围 | 公司、记账期间、允许状态和明确排除项。 | 已批准的源引用与提取参数。 | | 身份 | 稳定源标识、版本和目标引用。 | 每张源单据在整个交接过程中都可追踪。 | | 金额 | 币种、净额／税额／总额口径与约定精度。 | 逐项数值，以及按公司和币种分组的合计。 | | 映射 | 所选配置下已批准的科目、往来方和税务含义。 | 明确的映射版本和负责财务复核的人。 | | 贷项与更正 | 单据关系及接收配置中已批准的处理方式。 | 代表性更正到达预定目标结果。 | | 支持文件 | 必需文件、身份以及授权接收者的访问。 | 正确文件可从正确业务记录中取回。 | | 完成条件 | 接受的含义，以及部分或未知结果的处理方式。 | 绑定本批次及其单据的目标证据。 | 区分单据日期与本次交接使用的期间。决定迟到单据和更正如何进入后续批次，以及由谁批准处理方式。比较器负责检查既定规则，财务负责人负责批准账务处理。 保留可以独立复核的源依据。如果同一段错误转换同时生成导出值和预期值，比较结果就可能与错误一致。先选取源单据，直接对照已批准映射核查，再信任汇总控制。 单据进入系统时尚未解决的决定，由另一篇 [发票异常处理流程](/zh/blog/odoo-invoice-ocr-ai-exception-workflow/) 负责。导出不应把未决的源问题转换成看似合理的目标数值，从而掩盖它。 ## 为什么总额正确仍可能隐藏错误单据？ 方向相反的错误会在相加时抵消，因此正确合计可能掩盖错误单据。记录数量同样丢失了身份信息。应逐张比较已批准源单据与导出对应项，再把分组合计作为额外控制。本合成示例保留三张单据和全部合计，但其中两张单据的净额、总额都存在错误。 | 单据 | 净额 | 税额 | 总额 | | --- | --- | --- | --- | | INV-001 | 100.00 | 20.00 | 120.00 | | INV-002 | 200.00 | 40.00 | 240.00 | | CR-001 | -50.00 | -10.00 | -60.00 | | 合计 | 250.00 | 50.00 | 300.00 | 负数贷项只是示例约定。这些金额没有规定 BMD 的正负号规则，也没有证明税务处理有效。虚构映射标签 `DEMO-MAP-1`不具备账务依据。 现在把第一张发票改成净额 101.00 欧元、总额 121.00 欧元；第二张改成净额 199.00 欧元、总额 239.00 欧元。两张发票的税额和贷项保持不变。净额仍为 250.00 欧元，税额仍为 50.00 欧元，总额仍为 300.00 欧元。每行的净额加税额也仍等于总额。 逐单据比较会发现四处差异：两张发票各有净额、总额两个字段变化。即使合计相符，这些差异也会阻止批次通过。按标识比较仍不能自行确认参考值正确，更不能证明真实会计导出已经通过验证。 ## 十三个已运行模型案例证明了什么？ 十三个案例展示了规范化比较如何区分源差异、没有导入回执的正确候选批次，以及不完整的目标确认。脚本只使用虚构 JSON 单据和 Python 标准库，检查示例定义的规则。它没有解析 BMD 文件，也没有运行 Odoo 或 BMD。因此，结果只适用于所展示的本地模型边界。 | 案例 | 观察结果 | 在模型中的含义 | | --- | --- | --- | | 批次未变且模型回执完整 | ACKNOWLEDGED_IN_MODEL | 参考值、候选批次和虚构回执一致。 | | 没有目标回执 | READY_FOR_IMPORT_REHEARSAL | 候选批次核对通过，但目标接受尚未得到证明。 | | 贷项缺失 | BLOCKED | 缺少一张预期单据。 | | 单据重复 | BLOCKED | 同一个复合源身份出现两次。 | | 金额错误相互抵消 | BLOCKED | 数量和合计一致，四个金额字段却有差异。 | | 公司错误 | BLOCKED | 候选批次包含批准身份范围之外的单据。 | | 记账期间错误 | BLOCKED | 一张单据的期间与已批准源值不同。 | | 币种错误 | BLOCKED | 币种与参考值不同。 | | 映射缺失 | BLOCKED | 必需的虚构映射引用为空。 | | 文件引用缺失 | BLOCKED | 缺少必需支持文件的标签。 | | 导入配置变化 | BLOCKED | 候选批次不再指向已审核的配置。 | | 目标回执不完整 | RECONCILIATION_REQUIRED | 并非所有预定单据都有已接受的目标引用。 | | 回执属于其他内容 | RECONCILIATION_REQUIRED | 回执没有标识当前候选内容。 | 下载 [可运行比较模型](/downloads/odoo-bmd-export-reconciliation/reconcile-export.py) 和 [记录的运行结果](/downloads/odoo-bmd-export-reconciliation/model-results.json) 。保存 Python 文件后执行： ``` python3 reconcile-export.py ``` 十三项预期决定均与本地运行相符。金额按示例的精确比较规则使用十进制运算。内容哈希绑定的是规范化 JSON，而非导出的 BMD 文件。生产流程需要识别实际文件字节和配置，并保留真实的目标单据证据。 附件标签非空，并不能证明接收方取到了正确 PDF。真实验收时应检查文件本身及其与业务记录的关联。 ## 部分导入后应该怎样恢复？ 先确定哪些单据已接受、哪些被拒绝、哪些结果未知，再决定重做什么。根据目标报告和记录引用，与接收负责人约定更正动作。批次级失败消息不代表每张单据都失败；换一个文件名也不会让重复单据变成新的业务事件。恢复决定应以已查清的目标状态为依据。 | 观察情况 | 下一步 | 完成前所需证据 | | --- | --- | --- | | 尚无接收证据 | 索取目标结果，保持接收状态未决。 | 确定是否已有单据被处理。 | | 部分接受、部分拒绝 | 逐张核对处理结果，约定被拒单据如何更正或再次提交。 | 已接受记录得到说明，恢复没有产生未经批准的重复。 | | 中断后导入结果未知 | 再次执行前检查目标记录。 | 动作依据已确认结果，而非对中断的猜测。 | | 批准后源数据或映射变化 | 建立可识别的新版本，重做受影响比较。 | 当前批次有当前审批，并可追溯上一次尝试。 | 不要预设目标支持某种更正、撤销或选择性重放机制。应与接收团队在实际配置下演示双方认可的流程。即使更正后的批次替代了原尝试，也要保留原来的证据。 如果 n8n 负责调度或传输文件，它的执行记录可以证明传输过程。 [n8n 重试与恢复指南](/zh/blog/odoo-n8n-idempotency-recovery/) 解释了稳定业务身份和已知目标结果的重要性。在这里，决定后续动作的证据是接收端每张单据的处理情况。 ## 财务与工程团队分别验收什么？ 工程团队应证明选择、转换、传输和恢复过程可追踪；授权财务负责人应批准映射与结果的账务含义。两类决定分别记录。比较没有差异，不能代替财务批准。模板即使已经获批，其中的检查仍需要在真实系统上执行，才能支持对实际导入行为和交接结果的结论。 [建议的十三项验收表](/downloads/odoo-bmd-export-reconciliation/handoff-acceptance.csv) 初始执行状态为 `NOT_RUN`，财务批准状态为 `PENDING`。实际证据和批准人字段为空。检查涵盖源范围、贷项、重复、金额、公司、期间、币种、映射、文件、版本、部分导入及最终确认。 在受控环境中运行一个普通批次，以及一个刻意安排的接收不完整案例。加入已批准的贷项示例和一张必须继续拦截的单据。让双方仅依据保存的证据，把同一张源单据经由导出批次追踪到目标结果。 一次性系统迁移应使用更完整的 [Odoo 迁移验收框架](/zh/blog/odoo-migration-acceptance-reconciliation/) 。持续运行时，每个月的证据都应与当月批次和未决事项一起保存。连接器或接收配置变化后，应在下一次交接前重做受影响检查。 [上线前 QA 检查表](/zh/software-development-guide/software-qa-checklist-before-launch/) 可以把这些控制纳入整体交付决定。明确谁调查迟迟未到的确认，谁有权批准更正批次，使流程在日常操作人员缺席时仍能执行。 ## 我们会先实施哪一部分？ 先确定一个已批准源范围、一套具体导出配置，以及能指出结果单据的接收确认。自动安排执行时间前，先演示一个正常批次和一次部分失败。当财务与技术负责人都能解释结果，并依据保留证据处理异常时，再扩大支持范围。首个交付应证明这条完整路径，而不是只展示文件下载。 准备采用 Wavect 的 [API 集成服务](/zh/services/api-integration/) 时，可以带来获准使用的样例导出、已批准源单据、接收配置和一个难处理的更正案例。这样第一阶段就有了具体验收问题：双方能否逐张说明本次交接中所有预定单据的结果？ ## Odoo/BMD 导出核对常见问题 ### 普通 CSV 导出就兼容 BMD 吗？ CSV 只是承载数值的容器。兼容性取决于接收配置、必需字段、映射、编码和业务解释。取得这些要求后，应使用代表性单据演示真实导入。本文的规范化 JSON 说明比较规则，不是可以直接上传到 BMD 的文件布局。 ### Odoo 19 连接器能证明兼容 Odoo 20 吗？ 不能。针对具体版本的产品说明只能支持其中声明的范围。请维护方明确支持的版本、版本类型、依赖和连接器修订，再测试实际使用的接收配置。保存这套组合的证据，不要把熟悉的模块名称当作另一个版本的兼容证明。 ### 示例中的负数贷项规定了 BMD 的符号规则吗？ 没有。负数是本合成比较采用的约定。实际单据类型、正负号处理、更正关系和目标结果，都应遵循已批准的连接器配置及财务规则。在接受这部分范围之前，应与接收团队演示一张有代表性的贷项单据。 ### 比较器可以批准税务映射吗？ 它可以检查候选批次是否使用已批准的映射引用和值，却不能判断这些规则是否适用于具体交易。负责财务的人必须批准解释方式和例外。应把这种业务授权，与两个记录相符的技术检查结果分开保存。 ### 有文件引用就证明 PDF 正确吗？ 引用只能证明提交了标签或链接。真实验收需要取回文件，核实它属于预定业务记录，并确认授权接收者能够访问。对保留的原件和有意重新生成的文件，应预先决定比较方式，并把证据与交接记录一起保存。 ### 传输文件成功后就能关闭本期交接吗？ 只有当双方约定的完成条件止于送达，并明确分配后续责任时才可以。如果交接还包括导入接受，应先保留目标结果和未决单据列表。传输成功消息无法证明接收系统创建或接受了哪些会计记录。 ### 下载的 Python 脚本会连接 Odoo 或 BMD 吗？ 不会。它使用 Python 标准库对虚构 JSON 单据运行十三个案例，不需要凭据或网络访问。模型展示逐单据比较和确认边界。可以据此检查控制设计，再使用真实连接器、文件和接收环境执行另一份验收表。 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 迁移验收：逐条核对业务记录与余额](/zh/blog/odoo-migration-acceptance-reconciliation/) - [Odoo AI 智能体测试：验收实际保存的活动记录](/zh/blog/odoo-ai-agent-business-state-tests/) - [Odoo 20 权限迁移：如何验收多公司隔离？](/zh/blog/odoo-20-company-access-migration-tests/) [上一篇文章**Odoo AI 导入映射：核验供应商价格**](/zh/blog/odoo-ai-data-mapping-validation/) [下一篇文章**Lovable 数据暴露：如何验证权限修复？**](/zh/blog/lovable-supabase-data-exposure/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-migration-acceptance-reconciliation/)