Odoo 企业版 Tax Return 为什么不是“本月做完就行”：期间链、重置限制与前后期提交顺序讲透

很多财务团队把 Tax Return 当成月结附件：本月算完、本月提交。但 account.return 真正维护的是一条连续期间链，后一期是否能提交、前一期是否还能重置，都受整条链约束。

参考入口：

• enterprise/account_reports/models/account_return.py
• enterprise/account_reports/tests/test_account_returns.py

一、后一期不能跳过前一期直接 validate/submit

测试 test_cannot_submit_if_previous_not_submitted 明确证明：如果上一期间还没完成当前应有的提交动作，后一期间不能直接推进。Odoo 不是把每个 return 当孤立单据，而是把它们视为同一种 return type 下的时间序列。

二、前一期也不能随便 reset，尤其在后一期已提交后

test_cannot_reset_if_subsequent_submitted 说明，前一期 return 一旦已有后续期间建立并提交，前一期不能任意 reset common tax return。逻辑很直白：如果允许前面随便重开，后面期间基于什么口径建立就不再可信。

三、锁定日期会参与这条链的稳定性

测试里还会配合 tax_lock_date，因为申报并不是纯报表动作，往往伴随 closing entry 与税务锁定。期间链约束的意义，就是避免你在已被后期引用或已锁定的历史区间反复改口径。

四、这不是“流程麻烦”，而是合规防回写

从实现视角看，Tax Return 更像一个受控状态机 + 期间依赖图：

• 先保证 period continuity；
• 再允许 review / submit / pay；
• 最后通过 reset 限制防止历史重写污染后续期间。

五、实战建议

• 财务排期要按 return type 和 period 排好，不要并行乱做。
• 若发现后一期无法提交，先查前一期状态，不要先怀疑权限。
• 想重开历史期间时，先评估是否已有后续 return、锁定日期和 closing entry 依赖。

六、结论

Tax Return 的核心不是“生成一张申报单”，而是维持期间链的一致性。能不能提、能不能重开，答案永远和前后期有关。