Intrastat 真正麻烦的地方，不在采购单上看到字段，而在发票落地后这些字段还能不能继续支撑申报。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/purchase_intrastat/models/purchase_order.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
purchase_intrastat 看起来只是一个 bridge，但它决定了采购单进入供应商发票时，Intrastat 相关国家与申报字段如何被保留下来，避免后续统计时只剩会计单据而丢失采购来源语义。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 purchase_intrastat 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. 关键入口只有 _prepare_invoice
模块源码极简，正说明它抓的是最关键的桥点：采购转供应商发票时，如果准备值里不带 Intrastat 上下文，后面会计端就无从补救。
2. 采购来源语义必须穿透到会计单据
Intrastat 统计往往在发票或分录侧发起，但采购端才知道交易来源、供应商和业务上下文，所以 bridge 必须在这里做字段传播。
3. 国家/地区边界不是发票后算出来的
如果采购阶段没有把相关国家语义带过去，后面只看 vendor bill 金额无法可靠重建申报口径。
三、最容易被误解的边界
- 觉得 bridge 模块代码少就不重要。
- 等发票生成后再人工补 Intrastat 字段，既慢又容易错。
- 只看会计金额，不追采购来源与国家语义。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先查 purchase order _prepare_invoice 返回值。
- 再核对生成 vendor bill 后相关 Intrastat 字段是否仍在。
- 最后从申报口径反推，确认采购来源没有在桥接时丢失。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
purchase_intrastat 的价值，正是在最短的代码里守住了最容易丢失的“采购来源到会计申报”这段语义。
DISCUSSION
评论区