做 Intrastat 最怕的不是字段多，而是字段来源混乱：到底该看公司、仓库，还是发票背后的物流动作？
stock_intrastat 的 _fill_missing_values() 给了一个很清楚的答案。它先调用父类补基础值，然后专门处理 region_code。注释甚至写得很直白：如果仓库上有区域码，应当用仓库区域覆盖公司区域。也就是说，企业版承认“同公司不同仓库”在申报上可能有不同的地理语义。
逻辑顺序也很讲究。系统先把所有仓库捞出来，如果根本没有配置任何 intrastat_region_id，那就不做库存层补值，直接返回父类结果。若所有仓库都落在同一个 region，且每个仓库都已配置，则可以把这一地区代码一次性赋给全部结果，避免逐单追物流。
真正复杂的是多仓多区域场景。源码会按发票去找 _stock_account_get_last_step_stock_moves()，再从第一条 stock move 追到 warehouse_id，若 move 本身没有仓库，再退到 picking_type_id.warehouse_id。最后只有拿到仓库区域码时，才回填 vals['region_code']。这个兜底顺序很典型：先信最近一步库存事实，再信作业类型配置。
stock_warehouse.py 里新增的 intrastat_region_id 也不是随便一个 Many2one。它受公司 fiscal country 约束，只允许选本国或空国家的 region code。换句话说，企业版不是简单给仓库加个备注字段，而是在模型层就把合规边界压进来了。
实施里最容易出问题的地方有两个：一是仓库都没配 region，结果误以为报表会自动从物流猜出来；二是多仓库共公司时，只看公司国家字段，忽略了具体出货仓库才是申报区域来源。前者会让 region_code 留空，后者则会让申报口径错位。
所以库存 Intrastat 的关键，不是“字段补全”本身，而是在公司口径不够细时，优先回到真实仓库与最后一步物流事实去决定申报区域。
DISCUSSION
评论区