本文内容
Odoo 对接 BMD：月度交接前如何核对导出批次
一个虚构导出批次的总额是 300.00 欧元，其中两张单据的金额仍然有错。下面的示例说明：文件已生成、总额也相符，并不能证明交接正确。
核对 Odoo 到 BMD 的交接，应同时依据已批准的源单据、具体导出配置和接收方的接收证据。先比较单据身份与逐项金额，再查看汇总值。保留贷项、公司边界和版本变更记录，确认接收方接受了哪些单据之后再关闭交接任务。
资料核查日期：2026 年 11 月 5 日。本文参考 Odoo 官方文档、BMD 公开的标准接口课程大纲及针对具体版本的供应商资料。我们运行了十三个合成 Python 比较案例，没有执行真实的 Odoo 导出、BMD 导入、客户账务核查或财务审批。可下载模型使用规范化示例数据，并非 BMD 文件格式实现。
Odoo 到 BMD 的交接需要证明什么？
交接需要分别证明三件事：选中了正确的源数据范围，导出保留了已批准的业务含义，目标系统接受了预定单据。为每个阶段保留标识与证据。下载完成只能说明文件存在；接收方的实际记录才能说明文件到达后发生了什么。不要把这些不同结论压缩成一个含义不明的成功状态。
先请接收团队定义“已接受批次”。它是指单据已准备好等待审核，还是分录已导入指定工作区？记录双方同意的结果。如果双方对“已导入”的理解不同，共用这个状态也无法形成明确交接。
| 边界 | 需要保留的证据 | 回答的问题 |
|---|---|---|
| 已批准的源数据 | 快照、公司、期间、单据状态与排除项。 | 哪些业务单据应该转移？ |
| 生成的批次 | 连接器和配置版本、确切文件标识、逐单据比较。 | 这份导出携带了什么业务含义？ |
| 目标结果 | 导入报告、已接受和已拒绝的单据引用、未决项目。 | 接收方接受了哪些预定记录？ |
批次可以通过导出核对，但目标接收情况仍然未知。应明确保留这一状态，并提供双方都能查阅的证据。
你正在验证哪一个连接器和导入配置？
验证时要明确 Odoo 的版本与版本类型、已安装连接器的具体修订，以及 BMD 接收配置。请负责人用这套组合演示一张有代表性的单据。产品名称本身无法证明目标会如何解释你的记录。保留实际采用的配置和演示结果，后续变更才有可比较的依据。
MPI 的 BMD 模块页面针对 Odoo 19，列出了 Enterprise 会计、奥地利本地化和可配置导出列。这是特定版本的供应商说明。如果目标是 Odoo 20，需要另行确认支持情况。
Odoo 20.0 奥地利本地化文档介绍会计与报表模块，以及 SAF-T XML 导出。这些功能并不能确定所选 BMD 导入配置要求的文件格式。
BMD 标准接口课程大纲区分主数据、余额和记账文件导入，并涉及导入错误与提示。大纲不是完整字段规范。实现文件布局前，应向接收方取得适用配置及映射要求。
演示范围应包括需要支持的贷项和更正单据，必要时带上附件。普通发票并不会验证这些路径。记录为使示例成功而在目标端进行的任何人工准备。
如果托管方式或 API 访问决定集成路径，可参考已有的 Odoo 集成架构指南。无论由人传递已批准文件，还是由自动流程传输，本文的验收约定都可以保留。
月度导出约定应包含哪些内容？
导出约定需要固定预定单据范围、已批准的转换规则和目标端所需证据，并明确谁有权修改这些决定。审批应绑定源快照和批次版本。源数据或映射后续发生变化，就要重新审查。这样，批准的是哪份文件、哪些业务含义，才能在交接之后继续查清。
| 决定 | 导出前明确 | 应检查的证据 |
|---|---|---|
| 数据范围 | 公司、记账期间、允许状态和明确排除项。 | 已批准的源引用与提取参数。 |
| 身份 | 稳定源标识、版本和目标引用。 | 每张源单据在整个交接过程中都可追踪。 |
| 金额 | 币种、净额／税额／总额口径与约定精度。 | 逐项数值，以及按公司和币种分组的合计。 |
| 映射 | 所选配置下已批准的科目、往来方和税务含义。 | 明确的映射版本和负责财务复核的人。 |
| 贷项与更正 | 单据关系及接收配置中已批准的处理方式。 | 代表性更正到达预定目标结果。 |
| 支持文件 | 必需文件、身份以及授权接收者的访问。 | 正确文件可从正确业务记录中取回。 |
| 完成条件 | 接受的含义，以及部分或未知结果的处理方式。 | 绑定本批次及其单据的目标证据。 |
区分单据日期与本次交接使用的期间。决定迟到单据和更正如何进入后续批次，以及由谁批准处理方式。比较器负责检查既定规则，财务负责人负责批准账务处理。
保留可以独立复核的源依据。如果同一段错误转换同时生成导出值和预期值，比较结果就可能与错误一致。先选取源单据，直接对照已批准映射核查，再信任汇总控制。
单据进入系统时尚未解决的决定，由另一篇 发票异常处理流程负责。导出不应把未决的源问题转换成看似合理的目标数值，从而掩盖它。
为什么总额正确仍可能隐藏错误单据？
方向相反的错误会在相加时抵消，因此正确合计可能掩盖错误单据。记录数量同样丢失了身份信息。应逐张比较已批准源单据与导出对应项，再把分组合计作为额外控制。本合成示例保留三张单据和全部合计，但其中两张单据的净额、总额都存在错误。
| 单据 | 净额 | 税额 | 总额 |
|---|---|---|---|
| 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 | 回执没有标识当前候选内容。 |
下载可运行比较模型和记录的运行结果。保存 Python 文件后执行：
python3 reconcile-export.py十三项预期决定均与本地运行相符。金额按示例的精确比较规则使用十进制运算。内容哈希绑定的是规范化 JSON，而非导出的 BMD 文件。生产流程需要识别实际文件字节和配置，并保留真实的目标单据证据。
附件标签非空，并不能证明接收方取到了正确 PDF。真实验收时应检查文件本身及其与业务记录的关联。
部分导入后应该怎样恢复？
先确定哪些单据已接受、哪些被拒绝、哪些结果未知，再决定重做什么。根据目标报告和记录引用，与接收负责人约定更正动作。批次级失败消息不代表每张单据都失败；换一个文件名也不会让重复单据变成新的业务事件。恢复决定应以已查清的目标状态为依据。
| 观察情况 | 下一步 | 完成前所需证据 |
|---|---|---|
| 尚无接收证据 | 索取目标结果，保持接收状态未决。 | 确定是否已有单据被处理。 |
| 部分接受、部分拒绝 | 逐张核对处理结果，约定被拒单据如何更正或再次提交。 | 已接受记录得到说明，恢复没有产生未经批准的重复。 |
| 中断后导入结果未知 | 再次执行前检查目标记录。 | 动作依据已确认结果，而非对中断的猜测。 |
| 批准后源数据或映射变化 | 建立可识别的新版本，重做受影响比较。 | 当前批次有当前审批，并可追溯上一次尝试。 |
不要预设目标支持某种更正、撤销或选择性重放机制。应与接收团队在实际配置下演示双方认可的流程。即使更正后的批次替代了原尝试，也要保留原来的证据。
如果 n8n 负责调度或传输文件，它的执行记录可以证明传输过程。n8n 重试与恢复指南解释了稳定业务身份和已知目标结果的重要性。在这里，决定后续动作的证据是接收端每张单据的处理情况。
财务与工程团队分别验收什么？
工程团队应证明选择、转换、传输和恢复过程可追踪；授权财务负责人应批准映射与结果的账务含义。两类决定分别记录。比较没有差异，不能代替财务批准。模板即使已经获批，其中的检查仍需要在真实系统上执行，才能支持对实际导入行为和交接结果的结论。
建议的十三项验收表初始执行状态为 NOT_RUN，财务批准状态为 PENDING。实际证据和批准人字段为空。检查涵盖源范围、贷项、重复、金额、公司、期间、币种、映射、文件、版本、部分导入及最终确认。
在受控环境中运行一个普通批次，以及一个刻意安排的接收不完整案例。加入已批准的贷项示例和一张必须继续拦截的单据。让双方仅依据保存的证据，把同一张源单据经由导出批次追踪到目标结果。
一次性系统迁移应使用更完整的 Odoo 迁移验收框架。持续运行时，每个月的证据都应与当月批次和未决事项一起保存。连接器或接收配置变化后，应在下一次交接前重做受影响检查。
上线前 QA 检查表可以把这些控制纳入整体交付决定。明确谁调查迟迟未到的确认，谁有权批准更正批次，使流程在日常操作人员缺席时仍能执行。
我们会先实施哪一部分？
先确定一个已批准源范围、一套具体导出配置，以及能指出结果单据的接收确认。自动安排执行时间前，先演示一个正常批次和一次部分失败。当财务与技术负责人都能解释结果，并依据保留证据处理异常时，再扩大支持范围。首个交付应证明这条完整路径，而不是只展示文件下载。
准备采用 Wavect 的 API 集成服务时，可以带来获准使用的样例导出、已批准源单据、接收配置和一个难处理的更正案例。这样第一阶段就有了具体验收问题：双方能否逐张说明本次交接中所有预定单据的结果？