跨公司采购链路如果只停在 SO/PO 互生,结算阶段还是会断。企业版 account_inter_company_rules 补上的,正是“销售发票过账后,在对方公司落成采购账单/退款”的后半程。这里已经不只是采购和销售,而是采购、会计和多公司权限一起接力。
account.move._post() 是入口。源公司把销售发票真正过账后,系统才会去找 partner 对应的目标公司,并判断该公司是否启用了 intercompany_generate_bills_refund。也就是说,只有会计事实成立后,采购结算侧才开始生成对账单据。
_inter_company_prepare_invoice_data() 并不是机械复制源发票。它会重新计算目标公司的 fiscal position、切换到 intercompany_purchase_journal_id,并把 invoice_origin、ref、payment_reference 这些追踪信息重新组织成对方公司能理解的账单上下文。这里体现的不是镜像,而是语义重建。
行级别的 _inter_company_prepare_invoice_line_data() 更关键。它要在默认 analytic distribution 模型和源单已有 analytic distribution 之间做优先级处理,还会过滤掉只在源公司有效的分析账户组合。于是采购结算不只是复制金额,还要把能跨公司成立的分析语义带过去,把不能成立的部分挡在外面。
auto_generated 和 auto_invoice_id 则把这段结算链重新纳入可追溯范围。目标公司生成的 bill/refund 不是孤儿单据,而是能明确回指来源发票;同时它们也不会再被当成新源单去触发同类自动生成。
所以跨公司采购结算真正复杂的地方,不在“自动建一张 vendor bill”,而在“谁的会计事实先成立、目标公司用哪本 journal、税位是否重算、分析分布哪些还能合法继承”。这是一条结算重构链,不是一条复制链。
DISCUSSION
评论区